From nobody Sun Mar 1 18:06: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 495F61A0122 for ; Sun, 1 Mar 2015 18:06:17 -0800 (PST) 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 0MfRnB6Y9WJQ for ; Sun, 1 Mar 2015 18:06:14 -0800 (PST) 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 9ED941A0127 for ; Sun, 1 Mar 2015 18:06:14 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3kwPw309Ktz56H; Mon, 2 Mar 2015 03:06:11 +0100 (CET) Authentication-Results: mx.nohats.ca; dkim=pass reason="1024-bit key; unprotected key" header.d=nohats.ca header.i=@nohats.ca header.b=KWjVX4XY; dkim-adsp=pass 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 uMSvqSom9dSE; Mon, 2 Mar 2015 03:06:09 +0100 (CET) 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, 2 Mar 2015 03:06:09 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id BD7C580416; Sun, 1 Mar 2015 21:06:08 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1425261968; bh=eaquYk777/LB7fmE8nkf6HlUbnJgl906VYCwxifwoeo=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=KWjVX4XYuTZLulBxJbUuFOPiTzsWYxyHfpGFHkL9P8xIe6OUtiNJOsksSx3RMhhZT ETilsPATpMaZ4EfZTTT6oSRctxuAsRskUiHxkMRFQdlj/aH9DETvavkr+6qZ86D8rl kIZTVLzO8IRSCW2hGJC+hV2ST8WQ8/0u1wa8C5qM= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id t22267Rj000577; Sun, 1 Mar 2015 21:06:08 -0500 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Sun, 1 Mar 2015 21:06:07 -0500 (EST) From: Paul Wouters To: Petr Spacek In-Reply-To: <54EF3A7D.6070809@redhat.com> Message-ID: References: <54EF3A7D.6070809@redhat.com> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: dane@ietf.org Subject: Re: [dane] Start of WGLC for draft-ietf-dane-openpgpkey: objection about keyring format documentation X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 02 Mar 2015 02:06:17 -0000 On Thu, 26 Feb 2015, Petr Spacek wrote: > On 20.2.2015 21:30, Warren Kumari wrote: >> Please review this draft to see if you think it is ready for >> publication and send comments to the list, clearly stating your view. > > IMHO current version *should be rejected* because further clarification to > keyring format is needed. > > See previous discussion on > http://www.ietf.org/mail-archive/web/dane/current/msg07227.html > > As I already said, I believe that -01 version does not define an interoperable > standard. It was suggested you would raise this on the openpgp email list. It seems you have not done so. The interoperable standard is defined in RFC 4880, the OpenPGP Message Format. This document references that RFC for the keyring format. If you think that reference is insufficient, I suggest you take this up on the ietf openpgp email list and see about writing a 4880bis document that further clarifies the keyring format. It is not up to this document to rewrite or update RFC 4880. > Current format of records can stay as is but it has to be clearly documented > so we do not rely on current GPG implementation. In my opinion, it is documented in RFC 4880. Whether or not that is "clearly" is a subjective matter, and something that should be taken to the OpenPGP list. > 'It is beyond the scope of this standard to discuss the details of keyrings or > other databases.' is simply not sufficient. I believe it is. Paul From nobody Mon Mar 2 05:03: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 E09371A874D for ; Mon, 2 Mar 2015 05:03:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.911 X-Spam-Level: X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_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 7QwpdJMyyamO for ; Mon, 2 Mar 2015 05:02:59 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (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 27DE51A874A for ; Mon, 2 Mar 2015 05:02:59 -0800 (PST) Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t22D2wa8022525 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Mon, 2 Mar 2015 08:02:58 -0500 Received: from pspacek.brq.redhat.com (pspacek.brq.redhat.com [10.34.128.7]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t22D2uth016209 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Mon, 2 Mar 2015 08:02:57 -0500 Message-ID: <54F45F80.3070000@redhat.com> Date: Mon, 02 Mar 2015 14:02:56 +0100 From: Petr Spacek Organization: Red Hat User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Paul Wouters References: <54EF3A7D.6070809@redhat.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27 Archived-At: Cc: dane@ietf.org Subject: Re: [dane] Start of WGLC for draft-ietf-dane-openpgpkey: objection about keyring format documentation X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 02 Mar 2015 13:03:07 -0000 On 2.3.2015 03:06, Paul Wouters wrote: > On Thu, 26 Feb 2015, Petr Spacek wrote: > >> On 20.2.2015 21:30, Warren Kumari wrote: >>> Please review this draft to see if you think it is ready for >>> publication and send comments to the list, clearly stating your view. >> >> IMHO current version *should be rejected* because further clarification to >> keyring format is needed. >> >> See previous discussion on >> http://www.ietf.org/mail-archive/web/dane/current/msg07227.html >> >> As I already said, I believe that -01 version does not define an interoperable >> standard. > > It was suggested you would raise this on the openpgp email list. It > seems you have not done so. Right, I did not do so because I do not think it is the right approach. draft-ietf-dane-openpgpkey does not require general-purpose keyring format because it is very limited in its scope (no private keys, no secret keys etc.). I believe that for this reason the draft should not depend on/wait for 4880bis (which could be a huge effort). IMHO the draft should rather define stripped-down version of keyring tailored for this particular purpose. I was hoping that you already defined the format internally in your tool 'openpgpkey' but apparently it is not the case. Looking at the code, it does basically this (Python pseudo-code follows): gpgdisk = gnupg.GPG() disk_keys = gpgdisk.list_keys() for pgpkey in disk_keys: # pick the right key here ekey = gpgdisk.export_keys(pgpkey["keyid"], ...) It effectively means that you are going to output anything which was returned by current version of GnuPG Python bindings. - Looking at documentation for Python bindings, it does not say any word about output format. - Looking into the binding, it basically calls 'gpg --export' and returns what was returned by gpg binary. - Looking at 'man gpg', it does not define output format for --export. Please note that at this point already jumped though 4 hoops to find out the format of the data and found nothing. That is not what I call interoperable standard, sorry! To be constructive, it is possible to examine what GnuPG spitted out using: $ gpg --list-packets /tmp/what_you_exported_before :public key packet: version 4, algo 1, created 1412325631, expires 0 pkey[0]: [4096 bits] pkey[1]: [17 bits] keyid: 10587E881CB2BB71 :user ID packet: "Petr \xc5\xa0pa\xc4\x8dek " :signature packet: algo 1, keyid 10587E881CB2BB71 version 4, created 1412325631, md5len 0, sigclass 0x13 digest algo 2, begin of digest d2 11 hashed subpkt 2 len 4 (sig created 2014-10-03) hashed subpkt 27 len 1 (key flags: 03) hashed subpkt 11 len 5 (pref-sym-algos: 9 8 7 3 2) hashed subpkt 21 len 5 (pref-hash-algos: 8 2 9 10 11) hashed subpkt 22 len 3 (pref-zip-algos: 2 3 1) hashed subpkt 30 len 1 (features: 01) hashed subpkt 23 len 1 (key server preferences: 80) subpkt 16 len 8 (issuer key ID 10587E881CB2BB71) data: [4096 bits] :public sub key packet: version 4, algo 1, created 1412325631, expires 0 pkey[0]: [4096 bits] pkey[1]: [17 bits] keyid: E52EB436C0C402E3 :signature packet: algo 1, keyid 10587E881CB2BB71 version 4, created 1412325631, md5len 0, sigclass 0x18 digest algo 2, begin of digest 22 98 hashed subpkt 2 len 4 (sig created 2014-10-03) hashed subpkt 27 len 1 (key flags: 0C) subpkt 16 len 8 (issuer key ID 10587E881CB2BB71) data: [4096 bits] *This* can be standardized with small effort (in comparison with 4880bis) by listing expected packet types and by referencing RFC4880: The rough idea is to say something like this: The blob contains sequence consisting of 1) Public-Key Packet (Tag 6, section 5.5.1.1) 2) (non-empty?) sequence consisting of -- User ID Packet (Tag 13, section 5.11) which identifies the previous key -- Signature Packet (Tag 2, section 5.2) (+ signature over what with what key - maybe over preceding User ID?) 3) Signature Packet (Tag 2, section 5.2) (+ signature over what with what key - maybe over whole previous sequence? see sigclass 0x13) 4) (non-empty?) sequence consisting of - Public-Subkey Packet (Tag 14, section 5.5.1.2) -- Signature Packet (Tag 2, section 5.2) (+ signature over what with what key - maybe sign previous block with master key? see sigclass 0x18) You can see that even with current version of GnuPG at hand it is not 100% obvious what the data actually contain and how it should be interpreted. Also, please note that I did not try to export a public key with multiple user-IDs or subkeys but it would certainly be more messy. > The interoperable standard is defined in RFC 4880, the OpenPGP Message > Format. This document references that RFC for the keyring format. If you > think that reference is insufficient, I suggest you take this up on the I believe that the example above sufficiently demonstrates that it is hard to write a client which would interpret content of OPENGPGKEY records without actually using GnuPG's code. > ietf openpgp email list and see about writing a 4880bis document that > further clarifies the keyring format. As I said above, I do not think we need 4880bis because generic keyring format is overkill for simple application as OPENPGPKEY. > It is not up to this document to rewrite or update RFC 4880. Sure, but I'm not proposing that :-) I'm saying that this draft should clearly state what RFC 4880 packets are expected in OPENPGPKEY blob, in what order, and what has to be signed by which key (define expected sigclasses etc.). >> Current format of records can stay as is but it has to be clearly documented >> so we do not rely on current GPG implementation. > > In my opinion, it is documented in RFC 4880. Whether or not that is > "clearly" is a subjective matter, and something that should be taken > to the OpenPGP list. There is no room for subjectivity. Please imagine that you are going to write a new version of opengpgkey utility - without looking at GnuPG code and in a way which has to be interoperable with current version of the utility. You will see if RFC 4880 is sufficient or not. >> 'It is beyond the scope of this standard to discuss the details of keyrings or >> other databases.' is simply not sufficient. > > I believe it is. Hmm ... Are you saying that you and others are able to implement equivalent of 'opengpgkey' utility without using existing GnuPG bindings/code? Or a Thunderbird extension which would import keys and sign emails? -- Petr Spacek @ Red Hat From nobody Wed Mar 4 18:37: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 6FE911A8F4B; Wed, 4 Mar 2015 18:37:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u8fH8vA6CEUY; Wed, 4 Mar 2015 18:37:05 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 444EE1AD1DB; Wed, 4 Mar 2015 18:36:59 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 5.12.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150305023659.23712.38428.idtracker@ietfa.amsl.com> Date: Wed, 04 Mar 2015 18:36:59 -0800 Archived-At: Cc: dane@ietf.org Subject: [dane] I-D Action: draft-ietf-dane-smtp-with-dane-15.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2015 02:37:06 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS-based Authentication of Named Entities Working Group of the IETF. Title : SMTP security via opportunistic DANE TLS Authors : Viktor Dukhovni Wes Hardaker Filename : draft-ietf-dane-smtp-with-dane-15.txt Pages : 33 Date : 2015-03-04 Abstract: This memo describes a downgrade-resistant protocol for SMTP transport security between Mail Transfer Agents (MTAs) based on the DNS-Based Authentication of Named Entities (DANE) TLSA DNS record. Adoption of this protocol enables an incremental transition of the Internet email backbone to one using encrypted and authenticated Transport Layer Security (TLS). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dane-smtp-with-dane/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dane-smtp-with-dane-15 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-dane-smtp-with-dane-15 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Mar 5 05:07:24 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4504C1A8820 for ; Thu, 5 Mar 2015 05:07:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.611 X-Spam-Level: X-Spam-Status: No, score=-0.611 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gdkCFg6_i1gi for ; Thu, 5 Mar 2015 05:07:22 -0800 (PST) Received: from ore.jhcloos.com (ore.jhcloos.com [198.147.23.85]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CBA121A0318 for ; Thu, 5 Mar 2015 05:06:47 -0800 (PST) Received: by ore.jhcloos.com (Postfix, from userid 10) id 3BFC21EEEF; Thu, 5 Mar 2015 13:06:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=ore14; t=1425560807; bh=COsjOTsLXZ4psPv8DhFPUA7Uy3QC+73ZDBq5qBnQP+4=; h=From:To:Subject:In-Reply-To:References:Date:From; b=GUc7LVVePBbYtxeWTOUJoccy6iqx1o61S33hHKl6fMUtFxlqoL+Pvq7l/yVv5+Gw3 1Y+JvNhyupZDj57YzHJNXBEppvot2z9qgyB0qp8N/cBpvRnezi4I1mErCLeS2ZsjgX 6iSc+5FVVj9NbkxqBL4d1N77pLFdcrP8CNm1Od8c= Received: by carbon.jhcloos.org (Postfix, from userid 500) id 9BF6D106F92D6; Thu, 5 Mar 2015 13:06:38 +0000 (UTC) From: James Cloos To: dane@ietf.org In-Reply-To: <20150305023659.23712.38428.idtracker@ietfa.amsl.com> (internet-drafts@ietf.org's message of "Wed, 04 Mar 2015 18:36:59 -0800") References: <20150305023659.23712.38428.idtracker@ietfa.amsl.com> User-Agent: Gnus/5.130012 (Ma Gnus v0.12) Emacs/25.0.50 (gnu/linux) 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 Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC Date: Thu, 05 Mar 2015 08:06:38 -0500 Message-ID: Lines: 7 MIME-Version: 1.0 Content-Type: text/plain X-Hashcash: 1:28:150305:dane@ietf.org::z+icP0Ek8PMM+A6w:0000kdN9 Archived-At: Subject: Re: [dane] I-D Action: draft-ietf-dane-smtp-with-dane-15.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2015 13:07:23 -0000 I only looked at the changes URL. +1 on the new language. -JimC -- James Cloos OpenPGP: 0x997A9F17ED7DAEA6 From nobody Sun Mar 8 18:04: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 9FCFB1A0069 for ; Sun, 8 Mar 2015 18:04:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.552 X-Spam-Level: X-Spam-Status: No, score=0.552 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 p0jyzDEQTBOT for ; Sun, 8 Mar 2015 18:04:26 -0700 (PDT) Received: from proper.com (Opus1.Proper.COM [207.182.41.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A7FB91A0052 for ; Sun, 8 Mar 2015 18:04:26 -0700 (PDT) Received: from [10.20.30.101] (50-1-99-2.dsl.dynamic.fusionbroadband.com [50.1.99.2]) (authenticated bits=0) by proper.com (8.15.1/8.14.9) with ESMTPSA id t2914PNm091083 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 8 Mar 2015 18:04:26 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: proper.com: Host 50-1-99-2.dsl.dynamic.fusionbroadband.com [50.1.99.2] claimed to be [10.20.30.101] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Paul Hoffman In-Reply-To: <54EF3A7D.6070809@redhat.com> Date: Sun, 8 Mar 2015 18:04:25 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <8CB4E1AD-35C6-4A92-97ED-CC2853C2896C@vpnc.org> References: <54EF3A7D.6070809@redhat.com> To: dane WG list X-Mailer: Apple Mail (2.2070.6) Archived-At: Subject: Re: [dane] Start of WGLC for draft-ietf-dane-openpgpkey: objection about keyring format documentation X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 09 Mar 2015 01:04:27 -0000 On Feb 26, 2015, at 7:23 AM, Petr Spacek wrote: > The main problem is that > http://tools.ietf.org/html/draft-ietf-dane-openpgpkey-01#section-2.1 > 2.1. The OPENPGPKEY RDATA component > The RDATA (or RHS) of an OPENPGPKEY Resource Record contains a single > value consisting of a [RFC4880] formatted OpenPGP public keyring. >=20 > references >=20 > http://tools.ietf.org/html/rfc4880#section-3.6 > 3.6. Keyrings > A keyring is a collection of one or more keys in a file or database. > Traditionally, a keyring is simply a sequential list of keys, but may > be any suitable database. It is beyond the scope of this standard to > discuss the details of keyrings or other databases. >=20 > and this definitely is not a definition you could use for = implementation. I fully agree on this. In fact, I think I brought the lack of interop up = during the discussion leading up to RFC 2440, and was told that it was = too late to change. (To be fair, we used the "too late to change" phrase = a lot leading up to the spec for S/MIME v2. Ah, those carefree '90s.) Proposal: this draft should specify that the contents of the RDATA is a = single public key, defined in Section 5.5.1.1 of RFC 4880. Are there = common cases where this is not sufficient? --Paul Hoffman= From nobody Sun Mar 8 18:12: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 DD1AA1A0052 for ; Sun, 8 Mar 2015 18:12:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.552 X-Spam-Level: X-Spam-Status: No, score=0.552 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, 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 xZuX24odfUjl for ; Sun, 8 Mar 2015 18:12:12 -0700 (PDT) Received: from proper.com (Opus1.Proper.COM [207.182.41.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A6441A004D for ; Sun, 8 Mar 2015 18:12:12 -0700 (PDT) Received: from [10.20.30.101] (50-1-99-2.dsl.dynamic.fusionbroadband.com [50.1.99.2]) (authenticated bits=0) by proper.com (8.15.1/8.14.9) with ESMTPSA id t291CBPv091186 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 8 Mar 2015 18:12:11 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: proper.com: Host 50-1-99-2.dsl.dynamic.fusionbroadband.com [50.1.99.2] claimed to be [10.20.30.101] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Paul Hoffman In-Reply-To: Date: Sun, 8 Mar 2015 18:12:10 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: dane@ietf.org X-Mailer: Apple Mail (2.2070.6) Archived-At: Subject: Re: [dane] Start of WGLC for draft-ietf-dane-openpgpkey - *please* review. X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 09 Mar 2015 01:12:13 -0000 Here are some (admittedly late) comments that have not been brought up = on earlier threads on this document. Introduction: To obtain that public key, two problems need to be solved by the sender's email client, MUA or MTA. An Oxford comma is very much needed in that sentence. The following will cause problems: This trust model is not meant to replace the "web of trust" model. You either need to define that model (since it is not defined in any = other RFC), or delete the sentence. I strongly support the latter = action. In Section 3, item #2 is not really an item, it is a continuation of the = preceding item. There are only three steps here, not 4. --Paul Hoffman= From nobody Sun Mar 8 18:27: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 63E481A006F for ; Sun, 8 Mar 2015 18:27:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 754BA0Y7sf4c for ; Sun, 8 Mar 2015 18:27:33 -0700 (PDT) Received: from orthanc.ca (orthanc.ca [IPv6:2607:f2f8:abf8::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A4431A004D for ; Sun, 8 Mar 2015 18:27:33 -0700 (PDT) Received: from [192.168.42.6] (d66-183-211-183.bchsia.telus.net [66.183.211.183]) (authenticated bits=0) by orthanc.ca (8.14.7/8.14.7) with ESMTP id t291RVIe061910 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 8 Mar 2015 18:27:32 -0700 (PDT) (envelope-from lyndon@orthanc.ca) Content-Type: multipart/signed; boundary="Apple-Mail=_5B7B4826-C975-4C45-87CF-6B4546D505FF"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Lyndon Nerenberg In-Reply-To: Date: Sun, 8 Mar 2015 18:27:30 -0700 Message-Id: <3D4A757A-893D-498C-A022-B436FB0FEBE7@orthanc.ca> References: To: Paul Hoffman X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: dane@ietf.org Subject: Re: [dane] Start of WGLC for draft-ietf-dane-openpgpkey - *please* review. X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 09 Mar 2015 01:27:34 -0000 --Apple-Mail=_5B7B4826-C975-4C45-87CF-6B4546D505FF Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii On Mar 8, 2015, at 6:12 PM, Paul Hoffman wrote: > sender's email client, MUA or MTA. > An Oxford comma is very much needed in that sentence. If we're copy editing, "email client" and "MUA" are redundant. --Apple-Mail=_5B7B4826-C975-4C45-87CF-6B4546D505FF 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----- iQIcBAEBAgAGBQJU/PcCAAoJEG8PnXiV/JnUV+4P/RdLnXjjldrKIewQD5GYCHQ1 ZSBW4amEA4do3Lve+40BWl6rR97S6UZY2FITwmcg2LXT2+EOutMejKTKf6Y25rVU pc8F4PIs3OTM0FUFYu1fsKpKP2IOPFxqiZHip4WocyC5fyWrFAvutEWwToORaXTS 862hEmfwNn+djl6r1Osfhwpx+XEh9Xhrum42dWLyRTV8InfVBxep6NLRaceskwvi IMwd/+rWduSOz8ADGNQUOJa4AlRolk9R59wWMtqNNbKfmLm4dcTSCZtO9tJQSWKf E64+sHZIbdz8wKZ36sUfJ5lZnihCJ8rnR+Yq/9Fym4aBwVJdO4uRxSSLNEzym4Pq 197G39RIqSbtTSofGAsWQrMyE2lbwQICb8Rafy1CX+h6gFVE4UFFRlyOg+tkIkF5 cjjmB2dViYuKNV+HIjo7sygXUostwmqnjpojpneqKmxdKvZc1d/UXuIIQ4Sda+3O S0+yiHWyfcg9TDr+lcEz8gsV6keMpGPQOHYCatN49mEAIKLQ/vGf7gDmRRgCyQYU Ia6sMoiE9S43rvB3zULRSS8/WmeJVjErqGv3dalqP7MEs+Vqco/1jFJ7GzUuTkQ2 YDVFMxaZ7IfElmih4I2Darhpay+MxZxeYMc6ZVZWMrWUKGPibikt9O/ZlKT2u6vG TdkCsI5+7ZclO4pzp3ix =euVr -----END PGP SIGNATURE----- --Apple-Mail=_5B7B4826-C975-4C45-87CF-6B4546D505FF-- From nobody Sun Mar 8 20:10: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 C16DE1A0A6A for ; Sun, 8 Mar 2015 20:10:18 -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 adq9qndiMTgj for ; Sun, 8 Mar 2015 20:10:17 -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 520BF1A07BD for ; Sun, 8 Mar 2015 20:10:17 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3l0l0h4f1xzpP; Mon, 9 Mar 2015 04:10:12 +0100 (CET) Authentication-Results: mx.nohats.ca; dkim=pass reason="1024-bit key; unprotected key" header.d=nohats.ca header.i=@nohats.ca header.b=n+/bz2L2; dkim-adsp=pass 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 Qq4dINcbWSi5; Mon, 9 Mar 2015 04:10:12 +0100 (CET) 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, 9 Mar 2015 04:10:11 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 1EAA2803E0; Sun, 8 Mar 2015 23:10:11 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1425870611; bh=wlPJ9HIPlSANPbdrNY0VMppiR72g7ei3VvEWzH8HAr8=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=n+/bz2L2gwFP+WNsN2XMa7zpnl2btprXAVqrrXzkUzSpPVE1X+iyFZKfxs++svYz1 5lqmpvGhPj622P+TBIdIe4ZVbP77KSYe2SFRxtZrCUUQXYu/hBnpeO0DW38gqzdJl1 VW+osm1rkzbjmfRX7Di6QZbneE0SR4wxtgQ6iVOs= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id t293AAjE021982; Sun, 8 Mar 2015 23:10:10 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Sun, 8 Mar 2015 23:10:10 -0400 (EDT) From: Paul Wouters To: Paul Hoffman In-Reply-To: <8CB4E1AD-35C6-4A92-97ED-CC2853C2896C@vpnc.org> Message-ID: References: <54EF3A7D.6070809@redhat.com> <8CB4E1AD-35C6-4A92-97ED-CC2853C2896C@vpnc.org> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: dane WG list Subject: Re: [dane] Start of WGLC for draft-ietf-dane-openpgpkey: objection about keyring format documentation X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 09 Mar 2015 03:10:19 -0000 On Sun, 8 Mar 2015, Paul Hoffman wrote: > Proposal: this draft should specify that the contents of the RDATA is a single public key, defined in Section 5.5.1.1 of RFC 4880. Are there common cases where this is not sufficient? I'm okay with that. Will put into the -02 version. Paul From nobody Mon Mar 9 00:30: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 94E021A0419 for ; Sun, 8 Mar 2015 19:59:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h_zsuxrvbar0 for ; Sun, 8 Mar 2015 19:58:59 -0700 (PDT) Received: from st11p01mm-asmtp002.mac.com (st11p01mm-asmtp002.mac.com [17.172.204.237]) (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 F318B1A0104 for ; Sun, 8 Mar 2015 19:58:58 -0700 (PDT) Received: from [10.0.23.34] (media.merrymeet.com [173.164.244.98]) by st11p01mm-asmtp002.mac.com (Oracle Communications Messaging Server 7.0.5.35.0 64bit (built Dec 4 2014)) with ESMTPSA id <0NKX006FJCA8TO00@st11p01mm-asmtp002.mac.com> for dane@ietf.org; Mon, 09 Mar 2015 02:58:58 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.13.68,1.0.33,0.0.0000 definitions=2015-03-09_01:2015-03-06,2015-03-08,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1412110000 definitions=main-1503090032 Content-type: text/plain; charset=utf-8 MIME-version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Jon Callas In-reply-to: <8CB4E1AD-35C6-4A92-97ED-CC2853C2896C@vpnc.org> Date: Sun, 08 Mar 2015 19:58:55 -0700 Content-transfer-encoding: quoted-printable Message-id: <8BFE8BFB-2F40-46C8-8FA4-A1BC5D9C3847@icloud.com> References: <54EF3A7D.6070809@redhat.com> <8CB4E1AD-35C6-4A92-97ED-CC2853C2896C@vpnc.org> To: Paul Hoffman X-Mailer: Apple Mail (2.2070.6) Archived-At: X-Mailman-Approved-At: Mon, 09 Mar 2015 00:30:28 -0700 Cc: Jon Callas , dane WG list Subject: Re: [dane] Start of WGLC for draft-ietf-dane-openpgpkey: objection about keyring format documentation X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 09 Mar 2015 02:59:00 -0000 > On Mar 8, 2015, at 6:04 PM, Paul Hoffman = wrote: >=20 > I fully agree on this. In fact, I think I brought the lack of interop = up during the discussion leading up to RFC 2440, and was told that it = was too late to change. (To be fair, we used the "too late to change" = phrase a lot leading up to the spec for S/MIME v2. Ah, those carefree = '90s.) To be fair here =E2=80=94 back in the carefree '90s, we were *forbidden* = from being a "PKI" because there already was one, and it was PKIX. Despite that, if you look at section 3.6 of RFC 4880, you will see in = its entirety: 3.6. Keyrings A keyring is a collection of one or more keys in a file or database. Traditionally, a keyring is simply a sequential list of keys, but may be any suitable database. It is beyond the scope of this standard to discuss the details of keyrings or other databases. The second sentence of that, "...a keyring is simply a sequential list = of keys..." is in fact the *exact* definition of a keyring. The sentence = adverb in that sentence, "Traditionally," is the weasel word that = satisfies the requirement not to be a PKI. If you add in the last = sentence of the paragraph, it seals the deal. All you need else to do is to follow the SHOULD in the Trust Packet = section (5.10) and of course interpret a "local" signature as well, = local. Poof, you=E2=80=99re done. Jon From nobody Mon Mar 9 08:46: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 B82361A8A8D for ; Mon, 9 Mar 2015 08:45:58 -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 2tCpy3-hiMfh for ; Mon, 9 Mar 2015 08:45:56 -0700 (PDT) Received: from mail-wi0-f181.google.com (mail-wi0-f181.google.com [209.85.212.181]) (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 0C79A1A903F for ; Mon, 9 Mar 2015 08:43:10 -0700 (PDT) Received: by widex7 with SMTP id ex7so21196716wid.3 for ; Mon, 09 Mar 2015 08:43:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=4v+YzRKgl2AhaVD/WTeb+IhIZ83BLyplCDcQ9O/rH4c=; b=J5ObaLJH8O6UTxWEooe3nZpXAV3IuYchVtdWYQLl8p01GMUMGvDnncRRlpW+zMC5It eHl38UctWjIUld42DQ0icQsbq188+Q1Hw4F0nF1K8PE05/KbE/p4II7OARjeHnuRHKFd DfWhSIgTwOHp+89mx+eAEdbvU/rty7zFqm1esDBLh+5UXyV41pqsUrfJLnhaajb3tflE IxwaPtupxNhh1svd5wUsHUwwG3ybQGUHkX0qQj+51Ma1nUky5oLBirdGF6tXKNP041dX c48353rH2zmGfVv0q8o067UEyQMayZ5kSTJsefsTFBkZQGXt1JDoXH6QsYz/2w4HfAz7 f2DA== X-Gm-Message-State: ALoCoQnQM8/sG4DqOycnNSjC5xabpPmvsc9yxCnZ1FXSKJWFp/0aPEIAjniE7AJBKWWxcNqB9ku/ MIME-Version: 1.0 X-Received: by 10.194.63.16 with SMTP id c16mr60178760wjs.117.1425915788510; Mon, 09 Mar 2015 08:43:08 -0700 (PDT) Received: by 10.194.110.97 with HTTP; Mon, 9 Mar 2015 08:43:08 -0700 (PDT) In-Reply-To: References: Date: Mon, 9 Mar 2015 11:43:08 -0400 Message-ID: From: Warren Kumari To: "" , draft-ietf-dane-openpgpkey@tools.ietf.org, DANE-chairs Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [dane] Start of WGLC for draft-ietf-dane-openpgpkey - *please* review. X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 09 Mar 2015 15:45:58 -0000 [ Top post ] So, we have had a reasonable amount of discussion here, but only from a limited number of participants. In many cases it is unclear to me if people are OK with progressing hte document (once their comments are addressed), or if they dislike the document... So, I'm extending this till this Friday (Friday the 13th!). Paul W will also be releasing a new version of this document with many of the comments integrated. Can people please have a look at the new version (I think it will be out in a few hours), and let me know if: A: their comments / issues have been addressed, and B: are you OK with the general document? A clear "Yes, this is good" or "No, worst idea ever" would be useful. I'd really like more then 3 or 4 people commenting. W On Fri, Feb 20, 2015 at 3:30 PM, Warren Kumari wrote: > Dear DANE WG, > > The author of draft-ietf-dane-openpgpkey has indicated that he > believes that the document is ready for Working Group Last Call. > The draft is available here: > https://datatracker.ietf.org/doc/draft-ietf-dane-openpgpkey/ > > This document has been discussed a number of times, to jog your > memory, here is one slidedeck: > http://www.ietf.org/proceedings/89/slides/slides-89-dane-2.pdf > Also, a cute trick: dig type61 $(echo -n pwouters| sha224sum | sed "s/ > .*$//")._openpgpkey.fedoraproject.org |grep TYPE61 | sed > "s/^.*TYPE61.*\\\#[0-9]* //" | grep -v ";" | sed "s/ //g" | xxd -r -p > | gpg --import --dry-run > > > Please review this draft to see if you think it is ready for > publication and send comments to the list, clearly stating your view. > > This WGLC ends Fri 06-Mar-2015. > > > > In addition, to satisfy RFC 6702 ("Promoting Compliance with > Intellectual Property Rights (IPR)"): > Are you personally aware of any IPR that applies to > draft-ietf-dane-openpgpkey? If so, has this IPR been disclosed in > compliance with IETF IPR rules? (See RFCs 3979, 4879, 3669, and 5378 > for more details.) > > Thanks, > Warren Kumari > (as DANE WG co-chair) > > -- > I don't think the execution is relevant when it was obviously a bad > idea in the first place. > This is like putting rabid weasels in your pants, and later expressing > regret at having chosen those particular rabid weasels and that pair > of pants. > ---maf -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf From nobody Mon Mar 9 08:54:41 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34FDE1A8731; Mon, 9 Mar 2015 08:54:38 -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 fvTgQUzGItwQ; Mon, 9 Mar 2015 08:54:37 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 147711A87A4; Mon, 9 Mar 2015 08:54:20 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 5.12.0.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150309155420.8070.55482.idtracker@ietfa.amsl.com> Date: Mon, 09 Mar 2015 08:54:20 -0700 Archived-At: Cc: dane@ietf.org Subject: [dane] I-D Action: draft-ietf-dane-openpgpkey-02.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, 09 Mar 2015 15:54:38 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS-based Authentication of Named Entities Working Group of the IETF. Title : Using DANE to Associate OpenPGP public keys with email addresses Author : Paul Wouters Filename : draft-ietf-dane-openpgpkey-02.txt Pages : 9 Date : 2015-03-09 Abstract: OpenPGP is a message format for email (and file) encryption, that lacks a standardized lookup mechanism to obtain OpenPGP public keys. This document specifies a method for securely publishing and locating OpenPGP public keys in DNS using a new OPENPGPKEY DNS Resource Record. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dane-openpgpkey/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dane-openpgpkey-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-dane-openpgpkey-02 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 Mon Mar 9 08:59:24 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 002891A8A99 for ; Mon, 9 Mar 2015 08:59:23 -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 A8vyVvz7LKAb for ; Mon, 9 Mar 2015 08:59:21 -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 1B18D1A8AF7 for ; Mon, 9 Mar 2015 08:59:09 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3l143r5JMkzpC; Mon, 9 Mar 2015 16:59:04 +0100 (CET) Authentication-Results: mx.nohats.ca; dkim=pass reason="1024-bit key; unprotected key" header.d=nohats.ca header.i=@nohats.ca header.b=SD/74mvI; dkim-adsp=pass 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 GqG49Drv_21y; Mon, 9 Mar 2015 16:59:03 +0100 (CET) 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, 9 Mar 2015 16:59:03 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 4D96D803E0; Mon, 9 Mar 2015 11:59:02 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1425916742; bh=595vVyxFq/KrGju4zrYoSXbmYaPZtuMDgUWRA8p7mko=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=SD/74mvIxWzim0k1f5HLvCesCPJBO06BCPXqk8mS9GB97O9MpCS6NJ6UViP9Mkq1c bOsb6s2LR1SC+Uw3bCAAvZiiN2F+Hhlcwgkqrsp31Epgn4w0UC5m76xNG+ry9PCBwB 2lw2fdNXpP/KpByg0fIzmW7vNHq8nw6Bu3OaPFKk= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id t29Fx1VP023350; Mon, 9 Mar 2015 11:59:02 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Mon, 9 Mar 2015 11:59:01 -0400 (EDT) From: Paul Wouters To: Warren Kumari In-Reply-To: Message-ID: References: User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: "" Subject: Re: [dane] Start of WGLC for draft-ietf-dane-openpgpkey - *please* review. X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 09 Mar 2015 15:59:23 -0000 On Mon, 9 Mar 2015, Warren Kumari wrote: > So, I'm extending this till this Friday (Friday the 13th!). Paul W > will also be releasing a new version of this document with many of the > comments integrated. Done, see: http://datatracker.ietf.org/doc/draft-ietf-dane-openpgpkey/ The changes are roughly: - Using PaulH's suggested text to address Petr's comment regarding OpenPGP public key format. - Added section about email address variants - Rewrote 4 item list into 3 item list as per PaulH's suggestion - Added a security section talking about amplification and what servers MAY do to avoid problems (probable controversial, please read!) - Language fixes, example RRTYPE fixes. Paul From nobody Mon Mar 9 09:10: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 F42391A8BC5 for ; Mon, 9 Mar 2015 09:10:17 -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 YqNB-KdUjnT6 for ; Mon, 9 Mar 2015 09:10:13 -0700 (PDT) Received: from proper.com (Opus1.Proper.COM [207.182.41.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83D981A8AE0 for ; Mon, 9 Mar 2015 09:10:13 -0700 (PDT) Received: from [10.20.30.101] (50-1-99-2.dsl.dynamic.fusionbroadband.com [50.1.99.2]) (authenticated bits=0) by proper.com (8.15.1/8.14.9) with ESMTPSA id t29GACIP072945 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 9 Mar 2015 09:10:13 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: proper.com: Host 50-1-99-2.dsl.dynamic.fusionbroadband.com [50.1.99.2] claimed to be [10.20.30.101] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Paul Hoffman In-Reply-To: Date: Mon, 9 Mar 2015 09:10:12 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: "" X-Mailer: Apple Mail (2.2070.6) Archived-At: Subject: Re: [dane] Start of WGLC for draft-ietf-dane-openpgpkey - *please* review. X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 09 Mar 2015 16:10:18 -0000 With PaulW's changes in -03, I very much like this document and believe = it should be moved to IETF Last Call. --Paul Hoffman= From nobody Mon Mar 9 12:13: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 14E661A90B4 for ; Mon, 9 Mar 2015 12:13:55 -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 pmz9KHrV8qbZ for ; Mon, 9 Mar 2015 12:13:53 -0700 (PDT) Received: from waldorf.isode.com (ext-bt.isode.com [217.34.220.158]) by ietfa.amsl.com (Postfix) with ESMTP id 46E301A9026 for ; Mon, 9 Mar 2015 12:13:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1425928399; d=isode.com; s=selector; i=@isode.com; bh=ujkqqeXbGBJL9uJP4JgIWBf3+XqxSm4RoeMLgNQtSjI=; 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=Rm3//wL5YDtIDwDI4vjgdvtwEEP6rg8O0CD+0+gBd2mO8BWNs+v05M8U5PvCps19DusxCL dfdFga/5BeILeibokTROUV4NTDlEat7I0mAXZWe0UJzOk/92Pv4MUEUWnU/cprhGQw5MrJ QIJHwAtbDuSwE7eyD0g9MxQhEi4OTsU=; Received: from [172.20.1.215] (dhcp-215.isode.net [172.20.1.215]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Mon, 9 Mar 2015 19:13:19 +0000 Message-ID: <54FDF0CB.5070203@isode.com> Date: Mon, 09 Mar 2015 19:13:15 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 To: Warren Kumari , "" , draft-ietf-dane-openpgpkey@tools.ietf.org, DANE-chairs References: 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] Start of WGLC for draft-ietf-dane-openpgpkey - *please* review. X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 09 Mar 2015 19:13:55 -0000 On 09/03/2015 15:43, Warren Kumari wrote: > [ Top post ] > > So, we have had a reasonable amount of discussion here, but only from > a limited number of participants. In many cases it is unclear to me if > people are OK with progressing hte document (once their comments are > addressed), or if they dislike the document... > > So, I'm extending this till this Friday (Friday the 13th!). Paul W > will also be releasing a new version of this document with many of the > comments integrated. Can people please have a look at the new version > (I think it will be out in a few hours), and let me know if: > A: their comments / issues have been addressed, and > B: are you OK with the general document? A clear "Yes, this is good" > or "No, worst idea ever" would be useful. > > I'd really like more then 3 or 4 people commenting. Late review of the document: The document looks good to me and I support its publication. Some nits/minor things: 2.3. The OPENPGPKEY RDATA presentation format The RDATA Presentation Format, as visible in textual zone files, consists of a single OpenPGP public key as defined in Section 5.5.1.1. of [RFC4880] encoded in Base64 [RFC4648] The base64 section should say "Section 4 of [RFC4648]". Because there is also section 5, which uses a diffent alphabet. In 3.1: o Everything after a "+" symbol is dynamc. Typo: dynamic. If you want an informative reference here, you can reference RFC 5233. hugh+string@example.com maps to hugh@example.com. From nobody Mon Mar 9 13:00: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 41F831A901F for ; Mon, 9 Mar 2015 12:59:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.661 X-Spam-Level: X-Spam-Status: No, score=-1.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_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 otD6Lpr23N5u for ; Mon, 9 Mar 2015 12:59:57 -0700 (PDT) Received: from mail.sys4.de (mail.sys4.de [IPv6:2001:1578:400:111::7]) (using TLSv1.1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52DEB1AC40F for ; Mon, 9 Mar 2015 12:59:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sys4.de; h= content-transfer-encoding:content-disposition:content-type :content-type:mime-version:message-id:subject:subject:from:from :date:date; s=mail201310; t=1425931186; x=1427745587; bh=XG+GLqU Zm/pqruFu9R5nPhZEKHRGIB9nToX79a7kb80=; b=xQiHocpFNVBcIKDRmUFgPCi aQLH7aR36o0ERoxcNhm7vbK6GZRnJj9HwpSjy56tBvUq0u1HWYj2N3Fk8gyWz0YN Kz9AaeOLqP1ppbUmd31nzp3uq5DyavCnn6QmB/9WXtk2WGmwrcHzBxGzPDWHFOY+ Vj3lOKjwpT32FYV60eid+AXril31zaJKALSsrZjb2LvjsdD8kZSpX64GLUPa1NZg 8jzylvP4Qmqio7+hgRr0DuQh7UV7mmXNwI/cFrr8lFjG4p+jOqsnps4Jz8pI7z4R rC9g6nW0mVi194avDGLO/H8W/eAhciF/3sTVb/B3Dvfj8rNIFnTWo5VXesTuWhQ= = X-Virus-Scanned: Debian amavisd-new at mail.sys4.de Received: from sys4.de (ipb21b19f6.dynamic.kabel-deutschland.de [178.27.25.246]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.sys4.de (Postfix) with ESMTPSA id 3l19PZ5V2CzFy for ; Mon, 9 Mar 2015 20:59:46 +0100 (CET) Date: Mon, 9 Mar 2015 20:59:45 +0100 From: Patrick Ben Koetter To: dane@ietf.org Message-ID: <20150309195944.GB8242@sys4.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit Archived-At: Subject: [dane] Use OPENPGPKEY or SMIMEA if both are available? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 09 Mar 2015 19:59:59 -0000 Greetings, while thinking about OPENPGPKEY and SMIMEA I came across this question: What if a recipient publishes both, an OPENPGPKEY and a SMIMEA RR in DNS and what if a sender (MUA/MTA Filter) is capable to encrypt messages for both standars S/MIME and PGP. Which should the sender prefer? Could the receiver indicate a preference? Has there been any discussion on this? Should there be? Did it take place and I missed it? p@rick -- [*] sys4 AG https://sys4.de, +49 (89) 30 90 46 64 Franziskanerstraße 15, 81669 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein From nobody Mon Mar 9 13: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 977871AC400 for ; Mon, 9 Mar 2015 13:01:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22Iu4m74x1pR for ; Mon, 9 Mar 2015 13:01:21 -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 9DEC91AC3EE for ; Mon, 9 Mar 2015 13:01:18 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3l19RG6s4zz47H; Mon, 9 Mar 2015 21:01:14 +0100 (CET) Authentication-Results: mx.nohats.ca; dkim=pass reason="1024-bit key; unprotected key" header.d=nohats.ca header.i=@nohats.ca header.b=gQD2MSrR; dkim-adsp=pass 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 h2FwDptmZvKY; Mon, 9 Mar 2015 21:01:13 +0100 (CET) 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, 9 Mar 2015 21:01:13 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 579DF80416; Mon, 9 Mar 2015 16:01:12 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1425931272; bh=OKBrJhCYhfuB/YrXrD8r+S3DvhhAcgatg1oah2ZLgmc=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=gQD2MSrRGcya17Lc7q7i7F7KD+jgxG6TBe+RBQYxLKB4VD5qw+DMwIOHWvQ+sHq8O 2o8N7tUadVOeGnnvYDYo+Q3oj6GoKRLquE4z+EZoQmlDaHQdjmHvkHv/5tTHtWLXrX D21MvLtF2x9FAFD1bUk0F3YjKplgle4G5Gt2z7qA= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id t29K1B9O013001; Mon, 9 Mar 2015 16:01:12 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Mon, 9 Mar 2015 16:01:11 -0400 (EDT) From: Paul Wouters To: Alexey Melnikov In-Reply-To: <54FDF0CB.5070203@isode.com> Message-ID: References: <54FDF0CB.5070203@isode.com> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: "" Subject: Re: [dane] Start of WGLC for draft-ietf-dane-openpgpkey - *please* review. X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 09 Mar 2015 20:01:22 -0000 On Mon, 9 Mar 2015, Alexey Melnikov wrote: > The document looks good to me and I support its publication. Great :) > Some nits/minor things: > > 2.3. The OPENPGPKEY RDATA presentation format > > The RDATA Presentation Format, as visible in textual zone files, > consists of a single OpenPGP public key as defined in > Section 5.5.1.1. of [RFC4880] encoded in Base64 [RFC4648] > > The base64 section should say "Section 4 of [RFC4648]". Because there is > also section 5, which uses a diffent alphabet. Fixed for -03. > In 3.1: > > o Everything after a "+" symbol is dynamc. > > Typo: dynamic. Fixed for -03 > If you want an informative reference here, you can reference RFC 5233. Added for -03. Thanks! Paul From nobody Mon Mar 9 13:06:38 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAD871A0107 for ; Mon, 9 Mar 2015 13:06:36 -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 l6qIImAtd84e for ; Mon, 9 Mar 2015 13:06:35 -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 3319C1A9245 for ; Mon, 9 Mar 2015 13:06:35 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3l19YN6T2lz7Wc; Mon, 9 Mar 2015 21:06:32 +0100 (CET) Authentication-Results: mx.nohats.ca; dkim=pass reason="1024-bit key; unprotected key" header.d=nohats.ca header.i=@nohats.ca header.b=D/3kUGYh; dkim-adsp=pass 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 nyIjwNfXRsAS; Mon, 9 Mar 2015 21:06:29 +0100 (CET) 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, 9 Mar 2015 21:06:29 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 8204480416; Mon, 9 Mar 2015 16:06:28 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1425931588; bh=7KuJgh90cjF26oPFnxAiY17oHlq0ppiH0owFW4KyoT0=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=D/3kUGYhuya47+ltw8EHlR2BuL0+hi2r7YzToi/Qv/0rGnLTCy/79ZCz9fghsrNOW mi/bAloOTajhC4GA+pleVKHtGVvIZxwr78+4lO6g7Wn+Lp6G8IVzXQQn8GlYjoKCSL AACF9OEMWETRaSlxoPmLIsMpFgBUoT+3IQt+92zY= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id t29K6Sur021095; Mon, 9 Mar 2015 16:06:28 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Mon, 9 Mar 2015 16:06:28 -0400 (EDT) From: Paul Wouters To: Patrick Ben Koetter In-Reply-To: <20150309195944.GB8242@sys4.de> Message-ID: References: <20150309195944.GB8242@sys4.de> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: dane@ietf.org Subject: Re: [dane] Use OPENPGPKEY or SMIMEA if both are available? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 09 Mar 2015 20:06:36 -0000 On Mon, 9 Mar 2015, Patrick Ben Koetter wrote: > while thinking about OPENPGPKEY and SMIMEA I came across this question: > > What if a recipient publishes both, an OPENPGPKEY and a SMIMEA RR in DNS and > what if a sender (MUA/MTA Filter) is capable to encrypt messages for both > standars S/MIME and PGP. > > Which should the sender prefer? Could the receiver indicate a preference? > > Has there been any discussion on this? Should there be? Did it take place and > I missed it? It has not been discussed. I would think this is a local policy decision. Likely, if respondering to an encrypted message using X, one would encrypt back using X if the local policy allows this. If sending a message from scratch, I would think local policy applies? An email client could prompt the user. An MTA would have to make a decision on its own, based on its policy. I wouldn't go so far as to allow the recipient to show a preference. The recipient shows its accepted methods by publishing the related record in DNS. This works similar to crypto suite/algo negotiations. The initiator can pick its favourite from the intersection of what both parties support. Paul From nobody Mon Mar 9 14:21: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 70DF71ACD96 for ; Mon, 9 Mar 2015 14:21:28 -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 lHinBfoHWtum for ; Mon, 9 Mar 2015 14:21:21 -0700 (PDT) Received: from mail.sys4.de (mail.sys4.de [194.126.158.139]) (using TLSv1.1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05BF21ACD7C for ; Mon, 9 Mar 2015 14:21:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sys4.de; h= in-reply-to:content-transfer-encoding:content-disposition :content-type:content-type:mime-version:references:message-id :subject:subject:from:from:date:date; s=mail201310; t= 1425936077; x=1427750478; bh=jBMBvNDPU1EKu9YXFu20nDWRCSkDw3IsTm/ iLusSIKo=; b=hbO6qxNXTkg3PxArZF+KB6l4RqnHa3sWn/tG0k0xoGBQ0lE+5YJ J3bcBC99ahTbChz5Os5OK7flEeaAfyluahSWYu+seuXHb9qDsz2Kh3hEZMRIg/uC j2DQzZPeTWvrnUK6M0TDFSvV9mGlmoUTngxT5DGli/zwnBoF4W35XLSsWqzCtFyR d+LNpy57LgUy8wbsEvYZ5sWjpBeu0U8K3vR3jT8/WnCRxUIdwbUnm4geFFhY/2tM 5WnX00GO+ddBGQhUOLZgTwIlQAw3/cbk9QuPJ9MKMiH12wBDN2qnbkdognRdXAQX aLxh+0kQuMsYqtb1nxyhBuNLkflno9uw9tw== X-Virus-Scanned: Debian amavisd-new at mail.sys4.de Received: from sys4.de (ipb21b19f6.dynamic.kabel-deutschland.de [178.27.25.246]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.sys4.de (Postfix) with ESMTPSA id 3l1CCd16DGzFy for ; Mon, 9 Mar 2015 22:21:17 +0100 (CET) Date: Mon, 9 Mar 2015 22:21:15 +0100 From: Patrick Ben Koetter To: dane@ietf.org Message-ID: <20150309212115.GC8242@sys4.de> References: <20150309195944.GB8242@sys4.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Archived-At: Subject: Re: [dane] Use OPENPGPKEY or SMIMEA if both are available? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 09 Mar 2015 21:21:28 -0000 * Paul Wouters : > On Mon, 9 Mar 2015, Patrick Ben Koetter wrote: > > >while thinking about OPENPGPKEY and SMIMEA I came across this question: > > > >What if a recipient publishes both, an OPENPGPKEY and a SMIMEA RR in DNS and > >what if a sender (MUA/MTA Filter) is capable to encrypt messages for both > >standars S/MIME and PGP. > > > >Which should the sender prefer? Could the receiver indicate a preference? > > > >Has there been any discussion on this? Should there be? Did it take place and > >I missed it? > > It has not been discussed. > > I would think this is a local policy decision. Likely, if respondering > to an encrypted message using X, one would encrypt back using X if the > local policy allows this. If sending a message from scratch, I would > think local policy applies? > > An email client could prompt the user. An MTA would have to make a > decision on its own, based on its policy. > > I wouldn't go so far as to allow the recipient to show a preference. The > recipient shows its accepted methods by publishing the related record in > DNS. This works similar to crypto suite/algo negotiations. The initiator > can pick its favourite from the intersection of what both parties > support. I think there are several options to handle OPENPGPKEY and SMIMEA conflicts. My intention is to find the one that requires the least or no sender interaction. Why? End to end encryption is known to be complicated. That's one of the main reasons why average users refuse to use it. They consider themselves unable to make the right decisions. They avoid these conflicts refusing to use end-to-end encryption at all. Both, OPENPGPKEY and SMIMEA, carry the potential to increase wider usage of encryption. They offer a safe way for automated key distribution. All a sender will have to do is 'send' the message. Given appropriate software, MUA or MTA, will handle safe key retrieval and encrypt the message for any OPENPGPKEY and SMIMEA enabled recipient. Letting the sender decide in case of conflicts - OPENPGPKEY and SMIMEA are present at the time of sending - puts the burden back on the sender. I'd like to avoid that because I expect this to be counterproductive for wider adoption. One way to handle this without user interaction is to handle it at MTA level. The operator could specify a preference. Another way would be to let the recipient specify a preference. Preferring one over the other would only take place if the sending MUA/MTA was able to deal with either standard. The sender would not have to interact with the software to make a decision. The recipient could indicate preference for standard A e.g. simply because messages encrypted by A can be read on more devices (desktop/tablet/mobile). Standard B would only serve as fallback. This would still leave the option to override on the sender's side. But then it would be intentionally. Most of the time recipient preference would just "do the right thing". p@rick -- [*] sys4 AG https://sys4.de, +49 (89) 30 90 46 64 Franziskanerstraße 15, 81669 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein From nobody Mon Mar 9 15:04: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 96D971ACD8C for ; Mon, 9 Mar 2015 15:04:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.5 X-Spam-Level: X-Spam-Status: No, score=-0.5 tagged_above=-999 required=5 tests=[BAYES_05=-0.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1J6lzPiF3Zau for ; Mon, 9 Mar 2015 15:04:10 -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 DBFC11ACDAE for ; Mon, 9 Mar 2015 15:04:03 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id BD271282FC2; Mon, 9 Mar 2015 22:04:02 +0000 (UTC) Date: Mon, 9 Mar 2015 22:04:02 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20150309220402.GL1260@mournblade.imrryr.org> References: <20150309195944.GB8242@sys4.de> <20150309212115.GC8242@sys4.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150309212115.GC8242@sys4.de> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [dane] Use OPENPGPKEY or SMIMEA if both are available? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2015 22:04:12 -0000 On Mon, Mar 09, 2015 at 10:21:15PM +0100, Patrick Ben Koetter wrote: > Both, OPENPGPKEY and SMIMEA, carry the potential to increase wider usage of > encryption. They offer a safe way for automated key distribution. All a sender > will have to do is 'send' the message. Given appropriate software, MUA or MTA, > will handle safe key retrieval and encrypt the message for any OPENPGPKEY and > SMIMEA enabled recipient. Pick whichever is also supported by the sender (for which the sender also has a key). If the sender has a key for both, I would have historically gone with SMIME since more desktop clients support that. However, things are changing, because smartphones have a new breed of email clients, and I'm not sure which is more prevalent on iOS and Android phones. Also even if SMIME is more widely understood, it is prone to raise warnings with self-signed or private CA issued keys. And we want to avoid such warnings. So it is not yet clear which is to be preferred, in practice we should be so lucky as to have to choose. Most users have no keys of either type. -- Viktor. From nobody Mon Mar 9 15:16:41 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B67F1ACDD2 for ; Mon, 9 Mar 2015 15:16:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.661 X-Spam-Level: X-Spam-Status: No, score=-1.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_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 g-fbOFU9jmrA for ; Mon, 9 Mar 2015 15:16:38 -0700 (PDT) Received: from mail.sys4.de (mail.sys4.de [IPv6:2001:1578:400:111::7]) (using TLSv1.1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5AC0E1ACDCD for ; Mon, 9 Mar 2015 15:16:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sys4.de; h= in-reply-to:content-transfer-encoding:content-disposition :content-type:content-type:mime-version:references:message-id :subject:subject:from:from:date:date; s=mail201310; t= 1425939392; x=1427753793; bh=UYzHfZwo9yVIjlpJwI47X89tEONZY2XMQ7g XDCNbc60=; b=c/s9r5w5gasZDNHL/puGPo6WYVUPF1XmLAXZb9fiBUd2CmZDefU 7PHPioCKngXKPu7Ahzy961RJpkoWZWVKnZYZZyjQtKpyIc1M6Ldo/NKj7GWdmxsC NPWqLidYNeGOiAy3YNbFMyp0lLbez+wPCnS0yihCCeUs+6tjEe0iN/cdjuVEmJCG On4oJgl/wbx9Q9O3EL0ndzaJfpZPxkOecjCIDzce7S5RcI3EKJHbauO2remuGVWT 4+SzFRtVUOFsCTh69ZHrp7sv7FxkM3LftR9yxNPZf8MizOs4JYtUKtD4blnxbC/A 9suliB6MbZsdl5jgpZDgqIXCBfIKzh66Jkg== X-Virus-Scanned: Debian amavisd-new at mail.sys4.de Received: from sys4.de (ipb21b19f6.dynamic.kabel-deutschland.de [178.27.25.246]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.sys4.de (Postfix) with ESMTPSA id 3l1DRN3mDcz1CG for ; Mon, 9 Mar 2015 23:16:32 +0100 (CET) Date: Mon, 9 Mar 2015 23:16:30 +0100 From: Patrick Ben Koetter To: dane@ietf.org Message-ID: <20150309221629.GA16800@sys4.de> References: <20150309195944.GB8242@sys4.de> <20150309212115.GC8242@sys4.de> <20150309220402.GL1260@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20150309220402.GL1260@mournblade.imrryr.org> Archived-At: Subject: Re: [dane] Use OPENPGPKEY or SMIMEA if both are available? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 09 Mar 2015 22:16:39 -0000 * Viktor Dukhovni : > On Mon, Mar 09, 2015 at 10:21:15PM +0100, Patrick Ben Koetter wrote: > > > Both, OPENPGPKEY and SMIMEA, carry the potential to increase wider usage of > > encryption. They offer a safe way for automated key distribution. All a sender > > will have to do is 'send' the message. Given appropriate software, MUA or MTA, > > will handle safe key retrieval and encrypt the message for any OPENPGPKEY and > > SMIMEA enabled recipient. > > Pick whichever is also supported by the sender (for which the sender > also has a key). If the sender has a key for both, I would have > historically gone with SMIME since more desktop clients support that. ACK > However, things are changing, because smartphones have a new breed > of email clients, and I'm not sure which is more prevalent on iOS > and Android phones. Also even if SMIME is more widely understood, > it is prone to raise warnings with self-signed or private CA issued > keys. And we want to avoid such warnings. > > So it is not yet clear which is to be preferred, in practice we > should be so lucky as to have to choose. Most users have no keys > of either type. Are you saying I am worrying about a problem we don't have (yet)? p@rick -- [*] sys4 AG https://sys4.de, +49 (89) 30 90 46 64 Franziskanerstraße 15, 81669 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein From nobody Tue Mar 10 08:28: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 E70961A00C7 for ; Tue, 10 Mar 2015 08:28:51 -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 DhMXYNKrDbX2 for ; Tue, 10 Mar 2015 08:28:48 -0700 (PDT) Received: from ore.jhcloos.com (ore.jhcloos.com [198.147.23.85]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3AB3A1A00C8 for ; Tue, 10 Mar 2015 08:28:48 -0700 (PDT) Received: by ore.jhcloos.com (Postfix, from userid 10) id 863491E5B7; Tue, 10 Mar 2015 15:28:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=ore14; t=1426001327; bh=bhi8T8GF4BKbdFwGx4Ri7Ay/4BM1EsC2gi9h1HcYYGA=; h=From:To:Subject:In-Reply-To:References:Date:From; b=XcDiUzC43ftqw405Wn6f5TQQjnDC4pAI3YtgID9Y9T3eBEsUQ+HNO1HlPHyY2UZPb K244aqGL1GEt8TzPjh3R7Ye6wLdYI051JDI/7/rCkIomyFBMGUIGASKQT03FVWo7hn 2efjceBaKzwjE1CFpq0mR0sw9uqBcMjeXGy1FNoo= Received: by carbon.jhcloos.org (Postfix, from userid 500) id 74A3A1073F001; Tue, 10 Mar 2015 15:26:43 +0000 (UTC) From: James Cloos To: In-Reply-To: (Paul Hoffman's message of "Mon, 9 Mar 2015 09:10:12 -0700") References: 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: Tue, 10 Mar 2015 11:26:43 -0400 Message-ID: Lines: 10 MIME-Version: 1.0 Content-Type: text/plain X-Hashcash: 1:28:150310:dane@ietf.org::Q0sSd/QzuflHeMCi:000lu0zE Archived-At: Subject: Re: [dane] Start of WGLC for draft-ietf-dane-openpgpkey - *please* review. X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 10 Mar 2015 15:28:52 -0000 >>>>> "PH" == Paul Hoffman writes: PH> With PaulW's changes in -03, I very much like this document and PH> believe it should be moved to IETF Last Call. +1. It looks ready for Last Call. -JimC -- James Cloos OpenPGP: 0x997A9F17ED7DAEA6 From nobody Tue Mar 10 09:20:41 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 939701A1BCC for ; Tue, 10 Mar 2015 09:20:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kDb8PMF5ouyQ for ; Tue, 10 Mar 2015 09:20:37 -0700 (PDT) Received: from wsget1.nist.gov (wsget1.nist.gov [129.6.13.150]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6198E1A1BB9 for ; Tue, 10 Mar 2015 09:20:36 -0700 (PDT) Received: from WSXGHUB1.xchange.nist.gov (129.6.18.96) by wsget1.nist.gov (129.6.13.150) with Microsoft SMTP Server (TLS) id 14.3.224.2; Tue, 10 Mar 2015 12:20:29 -0400 Received: from postmark.nist.gov (129.6.16.94) by WSXGHUB1.xchange.nist.gov (129.6.18.96) with Microsoft SMTP Server (TLS) id 8.3.389.2; Tue, 10 Mar 2015 12:20:32 -0400 Received: from 6-140.antd.nist.gov (6-140.antd.nist.gov [129.6.140.6]) by postmark.nist.gov (8.13.8/8.13.1) with ESMTP id t2AGKJLJ000636 for ; Tue, 10 Mar 2015 12:20:19 -0400 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: "Rose, Scott W." In-Reply-To: Date: Tue, 10 Mar 2015 12:20:18 -0400 Content-Transfer-Encoding: 7bit Message-ID: <0E54BA49-146F-447F-8AF5-A69745F86963@nist.gov> References: <54FDF0CB.5070203@isode.com> To: "" X-Mailer: Apple Mail (2.1878.6) X-NIST-MailScanner-Information: Archived-At: Subject: Re: [dane] Start of WGLC for draft-ietf-dane-openpgpkey - *please* review. X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 10 Mar 2015 16:20:40 -0000 On Mar 9, 2015, at 4:01 PM, Paul Wouters wrote: > On Mon, 9 Mar 2015, Alexey Melnikov wrote: > >> The document looks good to me and I support its publication. > > Great :) > With those edits fixed, I think it is ready for WGLC. Scott =================================== Scott Rose NIST scott.rose@nist.gov +1 301-975-8439 Google Voice: +1 571-249-3671 http://www.dnsops.gov/ https://www.had-pilot.com/ =================================== From nobody Tue Mar 10 15:22: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 B41A41A9041 for ; Tue, 10 Mar 2015 15:22:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 IE4O1NvHmtsL for ; Tue, 10 Mar 2015 15:22:12 -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 B7F531A8F46 for ; Tue, 10 Mar 2015 15:22:11 -0700 (PDT) Received: by qgdq107 with SMTP id q107so536046qgd.2 for ; Tue, 10 Mar 2015 15:22:11 -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:accept-language:content-language:user-agent:content-type :mime-version; bh=bJA0c89Cnu6tns2hh5Ih5GaUlxCvJ1NvYYBfdYJy188=; b=nMwkBqQSO3W87lL1WQyImtl62NinIjxH8IM4344H66pWN1M3/W4nX0tFe6CKpHpYpA gSCnXZa7/baeEnFOOC4Uu5Y3J7Tl8FiR0851cF4aFUf3OltNTnPZlLK8Ukx9IMLm+E7x frPVS96ogD5iyzU7o3xFKSBWr6KPlJbRyJctVU/nvvZdTKfcENYGnyUEkFC5EY85fZHb mIlhhwhkJGcN6DXnmPHIkZHVMqBTIKCxoKh33lgCHTulIQqMttH/f2o7z8doPCfpCG5L T6sB4zbMOiTWDNltlFK+mM3fWL6H3NWJON7wxzLOJDODlLJrbuEhrRhetOJTbSaTzOR3 mA2g== X-Gm-Message-State: ALoCoQnPxSy7ikJV1ekH/xgS0+fhdFnxW5EyhirIOKxo+F3eV43d6GRGH+3ygclXHSfPSvcizoq4S4hkWrVAZDs7HzUhPi2zuA== X-Received: by 10.140.165.198 with SMTP id l189mr45370023qhl.93.1426026131010; Tue, 10 Mar 2015 15:22:11 -0700 (PDT) Received: from brn1lxmailout02.verisign.com (brn1lxmailout02.verisign.com. [72.13.63.42]) by mx.google.com with ESMTPS id jy4sm619318qcb.0.2015.03.10.15.22.10 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 10 Mar 2015 15:22:10 -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 t2AMMAm7027374 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 10 Mar 2015 18:22:10 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by BRN1WNEXCHM01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Tue, 10 Mar 2015 18:22:10 -0400 From: "Wiley, Glen" To: "dane@ietf.org" Thread-Topic: Payment association records Thread-Index: AQHQW4ClIQaNAKPSFUqV1JxlK/mNZA== Date: Tue, 10 Mar 2015 22:21:45 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.7.141117 x-originating-ip: [10.173.152.4] Content-Type: multipart/alternative; boundary="_000_D124E6D872BFgwileyverisigncom_" MIME-Version: 1.0 Archived-At: Subject: [dane] Payment association records X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 10 Mar 2015 22:22:13 -0000 --_000_D124E6D872BFgwileyverisigncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable A few of us have put some work into an 00 draft describing a DANE like RR t= hat would provide an association for payment information via the DNS. The a= bstract from the draft reads: There is no standard, interoperable method for associating Internet service= identifiers with payment information. This document specifies a means fo= r retrieving information sufficient for a party to render payment using var= ious payment networks given the recipient's email address by leveraging the= DNS to securely publish payment information in a payment association recor= d. A payment association record associates an Internet service identifier = such as an email address with payment information such as an account number= or Bitcoin address. Our draft is in the tracker: https://tools.ietf.org/html/draft-wiley-paymentassoc-00 And I=92d like to get some feedback from folks on this to see what we can d= o to make this an effective tool. There are a number of elements that need to be fleshed out and we have more= content in the works to address specific use cases. Looking forward to hearing from folks. -- Glen Wiley Principal Engineer Verisign, Inc. (571) 230-7917 A5E5 E373 3C75 5B3E 2E24 6A0F DC65 2354 9946 C63A --_000_D124E6D872BFgwileyverisigncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
A few of us have put some work into an 00 draft describing a DAN= E like RR that would provide an association for payment information vi= a the DNS. The abstract from the draft reads:

There is no standard, interoperable method for associating Inter= net serv= ice identifiers with payment information.  This document to rend= er payment using various payment networks given the recipient's email address by leveraging the DNS to securely publish payment information in a p= ayment association record.  A payment association record associates an Internet service identifier such as an email address with payment i= nformation such as an account number or Bitcoin address.

Our draft is in the tracker:
And&= nbsp;I=92d like to get some feedback from folks on this to see what we can do to make this an effective tool.=

There are a number of elements that need to be fleshed out and we hav= e more content in the works to address specific use cases.

Looking forward to hearing from folks.
-- 
Glen Wiley
Principal Engineer
Verisign, Inc.
(571) 230-7917

A5E5 E373 3C75 5B3E = 2E24  
6A0F DC65 2354 9946 = C63A
--_000_D124E6D872BFgwileyverisigncom_-- From nobody Wed Mar 11 00:36: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 4A4DD1AC402 for ; Wed, 11 Mar 2015 00:36:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=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 yZVn7VDslGhV for ; Wed, 11 Mar 2015 00:36:15 -0700 (PDT) Received: from smtp.iridiumlinux.org (akira.iridiumlinux.org [184.70.203.174]) by ietfa.amsl.com (Postfix) with ESMTP id 994051AC3F8 for ; Wed, 11 Mar 2015 00:36:15 -0700 (PDT) Received: by smtp.iridiumlinux.org (Postfix, from userid 65534) id A78B613F4333; Wed, 11 Mar 2015 01:35:44 -0600 (MDT) X-Spam-ASN: Received: from [192.168.0.5] (c-24-143-80-128.customer.broadstripe.net [24.143.80.128]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.iridiumlinux.org (Postfix) with ESMTPSA id 92FAF13F42DF for ; Wed, 11 Mar 2015 01:35:42 -0600 (MDT) Message-ID: <54FFF047.5010303@iridiumlinux.org> Date: Wed, 11 Mar 2015 00:35:35 -0700 From: Falcon Darkstar Momot User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: dane@ietf.org References: In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms070902060609000707030905" Archived-At: Subject: Re: [dane] Payment association records X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 11 Mar 2015 07:36:20 -0000 This is a cryptographically signed message in MIME format. --------------ms070902060609000707030905 Content-Type: multipart/alternative; boundary="------------060306010000090201000603" This is a multi-part message in MIME format. --------------060306010000090201000603 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I lightly draw attention to an ancient failed internet draft for storing substantive payment processing information in the DNS: https://tools.ietf.org/html/draft-eastlake-card-map-08 I also draw attention for a different reason to the yet-reserved HTTP status code 402 (https://tools.ietf.org/html/rfc7231#page-59). --Falcon Darkstar Momot --Shadytel On 10/03/2015 15:21, Wiley, Glen wrote: > A few of us have put some work into an 00 draft describing a DANE > like RR that would provide an association for payment information via > the DNS. The abstract from the draft reads: > > There is no standard, interoperable method for associating > Internet service identifiers with payment information. This > document specifies a means for retrieving information sufficient for > a party to render payment using various payment networks given > the recipient's email address by leveraging the DNS to securely > publish payment information in a payment association record. A > payment association record associates an Internet service identifier > such as an email address with payment information such as an account > number or Bitcoin address. > > Our draft is in the tracker: > https://tools.ietf.org/html/draft-wiley-paymentassoc-00 > And I=92d like to get some feedback from folks on this to see what we > can do to make this an effective tool. > > There are a number of elements that need to be fleshed out and we have > more content in the works to address specific use cases. > > Looking forward to hearing from folks. > --=20 > Glen Wiley > Principal Engineer > Verisign, Inc. > (571) 230-7917 > > A5E5 E373 3C75 5B3E 2E24 =20 > 6A0F DC65 2354 9946 C63A > > > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane --------------060306010000090201000603 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
I lightly draw attention to an ancient= failed internet draft for storing substantive payment processing information in the DNS: https://tools.ietf.org/html/draft-eastlak= e-card-map-08

I also draw attention for a different reason to the yet-reserved HTTP status code 402 (https://tools.ietf.org/html/rfc7231#page-59).
--Falcon Darkstar Momot
--Shadytel

On 10/03/2015 15:21, Wiley, Glen wrote:
A few of us have put some work into an 00 draf= t describing a DANE like=A0RR that would provide an association for payment information via the DNS. The abstract from the draft reads:

There is no standard, interoperable method for= associating Internet=A0service identifiers with payment information.=A0=A0This document=A0=A0specifies a means for retrievin= g information sufficient for a party=A0to render payment using various payment networks given the=A0recipient's email address by leveraging the DNS to securely publish=A0payment information in a payment association record.=A0=A0A payment=A0<= /span>association record associates an Internet service identifier such as=A0an email address with payment information such as an account number=A0or Bitcoin address.

Our draft is in the tracker:
=A0=A0https://tools.ietf.org/html/draft-wiley-paymentassoc-00
And=A0I=92d like to get some feedback from folks on this to se= e what we can do to make this an effective tool.

There are a number of elements that need to be fleshed out and we have more content in the works to address specific use cases.

Looking forward to hearing from folks.=
--=A0
Glen Wil= ey
Principal Engineer
Verisign, Inc.
(571) 230-7917

A5E5 E373 3C75 5B3E 2E24=A0=A0
6A0F DC65 2354 9946 C63A


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

--------------060306010000090201000603-- --------------ms070902060609000707030905 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKUjCC BRowggQCoAMCAQICEG0Z6qcZT2ozIuYiMnqqcd4wDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNV BAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoT FVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3Qu Y29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQg RW1haWwwHhcNMTEwNDI4MDAwMDAwWhcNMjAwNTMwMTA0ODM4WjCBkzELMAkGA1UEBhMCR0Ix GzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UE ChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGlj YXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBAJKEhFtLV5jUXi+LpOFAyKNTWF9mZfEyTvefMn1V0HhMVbdClOD5J3EHxcZppLkyxPFA GpDMJ1Zifxe1cWmu5SAb5MtjXmDKokH2auGj/7jfH0htZUOMKi4rYzh337EXrMLaggLW1DJq 1GdvIBOPXDX65VSAr9hxCh03CgJQU2yVHakQFLSZlVkSMf8JotJM3FLb3uJAAVtIaN3FSrTg 7SQfOq9xXwfjrL8UO7AlcWg99A/WF1hGFYE8aIuLgw9teiFX5jSw2zJ+40rhpVJyZCaRTqWS D//gsWD9Gm9oUZljjRqLpcxCm5t9ImPTqaD8zp6Q30QZ9FxbNboW86eb/8ECAwEAAaOCAUsw ggFHMB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2uBG59MB0GA1UdDgQWBBR6E04AdFvG eGNkJ8Ev4qBbvHnFezAOBgNVHQ8BAf8EBAMCAQYwEgYDVR0TAQH/BAgwBgEB/wIBADARBgNV HSAECjAIMAYGBFUdIAAwWAYDVR0fBFEwTzBNoEugSYZHaHR0cDovL2NybC51c2VydHJ1c3Qu Y29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwdAYI KwYBBQUHAQEEaDBmMD0GCCsGAQUFBzAChjFodHRwOi8vY3J0LnVzZXJ0cnVzdC5jb20vVVRO QWRkVHJ1c3RDbGllbnRfQ0EuY3J0MCUGCCsGAQUFBzABhhlodHRwOi8vb2NzcC51c2VydHJ1 c3QuY29tMA0GCSqGSIb3DQEBBQUAA4IBAQCF1r54V1VtM39EUv5C1QaoAQOAivsNsv1Kv/av QUn1G1rF0q0bc24+6SZ85kyYwTAo38v7QjyhJT4KddbQPTmGZtGhm7VNm2+vKGwdr+XqdFqo 2rHA8XV6L566k3nK/uKRHlZ0sviN0+BDchvtj/1gOSBH+4uvOmVIPJg9pSW/ve9g4EnlFsjr P0OD8ODuDcHTzTNfm9C9YGqzO/761Mk6PB/tm/+bSTO+Qik5g+4zaS6CnUVNqGnagBsePdIa XXxHmaWbCG0SmYbWXVcHG6cwvktJRLiQfsrReTjrtDP6oDpdJlieYVUYtCHVmdXgQ0BCML7q peeU0rD+83X5f27nMIIFMDCCBBigAwIBAgIRAN3sgt3ll/yQeOZPRId2L3IwDQYJKoZIhvcN AQEFBQAwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAO BgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBD T01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwHhcNMTQw NjEwMDAwMDAwWhcNMTUwNjEwMjM1OTU5WjAoMSYwJAYJKoZIhvcNAQkBFhdmYWxjb25AaXJp ZGl1bWxpbnV4Lm9yZzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANFEuUdfP+wv X950Km0FMhQMuSGDWruO3Wy6Vxf4kgEcGqDl73zZzQ7vohYUEtUc3kyluw9qwk42FGqHSs5Y pW5CDWr85Ov167Z3DwjCHJ2cA9qtTCD0GwjW9MkYRDQpWs87pq9Ur51G0/mkiG4y4Xkif4Dl 28R2YM3QIvs1XL6bobjmcyt30eZrArkgNuBBmcAybuo0pqFlBaKud8HcgrOR91keU7mAqJIz MVnV+jBeFbX5Rs7RXAtJBM1n3u48w8v3V/2E034DBa0vjhyafpPDKv9LQ4LyJysBZ9uIArCk 7HJqzGO2kT/6cXFbwCphHY5C3IMPx0FdMboi2isoDsUCAwEAAaOCAecwggHjMB8GA1UdIwQY MBaAFHoTTgB0W8Z4Y2QnwS/ioFu8ecV7MB0GA1UdDgQWBBTmkI6vq81eszHm8NLf/xOfFPDl ozAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYL KwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQEC AQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFcGA1Ud HwRQME4wTKBKoEiGRmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhl bnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgYgGCCsGAQUFBwEBBHwwejBSBggrBgEF BQcwAoZGaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPQ2xpZW50QXV0aGVudGljYXRp b25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2Rv Y2EuY29tMCIGA1UdEQQbMBmBF2ZhbGNvbkBpcmlkaXVtbGludXgub3JnMA0GCSqGSIb3DQEB BQUAA4IBAQABMQFyXEQDcedRrbgAbhuMFztPeTMz+XuM/tybABL8aCzxyB3b7tiJ1kY5jMA1 2O7bydcen9XGfXI2RZM2btU2zoOSYqdh9SoLX1pSIL2P48b7PV7SYK/iruplh8S/s9+/ziav 2f1q2LT3aN4brT+QBDHLz0+/g6sYNg6nnNbHBGT3uTX4mSS9iP5IohKmKmHGCKFXXiWmcRCU 1CynAd9fmQroFXRpJYtbRbR1nEpUfJ2NGffKO7qLkA+X2H9ORvBQvuBa20P5Q4sjehTX87d+ zdbtA4lxOsA5/MSoeZ+LKlx1hXmY+i/qmjlZO42FpMBKGQYW9ioJ8vSiiSHjarAuMYIEHDCC BBgCAQEwgakwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIx EDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYDVQQD EzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQDd 7ILd5Zf8kHjmT0SHdi9yMAkGBSsOAwIaBQCgggJHMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTE1MDMxMTA3MzUzNVowIwYJKoZIhvcNAQkEMRYEFPvjIKN8 c7Cp0ZnOUkBuHL0oKxnXMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFl AwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4D AgcwDQYIKoZIhvcNAwICASgwgboGCSsGAQQBgjcQBDGBrDCBqTCBkzELMAkGA1UEBhMCR0Ix GzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UE ChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGlj YXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAN3sgt3ll/yQeOZPRId2L3IwgbwGCyqGSIb3 DQEJEAILMYGsoIGpMIGTMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVz dGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcG A1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENB AhEA3eyC3eWX/JB45k9Eh3YvcjANBgkqhkiG9w0BAQEFAASCAQAyzRsY/NP8x78SMDRFXHg5 Yc51vkIqkb5mq/ZnqKmoCcvj/Tf94k8pmoSd/MLDIdhBEwQjq/V1K+LfH45a24MJWsy3tSKe 1ElZaezHckUFvKSPeszRZtoJxwqGygNHngwJQLEaBUQ+6RRYlBr+PGl1Anqavt/rS2pxmC0p IFjpifRn6QKoYRoTIpb5lmNQK7FLSEJwDhNIeLBGXGgLI8C43L6qUqUI6LEpw01CTQOYO15h Fh7h1B8iRzZjXhLx197aL89xn2N4PokV9S5wv4/ZnM6pZBOQc9BXLc70QaHprf2blbXrmELJ vZzmWUa5TyKo4W17aV4BRLNn0DdMULLMAAAAAAAA --------------ms070902060609000707030905-- From nobody Wed Mar 11 03:46:43 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 043551A8714 for ; Wed, 11 Mar 2015 03:46:42 -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 JgRv3YRTKXK7 for ; Wed, 11 Mar 2015 03:46:36 -0700 (PDT) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.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 277791ACDE6 for ; Wed, 11 Mar 2015 03:46:35 -0700 (PDT) Received: by wiwl15 with SMTP id l15so10583328wiw.0 for ; Wed, 11 Mar 2015 03:46:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=3F4KS+tfMpnHiiRNIdb8Zsm84FfSP/37c0JEHPlU1zQ=; b=areKzDMrRoNpCYEmQdpKaDL5SIBD7Dy8fSwpw3eMicdB6NWuInC4BaNt9yL/jkTb95 QJ1REEPSxlWs/u67WPxz2mbT/v3nHehDRBi/BRwRPDo9zrPwWCljD3kQNMfWHMjaAo74 XnYb7UjCEyBcT4gsNGqWA9ofJgtpH6TotQmFHbXCbND2A320HUZ+cK6yxRNZsMx9886P Sf6MA3z/IJ2XPR396dn686fJH7jL/mMssVh754z+08FURWQUrqHZVba4YstFZ1Cv4hI2 wPcD3UUzzfbuz2QTFVBQg5YE047ln3e6mD1iX9BNrYtOQkC7m556PxWVrxI4bVRFkl6o wavw== X-Gm-Message-State: ALoCoQkyb3F7ql5zlNlYfeQrUbW9NvadOCVx/CsMyiivuM3zwU2HbYuVQZuhwqcNE0ecDRsw/c8E MIME-Version: 1.0 X-Received: by 10.180.85.70 with SMTP id f6mr65588861wiz.22.1426070793743; Wed, 11 Mar 2015 03:46:33 -0700 (PDT) Received: by 10.194.110.97 with HTTP; Wed, 11 Mar 2015 03:46:33 -0700 (PDT) In-Reply-To: References: Date: Wed, 11 Mar 2015 06:46:33 -0400 Message-ID: From: Warren Kumari To: "Wiley, Glen" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "dane@ietf.org" Subject: Re: [dane] Payment association records X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 11 Mar 2015 10:46:42 -0000 On Tue, Mar 10, 2015 at 6:21 PM, Wiley, Glen wrote: > A few of us have put some work into an 00 draft describing a DANE like RR > that would provide an association for payment information via the DNS. Th= e > abstract from the draft reads: > > There is no standard, interoperable method for associating Internet servi= ce > identifiers with payment information. This document specifies a means f= or > retrieving information sufficient for a party to render payment using > various payment networks given the recipient's email address by leveragin= g > the DNS to securely publish payment information in a payment association > record. A payment association record associates an Internet service > identifier such as an email address with payment information such as an > account number or Bitcoin address. > > Our draft is in the tracker: > https://tools.ietf.org/html/draft-wiley-paymentassoc-00 > And I=E2=80=99d like to get some feedback from folks on this to see what = we can do > to make this an effective tool. > > There are a number of elements that need to be fleshed out and we have mo= re > content in the works to address specific use cases. > > Looking forward to hearing from folks. Personally I really like the idea -- I'm not quite sure about all the details though. I've had a few instances where people have wanted to send me money and I've had to explain that I use PayPal and my email address is warren@kumari.net (BTW, this is accurate, if anyone feels the need to test it, feel free to send me some dosh :-)). Having a way to make that easier / more automated would be nice... I'm a little confused about a few aspects though. I happen to run my own domain, and so am in control of the DNS for that, but I'm in the tiny minority. Let's say that I use my ISP's provided email address, so I'm bob@example.com. Unfortunately example.com is slightly sketchy, and has been going through some rough times financially. What's to stop example.com creating hash(224, bob)._pmta.example.com. IN PMTA or *._pmta.example.com. IN PMTA ? They could even claim that they are being helpful and collecting the money on your behalf, and if you simply send them a notarized, triplicated request, along with a $19.99 handling fee they will release this these funds to you... Yes, this is a somewhat related issue to publishing SMIMEA or OPENPGPKEY record, but this deals directly with money, and so I have more concerns about it being used abusively. -openpgpkey- also says: "Therefore, an OpenPGP key obtained via an OPENPGPKEY record can only be trusted as much as the DNS domain can be trusted, and is no substitute for in-person key verification of the "Web of Trust"" I don't really see this could be extended to verifying payment info. This (unfortunately) doesn't really seem to fit within the DANE charter, which sates: The WG will specify the use of DANE for protocols that use SRV to express service location. The WG will specify DANE use for SMTP, SMIME, OPENPGP, IPSEC and other base electronic mail protocols such as (IMAP or POP). The DANE WG shall also produce a set of implementation guidance for operators and tool developers. ... DANE is not intended to be a long-lived catch-all WG for all public key distribution in DNS issues and so will generally not adopt new work items without re-chartering. I'm in no way opposed to discussing the draft here, but we'd need to first finish some other work, and then discuss if DANE wants to recharter before we could take this on as a WG item (I note that you haven't proposed it be a WG item, but wanted to head off the "DANE cannot do this because..." discussion). > -- > Glen Wiley > Principal Engineer > Verisign, Inc. > (571) 230-7917 > > A5E5 E373 3C75 5B3E 2E24 > 6A0F DC65 2354 9946 C63A > > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane > --=20 I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf From nobody Thu Mar 12 06:16: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 6A88A1A00F7 for ; Thu, 12 Mar 2015 06:16:24 -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 T_Wx4LUgB5bX for ; Thu, 12 Mar 2015 06:16:23 -0700 (PDT) Received: from mail-we0-f169.google.com (mail-we0-f169.google.com [74.125.82.169]) (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 9D82D1A00E0 for ; Thu, 12 Mar 2015 06:16:22 -0700 (PDT) Received: by wesk11 with SMTP id k11so16245584wes.13 for ; Thu, 12 Mar 2015 06:16:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=0zAUnN+ju5UlboDKQTBnc67YeCZODRPfTNwjO/H9vQ8=; b=cCNkf+23DeJiuPVVBFcjfK/ZMUYxFkPN1Ex7UV4HWArxc+X3xEb3LDFHLZNNbWt7qw KYgxFk4z3S5j1RUx7i+3BqqNXRXOXGL/ERQchAJOEnPpJicDxvoPXI27aAJz81+4pXZi YHBmoKiN0ftemuSt6dh2HmoKEU5xzgKGWrh7QJ/+oXg7WhyDT3rsvjN7shm65jrydDdf SK01zI8SlHaZqV1TdEC9MMVmhabY2vfdvEdrwxbw/uNzZ7Cj+3PLUyirLZtgusNVKyG2 mOIFW3H36ptYwjbGPLFvORhac5qlFEHNShoI2FQxVnNRxmFc8CQfLcIsl0DBgKQIn7Lt fFpQ== X-Gm-Message-State: ALoCoQlKcVcLz2CGKmvZT2IVyV8PJQoRTvkVp6UNEn5qBhWtg2vlzlFy/gex4hAFz464A/hHuDKc MIME-Version: 1.0 X-Received: by 10.194.221.100 with SMTP id qd4mr85498643wjc.113.1426166181212; Thu, 12 Mar 2015 06:16:21 -0700 (PDT) Received: by 10.194.110.97 with HTTP; Thu, 12 Mar 2015 06:16:21 -0700 (PDT) Date: Thu, 12 Mar 2015 14:16:21 +0100 Message-ID: From: Warren Kumari To: "" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [dane] Preliminary agenda posted. X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2015 13:16:24 -0000 http://www.ietf.org/proceedings/92/agenda/agenda-92-dane What: DANE When: TUESDAY, March 24, 2015, 1730-1830 Where: Venetian Agenda: Administrivia Olafur / Warren 10 minutes Verisign IPSEC DANE Glen Wiley, Eric Osterweil 20 minutes ---------------- As you can see, we don't have a very full agenda. W -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf From nobody Thu Mar 12 14:07: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 A6A6F1A90B5 for ; Thu, 12 Mar 2015 14:07:48 -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 wweGDgpQtFhy for ; Thu, 12 Mar 2015 14:07:47 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5FE161A9086 for ; Thu, 12 Mar 2015 14:07:47 -0700 (PDT) Received: (qmail 90180 invoked from network); 12 Mar 2015 21:07:45 -0000 Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 12 Mar 2015 21:07:45 -0000 Date: 12 Mar 2015 21:07:23 -0000 Message-ID: <20150312210723.16146.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] Payment association records X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 12 Mar 2015 21:07:48 -0000 Interesting idea. One thing that immediately jumps out at me is that the DNS name token that is _pmta in this draft and _smimecert in the SMIMEA draft should really be _mailbox, since the DNS name corresponds to a mailbox, not a particular service. I don't think that affects the tree walk problem. With respect to Warren's concern that a sleazy mailbox provider might publish bogus PMTA records -- they can read your mail. If they're going to do that, they can steal any account for which your mailbox gets password recovery mail, so that horse is, as they say, exfaenile. Concretely, I have a few nits. All the other strings I can think of in DNS records have one-byte lengths, so I'm wondering if you actually expect URI strings to be more than 255 bytes. For ACH transfers, I think it needs to include a an account type for personal/business checking/saving, but that's not a big deal. To be a little less provincial, add a payment system selector for IBANs. The data is an 11 character BIC (sometimes 8 characters followed by 3 spaces or within much of Europe, all blank) and a variable length IBAN of up to 34 characters. Something that we'll need to address is payment systems that handle more than one currency. American ACH transfers only work in US dollars and bitcoins only in bitcoins, but IBAN transfers can handle many different currencies. So if you are paying me in dollars, I want to you do an ACH transfer to my account in the US, but if you're paying me in pounds or anything else, do an IBAN transfer to my account in the UK. An obvious approach is to add a three character currency field and a flag saying whether transfers in other currencies are OK. If this sounds awfully complicated, yeah, payment systems are like that. R's, John From nobody Thu Mar 12 18:01: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 08DCE1AC3F3 for ; Thu, 12 Mar 2015 18:01:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.911 X-Spam-Level: X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 Xo4tKZtwKLvV for ; Thu, 12 Mar 2015 18:01:04 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF30E1AC3FD for ; Thu, 12 Mar 2015 18:01:03 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP id 5FD4F349398; Fri, 13 Mar 2015 01:01:02 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id BE07016006A; Fri, 13 Mar 2015 01:08:06 +0000 (UTC) Received: from rock.dv.isc.org (c211-30-175-41.carlnfd1.nsw.optusnet.com.au [211.30.175.41]) by zmx1.isc.org (Postfix) with ESMTPSA id 8F9EA160069; Fri, 13 Mar 2015 01:08:06 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id A58142B4D235; Fri, 13 Mar 2015 12:01:08 +1100 (EST) To: "John Levine" From: Mark Andrews References: <20150312210723.16146.qmail@ary.lan> In-reply-to: Your message of "12 Mar 2015 21:07:23 -0000." <20150312210723.16146.qmail@ary.lan> Date: Fri, 13 Mar 2015 12:01:07 +1100 Message-Id: <20150313010108.A58142B4D235@rock.dv.isc.org> Archived-At: Cc: dane@ietf.org Subject: Re: [dane] Payment association records X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 13 Mar 2015 01:01:05 -0000 In message <2015031221>0723.16146.qmail@ary.lan>, "John Levine" writes: > Concretely, I have a few nits. All the other strings I can think of > in DNS records have one-byte lengths, so I'm wondering if you actually > expect URI strings to be more than 255 bytes. Given the record format has 16 bits for the length field I think the answer is yes. 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payment Network Selector | Preference | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | URI String Length | URI String / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Association Data Type | Payment Association Data / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From pieter.lexis@powerdns.com Fri Mar 13 06:09: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 23E721A1AA6 for ; Fri, 13 Mar 2015 06:09:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_40=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eVzkwI6WlHQU for ; Fri, 13 Mar 2015 06:09:43 -0700 (PDT) Received: from mango.plexis.eu (mango.plexis.eu [77.72.150.82]) by ietfa.amsl.com (Postfix) with ESMTP id 242421A19F0 for ; Fri, 13 Mar 2015 06:09:42 -0700 (PDT) Received: from aardbei.mobile.plexis.eu (hq.kumina.nl [88.159.22.132]) by mango.plexis.eu (Postfix) with ESMTPSA id CD4F671 for ; Fri, 13 Mar 2015 14:09:40 +0100 (CET) Message-ID: <5502E194.4020507@powerdns.com> Date: Fri, 13 Mar 2015 14:09:40 +0100 From: Pieter Lexis Organization: PowerDNS User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: dane@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [dane] Start of WGLC for draft-ietf-dane-openpgpkey - *please* review. X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 13 Mar 2015 13:12:22 -0000 Hi all, Late to the party, but here are some nits/things on draft-ietf-dane-openpgpkey-02. I have not read my huge backlog of the DANE mailinglist, so please correct me if I'm beating a dead horse. Nearly all issues I have are mentioned in draft-ietf-dane-openpgpkey-usage-01. On 03/09/2015 04:43 PM, Warren Kumari wrote: > B: are you OK with the general document? A clear "Yes, this is good" > or "No, worst idea ever" would be useful. I'm very much on the "Yes, this is good"-side of things. 3.1: The MAY in the last sentence is much too weak. We can’t have interoperability without some stronger rules. Suggest moving this whole section into -usage or mentioning that these will be specified in a later document (-usage in this case). 5.1: Singling out one RRTYPE to push DNS-COOKIES feels weird. I'm just mentioning it, but as this section is merely a suggestion, it is fine. Appendix A: Two things: I suggest moving this to -usage and adding pseudocode examples. The latter mostly to encourage more implementations. -- Pieter Lexis From nobody Fri Mar 13 07:32: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 1B5D81A0A6A for ; Fri, 13 Mar 2015 07:32:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_15=0.6] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wSjTWn6tsh0E for ; Fri, 13 Mar 2015 07:32:27 -0700 (PDT) Received: from mango.plexis.eu (mango.plexis.eu [77.72.150.82]) by ietfa.amsl.com (Postfix) with ESMTP id 227CE1A026F for ; Fri, 13 Mar 2015 07:32:25 -0700 (PDT) Received: from aardbei.mobile.plexis.eu (132-22-159-88.business.edutel.nl [88.159.22.132]) by mango.plexis.eu (Postfix) with ESMTPSA id 8B49C5F for ; Fri, 13 Mar 2015 15:32:24 +0100 (CET) Message-ID: <5502F4F8.1000906@powerdns.com> Date: Fri, 13 Mar 2015 15:32:24 +0100 From: Pieter Lexis Organization: PowerDNS User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: dane@ietf.org References: <20141027233634.2254.98590.idtracker@ietfa.amsl.com> In-Reply-To: <20141027233634.2254.98590.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [dane] I-D Action: draft-ietf-dane-openpgpkey-usage-01.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Mar 2015 14:32:31 -0000 Hi folks, I've read this draft (and not my dane@iets.org backlog, so dead horses may be beaten) and have some comments on it. On 10/28/2014 12:36 AM, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the DNS-based Authentication of Named Entities Working Group of the IETF. > > Title : Best Common Practise for using OPENPGPKEY records > Author : Paul Wouters > Filename : draft-ietf-dane-openpgpkey-usage-01.txt > Pages : 8 > Date : 2014-10-27 General remarks: Make it clear early in the document that OPENPGPKEY records are only valid for their TTL and never permanent but they MAY function to validate the local public keyring. Also, nowhere in this draft there is any mention if (and if so, under what conditions) keys obtained from the DNS may be added to the local keyring. Abstract: This document aims to be a Best Current Practice (in this document also referred to to Best Common Practice). But at the moment there is no common practice (or even a current practice ;-)), so this nomenclature is a bit off. I'd suggest dropping the C{ommon,urrent}. 1. Introduction - Broken x-ref - Singular and plural use of MTA and MUA, pick one. 2. The OPENPGPKEY record presence - Could use some more information on the threat model we're protecting against. Like the end-to-end nature of this solution vs transport security, or just a reference to section 4 of this document. 3. OpenPGP public key considerations - This should refer to later sections on what to do with keys obtained from the DNS. 3.3 Public Key UIDs and synthesized DNS records - CNAME's and DNAME's looks clunky, "CNAME and DNAME records" looks better imo. 3.4 OpenPGP Key size and DNS - s/DNS Resoruce/DNS Resource/ - Refer to draft-ietf-dane-openpgp section 4, and optionally expand as this is almost a copy-paste. 4. Security Considerations - s/twart/thwart/ - The terms MUA and MTA are used before in section 1, no need to explain/un-acronym them here (do it in section 1) 4.1. Email address information leak - Pretends that dictionary attack against a zone (even with NSEC3) has the same difficulty as against SMTP 4.2. OpenPGP security and DNSSEC - (and other sections) appear to be partially duplicated from the openpgpkey draft. Should refer to these sections and expand on them - s/twart/thwart/ 4.3. MTA behaviour - s/bogus/Bogus/; s/indeterminate/Indeterminate/ (to match terminology from 4035 4.3) - "the MTA MUST NOT sent the message and queue the plaintext message for delivery at a later time” is unclear - should it or should it not queue the plaintext message? - s/sent/send/ - Whether or not encrypt with both keys is also 'just' part of the local policy 4.4. MUA behaviour - "contradicting properties" is somewhat broad, needs examples/expansion. 4.5. Email client behaviour - Needs some information on adding the key to the local keyring and what the trust implication is. -- Pieter Lexis From nobody Fri Mar 13 08: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 45ECE1A8A6A for ; Fri, 13 Mar 2015 08:09:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 3ZRE6585Mq0O for ; Fri, 13 Mar 2015 08:09:00 -0700 (PDT) Received: from mail-oi0-f98.google.com (mail-oi0-f98.google.com [209.85.218.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 EA6901A1B14 for ; Fri, 13 Mar 2015 08:08:49 -0700 (PDT) Received: by oiba3 with SMTP id a3so1053833oib.2 for ; Fri, 13 Mar 2015 08:08:49 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:thread-topic:thread-index:date :message-id:references:in-reply-to:accept-language:content-language :content-type:mime-version; bh=1dhVF+vf45GCh+OJMmkP3vQuUvlOm0Pnuldf9BueulE=; b=nJs0P5CRQhkURNXtY+lwa/Z1x/3yn4gP0pF5HaoAOYazTFkWNPrUXDMI7T2LoW04fz Uhqgyd0krLedQImvhDYYAlytGXkCew+AV4bC/xFvH497TEcpGP/TqTEECPcR0hfbny56 AGmCc+eqM28dsLBzREpR7qtQDAl1eTT9qgo0aS6N58o357ZnKiFHUwj3vTZVl2utNwty t4qiuCEs/KXxrk8pK1Nmf1X/lxub1fmbMLZDOY1wDExvCxuQy2/nV25j+50MMHJBNjKh GcAT7Y8VxI+Sy0avY5gAmDsqnVBxEk6r5RlWNVp6tWaRl1J0uxClJjfASNSCd62h437Z bHxA== X-Gm-Message-State: ALoCoQnt0+7shjEgN8mLwd0gKUDnBLs8Uy2xjXxAjbJbFpdVyl3qavkcbIdBTb1aRIl016NOpJLRj2UzQLE55gzs/XgjUSwBdQ== X-Received: by 10.55.23.220 with SMTP id 89mr8396103qkx.56.1426259329348; Fri, 13 Mar 2015 08:08:49 -0700 (PDT) Received: from brn1lxmailout02.verisign.com (brn1lxmailout02.verisign.com. [72.13.63.42]) by mx.google.com with ESMTPS id jy4sm645515qcb.0.2015.03.13.08.08.49 (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 13 Mar 2015 08:08:49 -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 t2DF8mxB015750 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 13 Mar 2015 11:08:48 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by BRN1WNEXCHM01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Fri, 13 Mar 2015 11:08:48 -0400 From: "Wiley, Glen" To: Falcon Darkstar Momot , "dane@ietf.org" Thread-Topic: [dane] Payment association records Thread-Index: AQHQW4ClIQaNAKPSFUqV1JxlK/mNZJ0XJ/mAgANc0fk= Date: Fri, 13 Mar 2015 15:08:19 +0000 Message-ID: <641EE49757824F4BBE5F863B22FDDBF23C454AB0@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: , <54FFF047.5010303@iridiumlinux.org> In-Reply-To: <54FFF047.5010303@iridiumlinux.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: multipart/alternative; boundary="_000_641EE49757824F4BBE5F863B22FDDBF23C454AB0BRN1WNEXMBX01vc_" MIME-Version: 1.0 Archived-At: Subject: Re: [dane] Payment association records X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 13 Mar 2015 15:09:03 -0000 --_000_641EE49757824F4BBE5F863B22FDDBF23C454AB0BRN1WNEXMBX01vc_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I took a quick look at the eastlake draft from 2001 and although I wasn't w= atching those discussions here are my observations: - This was prior to the supporting work of DNSSEC and DANE which provide an= established trust anchor and chain of trust. This looks as though it was = an idea before its time :) - Their proposal used the DNS hierarchy rooted in a single TLD to locate th= e records. There are significant advantages to following the more familiar= model in the DNS of expecting RR sets within the domain associated with th= e target entity (I go to google.com to find records related to google) rath= er than capturing application usages within a TLD. - Their security considerations beg the question of DNSSEC and the work bei= ng done in DPRIV! - I suspect that some of the work in the eastlake draft may be relevant to = this proposal and I want to digest it more completely to see what we might = leverage. I'd love to hear relevant thoughts form the discussions in 2001 if any of t= hose folks are on the list. thanks Glen ________________________________ From: dane [dane-bounces@ietf.org] on behalf of Falcon Darkstar Momot [falc= on@iridiumlinux.org] Sent: Wednesday, March 11, 2015 3:35 AM To: dane@ietf.org Subject: Re: [dane] Payment association records I lightly draw attention to an ancient failed internet draft for storing su= bstantive payment processing information in the DNS: https://tools.ietf.org= /html/draft-eastlake-card-map-08 I also draw attention for a different reason to the yet-reserved HTTP statu= s code 402 (https://tools.ietf.org/html/rfc7231#page-59). --Falcon Darkstar Momot --Shadytel On 10/03/2015 15:21, Wiley, Glen wrote: A few of us have put some work into an 00 draft describing a DANE like RR t= hat would provide an association for payment information via the DNS. The a= bstract from the draft reads: There is no standard, interoperable method for associating Internet service= identifiers with payment information. This document specifies a means fo= r retrieving information sufficient for a party to render payment using var= ious payment networks given the recipient's email address by leveraging the= DNS to securely publish payment information in a payment association recor= d. A payment association record associates an Internet service identifier = such as an email address with payment information such as an account number= or Bitcoin address. Our draft is in the tracker: https://tools.ietf.org/html/draft-wiley-paymentassoc-00 And I=92d like to get some feedback from folks on this to see what we can d= o to make this an effective tool. There are a number of elements that need to be fleshed out and we have more= content in the works to address specific use cases. Looking forward to hearing from folks. -- Glen Wiley Principal Engineer Verisign, Inc. (571) 230-7917 A5E5 E373 3C75 5B3E 2E24 6A0F DC65 2354 9946 C63A _______________________________________________ dane mailing list dane@ietf.org https://www.ietf.org/mailman/listinfo/dane --_000_641EE49757824F4BBE5F863B22FDDBF23C454AB0BRN1WNEXMBX01vc_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
I took a quick look at the eastlake draft from 2001 and although I w= asn't watching those discussions here are my observations:

- This was prior to the supporting work of DNSSEC and DANE which provide an= established trust anchor and chain of trust.  This looks as though it= was an idea before its time :)

- Their proposal used the DNS hierarchy rooted in a single TLD to locate th= e records.  There are significant advantages to following the more fam= iliar model in the DNS of expecting RR sets within the domain associated wi= th the target entity (I go to google.com to find records related to google) rather than capturing application usage= s within a TLD.

- Their security considerations beg the question of DNSSEC and the work bei= ng done in DPRIV!

- I suspect that some of the work in the eastlake draft may be relevant to = this proposal and I want to digest it more completely to see what we might = leverage.

I'd love to hear relevant thoughts form the discussions in 2001 if any of t= hose folks are on the list.

thanks
Glen

From: dane [dane-bounces@ietf.org] on beh= alf of Falcon Darkstar Momot [falcon@iridiumlinux.org]
Sent: Wednesday, March 11, 2015 3:35 AM
To: dane@ietf.org
Subject: Re: [dane] Payment association records

I lightly draw attention to an ancient faile= d internet draft for storing substantive payment processing information in = the DNS: https://tools.ietf.org/html/draft-eastlake-card-map-08

I also draw attention for a different reason to the yet-reserved HTTP statu= s code 402 (https://tools.ietf.org/html/rfc7= 231#page-59).

--Falcon Darkstar Momot
--Shadytel

On 10/03/2015 15:21, Wiley, Glen wrote:
A few of us have put some work into an 00 draft describing a DANE like=  RR that would provide an association for payment information via the = DNS. The abstract from the draft reads:

There is no standard, interoperable method for associating Internet&nb= sp;service ident= ifiers with payment information.  This document  specifies a means for retrieving information sufficient for a party to render payment using var= ious payment networks given the recipient's email address by leveraging the DNS to securely publish payment information in a payment associatio= n record.  A payment association record associates an Internet service identifier such as an email address with payment information such as an accou= nt number o= r Bitcoin address.

Our draft is in the tracker:
A<= font style=3D"color:rgb(0,0,0); font-size:12px" face=3D"Courier">nd = I=92d like to get some feedback from folks on this to see what we can do to make this an effective tool.
=
= There are a number of elements that need to be fleshed out and we have more= content in the works to address specific use cases.
=
= Looking forward to hearing from folks.
-- 
Glen Wiley
Principal Engineer
Verisign, Inc.<= /div>
(571) 230-7917<= /div>

A5E5 E373 3C75 5B3E 2E= 24  
6A0F DC65 2354 9946 C6= 3A


_______________________________________________=0A=
dane mailing list=0A=
dane@ietf.org=0A=
https://www.ietf.org/mailman/listinfo/dane=0A=

--_000_641EE49757824F4BBE5F863B22FDDBF23C454AB0BRN1WNEXMBX01vc_-- From nobody Fri Mar 13 08:18: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 7EBCF1A19E4 for ; Fri, 13 Mar 2015 08:18:39 -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 MzALpCo31BVh for ; Fri, 13 Mar 2015 08:18:37 -0700 (PDT) Received: from mail-qg0-f100.google.com (mail-qg0-f100.google.com [209.85.192.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3EBB61A0AF8 for ; Fri, 13 Mar 2015 08:18:37 -0700 (PDT) Received: by qgdq107 with SMTP id q107so2481296qgd.2 for ; Fri, 13 Mar 2015 08:18:36 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:thread-topic:thread-index :date:message-id:references:in-reply-to:accept-language :content-language:content-type:content-transfer-encoding :mime-version; bh=/M9cb7A5hb+6gSixdlwH+V8c8hkfRdehtQpJi6rcjTs=; b=G4/RcL1HGafRCFQZ3OpAuSrhXC7XjpXh6AJ2hF1eIkyBplVX0/Sb5GeKSncPAIsmdo UQN1455sZHPdp6CIxNH+XuBEU/Iw1iP6/YkH78zaNJjPI2K6eLmZY8OpzKe/FkO29Fcu /gYyHQTKTyQwMWdSTwoT7AUvbh8g3QJdSMeb5QWGzuVZUH6+6c6AyRXSRMgPyUJw8/FP KvsQIdkkspEltDZOsxddPUyhhGamftYbRFN8QShDh8QbzXi86/2NurGzi00c39rEPl1c 3WB7CDJ+4Dkxho9O/cs0vcirmILIAHQbiXydedXMxw9Qb4KRWDI+EBPYJ2zSBokFT8Um Pa/g== X-Gm-Message-State: ALoCoQmMa6EVZH5RYCDedeEAn2hPcz/MYab2C9T5lyQNW5Ka85RZf77pSWRNjeORpY1DKmHGt80smFqhGrbpK9Wxx8Y7YglBbg== X-Received: by 10.140.20.226 with SMTP id 89mr59072800qgj.16.1426259916329; Fri, 13 Mar 2015 08:18:36 -0700 (PDT) Received: from brn1lxmailout01.verisign.com (brn1lxmailout01.verisign.com. [72.13.63.41]) by mx.google.com with ESMTPS id l10sm637070qcs.4.2015.03.13.08.18.36 (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 13 Mar 2015 08:18:36 -0700 (PDT) X-Relaying-Domain: verisign.com Received: from brn1wnexcas02.vcorp.ad.vrsn.com (brn1wnexcas02 [10.173.152.206]) by brn1lxmailout01.verisign.com (8.13.8/8.13.8) with ESMTP id t2DFIZKH015369 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 13 Mar 2015 11:18:36 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas02.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Fri, 13 Mar 2015 11:18:34 -0400 From: "Wiley, Glen" To: Warren Kumari Thread-Topic: [dane] Payment association records Thread-Index: AQHQW4ClIQaNAKPSFUqV1JxlK/mNZJ0XXVSAgAMrAWo= Date: Fri, 13 Mar 2015 15:18:07 +0000 Message-ID: <641EE49757824F4BBE5F863B22FDDBF23C454B05@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "dane@ietf.org" Subject: Re: [dane] Payment association records X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 13 Mar 2015 15:18:39 -0000 Warren,=0A= =0A= Thanks for taking the time to offer so much supporting detail behind your a= nalysis.=0A= =0A= Regarding nefarious domain operators=0A= =0A= You have identified a very real risk that we all face when we leverage a do= main over which we have no real control. I trust google to not impersonate= me with my personal email address, if they did they could do real harm to = me. As you well know this isn't new to the payment association record. If= you want good security then you have to follow good security practices whi= ch means there must be a chain of trust AND custody of the assets. Whether= a third party can be trusted with a payment association is a question best= answered in the same way we answer that question regarding payal, etc.=0A= =0A= Risk=0A= =0A= The shared issues with SMIMEA and OPENPGPKEY that you mention are correct, = I would suggest though that if I decide to rely on those records to encrypt= communicaitons there will likely be even MORE at stake than relying on PMT= A for incidental receipts or even daily commerce. It is not hard to imagin= e information being exchanged that is far =0A= more valuable than a company's daily receipts over some finite period (the = itme it takes to discover a compromise). =0A= =0A= Chair Hat/Charter=0A= =0A= Thanks for pointing that out. I fully expected some dialog on the question= - I decided that the folks in this WG were the best audience to field the = idea to. I hope that we will see an evolution of ideas that leverage DANE = and DNSSEC to provide the security substrate for many applications, we need= to find a good home for the ideas whether that is here or another WG.=0A= =0A= thanks again for everyone's time.=0A= Glen=0A= =0A= ________________________________________=0A= From: Warren Kumari [warren@kumari.net]=0A= Sent: Wednesday, March 11, 2015 6:46 AM=0A= To: Wiley, Glen=0A= Cc: dane@ietf.org=0A= Subject: Re: [dane] Payment association records=0A= =0A= On Tue, Mar 10, 2015 at 6:21 PM, Wiley, Glen wrote:= =0A= > A few of us have put some work into an 00 draft describing a DANE like RR= =0A= > that would provide an association for payment information via the DNS. Th= e=0A= > abstract from the draft reads:=0A= >=0A= > There is no standard, interoperable method for associating Internet servi= ce=0A= > identifiers with payment information. This document specifies a means f= or=0A= > retrieving information sufficient for a party to render payment using=0A= > various payment networks given the recipient's email address by leveragin= g=0A= > the DNS to securely publish payment information in a payment association= =0A= > record. A payment association record associates an Internet service=0A= > identifier such as an email address with payment information such as an= =0A= > account number or Bitcoin address.=0A= >=0A= > Our draft is in the tracker:=0A= > https://tools.ietf.org/html/draft-wiley-paymentassoc-00=0A= > And I=92d like to get some feedback from folks on this to see what we can= do=0A= > to make this an effective tool.=0A= >=0A= > There are a number of elements that need to be fleshed out and we have mo= re=0A= > content in the works to address specific use cases.=0A= >=0A= > Looking forward to hearing from folks.=0A= =0A= =0A= Personally I really like the idea -- I'm not quite sure about all the=0A= details though.=0A= I've had a few instances where people have wanted to send me money and=0A= I've had to explain that I use PayPal and my email address is=0A= warren@kumari.net (BTW, this is accurate, if anyone feels the need to=0A= test it, feel free to send me some dosh :-)). Having a way to make=0A= that easier / more automated would be nice...=0A= =0A= I'm a little confused about a few aspects though.=0A= I happen to run my own domain, and so am in control of the DNS for=0A= that, but I'm in the tiny minority. Let's say that I use my ISP's=0A= provided email address, so I'm bob@example.com. Unfortunately=0A= example.com is slightly sketchy, and has been going through some rough=0A= times financially.=0A= What's to stop example.com creating hash(224, bob)._pmta.example.com.=0A= IN PMTA or=0A= *._pmta.example.com. IN PMTA ?=0A= They could even claim that they are being helpful and collecting the=0A= money on your behalf, and if you simply send them a notarized,=0A= triplicated request, along with a $19.99 handling fee they will=0A= release this these funds to you...=0A= =0A= Yes, this is a somewhat related issue to publishing SMIMEA or=0A= OPENPGPKEY record, but this deals directly with money, and so I have=0A= more concerns about it being used abusively.=0A= -openpgpkey- also says:=0A= "Therefore, an OpenPGP key obtained via an OPENPGPKEY record can only=0A= be trusted as much as the DNS domain can be trusted, and is no=0A= substitute for in-person key verification of the "Web of Trust""=0A= I don't really see this could be extended to verifying payment info.=0A= =0A= =0A= =0A= This (unfortunately) doesn't really seem to fit within the DANE=0A= charter, which sates:=0A= The WG will specify the use of DANE=0A= for protocols that use SRV to express service location. The WG will=0A= specify DANE use for SMTP, SMIME, OPENPGP, IPSEC and=0A= other base electronic mail protocols such as (IMAP or POP). The=0A= DANE WG shall also produce a set of implementation guidance=0A= for operators and tool developers.=0A= ...=0A= DANE is not intended to be a long-lived catch-all WG for all=0A= public key distribution in DNS issues and so will generally not=0A= adopt new work items without re-chartering.=0A= =0A= =0A= I'm in no way opposed to discussing the draft here, but we'd need to=0A= first finish some other work, and then discuss if DANE wants to=0A= recharter before we could take this on as a WG item (I note that you=0A= haven't proposed it be a WG item, but wanted to head off the "DANE=0A= cannot do this because..." discussion).=0A= =0A= =0A= =0A= =0A= =0A= > --=0A= > Glen Wiley=0A= > Principal Engineer=0A= > Verisign, Inc.=0A= > (571) 230-7917=0A= >=0A= > A5E5 E373 3C75 5B3E 2E24=0A= > 6A0F DC65 2354 9946 C63A=0A= >=0A= > _______________________________________________=0A= > dane mailing list=0A= > dane@ietf.org=0A= > https://www.ietf.org/mailman/listinfo/dane=0A= >=0A= =0A= =0A= =0A= --=0A= I don't think the execution is relevant when it was obviously a bad=0A= idea in the first place.=0A= This is like putting rabid weasels in your pants, and later expressing=0A= regret at having chosen those particular rabid weasels and that pair=0A= of pants.=0A= ---maf=0A= From nobody Fri Mar 13 09:01:22 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3648A1A8AAE for ; Fri, 13 Mar 2015 09:01:20 -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 Wrg1nwrg4wL3 for ; Fri, 13 Mar 2015 09:01:18 -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 8AFE31A8AA8 for ; Fri, 13 Mar 2015 09:01:18 -0700 (PDT) Received: by oiba3 with SMTP id a3so1091988oib.2 for ; Fri, 13 Mar 2015 09:01:18 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:thread-topic:thread-index:date :message-id:references:in-reply-to:accept-language:content-language :content-type:content-transfer-encoding:mime-version; bh=xPv9Sj0POfyVcZuT0Gik1fEDtrPx0jBVLq+gv5eqmjU=; b=HkqcPxiUAPQlohMde5v5DXhX21lrMiv3Q3VmG0UGnzF289XGSB7QSoYYgaSd2q6pIM X4xsnfgrVa4Qofm7U3Yq+ZmkekE2v6xG9xUTU95VkAFcjkCPPiNcJBqCaTPSS6CBv5w9 BbTup4Ex9/jKbrSti2q5i62WA6/MhtA1tOYQ2blZ6NaiFKFF+/bptg2RKYA9YyWSWKj4 AlMYQuOva23S3MqgzqKMpgCVBuAQic17CsQORYjhtNGsuIoAF662TT6NpzLR4dwNcmAw 4i7+PJ4Q4eOO4HpXt0TXyStog8TMySc6epJYBLW+BJxIThoJzLh2WHrXe+ksbMdY1dfC Q10g== X-Gm-Message-State: ALoCoQmVsPesc83NDNW0HPLWIlueU2IHzhYWgmUWKHOMlK6vXG6V1mwN8Aox3/pTiB62hZUpBF4POD19CJU0sS9cdM8b8yMljg== X-Received: by 10.55.55.85 with SMTP id e82mr49382694qka.2.1426262477919; Fri, 13 Mar 2015 09:01:17 -0700 (PDT) Received: from brn1lxmailout01.verisign.com (brn1lxmailout01.verisign.com. [72.13.63.41]) by mx.google.com with ESMTPS id cd6sm671806qcb.2.2015.03.13.09.01.17 (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 13 Mar 2015 09:01:17 -0700 (PDT) X-Relaying-Domain: verisign.com Received: from brn1wnexcas02.vcorp.ad.vrsn.com (brn1wnexcas02 [10.173.152.206]) by brn1lxmailout01.verisign.com (8.13.8/8.13.8) with ESMTP id t2DG1HxV020410 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 13 Mar 2015 12:01:17 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas02.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Fri, 13 Mar 2015 12:01:16 -0400 From: "Wiley, Glen" To: John Levine , "dane@ietf.org" Thread-Topic: [dane] Payment association records Thread-Index: AQHQW4ClIQaNAKPSFUqV1JxlK/mNZJ0ZnR6AgADuB/4= Date: Fri, 13 Mar 2015 16:00:48 +0000 Message-ID: <641EE49757824F4BBE5F863B22FDDBF23C454BA9@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: , <20150312210723.16146.qmail@ary.lan> In-Reply-To: <20150312210723.16146.qmail@ary.lan> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [dane] Payment association records X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 13 Mar 2015 16:01:20 -0000 John,=0A= =0A= In the PMTA draft I offered the same locator approach as SMIMEA, however al= so mention that that is one of many possible means for locating the record.= It is not hard to image use cases in which a recipient would want to expo= se multiple payment associations that don't necessarily correspond to a mai= lbox.=0A= =0A= URI length: I initially wrote URI length as a one byte value however I was= thinking about some of the REST entry points that I have seen that are pre= tty long. I am not married to a two byte length, just trying to anticipate= the use cases - I am open to input from folks.=0A= =0A= IBAN sounds like a good idea. One of the things we wrestled with is do we = write a completely generic draft that has no specific payment networks and = then handle each payment network as a separate draft or do we take the appr= oach that we ended up with and specify two examples to provide a concrete g= rounding for the record (simialr to the approach taken with TLSA). We deci= ded that showing a crypto currency and non-crypto currency use case would g= et things rolling then subsequent payment networks could be added outside t= he draft. Do you feel IBAN should be an exemplar?=0A= =0A= I agree that we should add a few more fields - fully expect this to morph f= rom 00 to 00+ that way :)=0A= =0A= Glen=0A= =0A= ________________________________________=0A= From: John Levine [johnl@taugh.com]=0A= Sent: Thursday, March 12, 2015 5:07 PM=0A= To: dane@ietf.org=0A= Cc: Wiley, Glen=0A= Subject: Re: [dane] Payment association records=0A= =0A= Interesting idea.=0A= =0A= One thing that immediately jumps out at me is that the DNS name token=0A= that is _pmta in this draft and _smimecert in the SMIMEA draft should=0A= really be _mailbox, since the DNS name corresponds to a mailbox, not a=0A= particular service. I don't think that affects the tree walk problem.=0A= =0A= With respect to Warren's concern that a sleazy mailbox provider might=0A= publish bogus PMTA records -- they can read your mail. If they're=0A= going to do that, they can steal any account for which your mailbox=0A= gets password recovery mail, so that horse is, as they say, exfaenile.=0A= =0A= Concretely, I have a few nits. All the other strings I can think of=0A= in DNS records have one-byte lengths, so I'm wondering if you actually=0A= expect URI strings to be more than 255 bytes.=0A= =0A= For ACH transfers, I think it needs to include a an account type for=0A= personal/business checking/saving, but that's not a big deal.=0A= =0A= To be a little less provincial, add a payment system selector for=0A= IBANs. The data is an 11 character BIC (sometimes 8 characters=0A= followed by 3 spaces or within much of Europe, all blank) and a=0A= variable length IBAN of up to 34 characters.=0A= =0A= Something that we'll need to address is payment systems that handle=0A= more than one currency. American ACH transfers only work in US=0A= dollars and bitcoins only in bitcoins, but IBAN transfers can handle=0A= many different currencies. So if you are paying me in dollars, I want=0A= to you do an ACH transfer to my account in the US, but if you're=0A= paying me in pounds or anything else, do an IBAN transfer to my=0A= account in the UK. An obvious approach is to add a three character=0A= currency field and a flag saying whether transfers in other currencies=0A= are OK.=0A= =0A= If this sounds awfully complicated, yeah, payment systems are like that.=0A= =0A= R's,=0A= John=0A= =0A= =0A= From nobody Fri Mar 13 10:04:53 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E1231A8775 for ; Fri, 13 Mar 2015 10:04:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.137 X-Spam-Level: X-Spam-Status: No, score=-1.137 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ipKKmrQ1NTLT for ; Fri, 13 Mar 2015 10:04:51 -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 076CB1A0117 for ; Fri, 13 Mar 2015 10:04:50 -0700 (PDT) Received: (qmail 57495 invoked from network); 13 Mar 2015 17:04:50 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=e096.550318b2.k1503; bh=li0IEQmlJWYf/+l57mYdDHErGFARl64tIMo3q4/8apQ=; b=P4HdqB/GI/+A1JdNVbNnqPn8zuzLigcURdGKD2KQ1vgvOqrVi1forbgi7ttuMLXLqNIJ+utDuqHD97bHqHmBQxtUM3w1/89oNPFziDZ9fGB5VmiWQCN/brfu6Bd8jXI/zeOO6KTsGkpA2KOUSTNJn2/m/c6VP7lYCzjsg4awDAlpnvgl47DdxiJqCYaiqpDO0POjA79q4DRyVdYeVOkRG9jzqI9OMdia4i2OgqOB4bom7pKuvOz7kMy5ToaQJI6K 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=e096.550318b2.k1503; bh=li0IEQmlJWYf/+l57mYdDHErGFARl64tIMo3q4/8apQ=; b=pPwkayDcZOH+lUdylGguUeH/4RaYADL6u6XyxqWqDkkaxc7X72Pg3DWq2KR/21nUZxkHpuLUgzfQpEsgBHu69p6XeLSK7l+C5ZgFJWVf3AGwcV96Mv+q5hzMyaRKnd/y5hfJRB4FQYbPQ6TkdFy4k+Dl9lwKtDzvUcF/pFspfWeuXzJ9LMmey2MTOSeHQRcq/1womYWtwEdifAsfA06Z0E+Ylm01LD6M1IoBdSLDH2Ws8BwYCDTGCVu8+ffVvKpd 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; 13 Mar 2015 17:04:49 -0000 Date: 13 Mar 2015 13:04:49 -0400 Message-ID: From: "John R Levine" To: "Wiley, Glen" In-Reply-To: <641EE49757824F4BBE5F863B22FDDBF23C454BA9@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: , <20150312210723.16146.qmail@ary.lan> <641EE49757824F4BBE5F863B22FDDBF23C454BA9@BRN1WNEXMBX01.vcorp.ad.vrsn.com> 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] Payment association records X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 13 Mar 2015 17:04:52 -0000 > In the PMTA draft I offered the same locator approach as SMIMEA, however > also mention that that is one of many possible means for locating the > record. It is not hard to image use cases in which a recipient would > want to expose multiple payment associations that don't necessarily > correspond to a mailbox. There's two separate questions here -- one is what name to use in the DNS, and the other is what sort of RR to put there. My point is that if the name corresponds to a hashed mailbox, the sensible name is ._mailbox.domain, regardless of what RRs one uses. If you want to publish PMTA records that don't correspond to a mailbox, that's no problem, use the same record with different names. For obvious reasons, it would not be great to have some _pmta names being mailboxes and some being something else. > Do you feel IBAN should be an exemplar? Yes, both because it's very widely used, and it brings in the important issue of payment systems that handle multiple currencies. I think you'll find that ACH and Bitcoin are fairly unusual in that they are each single currency. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. From nobody Fri Mar 13 11:10: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 EA55E1A1BC9 for ; Fri, 13 Mar 2015 11:10:14 -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 SpeYW1pl9PtC for ; Fri, 13 Mar 2015 11:10:13 -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 BE15E1A19F8 for ; Fri, 13 Mar 2015 11:10:13 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3l3ZnJ0Qrmz26t; Fri, 13 Mar 2015 19:10:12 +0100 (CET) Authentication-Results: mx.nohats.ca; dkim=pass reason="1024-bit key; unprotected key" header.d=nohats.ca header.i=@nohats.ca header.b=ab76h2zn; dkim-adsp=pass 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 Bq-hVpJIBclR; Fri, 13 Mar 2015 19:10:11 +0100 (CET) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Fri, 13 Mar 2015 19:10:11 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 756F8803E0; Fri, 13 Mar 2015 14:10:10 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1426270210; bh=JUPsXW00wK56uWBchZbS6jto9TurMyX9Qy2iML5J2m8=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=ab76h2znLk5x+piIXm2VYUnXtJZzJcQ+46FZA2wYpYxsM/KGHTAm9w6alWp92pvJk Kvf5F4J9riOUgusTdVNdnFo5o5S2minWFtTeisXDMiK3i6QH6SoI6ZB2luqYivHgWV 4/YOzZ3DzvliTvngcpPoAGMarDc59sXMgPoeJyYo= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id t2DIA9JR027476; Fri, 13 Mar 2015 14:10:10 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Fri, 13 Mar 2015 14:10:09 -0400 (EDT) From: Paul Wouters To: Pieter Lexis In-Reply-To: <5502E194.4020507@powerdns.com> Message-ID: References: <5502E194.4020507@powerdns.com> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8BIT Archived-At: Cc: dane@ietf.org Subject: Re: [dane] Start of WGLC for draft-ietf-dane-openpgpkey - *please* review. X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 13 Mar 2015 18:10:15 -0000 On Fri, 13 Mar 2015, Pieter Lexis wrote: Thanks for the review Pieter, > I'm very much on the "Yes, this is good"-side of things. > > 3.1: > The MAY in the last sentence is much too weak. We can’t have > interoperability without some stronger rules. Suggest moving this whole > section into -usage or mentioning that these will be specified in a > later document (-usage in this case). I'm happy to add a much larger recommendation advise in the -usage document, but I did want to mention it in the record format document because it _does_ affect the lookup mechanism that implementors might need or want to support. > 5.1: > Singling out one RRTYPE to push DNS-COOKIES feels weird. I'm just > mentioning it, but as this section is merely a suggestion, it is fine. I would gladly generalise it, but this document is not allowed to update the core DNS protocol. But I would like implementors to look at this and possibly put that restriction in. I'm actually worried about this, especially since using old software with the generic record syntax would actually not have any such limitation implemented. > Appendix A: > Two things: I suggest moving this to -usage and adding pseudocode > examples. The latter mostly to encourage more implementations. I thought about keeping it software agnostic, but in the end figured since gnupg has been around for over a decade, it is kind of similar to using openssl commands as example. But I have no problems making this software agnostic if the WG thinks that is more appropriate. Paul From nobody Fri Mar 13 11:24: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 6EE371A0187 for ; Fri, 13 Mar 2015 11:24:00 -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 Eh_L5tdNQki2 for ; Fri, 13 Mar 2015 11:23:58 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C7541A0097 for ; Fri, 13 Mar 2015 11:23:57 -0700 (PDT) Received: (qmail 71468 invoked from network); 13 Mar 2015 18:23:56 -0000 Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 13 Mar 2015 18:23:56 -0000 Date: 13 Mar 2015 18:23:34 -0000 Message-ID: <20150313182334.24823.qmail@ary.lan> From: "John Levine" To: dane@ietf.org Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: [dane] Names of mailbox records in draft-ietf-dane-smime and 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: Fri, 13 Mar 2015 18:24:00 -0000 I see that in dane-openpgpkey, the name on the record is ._openpgpkey.domain and in dane-smime, the name is: ._smimecert.domain These are two different names for the same mailbox. Since they use the same hash, wouldn't it be a better idea for both of them and any future RRs that use hashed mailboxes to use the same name? ._mailbox.domain There's no confusion between the two, since they're different RR types. The tree walking attacks are no different, since the attacker knows the small set of _token names that might be in use either way. I expect we will end up with conventional kludges to deal with the reality that systems treat mailbox names as case independent, e.g., publish the hash of the name as normally capitalized, but also publish a CNAME at the hash of the name with everything in lower case. (This doesn't work very well for non-ASCII names. It's a kludge, but like all kludges, it'll work better in practice than in theory.) With one name, we only need to do one kludge per mailbox, rather than the product of the number of mailboxes and the number of RR types. R's, John PS: The payment record draft that showed up a few days ago uses _pmta, but again, same mailbox, should be at the same name. From nobody Fri Mar 13 12:45: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 7F9231A020A for ; Fri, 13 Mar 2015 12:45:30 -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 aICngW00h5mm for ; Fri, 13 Mar 2015 12:45:28 -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 A7AEA1A001B for ; Fri, 13 Mar 2015 12:45:28 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3l3cv81fhXz27s; Fri, 13 Mar 2015 20:45:24 +0100 (CET) Authentication-Results: mx.nohats.ca; dkim=pass reason="1024-bit key; unprotected key" header.d=nohats.ca header.i=@nohats.ca header.b=oAAMsFXx; dkim-adsp=pass 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 QOodG_uZwRZw; Fri, 13 Mar 2015 20:45:23 +0100 (CET) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Fri, 13 Mar 2015 20:45:23 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id A6E6480A01; Fri, 13 Mar 2015 15:45:22 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1426275922; bh=+SFXhoDeNtzzsqN7hIRSFnD27vdWe7RJ5EflURoXo2U=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=oAAMsFXxJNVww4JOzweP1TRMbzvZ7Co3rnVTuaRSrLDFd1ruHmWJ3AeO5bb7/kRdX ljwlLiQP645ScYIpltkLr85C0JbWw2SKH7cuS3NNtO/27cdJsZflGzp1YRVq1JjArk dW4+d03z+mZPERYxEn2dCwqj3MC/0rjEu94S8skw= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id t2DJjL6h023322; Fri, 13 Mar 2015 15:45:22 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Fri, 13 Mar 2015 15:45:21 -0400 (EDT) From: Paul Wouters To: John Levine In-Reply-To: <20150313182334.24823.qmail@ary.lan> Message-ID: References: <20150313182334.24823.qmail@ary.lan> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: dane@ietf.org Subject: Re: [dane] Names of mailbox records in draft-ietf-dane-smime and 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: Fri, 13 Mar 2015 19:45:30 -0000 On Fri, 13 Mar 2015, John Levine wrote: > future RRs that use hashed mailboxes to use the same name? > > ._mailbox.domain > I expect we will end up with conventional kludges to deal with the > reality that systems treat mailbox names as case independent, e.g., > publish the hash of the name as normally capitalized, but also publish > a CNAME at the hash of the name with everything in lower case. (This > doesn't work very well for non-ASCII names. It's a kludge, but like > all kludges, it'll work better in practice than in theory.) With one > name, we only need to do one kludge per mailbox, rather than the > product of the number of mailboxes and the number of RR types. I can see how two different sysadmins administer the _openpgpkey and the _smimecert zones possibly even running on different nameservers. Like the smime one on Microsoft and the openpgp one on Linux. > PS: The payment record draft that showed up a few days ago uses _pmta, > but again, same mailbox, should be at the same name. If we really want a "user" to have their own private "space" inside the DNS, we should really give the user their own zone so they are the only ones signing for it. So then ._mailbox.domain should have an NS record. That might be a good idea, but very much out of scope here. Paul ps.Don't tell me you want to start running ANY queries against ._mailbox.domain :) From nobody Fri Mar 13 13:05:48 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9706D1A90B0 for ; Fri, 13 Mar 2015 13:05:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.137 X-Spam-Level: X-Spam-Status: No, score=-1.137 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TaJKumNM9veN for ; Fri, 13 Mar 2015 13: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 124AF1A90A4 for ; Fri, 13 Mar 2015 13:05:45 -0700 (PDT) Received: (qmail 86377 invoked from network); 13 Mar 2015 20:05:45 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=15168.55034319.k1503; bh=z2uJ4RDBM3GucMTu28Cz0Af9JO76njJzM43ctG13siA=; b=lzRtNp4vy/BEJ1UNfHZOKY7ozbIPkKxsvrGzB9wEjcNVro5AmA867U2+N8fHlw+EGt+jJS8GBso0wpIOjPPDJyD6XrX22lG2UBtY8EmCrcuF8wGlhkpCfnSZgm7i/eaPPHxNEqdBVgjW9diUsCBMN2sdcH2iEp2ZtAKS3B1x170nuro8wFaCT3BcA2m2/9aH0vbhdiec28poTlqk1h9UPAPkQre1Jix1Fc4o4/sSYyFMJKLdqhY2aYzCrRgG8Wmj 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=15168.55034319.k1503; bh=z2uJ4RDBM3GucMTu28Cz0Af9JO76njJzM43ctG13siA=; b=Y++ZwZTwoCmNeS3K6YJWL/9tmdqNVxbkkSz9MCWNvzGJyOGgWZ5YPDvdbNu+iskNb5YmrO4r/Ila1xOWs4jhwTtf8rVIkselFp6p/C/NUGjP6ckTLpaCuMCdL0jVcNuVMGY7w3uO9XRDzu5GU6VZyVzPnlvG8RX0KVZvKuhgbBgLXuZxqxbxn7xNMQLhIxXCx8eQami3FCxFKdrafY0onrX7LAk5HA/28UGcFGq4EwPsuvQuVhEW/unkUScKNoF5 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; 13 Mar 2015 20:05:44 -0000 Date: 13 Mar 2015 16:05:44 -0400 Message-ID: From: "John R Levine" To: "Paul Wouters" In-Reply-To: References: <20150313182334.24823.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] Names of mailbox records in draft-ietf-dane-smime and 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: Fri, 13 Mar 2015 20:05:47 -0000 > I can see how two different sysadmins administer the _openpgpkey and > the _smimecert zones possibly even running on different nameservers. > Like the smime one on Microsoft and the openpgp one on Linux. But we've gotten along with A and MX records at the same name for 30 years. By this logic, every new RR type should have its own name prefix, just in case someone might want to manage it differently. I hope we agree that's ridiculous. There's no special processing for OPENPGPKEY or SMIMEA records, so there's no reason they would be handled differently by name servers. If someone wants to manage OPENPGPKEY and SMIMEA records separately, why should the answer be any different than if they want to manage A and MX records separately? Do it in your provisioning system, don't put extra noise in the DNS. > ps.Don't tell me you want to start running ANY queries against > ._mailbox.domain :) Naah, my qmail is patched. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. From nobody Fri Mar 13 13:10: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 BACE41A1B2E for ; Fri, 13 Mar 2015 13:10:23 -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 E8q_vt1w7V2e for ; Fri, 13 Mar 2015 13:10:23 -0700 (PDT) Received: from proper.com (Opus1.Proper.COM [207.182.41.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F107F1A1AE8 for ; Fri, 13 Mar 2015 13:10:22 -0700 (PDT) Received: from [10.20.30.101] (50-1-99-2.dsl.dynamic.fusionbroadband.com [50.1.99.2]) (authenticated bits=0) by proper.com (8.15.1/8.14.9) with ESMTPSA id t2DKAL1D020530 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 13 Mar 2015 13:10:22 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: proper.com: Host 50-1-99-2.dsl.dynamic.fusionbroadband.com [50.1.99.2] claimed to be [10.20.30.101] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Paul Hoffman In-Reply-To: <20150313182334.24823.qmail@ary.lan> Date: Fri, 13 Mar 2015 13:10:21 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <33E881E6-A73B-4EC3-AAD9-E07B82C21D83@vpnc.org> References: <20150313182334.24823.qmail@ary.lan> To: "" X-Mailer: Apple Mail (2.2070.6) Archived-At: Subject: Re: [dane] Names of mailbox records in draft-ietf-dane-smime and 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: Fri, 13 Mar 2015 20:10:23 -0000 > On Mar 13, 2015, at 11:23 AM, John Levine wrote: >=20 > I see that in dane-openpgpkey, the name on the record is >=20 > ._openpgpkey.domain >=20 > and in dane-smime, the name is: >=20 > ._smimecert.domain >=20 > These are two different names for the same mailbox. Since they use > the same hash, wouldn't it be a better idea for both of them and any > future RRs that use hashed mailboxes to use the same name? >=20 > ._mailbox.domain This could go either way. If the WG thinks that the user, or someone = responsible for the user, will add and change DNS records for that user, = your proposal would clearly be better because you could delegate the = user to a new subzone. On the other hand, if the WG thinks that the = security admin will be the one adding and changing records for a = particular type of mail security, then the design we are using now is = better. I lean towards the second, but can see the merit of the first = now that people are thinking of using this for things other than just = mail security. --Paul Hoffman= From nobody Fri Mar 13 13:18: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 AF1E81A90DC for ; Fri, 13 Mar 2015 13:18:11 -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 KmClS8ogP0Xu for ; Fri, 13 Mar 2015 13:18:09 -0700 (PDT) Received: from mail-ie0-x229.google.com (mail-ie0-x229.google.com [IPv6:2607:f8b0:4001:c03::229]) (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 09CA11A90A4 for ; Fri, 13 Mar 2015 13:17:40 -0700 (PDT) Received: by iecvj10 with SMTP id vj10so120316956iec.0 for ; Fri, 13 Mar 2015 13:17:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=VlZhHbUqJYGpMTWlQaXlIDJtFF8OH2MuYPUTcZIsGys=; b=HA7D+IWOJy9ZA5l2DRPUvAiI/k9sFAv7mzaYT8Tr+Mt3/Z/XP8gKVYvW+TZ1ppvri0 HPHX9xqwWEeJK+WiOku52N4B9IMtQUGq5cgriHbmsMoMI1jqMNStMtGfNJkN0IcdJUo1 vJvO4e9O7RWlr87mEswPW+gukipwDcDEWFuOSsl/aoCyfv/KQjcfuUNMV8XoskatSgvo S91nFW23RKfSMaEpRyiS+qR/aFLGdso4pXlCq8oHg6HgyFIA0lMmAJFW3EoI1+kZ9k1Z /19+vgpvgDk5FbYsEEr8tmKKetVgXMqdxXomYCesZEqVpjxsUdmOnWeMXNLMbaxRhZWm do4w== MIME-Version: 1.0 X-Received: by 10.42.79.205 with SMTP id s13mr60562068ick.67.1426277853368; Fri, 13 Mar 2015 13:17:33 -0700 (PDT) Received: by 10.64.57.201 with HTTP; Fri, 13 Mar 2015 13:17:33 -0700 (PDT) In-Reply-To: References: <20150313182334.24823.qmail@ary.lan> Date: Fri, 13 Mar 2015 13:17:33 -0700 Message-ID: From: Brian Dickson To: "dane@ietf.org" Content-Type: multipart/alternative; boundary=20cf3011e345cd163a05113130f4 Archived-At: Subject: [dane] Fwd: Names of mailbox records in draft-ietf-dane-smime and 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: Fri, 13 Mar 2015 20:18:11 -0000 --20cf3011e345cd163a05113130f4 Content-Type: text/plain; charset=UTF-8 Forgot to CC the list on my reply to John. (Sorry for the duplicate, John.) There are some problems that can only be solved by adding a level of indirection. However, in the reverse direction (removing a level of indirection), this can be done trivially: DNAME. I.e. for those places where putting both RRtypes at the same owner name is desired, it is enough to add one DNAME record that points to the other place in the DNS tree. (It doesn't matter much which one is "primary", other than maybe some performance). DNAME-aware things will use the DNAME. DNAME-unaware things will expect, receive, and use, synthesized CNAMEs. This scales a lot better (DNAME vs manually- or script- maintained CNAMEs). Having DNAME then allows the case-munging CNAME-per-mailbox to also scale. So, I do not support unifying the _labels to a single _label. Brian On Fri, Mar 13, 2015 at 11:23 AM, John Levine wrote: > I see that in dane-openpgpkey, the name on the record is > > ._openpgpkey.domain > > and in dane-smime, the name is: > > ._smimecert.domain > > These are two different names for the same mailbox. Since they use > the same hash, wouldn't it be a better idea for both of them and any > future RRs that use hashed mailboxes to use the same name? > > ._mailbox.domain > > There's no confusion between the two, since they're different RR > types. The tree walking attacks are no different, since the attacker > knows the small set of _token names that might be in use either way. > > I expect we will end up with conventional kludges to deal with the > reality that systems treat mailbox names as case independent, e.g., > publish the hash of the name as normally capitalized, but also publish > a CNAME at the hash of the name with everything in lower case. (This > doesn't work very well for non-ASCII names. It's a kludge, but like > all kludges, it'll work better in practice than in theory.) With one > name, we only need to do one kludge per mailbox, rather than the > product of the number of mailboxes and the number of RR types. > > R's, > John > > PS: The payment record draft that showed up a few days ago uses _pmta, > but again, same mailbox, should be at the same name. > > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane > --20cf3011e345cd163a05113130f4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Forgot to CC the list on my reply to John. (Sorry for the = duplicate, John.)


There = are some problems that can only be solved by adding a level of indirection.=

However, in the reverse direction (removing a level of = indirection), this can be done trivially: DNAME.

I= .e. for those places where putting both RRtypes at the same owner name is d= esired, it is enough to add one DNAME record that points to the other place= in the DNS tree. (It doesn't matter much which one is "primary&qu= ot;, other than maybe some performance).

DNAME-awa= re things will use the DNAME. DNAME-unaware things will expect, receive, an= d use, synthesized CNAMEs.

This scales a lot bette= r (DNAME vs manually- or script- maintained CNAMEs).

Having DNAME then allows the case-munging CNAME-per-mailbox to also scal= e.

So, I do not support unifying the _labels to a = single _label.
Brian

On Fri, M= ar 13, 2015 at 11:23 AM, John Levine <johnl@taugh.com> wrote:<= br>
I see that in dane-openpgpkey, the name o= n the record is

=C2=A0 =C2=A0 =C2=A0 =C2=A0 <hash>._openpgpkey.domain

and in dane-smime, the name is:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 <hash>._smimecert.domain

These are two different names for the same mailbox.=C2=A0 Since they use the same hash, wouldn't it be a better idea for both of them and any future RRs that use hashed mailboxes to use the same name?

=C2=A0 =C2=A0 =C2=A0 =C2=A0 <hash>._mailbox.domain

There's no confusion between the two, since they're different RR types.=C2=A0 The tree walking attacks are no different, since the attacker<= br> knows the small set of _token names that might be in use either way.

I expect we will end up with conventional kludges to deal with the
reality that systems treat mailbox names as case independent, e.g.,
publish the hash of the name as normally capitalized, but also publish
a CNAME at the hash of the name with everything in lower case.=C2=A0 (This<= br> doesn't work very well for non-ASCII names.=C2=A0 It's a kludge, bu= t like
all kludges, it'll work better in practice than in theory.)=C2=A0 With = one
name, we only need to do one kludge per mailbox, rather than the
product of the number of mailboxes and the number of RR types.

R's,
John

PS: The payment record draft that showed up a few days ago uses _pmta,
but again, same mailbox, should be at the same name.

_______________________________________________
dane mailing list
dane@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/dane


--20cf3011e345cd163a05113130f4-- From nobody Fri Mar 13 13:26:16 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46C311A3BA3 for ; Fri, 13 Mar 2015 13:26:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1 X-Spam-Level: X-Spam-Status: No, score=-1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_SIGNED=0.1, T_DKIM_INVALID=0.01, 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 aU2BC0hZkSGh for ; Fri, 13 Mar 2015 13:26:14 -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 1C9CB1A1EF4 for ; Fri, 13 Mar 2015 13:26:14 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3l3dpB5kpgz2C5; Fri, 13 Mar 2015 21:26:10 +0100 (CET) Authentication-Results: mx.nohats.ca; dkim=fail reason="verification failed; unprotected key" header.d=nohats.ca header.i=@nohats.ca header.b=Is2VYP8+; dkim-adsp=fail (unprotected policy) 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 nEzFItgho9Wu; Fri, 13 Mar 2015 21:25:30 +0100 (CET) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Fri, 13 Mar 2015 21:25:29 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 1E4E580A01; Fri, 13 Mar 2015 16:25:29 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1426278329; bh=HrpOJWvDugn2xbnsbe3jW9jyGh4bYEza/i0f49LotoM=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=Is2VYP8+0o47giEgYdTCVlK3RYPyU5edJUrxLL5z7K2PxPY3Y6HBAONI93GGuV+dr h6Glk7AAspVwxY977YtSPtqiVgB2qujQeVbRKmjo8VmV7i4wmboBcQGb9gOA6dosZd MKyw1HvIBykZIvCeAJBgGpNW+UVKODFVBMNj/ALw= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id t2DKPSXk024757; Fri, 13 Mar 2015 16:25:28 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Fri, 13 Mar 2015 16:25:28 -0400 (EDT) From: Paul Wouters To: John R Levine In-Reply-To: Message-ID: References: <20150313182334.24823.qmail@ary.lan> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: dane@ietf.org Subject: [dane] ***UNCHECKED*** Re: Names of mailbox records in draft-ietf-dane-smime and 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: Fri, 13 Mar 2015 20:26:15 -0000 On Fri, 13 Mar 2015, John R Levine wrote: >> I can see how two different sysadmins administer the _openpgpkey and >> the _smimecert zones possibly even running on different nameservers. >> Like the smime one on Microsoft and the openpgp one on Linux. > > But we've gotten along with A and MX records at the same name for 30 years. But A and MX records live within the same zone, whereas _openpgpkey.tld currently is its own zone. It is a nice and clean separation. For example, when I filled this up with 3000 records for _openpgpkey.fedoraproject.org it became obvious this zone couldn't live in the same git repository as everything else due to its sheer size. The same might no be true for some payment record or email alias record. We could use _mailbox, but I don't see much advantage from tying different RRtype's at the same prefix. What is affected by this other then a line of code somewhere in a program only few few people will see? As you said, people still need to query for the individual QTYPEs. Paul From nobody Fri Mar 13 13:48: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 52FD71A6F87 for ; Fri, 13 Mar 2015 13:48:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.137 X-Spam-Level: X-Spam-Status: No, score=-1.137 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w1JMOcsfZM0e for ; Fri, 13 Mar 2015 13:48: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 3C7701A1B95 for ; Fri, 13 Mar 2015 13:48:31 -0700 (PDT) Received: (qmail 91327 invoked from network); 13 Mar 2015 20:48:30 -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=164be.55034d1e.k1503; bh=ewR5+1D2TrXFMX4eeQhws5sVkZJcZOijuzVGyeIXk8U=; b=Vk5OxQYbFoKvX2wjRSC+a9EUj90ZtZgKbiCnqDyvv+ibNzzlEg+gdjonCS4mU+VJjC57N/d4uvlryQ2dbw9QcZgoXvgM9Z8896HxZ4Sly1kFglhZyj7C5CPOvV41TqqJjQ6jTEHoYKJCUA9EBTtSb1QLHf0UhPOrLmusCgrMScIP6QRtlyByCEe2IoWrnGy3zYk3d7ZrKg1mMl1lWn5T/+H8dfa+wrN40+IIZu/A75l+eEPHDK/xpU3L0hB/zUz1 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=164be.55034d1e.k1503; bh=ewR5+1D2TrXFMX4eeQhws5sVkZJcZOijuzVGyeIXk8U=; b=xiNOsv/VvyNaZMulPBT4h2Ganf/UP8WedYlKbhnKnJ1ok1coyh4U8ys2uly5xoASSI2lOpuDs8Pw4wgO98tuDLo/J9RiOGsR1FDN2hrqS6qa5IENwbh20w8wJdYkpYztP+CgEAGJmzRy/R/Prloppx315MudAu5Y3WAB/Shh8qBlaZqP9nonGs75jLXnE5YReenCiAol0Q6uQG+l8kLorNyfEba1eEx49vPjuYIrI2T8/ZX3zMkvRTsZ9Qj0a6TW 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; 13 Mar 2015 20:48:29 -0000 Date: 13 Mar 2015 16:48:29 -0400 Message-ID: From: "John R Levine" To: "Paul Wouters" In-Reply-To: References: <20150313182334.24823.qmail@ary.lan> User-Agent: Alpine 2.11 (OSX 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Archived-At: Cc: dane@ietf.org Subject: Re: [dane] Names of mailbox records in draft-ietf-dane-smime and 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: Fri, 13 Mar 2015 20:48:32 -0000 >> But we've gotten along with A and MX records at the same name for 30 years. > > But A and MX records live within the same zone, whereas _openpgpkey.tld > currently is its own zone. It is a nice and clean separation. It sounds like you are you saying that every new RR type should come with a prefix, to provide this same nice clean separation. If not, what's different about this RR type? It's not like we've never had zones with a lot of leaf names before. > For example, when I filled this up with 3000 records for > _openpgpkey.fedoraproject.org it became obvious this zone couldn't live > in the same git repository as everything else due to its sheer size. The > same might no be true for some payment record or email alias record. Maybe I'm spoiled, but a zone with 3000 records does not seem particularly large to me. (One of my zones, admittedly an outlier, has 110,000, but it poses no problems for the python and mysql scripts and NSD servers I use to manage my DNS. I update it every day.) Poor provisioning tools don't strike me as a very good reason to make long term DNS design decisions. That's how we ended up with everything overloaded onto TXT. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. From nobody Fri Mar 13 13:54: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 23CDD1A8778 for ; Fri, 13 Mar 2015 13:54:44 -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 ka0yC_55FH93 for ; Fri, 13 Mar 2015 13:54:43 -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 DCB571A879E for ; Fri, 13 Mar 2015 13:54:40 -0700 (PDT) Received: (qmail 92172 invoked from network); 13 Mar 2015 20:54:39 -0000 Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 13 Mar 2015 20:54:39 -0000 Date: 13 Mar 2015 20:54:17 -0000 Message-ID: <20150313205417.25296.qmail@ary.lan> From: "John Levine" To: dane@ietf.org In-Reply-To: <33E881E6-A73B-4EC3-AAD9-E07B82C21D83@vpnc.org> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Cc: paul.hoffman@vpnc.org Subject: Re: [dane] Names of mailbox records in draft-ietf-dane-smime and 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: Fri, 13 Mar 2015 20:54:44 -0000 > On the other hand, if >the WG thinks that the security admin will be the one adding and changing records for >a particular type of mail security, then the design we are using now is better. I'm trying to imagine a situation where one security admin assigns PGP keys, a different one assigns S/MIME keys for the same users, and they hate each other so much that they need to use separate DNS provisioning systems. Then I try to imagine how those same two admins nonetheless manage to get both sets of keys into the same MUAs. Now I'll be quiet. R's, John From nobody Fri Mar 13 14: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 51F621A0282 for ; Fri, 13 Mar 2015 14:10:32 -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 QzN36EIH2naZ for ; Fri, 13 Mar 2015 14:10:31 -0700 (PDT) Received: from mail-ie0-x233.google.com (mail-ie0-x233.google.com [IPv6:2607:f8b0:4001:c03::233]) (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 E648D1A00CD for ; Fri, 13 Mar 2015 14:10:30 -0700 (PDT) Received: by iecvj10 with SMTP id vj10so122668013iec.0 for ; Fri, 13 Mar 2015 14:10:30 -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=Vj2JDsWLhWz5SExgfNCZ5rruwH9jpBjlGUG0ocqhCV4=; b=Vx0iKyXXf+KUIhFci2tESl3DXAP1dibVeSnQZferb+FW3voV2qe1T6WsnfRLp7NEBd PQKUYQbCoxjKWTli4LxHW8Tr2r8FbxLWHwuAG0NxihRcTc7vMr1dJtmJ1wBfIcAumbUk fAbdDTG5WYAy2rY/XW1sI35KuEOKSYBXGcJfYZ+9W3LS72oAj6goq4f/gCoNm2wMvlOi /DFOiceVj2DJ942wZk/dp4pib2JXbvNjqIIcVt9bNRe9eJUXcJiWLDMtosGSaVQZaaVf Z/mi5CwOayGRPUtkeQ7jvnxZtm2GjoB1V+sfPoSjccUnU1s7w5tH3rFu5SEWYHbZ3kWN 48gg== MIME-Version: 1.0 X-Received: by 10.42.79.205 with SMTP id s13mr60889825ick.67.1426281029722; Fri, 13 Mar 2015 14:10:29 -0700 (PDT) Received: by 10.64.57.201 with HTTP; Fri, 13 Mar 2015 14:10:29 -0700 (PDT) In-Reply-To: <20150313205417.25296.qmail@ary.lan> References: <33E881E6-A73B-4EC3-AAD9-E07B82C21D83@vpnc.org> <20150313205417.25296.qmail@ary.lan> Date: Fri, 13 Mar 2015 14:10:29 -0700 Message-ID: From: Brian Dickson To: John Levine Content-Type: multipart/alternative; boundary=20cf3011e34520734c051131ee22 Archived-At: Cc: Paul Hoffman , "dane@ietf.org" Subject: Re: [dane] Names of mailbox records in draft-ietf-dane-smime and 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: Fri, 13 Mar 2015 21:10:32 -0000 --20cf3011e34520734c051131ee22 Content-Type: text/plain; charset=UTF-8 On Fri, Mar 13, 2015 at 1:54 PM, John Levine wrote: > > I'm trying to imagine a situation where one security admin assigns PGP > keys, a different one assigns S/MIME keys for the same users, and they > hate each other so much that they need to use separate DNS > provisioning systems. You obviously haven't had the fun of big corporate environments. They might not even know who each other are, let alone trust each other. And, there may be anti-social-engineering reasons that they are not allowed to trust each other. FWIW, I doubt very much that PGP keys are assigned by a security admin. > Then I try to imagine how those same two admins > nonetheless manage to get both sets of keys into the same MUAs. > > If you have to get public keys INTO the MUA, you are (by definition) not using DNS. The entire point of these proposals are for publishing and querying/discovery via DNS. Or are you thinking private keys? For PGP and S/MIME, I believe those are apples & oranges. Again, it is the MUA developer's responsibility to make them both work, and I expect a "pull" model vs a "push" model. Brian --20cf3011e34520734c051131ee22 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Mar 13, 2015 at 1:54 PM, John Levine <johnl@taugh.com> wrote:

I'm trying to imagine a situation where one security admin assig= ns PGP
keys, a different one assigns S/MIME keys for the same users, and they
hate each other so much that they need to use separate DNS
provisioning systems.=C2=A0

You obviously = haven't had the fun of big corporate environments.

=
They might not even know who each other are, let alone trust each othe= r.

And, there may be anti-social-engineering reaso= ns that they are not allowed
to trust each other.

<= /div>
FWIW, I doubt very much that PGP keys are assigned by a security = admin.

=C2=A0
= Then I try to imagine how those same two admins
nonetheless manage to get both sets of keys into the same MUAs.


If you have to get public keys INTO th= e MUA, =C2=A0you are (by definition) not using DNS.

The entire point of these proposals are for publishing and querying/disco= very via DNS.

Or are you thinking private keys? Fo= r PGP and S/MIME, I believe those
are apples & oranges. Again= , it is the MUA developer's responsibility to make them
both = work, and I expect a "pull" model vs a "push" model.

Brian

--20cf3011e34520734c051131ee22-- From nobody Fri Mar 13 15:19: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 EC8D51A87C2 for ; Fri, 13 Mar 2015 15:19:57 -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 3EvR29hnjwsn for ; Fri, 13 Mar 2015 15:19:57 -0700 (PDT) Received: from homiemail-a96.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 4639F1A1E0B for ; Fri, 13 Mar 2015 15:19:57 -0700 (PDT) Received: from homiemail-a96.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a96.g.dreamhost.com (Postfix) with ESMTP id 0A67D3B807B; Fri, 13 Mar 2015 15:19:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=ZOovNRlIRqr/to zziHpicIOn3yY=; b=ZsS1ElHAb+/MpEH1uhKNBaiyb/E/r7hjuBJmWOOuDtWoSU OescvuROiyAVPzaSLOykLsfiWKaL0tRqb0CRgph8S0LDO8GBpAzmkSjrFgkfudJ1 phKWSg/pmu9vH+Fj0WmTdpmvcHHeCZuJXbwi/tSUXEAdoFEnaOmhWldEwTXJA= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a96.g.dreamhost.com (Postfix) with ESMTPA id B5AE63B8072; Fri, 13 Mar 2015 15:19:56 -0700 (PDT) Date: Fri, 13 Mar 2015 17:19:56 -0500 From: Nico Williams To: John Levine Message-ID: <20150313221955.GB3479@localhost> References: <20150313182334.24823.qmail@ary.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150313182334.24823.qmail@ary.lan> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: dane@ietf.org Subject: Re: [dane] Names of mailbox records in draft-ietf-dane-smime and 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: Fri, 13 Mar 2015 22:19:58 -0000 On Fri, Mar 13, 2015 at 06:23:34PM -0000, John Levine wrote: > I see that in dane-openpgpkey, the name on the record is > > ._openpgpkey.domain > > and in dane-smime, the name is: > > ._smimecert.domain > > These are two different names for the same mailbox. Since they use > the same hash, wouldn't it be a better idea for both of them and any > future RRs that use hashed mailboxes to use the same name? > > ._mailbox.domain I prefer the latter. > PS: The payment record draft that showed up a few days ago uses _pmta, > but again, same mailbox, should be at the same name. If they are all the same thing, they should all be using the same domainname. If it could make sense to separate them, then not. But I think these are all the same thing. Nico -- From nobody Fri Mar 13 15:33: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 CE0411A8738 for ; Fri, 13 Mar 2015 15:33:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.911 X-Spam-Level: X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 fCy-7JVLJELp for ; Fri, 13 Mar 2015 15:33:53 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [199.6.1.65]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 160081A8731 for ; Fri, 13 Mar 2015 15:33:53 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.ams1.isc.org (Postfix) with ESMTP id E91DD1FCC7F; Fri, 13 Mar 2015 22:33:49 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 40185160067; Fri, 13 Mar 2015 22:40:54 +0000 (UTC) Received: from rock.dv.isc.org (c211-30-175-41.carlnfd1.nsw.optusnet.com.au [211.30.175.41]) by zmx1.isc.org (Postfix) with ESMTPSA id 0CC44160055; Fri, 13 Mar 2015 22:40:54 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id EAC992B557DC; Sat, 14 Mar 2015 09:33:50 +1100 (EST) To: Nico Williams From: Mark Andrews References: <20150313182334.24823.qmail@ary.lan> <20150313221955.GB3479@localhost> In-reply-to: Your message of "Fri, 13 Mar 2015 17:19:56 -0500." <20150313221955.GB3479@localhost> Date: Sat, 14 Mar 2015 09:33:49 +1100 Message-Id: <20150313223350.EAC992B557DC@rock.dv.isc.org> Archived-At: Cc: John Levine , dane@ietf.org Subject: Re: [dane] Names of mailbox records in draft-ietf-dane-smime and 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: Fri, 13 Mar 2015 22:33:55 -0000 Why are we arguing about this? We can support both seperate zones and combined zones. Just use "_openpgpkey DNAME _mailbox" if you want to collape the number of zones. Mark In message <20150313221955.GB3479@localhost>, Nico Williams writes: > On Fri, Mar 13, 2015 at 06:23:34PM -0000, John Levine wrote: > > I see that in dane-openpgpkey, the name on the record is > > > > ._openpgpkey.domain > > > > and in dane-smime, the name is: > > > > ._smimecert.domain > > > > These are two different names for the same mailbox. Since they use > > the same hash, wouldn't it be a better idea for both of them and any > > future RRs that use hashed mailboxes to use the same name? > > > > ._mailbox.domain > > I prefer the latter. > > > PS: The payment record draft that showed up a few days ago uses _pmta, > > but again, same mailbox, should be at the same name. > > If they are all the same thing, they should all be using the same > domainname. If it could make sense to separate them, then not. But I > think these are all the same thing. > > Nico > -- > > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Fri Mar 13 16:07: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 D05211A874D for ; Fri, 13 Mar 2015 16:07:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.862 X-Spam-Level: X-Spam-Status: No, score=0.862 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DTWQJOUn2kmT for ; Fri, 13 Mar 2015 16:07:44 -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 959F41A1BDC for ; Fri, 13 Mar 2015 16:07:43 -0700 (PDT) Received: (qmail 39371 invoked from network); 13 Mar 2015 23:07:42 -0000 Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 13 Mar 2015 23:07:42 -0000 Date: 13 Mar 2015 23:07:20 -0000 Message-ID: <20150313230720.25751.qmail@ary.lan> From: "John Levine" To: dane@ietf.org In-Reply-To: <20150313223350.EAC992B557DC@rock.dv.isc.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] Names of mailbox records in draft-ietf-dane-smime and 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: Fri, 13 Mar 2015 23:07:45 -0000 In article <20150313223350.EAC992B557DC@rock.dv.isc.org> you write: > >Why are we arguing about this? We can support both seperate zones >and combined zones. Just use "_openpgpkey DNAME _mailbox" if you >want to collape the number of zones. That would certainly work, but if there isn't actually an important operational reason to use more than one zone for per-mailbox data, why use more magic token names than we need to? Now that I look at it again, I don't follow Paul W's argument about large numbers of names in the zone. He can have a separate zone for his PGP keys whether it's _openpgpkey.domain or _mailbox.domain. For people who manage their file of S/MIME and PGP key records separately, this should usually do the trick: $ cat file-of-openpgpkey-records file-of-smimea-records > my-mailbox-zone R's, John From nobody Fri Mar 13 16:26: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 BBBC91A875A for ; Fri, 13 Mar 2015 16:26:34 -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 0LlmfFC3B0ys for ; Fri, 13 Mar 2015 16:26:33 -0700 (PDT) Received: from ore.jhcloos.com (ore.jhcloos.com [198.147.23.85]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD8C91A8749 for ; Fri, 13 Mar 2015 16:26:32 -0700 (PDT) Received: by ore.jhcloos.com (Postfix, from userid 10) id 122F11E3AF; Fri, 13 Mar 2015 23:26:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=ore14; t=1426289192; bh=wuFAPbUyUdZKmbBbJx5VeLBXpyfHsZ/vVXvO/1UvOAQ=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=HZpmr7lLMJZEDXib75TfvwqV2kwMaq/DfdNzZ2KB96SaDiNzBYc7B1A/77JZWAjTq 2XXbL79QN/3oqpLHezO/Wnw0T/Qxs3UK8EN3gFwV/nUs7yooxaJMgKo/NMCRfgsUL7 DOanIpHkNV5xtedFpmmltOmB6y7DBXOVap34qIRM= Received: by carbon.jhcloos.org (Postfix, from userid 500) id BF5411073F001; Fri, 13 Mar 2015 23:25:22 +0000 (UTC) From: James Cloos To: dane@ietf.org In-Reply-To: <20150313182334.24823.qmail@ary.lan> (John Levine's message of "13 Mar 2015 18:23:34 -0000") References: <20150313182334.24823.qmail@ary.lan> 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: Fri, 13 Mar 2015 19:25:22 -0400 Message-ID: Lines: 15 MIME-Version: 1.0 Content-Type: text/plain X-Hashcash: 1:28:150313:dane@ietf.org::3A0jyBCqKeOolSmj:00012n48 X-Hashcash: 1:28:150313:johnl@taugh.com::LcXzDg45pz7EmNY1:0P9W3J Archived-At: Cc: John Levine Subject: Re: [dane] Names of mailbox records in draft-ietf-dane-smime and 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: Fri, 13 Mar 2015 23:26:34 -0000 >>>>> "JL" == John Levine writes: JL> ._mailbox.domain I posted in the past that smime and openpgp should use the same _name (search the archives for '_at'). I gave up when it got zero traction. It also would be a good place to look for TLSA RRs for certs supplied by tls clients which have mailbox-like names. I hope you hae better luck. -JimC -- James Cloos OpenPGP: 0x997A9F17ED7DAEA6 From nobody Fri Mar 13 19:10: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 70F841A01F6 for ; Fri, 13 Mar 2015 19:10:06 -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 GaSI7JHjMYEC for ; Fri, 13 Mar 2015 19:10: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 4F23A1A01BA for ; Fri, 13 Mar 2015 19:10:04 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3l3nQx3F3tz28R; Sat, 14 Mar 2015 03:10:01 +0100 (CET) Authentication-Results: mx.nohats.ca; dkim=pass reason="1024-bit key; unprotected key" header.d=nohats.ca header.i=@nohats.ca header.b=hlm2M125; dkim-adsp=pass 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 q3wO3K9BI0jR; Sat, 14 Mar 2015 03:09:59 +0100 (CET) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Sat, 14 Mar 2015 03:09:59 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 484C080A01; Fri, 13 Mar 2015 22:09:58 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1426298998; bh=VN+syR14DlhL4ivNqWRlDflwo6NvB3znxi6v9cAy0H0=; h=Date:From:To:cc:Subject; b=hlm2M125GqGWUIXU4NxqA6d0u/Cq5h5T1dFbCxTZQrooJqh7tZfhsI5QMipT/Omm0 7gPMczrXF7GYkdTUAgGmEZwx20BNJkck79Vh7QOuVooJZFU989N5LBKNwPml3fYmfG Hcq6yuBwaoT499VD9e/D4xiU74fWMn6H/6cgN5Lk= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id t2E29vMY010539; Fri, 13 Mar 2015 22:09:57 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Fri, 13 Mar 2015 22:09:57 -0400 (EDT) From: Paul Wouters To: dane WG list Message-ID: User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT Archived-At: Cc: Wil Tan Subject: Re: [dane] Comments on draft-ietf-dane-openpgpkey-02 (fwd) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Mar 2015 02:10:06 -0000 Wil Tan wrote: (added the dane list in my reply) Thanks for your review Wil. > My comments on draft-ietf-dane-openpgpkey-02: > > 1) Section 3, in case of EAI, it should specify the character encoding of > the local-part on which to perform the SHA224 function. That's a valid point. Should we say that it should be UTF-8 ? I will add some text for this if I get a few more agreeing nods of people. > 2) Section 3, it should probably reference RFC5322 instead of 2822? In fact, > would it make more sense to reference RFC5321 instead of RFC5322? You are right, that would make more sense. If no one objects, I will make that change. > 3) Section 3.1, mapping should only be done if the software knows for sure > that the rules it is applying are correct for that domain. I suggest > qualifying the last sentence so that it reads: > >    Software implementing DNS lookup for the OPENPGPKEY RRtype MAY perform > similar translations rules while trying to find the OPENPGPKEY > record if it has definitive knowledge of the rules applicable at the target > domain. I agree with the sentiment, although I'm not sure if "definitive knowledge" about a "domain" is a fair thing to say, since there is not RFC where an implementor could go and request such information about how to get such knowledge of a certain domain. But I also have no better alternative text suggestion right now. Anyone else? Paul From nobody Fri Mar 13 19:24: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 9FF171A884B for ; Fri, 13 Mar 2015 19:24:02 -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 bMXfOkIxDHUw for ; Fri, 13 Mar 2015 19:23:56 -0700 (PDT) Received: from proper.com (Opus1.Proper.COM [207.182.41.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D98F31A87EF for ; Fri, 13 Mar 2015 19:23:55 -0700 (PDT) Received: from [10.20.30.101] (50-1-99-2.dsl.dynamic.fusionbroadband.com [50.1.99.2]) (authenticated bits=0) by proper.com (8.15.1/8.14.9) with ESMTPSA id t2E2Nr5w062478 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 13 Mar 2015 19:23:53 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: proper.com: Host 50-1-99-2.dsl.dynamic.fusionbroadband.com [50.1.99.2] claimed to be [10.20.30.101] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Paul Hoffman In-Reply-To: Date: Fri, 13 Mar 2015 19:23:52 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <36874A39-B6A4-4D28-BE6B-39D2FE4D6BA6@vpnc.org> References: To: Paul Wouters X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: Wil Tan , dane WG list Subject: Re: [dane] Comments on draft-ietf-dane-openpgpkey-02 (fwd) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Mar 2015 02:24:02 -0000 On Mar 13, 2015, at 7:09 PM, Paul Wouters wrote: >> My comments on draft-ietf-dane-openpgpkey-02: >> 1) Section 3, in case of EAI, it should specify the character = encoding of >> the local-part on which to perform the SHA224 function. >=20 > That's a valid point. Should we say that it should be UTF-8 ? I will > add some text for this if I get a few more agreeing nods of people. Maybe I've lost track of EAI, but from RFC 6530, I got the impression = that all addresses already were in UTF-8. If so, you don't want to = encourage people to double-encode. --Paul Hoffman= From nobody Fri Mar 13 20:26:16 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6B5B1A9252 for ; Fri, 13 Mar 2015 20:26:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.363 X-Spam-Level: X-Spam-Status: No, score=0.363 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0-NSlJYqiUoC for ; Fri, 13 Mar 2015 20:26:13 -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 862FF1A924C for ; Fri, 13 Mar 2015 20:26:13 -0700 (PDT) Received: (qmail 64777 invoked from network); 14 Mar 2015 03:26:12 -0000 Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 14 Mar 2015 03:26:12 -0000 Date: 14 Mar 2015 03:25:50 -0000 Message-ID: <20150314032550.26364.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] Comments on draft-ietf-dane-openpgpkey-02 (fwd) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Mar 2015 03:26:14 -0000 >> 1) Section 3, in case of EAI, it should specify the character encoding of >> the local-part on which to perform the SHA224 function. Paul H is right. Regular mail addresses are 7-bit ASCII, and EAI is UTF-8. Those are the only two choices, and since ASCII is a subset of UTF-8, it's really only one choice. See RFC 6530. Section 3.1 seems very ill-advised -- it says the client probes for various addresses which might be the person you want, but might equally well be someone else if you guess wrong. While it is unusual for foobar@domain and FOOBAR@domain and foo.bar@domain to be different people, that is and always has been entirely valid. With + and - variants, there's no consistency at all. Nerds who are used to sendmail think it's normal for foo+bar to be a variant of foo, but the other 98% of the world doesn't. And some even use foo-bar as a variant of foo. My advice would be to remove all of the current text in 3.1 and replace it with a note that systems that publish records at names that are hashed mailboxes may publish CNAMEs for variant mailbox hashes that they consider to be equivalent. That's safe, since the party publishing the variants is the one that knows what they mean. It's also fairly hopeless once you get beyond folding stuff to lower case and stripping dots since the number of possibilities explodes. R's, John PS: If we have name variant rules, which I'm not at all sure we should, they really should be the same for OPENPGPKEY and SMIMEA and anything else that uses a hashed mailbox. This suggests if we go down that road, the name management belongs in a separate document from the definition of the RR type, and it needs attention from the SMTP crowd. From nobody Fri Mar 13 21:08: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 9DF3B1A8A25 for ; Fri, 13 Mar 2015 21:08:55 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1aZAWkJPd8D6 for ; Fri, 13 Mar 2015 21:08:53 -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 B5A1F1A89FB for ; Fri, 13 Mar 2015 21:08:53 -0700 (PDT) Received: by obbgg8 with SMTP id gg8so3736232obb.1 for ; Fri, 13 Mar 2015 21:08:53 -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:from:date :message-id:subject:to:cc:content-type; bh=jeN+YrNKKY0VIyKCEy+dYc+/E1rXOVI8NyCdSdE0vLc=; b=Wf+E9iY+urYf68ngR6AhexDK68AOGSMn/bxj05cPdb3ABnE8vdA9D8B6+aNU+y2wP6 hNoJsRXMMxPerZHpFkm4PobUk5klYVyqdW0tKPWBU2QqgOakg4vGfwp5nl+a7XGv8wgy 6kjxHMuWG7hgv/Gsqksy5PGArWHpkYKBKu2pa1XoTJMxEuT7gQKkIu8BnVwb8g/c/5Pl wAfiEYfPTJVij815WXTO7CfaSBnsDIF0uA3J9KwrFJvf8u+tkm+fzLF0IirpuI0b+Dti KgZrlFC6B1t0oo39ezkxGC9X4YJa+MZtF2TsM+LDnwSjSKBb5BkVOa/wqQLgWkpKApuB S7TQ== X-Gm-Message-State: ALoCoQlwuWOGJgDeg7zhTStckmbHo8F6hjJh0BSq+lOYiChlh7/XuJI5WxyapT4CopSM7XiUjXmR X-Received: by 10.202.201.141 with SMTP id z135mr4989276oif.2.1426306133046; Fri, 13 Mar 2015 21:08:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.202.197.70 with HTTP; Fri, 13 Mar 2015 21:08:12 -0700 (PDT) In-Reply-To: <36874A39-B6A4-4D28-BE6B-39D2FE4D6BA6@vpnc.org> References: <36874A39-B6A4-4D28-BE6B-39D2FE4D6BA6@vpnc.org> From: Wil Tan Date: Sat, 14 Mar 2015 15:08:12 +1100 Message-ID: To: Paul Hoffman Content-Type: multipart/alternative; boundary=001a1134fc2466d0cc051137c653 Archived-At: Cc: Paul Wouters , dane WG list Subject: Re: [dane] Comments on draft-ietf-dane-openpgpkey-02 (fwd) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Mar 2015 04:08:55 -0000 --001a1134fc2466d0cc051137c653 Content-Type: text/plain; charset=UTF-8 On Sat, Mar 14, 2015 at 1:23 PM, Paul Hoffman wrote: > On Mar 13, 2015, at 7:09 PM, Paul Wouters wrote: > >> My comments on draft-ietf-dane-openpgpkey-02: > >> 1) Section 3, in case of EAI, it should specify the character encoding > of > >> the local-part on which to perform the SHA224 function. > > > > That's a valid point. Should we say that it should be UTF-8 ? I will > > add some text for this if I get a few more agreeing nods of people. > > Maybe I've lost track of EAI, but from RFC 6530, I got the impression that > all addresses already were in UTF-8. If so, you don't want to encourage > people to double-encode. True, double encoding would be bad. However, from a practical perspective it is likely that software would be working with addresses in a Unicode-aware type that is native to the programming language, rather than a byte string. As such, I think it would be good if we could include text that specifies the encoding without misleading implementers into double encoding. I suggest breaking the first bullet in Section 3 into the following: o The user name (the "left-hand side" of the email address, called the "local-part" in the mail message format definition [RFC2822] and the "local part" in the specification for internationalized email [RFC6530]) is extracted from the email address. This does not include the at symbol ("@") that separates the left and right sides of the email address. o The user name SHOULD be converted to UTF-8, unless it is already encoded in UTF-8. o The user name should then be hashed using the SHA2-224 [RFC5754] algorithm, with the hash being represented in its hexadecimal representation, to become the left-most label in the prepared domain name. .wil --001a1134fc2466d0cc051137c653 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Sat, Mar 14, 2015 at 1:23 PM, Paul Hoffman <paul.hoffman@vpnc.org> wrote:
On Mar 13, 2015, = at 7:09 PM, Paul Wouters <paul@nohats.= ca> wrote:
>> My comments on draft-ietf-dane-openpgpkey-02:
>> 1) Section 3, in case of EAI, it should specify the character enco= ding of
>> the local-part on which to perform the SHA224 function.
>
> That's a valid point. Should we say that it should be UTF-8 ? I wi= ll
> add some text for this if I get a few more agreeing nods of people.
Maybe I've lost track of EAI, but from RFC 6530, I got the impre= ssion that all addresses already were in UTF-8. If so, you don't want t= o encourage people to double-encode.

True, = double encoding would be bad. However, from a practical perspective it is l= ikely that software would be working with addresses in a Unicode-aware type= that is native to the programming language, rather than a byte string.

As such, I think it would be good if we could include= text that specifies the encoding without misleading implementers into doub= le encoding. I suggest breaking the first bullet in Section 3 into the foll= owing:

o The user name (the "left-hand s= ide" of the email address, called the "local-part" in the ma= il message format definition [RFC2822] and the "local part" in th= e specification for internationalized email [RFC6530]) is extracted from th= e email address. This does not include the at symbol ("@") that s= eparates the left and right sides of the email address.

o The user name SHOULD be converted to UTF-8, unless it is= already encoded in UTF-8.

o The user name sho= uld then be hashed using the SHA2-224 [RFC5754] algorithm, with the hash be= ing represented in its hexadecimal representation, to become the left-most = label in the prepared domain name.


.wil
--001a1134fc2466d0cc051137c653-- From nobody Sat Mar 14 00:38:48 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DCF61AC42E for ; Sat, 14 Mar 2015 00:38:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_FILL_THIS_FORM_SHORT=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 zOJx463dvbtW for ; Sat, 14 Mar 2015 00:38:45 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 747531A8A4A for ; Sat, 14 Mar 2015 00:38:45 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id DD906282FCC; Sat, 14 Mar 2015 07:38:41 +0000 (UTC) Date: Sat, 14 Mar 2015 07:38:41 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20150314073841.GM18819@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] Comments on draft-ietf-dane-openpgpkey-02 (fwd) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Mar 2015 07:38:47 -0000 On Fri, Mar 13, 2015 at 10:09:57PM -0400, Paul Wouters wrote: > >1) Section 3, in case of EAI, it should specify the character encoding of > >the local-part on which to perform the SHA224 function. > > That's a valid point. Should we say that it should be UTF-8 ? I will > add some text for this if I get a few more agreeing nods of people. EAI email *addresses* ARE UTF-8 by definition. There is simply no mechanism to signal any other encoding, either in SMTP envelopes or in primary message headers (where one can signal the encoding of "phrases" like the display name, but not the address itself. But if this is not obvious to everyone, it may be helpful to say so. > >2) Section 3, it should probably reference RFC5322 instead of 2822? In fact, > >would it make more sense to reference RFC5321 instead of RFC5322? > > You are right, that would make more sense. If no one objects, I will > make that change. I object. You're not discussing SMTP, you're discussing email. Email addresses are defined in RFC 822/2822/5322 (5322 Section 3.4.1 addr-spec). http://tools.ietf.org/html/rfc5322#section-3.4.1 Any particular transport (SMTP say) representation of email addresses seems to me to be the wrong object to describe here. -- Viktor. From nobody Sat Mar 14 00:52: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 5523D1AC436 for ; Sat, 14 Mar 2015 00:52:04 -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 EQ5gWJ1Iw_9D for ; Sat, 14 Mar 2015 00:52:03 -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 1EFB91AC406 for ; Sat, 14 Mar 2015 00:52:03 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 1A715282FCC; Sat, 14 Mar 2015 07:52:02 +0000 (UTC) Date: Sat, 14 Mar 2015 07:52:02 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20150314075201.GN18819@mournblade.imrryr.org> References: <20150313182334.24823.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] Names of mailbox records in draft-ietf-dane-smime and draft-ietf-dane-openpgpkey X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Mar 2015 07:52:04 -0000 On Fri, Mar 13, 2015 at 07:25:22PM -0400, James Cloos wrote: > JL> ._mailbox.domain > > I posted in the past that smime and openpgp should use the same _name > (search the archives for '_at'). I gave up when it got zero traction. I don't recall seeing this proposal, perhaps it predates my membership on this list (since ~March 2013). I like it a lot. The different RRtypes adequately partition the various records, and a common prefix collates them per user. > It also would be a good place to look for TLSA RRs for certs supplied > by tls clients which have mailbox-like names. Including user-specific TLS certs as TLSA RRs also makes some sense. I can imagine adding a "check_dane_access" to Postfix that is an alternative to "check_sasl_access". The authenticated name would be the envelope sender, and the associated TLSA RRs enable verification of the presented certificate chain. -- Viktor. From nobody Sat Mar 14 01:00: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 D013D1AC436 for ; Sat, 14 Mar 2015 01:00:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vcyFfj-nwvNo for ; Sat, 14 Mar 2015 01:00:49 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5ABC51AC406 for ; Sat, 14 Mar 2015 01:00:49 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 3BAF9282FCC; Sat, 14 Mar 2015 08:00:48 +0000 (UTC) Date: Sat, 14 Mar 2015 08:00:48 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20150314080047.GO18819@mournblade.imrryr.org> References: <20150313182334.24823.qmail@ary.lan> <33E881E6-A73B-4EC3-AAD9-E07B82C21D83@vpnc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <33E881E6-A73B-4EC3-AAD9-E07B82C21D83@vpnc.org> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [dane] Names of mailbox records in draft-ietf-dane-smime and draft-ietf-dane-openpgpkey X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Mar 2015 08:00:51 -0000 On Fri, Mar 13, 2015 at 01:10:21PM -0700, Paul Hoffman wrote: > This could go either way. If the WG thinks that the user, or > someone responsible for the user, will add and change DNS records > for that user, your proposal would clearly be better because you > could delegate the user to a new subzone. On the other hand, if > the WG thinks that the security admin will be the one adding and > changing records for a particular type of mail security, then the > design we are using now is better. I lean towards the second, but > can see the merit of the first now that people are thinking of > using this for things other than just mail security. I think this mental model of tools that update the DNS is too naive. It seems to assume that the tools can make decisions based only on the requestor credentials and the owner name of the RRset to be added. I think it is far more likely that administrators and users will be interacting with a middle-ware management system that enables them to add and remove keys and *that* system will be able to publish all the requisite records on behalf of either individual users or administrators. So the structure of the DNS namespace should be optimized for clarity/simplicity, rather than a presumed set of management tools (e.g. direct authorization to inject records via dynamic update into a particular portion of the namespace). -- Viktor. From nobody Sat Mar 14 03:31: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 2480D1ACC8A for ; Sat, 14 Mar 2015 03:31:27 -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 5CmpZZJ-qF9z for ; Sat, 14 Mar 2015 03:31:26 -0700 (PDT) Received: from waldorf.isode.com (ext-bt.isode.com [217.34.220.158]) by ietfa.amsl.com (Postfix) with ESMTP id 0B5771ACCDA for ; Sat, 14 Mar 2015 03:31:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1426329084; d=isode.com; s=selector; i=@isode.com; bh=SDwowNXeEt8SHOY35M7hQ9j4/ulPRVRQ7dQwjjjOyTw=; 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=S4aehivW17hB5p1q0423PXU+Uf28QVXuSUXRH0hPi1IlgBkk3snsQimJTN8o+XNyFS5FDC Qq/lhL9kXxrjWYUlBF51TmPvVOB0J1zx89OTaW362PASXMLHPbwmQi0jki2f9ytThyiZz4 1HQ7LmcCycZ39UX+gQgjMRSo/8NxdY0=; Received: from [192.168.0.9] (cpc5-nmal20-2-0-cust24.19-2.cable.virginm.net [92.234.84.25]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Sat, 14 Mar 2015 10:31:24 +0000 X-SMTP-Protocol-Errors: PIPELINING From: Alexey Melnikov X-Mailer: iPad Mail (12B435) In-Reply-To: Date: Sat, 14 Mar 2015 10:38:40 +0000 Message-Id: <15467987-08AA-439A-99AB-22F813C0F841@isode.com> References: <5502E194.4020507@powerdns.com> To: Paul Wouters MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "dane@ietf.org" Subject: Re: [dane] Start of WGLC for draft-ietf-dane-openpgpkey - *please* review. X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Mar 2015 10:31:27 -0000 Hi, On 13 Mar 2015, at 18:10, Paul Wouters wrote: >> Appendix A: >> Two things: I suggest moving this to -usage and adding pseudocode >> examples. The latter mostly to encourage more implementations. >=20 > I thought about keeping it software agnostic, but in the end figured > since gnupg has been around for over a decade, it is kind of similar > to using openssl commands as example. I agree. Some real world usage is good. > But I have no problems making > this software agnostic if the WG thinks that is more appropriate. More examples are always better :-). (I am not suggesting you change anythin= g, if you can't think of any). From nobody Sat Mar 14 03: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 200901ACCE4 for ; Sat, 14 Mar 2015 03:37:26 -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 qG8syr_DfM3P for ; Sat, 14 Mar 2015 03:37:24 -0700 (PDT) Received: from mail-wi0-f175.google.com (mail-wi0-f175.google.com [209.85.212.175]) (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 64E2A1ACCDF for ; Sat, 14 Mar 2015 03:37:24 -0700 (PDT) Received: by wibg7 with SMTP id g7so4310005wib.1 for ; Sat, 14 Mar 2015 03:37:23 -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:cc:content-type; bh=yWQ+aI7XOkUYOYaMkx+eKdbFKncLP3WR7qYinNl81vI=; b=hV9OpTt6zzXpRnDHKMr96ulxEpjZWFRr4E2kec3SAJGq2y/USF3Lh1udANr5hBL+1c fm010IuEQgPDjHWEvP5kgw2vQiss6TQj2B/mZ+8ZgqF3fRF5LpbrOs3K4JDfAB4K4V5T XHwezNZtHuH2y2sBRPfkHm120iCXrMNy+DgX+B4Qmk2zNEzn8LZ/spt2K7W4o1u1DLhq acMGW26nX0FpW5VPAgm/b8jJ/wY67wBgvohJ5dSXFdn64+/GkDHwh0QP3s8wlK/OpAV6 WsCpqOf733vDU24oi9LYFcuUzZl85pJC83r+MxG3IWaTEMr2A7ts1uGHtyP6EJ2UlAg5 kn5g== X-Gm-Message-State: ALoCoQmWJvdzkrdFrWtLAS81MKfwcFewxuJi/JNTy7Id1G41kaMsP4PPNrxwUM8xIwyqjkh8+nSU MIME-Version: 1.0 X-Received: by 10.194.2.43 with SMTP id 11mr105284117wjr.104.1426329443022; Sat, 14 Mar 2015 03:37:23 -0700 (PDT) Received: by 10.194.110.97 with HTTP; Sat, 14 Mar 2015 03:37:22 -0700 (PDT) In-Reply-To: <15467987-08AA-439A-99AB-22F813C0F841@isode.com> References: <5502E194.4020507@powerdns.com> <15467987-08AA-439A-99AB-22F813C0F841@isode.com> Date: Sat, 14 Mar 2015 11:37:22 +0100 Message-ID: From: Warren Kumari To: Alexey Melnikov Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Paul Wouters , "dane@ietf.org" Subject: Re: [dane] Start of WGLC for draft-ietf-dane-openpgpkey - *please* review. X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Mar 2015 10:37:26 -0000 Thanks everyone for your feedback and comments, the WGLC is now closed. I think that it looks like there is strong consensus for publishing, but I'm hoping to re-read all the comments on my flight home (currently sitting in TXL) to see if I've missed anything obvious... W On Sat, Mar 14, 2015 at 11:38 AM, Alexey Melnikov wrote: > Hi, > > On 13 Mar 2015, at 18:10, Paul Wouters wrote: > >>> Appendix A: >>> Two things: I suggest moving this to -usage and adding pseudocode >>> examples. The latter mostly to encourage more implementations. >> >> I thought about keeping it software agnostic, but in the end figured >> since gnupg has been around for over a decade, it is kind of similar >> to using openssl commands as example. > > I agree. Some real world usage is good. > >> But I have no problems making >> this software agnostic if the WG thinks that is more appropriate. > > More examples are always better :-). (I am not suggesting you change anything, if you can't think of any). > > _______________________________________________ > 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 Sat Mar 14 09:01: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 E31931A01D6 for ; Sat, 14 Mar 2015 09:01:11 -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 mIZ1Hc5qXr_7 for ; Sat, 14 Mar 2015 09:01:11 -0700 (PDT) Received: from proper.com (Opus1.Proper.COM [207.182.41.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 187531A019B for ; Sat, 14 Mar 2015 09:01:11 -0700 (PDT) Received: from [10.20.30.101] (50-1-99-2.dsl.dynamic.fusionbroadband.com [50.1.99.2]) (authenticated bits=0) by proper.com (8.15.1/8.14.9) with ESMTPSA id t2EG171H085599 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 14 Mar 2015 09:01:08 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: proper.com: Host 50-1-99-2.dsl.dynamic.fusionbroadband.com [50.1.99.2] claimed to be [10.20.30.101] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Paul Hoffman In-Reply-To: Date: Sat, 14 Mar 2015 09:01:07 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <71C74443-FF0C-462C-81C4-0EBF2FC79920@vpnc.org> References: <36874A39-B6A4-4D28-BE6B-39D2FE4D6BA6@vpnc.org> To: Wil Tan X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: Paul Wouters , dane WG list Subject: Re: [dane] Comments on draft-ietf-dane-openpgpkey-02 (fwd) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Mar 2015 16:01:12 -0000 On Mar 13, 2015, at 9:08 PM, Wil Tan wrote: > o The user name (the "left-hand side" of the email address, called the = "local-part" in the mail message format definition [RFC2822] and the = "local part" in the specification for internationalized email [RFC6530]) = is extracted from the email address. This does not include the at symbol = ("@") that separates the left and right sides of the email address. >=20 > o The user name SHOULD be converted to UTF-8, unless it is already = encoded in UTF-8. >=20 > o The user name should then be hashed using the SHA2-224 [RFC5754] = algorithm, with the hash being represented in its hexadecimal = representation, to become the left-most label in the prepared domain = name. That seems pretty clear. Thanks! --Paul Hoffman= From nobody Sat Mar 14 09:37: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 9C3F91A01FA for ; Sat, 14 Mar 2015 09:36:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.862 X-Spam-Level: X-Spam-Status: No, score=0.862 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hiGQ2j5JZime for ; Sat, 14 Mar 2015 09:36:58 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7CB6C1A00A2 for ; Sat, 14 Mar 2015 09:36:58 -0700 (PDT) Received: (qmail 59347 invoked from network); 14 Mar 2015 16:36:57 -0000 Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 14 Mar 2015 16:36:57 -0000 Date: 14 Mar 2015 16:36:35 -0000 Message-ID: <20150314163635.29627.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] Start of WGLC for draft-ietf-dane-openpgpkey - *please* review. X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Mar 2015 16:36:59 -0000 In article you write: >Thanks everyone for your feedback and comments, the WGLC is now closed. > >I think that it looks like there is strong consensus for publishing, >but I'm hoping to re-read all the comments on my flight home >(currently sitting in TXL) to see if I've missed anything obvious... I am fairly sure that the current text in section 3.1 will never get through the IESG. Telling people to guess e-mail addresses is, well, just wrong. The draft is fixable, but it's a fairly significant change. R's, John From nobody Sat Mar 14 11:40: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 E51E11A00FE for ; Sat, 14 Mar 2015 11:40:27 -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 dT4iM5Wv1BLl for ; Sat, 14 Mar 2015 11:40:27 -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 DBB331A00EF for ; Sat, 14 Mar 2015 11:40:26 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3l4CPg2BYHz449; Sat, 14 Mar 2015 19:40:23 +0100 (CET) Authentication-Results: mx.nohats.ca; dkim=pass reason="1024-bit key; unprotected key" header.d=nohats.ca header.i=@nohats.ca header.b=uf4Fmg8V; dkim-adsp=pass 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 uhsbKpwqcgtG; Sat, 14 Mar 2015 19:40:22 +0100 (CET) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Sat, 14 Mar 2015 19:40:22 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 91EC880A01; Sat, 14 Mar 2015 14:40:21 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1426358421; bh=QiZ1HVVJGQCggNeFgmwaiodP02qsIn013GnzCsa/tRo=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=uf4Fmg8VdE1V8rs9QJfKSIKkkkldUBlv20cR2IPok0Lnyi1p7Hv3XETJOYbgBybXp Lyi01QHZXA65Pex0YG13lEw09pdUp5mgOQ0BscaULQPC0agFftZG9Z3r3rEyEI41EG R4KWjh9yb75Be1xUj5RIUJnyU5alqckNeDdP9aRI= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id t2EIeKh7015845; Sat, 14 Mar 2015 14:40:21 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Sat, 14 Mar 2015 14:40:20 -0400 (EDT) From: Paul Wouters To: John Levine In-Reply-To: <20150314163635.29627.qmail@ary.lan> Message-ID: References: <20150314163635.29627.qmail@ary.lan> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: dane@ietf.org Subject: Re: [dane] Start of WGLC for draft-ietf-dane-openpgpkey - *please* review. X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Mar 2015 18:40:28 -0000 On Sat, 14 Mar 2015, John Levine wrote: > In article you write: >> Thanks everyone for your feedback and comments, the WGLC is now closed. >> >> I think that it looks like there is strong consensus for publishing, >> but I'm hoping to re-read all the comments on my flight home >> (currently sitting in TXL) to see if I've missed anything obvious... > > I am fairly sure that the current text in section 3.1 will never get > through the IESG. Telling people to guess e-mail addresses is, well, > just wrong. > > The draft is fixable, but it's a fairly significant change. Section 3.1 was never meant to dictate processing. It was only meant to warn about email address mapping services out in the wild that we know about. I can try and come up with better text if that solved this issue for you. Paul From nobody Sat Mar 14 12:05: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 A8AF01A0263 for ; Sat, 14 Mar 2015 12:05:16 -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, T_FILL_THIS_FORM_SHORT=0.01, 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 gKbH4f_9bHSE for ; Sat, 14 Mar 2015 12:05:15 -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 64C691A0167 for ; Sat, 14 Mar 2015 12:05:15 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3l4CyH48t7z44C for ; Sat, 14 Mar 2015 20:05:11 +0100 (CET) Authentication-Results: mx.nohats.ca; dkim=pass reason="1024-bit key; unprotected key" header.d=nohats.ca header.i=@nohats.ca header.b=GHdaKvaU; dkim-adsp=pass 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 g6miCJaivgx0 for ; Sat, 14 Mar 2015 20:05:10 +0100 (CET) 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 ; Sat, 14 Mar 2015 20:05:10 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id D08DD80A01 for ; Sat, 14 Mar 2015 15:05:09 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1426359909; bh=66CfPEqF5KTKAX7wEQgwZGZRBJneldLW7bYzqSHZTcg=; h=Date:From:To:Subject:In-Reply-To:References; b=GHdaKvaUUsuAf80BfbdkQF+WrJRQO1+C5h8ffu/7mBceMOJ+fOqP8QV12M/j9ZV7W lsup1WMTn4Pys1F6NCUVAvzAziLBNWqiPP4HNBggfHYafAlqaGh4GlkEUVY72gAiQ7 8HWHQpaB8MnJP6zVtrSpAsNyFvPBHEPTzXvJlNrU= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id t2EJ59IN023980 for ; Sat, 14 Mar 2015 15:05:09 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Sat, 14 Mar 2015 15:05:09 -0400 (EDT) From: Paul Wouters To: dane@ietf.org In-Reply-To: <20150314073841.GM18819@mournblade.imrryr.org> Message-ID: References: <20150314073841.GM18819@mournblade.imrryr.org> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [dane] Comments on draft-ietf-dane-openpgpkey-02 (fwd) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Mar 2015 19:05:16 -0000 On Sat, 14 Mar 2015, Viktor Dukhovni wrote: > > EAI email *addresses* ARE UTF-8 by definition. There is simply no > mechanism to signal any other encoding, either in SMTP envelopes > or in primary message headers (where one can signal the encoding > of "phrases" like the display name, but not the address itself. > But if this is not obvious to everyone, it may be helpful to say so. Yes, that surely deserves to be stated more clearly in the draft. >>> 2) Section 3, it should probably reference RFC5322 instead of 2822? In fact, >>> would it make more sense to reference RFC5321 instead of RFC5322? >> >> You are right, that would make more sense. If no one objects, I will >> make that change. > > I object. You're not discussing SMTP, you're discussing email. Email > addresses are defined in RFC 822/2822/5322 (5322 Section 3.4.1 addr-spec). > > http://tools.ietf.org/html/rfc5322#section-3.4.1 > > Any particular transport (SMTP say) representation of email addresses > seems to me to be the wrong object to describe here. Point taken here as well. Thanks Viktor! Paul From nobody Sat Mar 14 12:08:10 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 505801A026A for ; Sat, 14 Mar 2015 12:08:08 -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 7aOF0cAFfwP1 for ; Sat, 14 Mar 2015 12:08: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 8E4851A01FA for ; Sat, 14 Mar 2015 12:08:04 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3l4D1Y3gXKz44c; Sat, 14 Mar 2015 20:08:01 +0100 (CET) Authentication-Results: mx.nohats.ca; dkim=pass reason="1024-bit key; unprotected key" header.d=nohats.ca header.i=@nohats.ca header.b=KMXGkuCy; dkim-adsp=pass 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 9XYdixTZOMFK; Sat, 14 Mar 2015 20:08:00 +0100 (CET) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Sat, 14 Mar 2015 20:08:00 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 9464F80A01; Sat, 14 Mar 2015 15:07:59 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1426360079; bh=ejcNMd/WGoDkPKX6J/Q0iluPsF3GttAGHYhB1D06JV4=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=KMXGkuCywddZe+eLdXLBtB+UZ1QgsTKSqyWIXdCO/RGbhrcxALaZfVOgp058lSKUc DIU1U4VwHn482i5Yugrpnxso2Oro50UkSVRIjn8TDDmUWETwEPZ6WceChLhFWk+/Kn XA1fdu/6oQP7imcgE8kK9ubQ2Y2MD8Hvm6LjOB0U= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id t2EJ7xj1028588; Sat, 14 Mar 2015 15:07:59 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Sat, 14 Mar 2015 15:07:59 -0400 (EDT) From: Paul Wouters To: John Levine In-Reply-To: <20150314032550.26364.qmail@ary.lan> Message-ID: References: <20150314032550.26364.qmail@ary.lan> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: dane@ietf.org Subject: Re: [dane] Comments on draft-ietf-dane-openpgpkey-02 (fwd) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Mar 2015 19:08:08 -0000 On Fri, 14 Mar 2015, John Levine wrote: > My advice would be to remove all of the current text in 3.1 and > replace it with a note that systems that publish records at names that > are hashed mailboxes may publish CNAMEs for variant mailbox hashes > that they consider to be equivalent. That's safe, since the party > publishing the variants is the one that knows what they mean. It's > also fairly hopeless once you get beyond folding stuff to lower case > and stripping dots since the number of possibilities explodes. That sounds fine. Are you saying you prefer the document to not list the example mappings we know about, or are you okay with still mentioning the example mappings? > PS: If we have name variant rules, which I'm not at all sure we > should, they really should be the same for OPENPGPKEY and SMIMEA and > anything else that uses a hashed mailbox. This suggests if we go down > that road, the name management belongs in a separate document from the > definition of the RR type, and it needs attention from the SMTP crowd. Agreed. Paul From nobody Sat Mar 14 12:09: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 9D65D1A0354 for ; Sat, 14 Mar 2015 12:09:07 -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 MmU753DU-GSN for ; Sat, 14 Mar 2015 12:09:06 -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 CA4A71A035F for ; Sat, 14 Mar 2015 12:09:03 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3l4D2h2tCKz44K; Sat, 14 Mar 2015 20:09:00 +0100 (CET) Authentication-Results: mx.nohats.ca; dkim=pass reason="1024-bit key; unprotected key" header.d=nohats.ca header.i=@nohats.ca header.b=ibq48Ur8; dkim-adsp=pass 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 qKOui6EnQLDn; Sat, 14 Mar 2015 20:09:00 +0100 (CET) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Sat, 14 Mar 2015 20:08:59 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 2311080A01; Sat, 14 Mar 2015 15:08:59 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1426360139; bh=R04IiQrECjwJRQTgTtoE4gtTLoxD9iSS7BCy8l8Rz4A=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=ibq48Ur8B8v7hSm8mo3QzV6HXF/8vw1vRsit95WvwH7q5fhC/ft60QB6r+DHD6TmJ R7WH6fixkcGOoOzvY+AUoYPDoakkpriHSIv3cPeDuoK9lPiU8M4iwtSrNzzmZa8Rau AeY/wBK0d/rXnwvvVzvljmW1ZUsB1QtspIZ4EwYI= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id t2EJ8wpt030195; Sat, 14 Mar 2015 15:08:58 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Sat, 14 Mar 2015 15:08:58 -0400 (EDT) From: Paul Wouters To: Paul Hoffman In-Reply-To: <36874A39-B6A4-4D28-BE6B-39D2FE4D6BA6@vpnc.org> Message-ID: References: <36874A39-B6A4-4D28-BE6B-39D2FE4D6BA6@vpnc.org> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: dane WG list Subject: Re: [dane] Comments on draft-ietf-dane-openpgpkey-02 (fwd) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Mar 2015 19:09:07 -0000 On Fri, 13 Mar 2015, Paul Hoffman wrote: >> That's a valid point. Should we say that it should be UTF-8 ? I will >> add some text for this if I get a few more agreeing nods of people. > > Maybe I've lost track of EAI, but from RFC 6530, I got the impression that all addresses already were in UTF-8. If so, you don't want to encourage people to double-encode. I'll clarify that in the new text and run it by you so you can add the same to the smimecert document. Thanks, Paul From nobody Sat Mar 14 12:27: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 82ECA1A0194 for ; Sat, 14 Mar 2015 12:27:53 -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 WnIlPax6uVvt for ; Sat, 14 Mar 2015 12:27:52 -0700 (PDT) Received: from mail-ob0-f169.google.com (mail-ob0-f169.google.com [209.85.214.169]) (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 D63881A0193 for ; Sat, 14 Mar 2015 12:27:51 -0700 (PDT) Received: by obdfc2 with SMTP id fc2so11105979obd.3 for ; Sat, 14 Mar 2015 12:27:51 -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:cc:content-type; bh=Ei4B+/vB7zPtZNNwzn/GvNnOnwrR9/SqIT74j7eaUr4=; b=ILrH9aOhJR7AvEb7vbqnrx2OY1n/KUQwcm/TLb/aDQqSUD88iUnxQUGOvBEUeKsIhw W3K96vQM1wSOXw3J+n6BL/V75EESX409sxJMucWhrF63W8H92EfTQwMyP7X79RRGVmny RSULpjoHSOxyouffYhGTRNIMz9s1fY9AMwOvlnj6fyqms0ewwi4AXfl8ihHn9a+SDhh1 fZ8FN3GXUre63VhPpirDRY+ue3Y+x0i/5iufrq/okErrzYEjsagd1chFkdD/CJeWzPzg RRzIBemP5StwgJt/PQ2kt7m9nJ76tQvvrYEX4jA2xjeSMBRZbUC7fyExNE4z460hL3YP rK8A== X-Gm-Message-State: ALoCoQmyxP4EHSTwlwRoYZFzcoKWj9fO8T0Xc6p5J13P20+Jc6gyKSsgmzNAvZWVIhHAYxB3BQ/1 MIME-Version: 1.0 X-Received: by 10.202.66.136 with SMTP id p130mr40165808oia.110.1426361271286; Sat, 14 Mar 2015 12:27:51 -0700 (PDT) Received: by 10.202.79.86 with HTTP; Sat, 14 Mar 2015 12:27:51 -0700 (PDT) In-Reply-To: References: <5502E194.4020507@powerdns.com> <15467987-08AA-439A-99AB-22F813C0F841@isode.com> Date: Sat, 14 Mar 2015 20:27:51 +0100 Message-ID: From: Warren Kumari To: Alexey Melnikov Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Paul Wouters , "dane@ietf.org" Subject: Re: [dane] Start of WGLC for draft-ietf-dane-openpgpkey - *please* review. X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Mar 2015 19:27:53 -0000 Oh yeah. I sent this all in a bit of a rush (while waiting for a cab). I'm also writing this in a bit of a rush, but I'm still going to have to chat with Olafur to try and figure out what we do with the whole "many trees" / DNAME issues. W On Sat, Mar 14, 2015 at 11:37 AM, Warren Kumari wrote: > Thanks everyone for your feedback and comments, the WGLC is now closed. > > I think that it looks like there is strong consensus for publishing, > but I'm hoping to re-read all the comments on my flight home > (currently sitting in TXL) to see if I've missed anything obvious... > > W > > On Sat, Mar 14, 2015 at 11:38 AM, Alexey Melnikov > wrote: >> Hi, >> >> On 13 Mar 2015, at 18:10, Paul Wouters wrote: >> >>>> Appendix A: >>>> Two things: I suggest moving this to -usage and adding pseudocode >>>> examples. The latter mostly to encourage more implementations. >>> >>> I thought about keeping it software agnostic, but in the end figured >>> since gnupg has been around for over a decade, it is kind of similar >>> to using openssl commands as example. >> >> I agree. Some real world usage is good. >> >>> But I have no problems making >>> this software agnostic if the WG thinks that is more appropriate. >> >> More examples are always better :-). (I am not suggesting you change anything, if you can't think of any). >> >> _______________________________________________ >> 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 -- 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 Sat Mar 14 12:48: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 C9AF11A0231 for ; Sat, 14 Mar 2015 12:48:33 -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 5NqKPJtZ-vuT for ; Sat, 14 Mar 2015 12:48:32 -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 331ED1A0354 for ; Sat, 14 Mar 2015 12:48:32 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 187B1282FC2; Sat, 14 Mar 2015 19:48:25 +0000 (UTC) Date: Sat, 14 Mar 2015 19:48:25 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20150314194824.GC27479@mournblade.imrryr.org> References: <5502E194.4020507@powerdns.com> <15467987-08AA-439A-99AB-22F813C0F841@isode.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [dane] Start of WGLC for draft-ietf-dane-openpgpkey - *please* review. X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Mar 2015 19:48:33 -0000 On Sat, Mar 14, 2015 at 08:27:51PM +0100, Warren Kumari wrote: > Oh yeah. I sent this all in a bit of a rush (while waiting for a cab). > I'm also writing this in a bit of a rush, but I'm still going to have > to chat with Olafur to try and figure out what we do with the whole > "many trees" / DNAME issues. I hope this is a reference to the _prefix issue. That is, whether SMIMEA and OPENPGPKEY, ... should share the same _prefix: ._.example.com. ... so that all DANE records related to a given mailbox are collocated in DNS. Perhaps this discussion should continue... Having one such prefix is sufficient for separating such data from other data for the domain. Having many such prefixes, (at least one each for SMIMEA and OPENPGPKEY) seems to me to be unnecessary and inelegant. That is I think one such prefix is enough for both, and for any other closely related DANE records. -- Viktor. From nobody Sun Mar 15 12:06: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 F344D1A1B5F for ; Sun, 15 Mar 2015 12:06:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.137 X-Spam-Level: X-Spam-Status: No, score=-1.137 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FEEBtHTtmw1l for ; Sun, 15 Mar 2015 12:06:54 -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 BD3141A01D8 for ; Sun, 15 Mar 2015 12:06:53 -0700 (PDT) Received: (qmail 28328 invoked from network); 15 Mar 2015 19:06:52 -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=6ea7.5505d84c.k1503; bh=a9+pITp3kTuwAeDRCl5EKlX48NWKSNT7WrhjcFHmWeg=; b=ahO1q4JOxgINuJjt/7vkL2l8AqJEDKkn09bGE3E8ljeuJIW/ACRPFoHhoWXKNsfwn0uRFxPZyajquRMy04BGh/1phjgviFBVpSR5vr7dKn3MMBjW5qCznVsTIfDrE5Q/4ZVAegsBTUZgetpK94GWHKRCCIcolXNsViOEiclNjg7kePLJlFgKv6RpJiE4fqwg4ZVUqneWLQujwD/PfOWRyFx/Zo8oBvNNwELfLMjKLWk5Xq2v4ySbig5W5FO/V+mH 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=6ea7.5505d84c.k1503; bh=a9+pITp3kTuwAeDRCl5EKlX48NWKSNT7WrhjcFHmWeg=; b=FkfQLZb2w5jDExPT4AwjNH8MZXXbHHH+ndEYgPAgfhYxQwhLhTCnbadIiahSfoqiihh3P7mHnhWhdkFW3yUhSMVOckcwHUDirXjT3VOTjtYtEDiEjCHZP+WLH52DYwxwCg8aIdknSKKRZNaJmXw0vgXqcW4/ssT9IQXsiRJcbwqwrEt6wc1moQqKGfUZBF5Tgwtkyk2kWY2kS9tjx0JMF/tmzKDX2h/JjadCuzrpnTTEx65iWSOpNVx6Qa5dsNT/ 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; 15 Mar 2015 19:06:52 -0000 Date: 15 Mar 2015 15:06:54 -0400 Message-ID: From: "John R Levine" To: "Paul Wouters" In-Reply-To: References: <20150314032550.26364.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] Comments on draft-ietf-dane-openpgpkey-02 (fwd) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Mar 2015 19:06:55 -0000 > That sounds fine. Are you saying you prefer the document to not list the > example mappings we know about, or are you okay with still mentioning > the example mappings? This whole can of worms needs attention from the people who think about mail all the time. The RFCs are quite clear that mailbox namees are opaque and clients are not allowed to make any assumptions that similar names are the same mailbox. Servers can use CNAMEs to publish likely variants that people will try, but I'm wondering whether it will still turn out to be too frustrating to use. >> anything else that uses a hashed mailbox. This suggests if we go down >> that road, the name management belongs in a separate document from the >> definition of the RR type, and it needs attention from the SMTP crowd. > > Agreed. OK. Want me to split it out and do a draft? Can't submit it now but we can talk about it in Dallas. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. From nobody Sun Mar 15 14:53: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 403AE1A1B92 for ; Sun, 15 Mar 2015 14:53:07 -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 cevo0eWqSs_8 for ; Sun, 15 Mar 2015 14:53:05 -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 258CC1A1B8A for ; Sun, 15 Mar 2015 14:53:05 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3l4vdV6s4Mz71y; Sun, 15 Mar 2015 22:53:02 +0100 (CET) Authentication-Results: mx.nohats.ca; dkim=pass reason="1024-bit key; unprotected key" header.d=nohats.ca header.i=@nohats.ca header.b=ipqsFygC; dkim-adsp=pass 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 mh77LQklJQwO; Sun, 15 Mar 2015 22:53:02 +0100 (CET) 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, 15 Mar 2015 22:53:02 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 5AD1A80416; Sun, 15 Mar 2015 17:53:01 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1426456381; bh=ILvYuUpkHwK26gcskYMKK1AIbrPmOD6w2+VX4Z5SpgI=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=ipqsFygCKmH8WAEXY/Gt8DLRnXjoA4X954nx1mSzFEMjT85YHS2Xcl+TRnOYweuYC P3IHf+0yJCFd8rMGMn8uIEN1Yovg8PbbFGWq1PA5SwU1WHZCQzCiMn5gGwGtaXGveu BdSdE56oNAY/Beire6apC95Ix1CYQA8cnH3uARgg= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id t2FLr0k5029361; Sun, 15 Mar 2015 17:53:00 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Sun, 15 Mar 2015 17:52:59 -0400 (EDT) From: Paul Wouters To: John R Levine In-Reply-To: Message-ID: References: <20150314032550.26364.qmail@ary.lan> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: dane@ietf.org Subject: Re: [dane] Comments on draft-ietf-dane-openpgpkey-02 (fwd) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Mar 2015 21:53:07 -0000 On Sun, 15 Mar 2015, John R Levine wrote: >> That sounds fine. Are you saying you prefer the document to not list the >> example mappings we know about, or are you okay with still mentioning >> the example mappings? > > This whole can of worms needs attention from the people who think about mail > all the time. The RFCs are quite clear that mailbox namees are opaque and > clients are not allowed to make any assumptions that similar names are the > same mailbox. Servers can use CNAMEs to publish likely variants that people > will try, but I'm wondering whether it will still turn out to be too > frustrating to use. That did not answer my question though. Do you prefer the example mappings to be in the document or not? If a new document is started on the issue of email address mappings, it should not stall progress on this document. So I'm looking at text that points out the issue, yet punts a solution elsewhere. I am thinking the current Section 3.1 with only the last sentence changed could do that and this document can move forward. >>> anything else that uses a hashed mailbox. This suggests if we go down >>> that road, the name management belongs in a separate document from the >>> definition of the RR type, and it needs attention from the SMTP crowd. >> >> Agreed. > > OK. Want me to split it out and do a draft? Can't submit it now but we can > talk about it in Dallas. I think a clarification on the case sensitivity issue and the well known mappings would be a useful document and I'm willing to co-author. Personally, I would like to see some advise telling email clients not to auto-capitalize the first letter in an email address input box for example. (hint to Apple for iOS) I don't think we could advise anyone on interpreting ".", "-" or "+" other that text proposed by Wil along the lines of "Only support these mappings when you _know_ the target domain performs these". Which is what the last line in Section 3.1 should say as well. Paul From nobody Sun Mar 15 16:28: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 5EE9B1A0379 for ; Sun, 15 Mar 2015 16:28:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.137 X-Spam-Level: X-Spam-Status: No, score=-3.137 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_I_LETTER=-2, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8qh0VgOtDfrv for ; Sun, 15 Mar 2015 16:28:07 -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 D477F1A0318 for ; Sun, 15 Mar 2015 16:28:06 -0700 (PDT) Received: (qmail 59942 invoked from network); 15 Mar 2015 23:28:05 -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=ea25.55061585.k1503; bh=YGWFD0Kr7IufBMlguoVw5jLu9RRCkx8hPnokUM/njP0=; b=FYxywQdYfWH8DBYEGtUB2x5HfQhDeMKIhXUUNT/3DpRxZLZvbSsaeOSFS/Yx30KSWhxl1wWTUFjRr7J/KrM0VjXotdmbqvkxMXwcPCo2uLBgi6wXCxVRjWRkx60QahN3OWx1Fm9SivCK277Jx/23JfGN1Nh/yEiM4xhap8McYU3pRNsVZQ6rDY+xk+byoo7/mvRZWtilNXD2yndAeavmISATtxUTlk1i5uLoWht+KF5afKFgkXGhCHdCEmAuo1Un 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=ea25.55061585.k1503; bh=YGWFD0Kr7IufBMlguoVw5jLu9RRCkx8hPnokUM/njP0=; b=GwCOgX7NEuWN+bGllmBMfci4JV3lIMQt1OPtAIVCPiR14Tkar6+xZ1wtdT9uQ3Na0pu8v9jVgBlFdeLhebFGmqBoMTi/PuHlN5X37axiot4QYkUAfarG+T2agzo5UmrPezal9yj+EDZW9ocMWAGCuzN1Wx0/utNGPy3QkwZGhTha8sBALm8xW/aQZnaMOCFt0TJQLTXW+WKiCWkEo85YC6+G8axywSNvoP4IKWQajTxOOb/Il4vS63yvJLUxrFAx 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; 15 Mar 2015 23:28:05 -0000 Date: 15 Mar 2015 19:28:04 -0400 Message-ID: From: "John R Levine" To: "Paul Wouters" In-Reply-To: References: <20150314032550.26364.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] Comments on draft-ietf-dane-openpgpkey-02 (fwd) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Mar 2015 23:28:08 -0000 > That did not answer my question though. Do you prefer the example > mappings to be in the document or not? As I think I said, the entire section 3.1 needs to go. That includes the examples. > Personally, I would like to see some advise telling email clients not to > auto-capitalize the first letter in an email address input box for > example. (hint to Apple for iOS) Only if you never want your draft to be published. Please review previous correspondence for why. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. From nobody Sun Mar 15 16:37: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 035B61A1BDB for ; Sun, 15 Mar 2015 16:37:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EoCImjtLiA1m for ; Sun, 15 Mar 2015 16:37:01 -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 3AD9A1A1BD7 for ; Sun, 15 Mar 2015 16:37:01 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3l4xxK6ksbz1wF; Mon, 16 Mar 2015 00:36:53 +0100 (CET) Authentication-Results: mx.nohats.ca; dkim=pass reason="1024-bit key; unprotected key" header.d=nohats.ca header.i=@nohats.ca header.b=AV8YXSKw; dkim-adsp=pass 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 Q2Kaa7z8ZqkU; Mon, 16 Mar 2015 00:36:52 +0100 (CET) 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, 16 Mar 2015 00:36:52 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 43AD680A01; Sun, 15 Mar 2015 19:36:50 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1426462610; bh=37k9ctC4ixr0bLkEKWSjmIIY98s7EVvtDxkP2qQ0v2s=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=AV8YXSKwDv45N7Pw3u8j+UzK73BUGifSdcmErp8yn2IaKOfTe3bZfK0aQKAYl1p6p xdDj5knOIvG/T3gLFGe61SjVSRRB0g0Ui4mY2/kKOd7Xw91jKW6BRhGS1wKE8VIEy5 pn0qODSpkV8iaXqjEbfqAEaDYIvFTHPJyyLqNdPc= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id t2FNanMk005279; Sun, 15 Mar 2015 19:36:49 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Sun, 15 Mar 2015 19:36:49 -0400 (EDT) From: Paul Wouters To: John R Levine In-Reply-To: Message-ID: References: <20150314032550.26364.qmail@ary.lan> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: dane@ietf.org Subject: Re: [dane] Comments on draft-ietf-dane-openpgpkey-02 (fwd) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Mar 2015 23:37:03 -0000 On Sun, 15 Mar 2015, John R Levine wrote: >> That did not answer my question though. Do you prefer the example >> mappings to be in the document or not? > > As I think I said, the entire section 3.1 needs to go. That includes the > examples. What's the logic behind not mentioning a possible known problem for implementors of OPENPGPKEY? Paul From nobody Sun Mar 15 16:52: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 6C4061A1BE5 for ; Sun, 15 Mar 2015 16:52:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.137 X-Spam-Level: X-Spam-Status: No, score=-1.137 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xsncFBXrvvmH for ; Sun, 15 Mar 2015 16:52:57 -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 5FD6C1A1BE4 for ; Sun, 15 Mar 2015 16:52:57 -0700 (PDT) Received: (qmail 62574 invoked from network); 15 Mar 2015 23:52:56 -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=f46d.55061b58.k1503; bh=1IXbqdpKKJp92X4FDc/FvHyY/l+HhJI/zB6zyArWeAw=; b=OArP1kjjayMVX7xQq3+vM0LGuIgOcoRbhzHNWTa0Z4dOUbOZIR7OJd80QQFRkChZDEk1D4oKfWjSYAI7hFmKeKYkyYDEp4f8oJfX77ETd4/ikzKzLvmPgmzBsTLwJpoCTu3buNmjdsOKcFyXJk98ZnAX63kFX8I3p+/T2QF2G3yJaICwaf1xaIOHt6SFn24jYsGcfi9v2H4tXxciOMDv9L1ulqHxtREf7DOK/nFK9jZYAVsABjt19+m6Eviw1av1 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=f46d.55061b58.k1503; bh=1IXbqdpKKJp92X4FDc/FvHyY/l+HhJI/zB6zyArWeAw=; b=Abour7KIpxp4fg9b1xosTReZtYO+5hxUfUjYALym+xwOK9kNRIJECxcQ2R2SutCgGQXOZTtvNPfdOPdcPR3RDKUYMedu9AxHPMUjNNJbVKtCRmG2GN0PGWe+3JR8lNNl/GsRUL73SBPtZw/Da9RYho5nzj3nsfXzowz8f0nST4VHVMUlfDj3ifGIKgGX/SdILUUzYaW0PPOxxg1ENP81vMLuivZllb+ozERqUk71/CBRhFof/Z/2DtXYPJpUD0tn 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; 15 Mar 2015 23:52:55 -0000 Date: 15 Mar 2015 19:52:54 -0400 Message-ID: From: "John R Levine" To: "Paul Wouters" In-Reply-To: References: <20150314032550.26364.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] Comments on draft-ietf-dane-openpgpkey-02 (fwd) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Mar 2015 23:52:58 -0000 > What's the logic behind not mentioning a possible known problem for > implementors of OPENPGPKEY? Because we have no workable solutions for it. Probing addresses is a non-starter, servers publishing variants doesn't scale. As I've said before, the reality that mail systems do fuzzy matching on incoming addresses, but not in a way that is at all consistent, is a big problem. I don't think it makes sense to try to advance OPENPGPKEY or SMIMEA or _mailbox until we and the people who know about mail figure out what to do about it. I'm asking them to take a look. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. From nobody Sun Mar 15 17:00: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 121051A1BE7 for ; Sun, 15 Mar 2015 17:00:38 -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 HZi3_AeFWyPK for ; Sun, 15 Mar 2015 17:00:37 -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 E696B1A1BE6 for ; Sun, 15 Mar 2015 17:00:34 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3l4ySd1q1yz1wF; Mon, 16 Mar 2015 01:00:33 +0100 (CET) Authentication-Results: mx.nohats.ca; dkim=pass reason="1024-bit key; unprotected key" header.d=nohats.ca header.i=@nohats.ca header.b=kZIRVlVk; dkim-adsp=pass 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 zeph_QtHWaK1; Mon, 16 Mar 2015 01:00:32 +0100 (CET) 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, 16 Mar 2015 01:00:31 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 0E23180A01; Sun, 15 Mar 2015 20:00:31 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1426464031; bh=2ZqgsnhSP/aYTc2mv10aUCSqsvWaMtG0xXZBgtrRWxQ=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=kZIRVlVk1KZVq6iossLItaZFfpNMObRY67ytBGl/YdFp/znwQ7Y00xwBW3Bys5Hul 6HAxhZPLtu2wVdkZTZvrOhVqxEFNohXGj0bzo7Z+Yh73DxscP0N2gptFAJF20xQTJu Fga9i/IAJnKkmfgM2SuRqwTD9Fl8imTqTBpyN6UI= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id t2G00UUQ020108; Sun, 15 Mar 2015 20:00:30 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Sun, 15 Mar 2015 20:00:30 -0400 (EDT) From: Paul Wouters To: John R Levine In-Reply-To: Message-ID: References: <20150314032550.26364.qmail@ary.lan> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: dane@ietf.org Subject: Re: [dane] Comments on draft-ietf-dane-openpgpkey-02 (fwd) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Mar 2015 00:00:38 -0000 On Sun, 15 Mar 2015, John R Levine wrote: >> What's the logic behind not mentioning a possible known problem for >> implementors of OPENPGPKEY? > > Because we have no workable solutions for it. I do not find that an acceptable reason to not mention a known problem in the document. It is clearly something implementors need to be aware of. > As I've said before, the reality that mail systems do fuzzy matching on > incoming addresses, but not in a way that is at all consistent, is a big > problem. It is such a big problem that we should not even mention it in the document? > I don't think it makes sense to try to advance OPENPGPKEY or SMIMEA > or _mailbox until we and the people who know about mail figure out what to do > about it. I'm asking them to take a look. This is a 20 year old problem. I see no reason why that 20 year old problem needs to stop the advancements of the OPENPGPKEY or SMIMEA RRtypes. It would be great if these people would want to help with a replacement text for Section 3.1. Paul From nobody Sun Mar 15 17:07: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 0E59E1A1BE7 for ; Sun, 15 Mar 2015 17:07:27 -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=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DznEJAUf7vww for ; Sun, 15 Mar 2015 17:07:26 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A8191A1BE6 for ; Sun, 15 Mar 2015 17:07:26 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3l4ycW0b08z6rN; Mon, 16 Mar 2015 01:07:22 +0100 (CET) Authentication-Results: mx.nohats.ca; dkim=pass reason="1024-bit key; unprotected key" header.d=nohats.ca header.i=@nohats.ca header.b=kZIRVlVk; dkim-adsp=pass 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 zFBmq9rNWqKv; Mon, 16 Mar 2015 01:07:22 +0100 (CET) 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, 16 Mar 2015 01:07:21 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 0E23180A01; Sun, 15 Mar 2015 20:00:31 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1426464031; bh=2ZqgsnhSP/aYTc2mv10aUCSqsvWaMtG0xXZBgtrRWxQ=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=kZIRVlVk1KZVq6iossLItaZFfpNMObRY67ytBGl/YdFp/znwQ7Y00xwBW3Bys5Hul 6HAxhZPLtu2wVdkZTZvrOhVqxEFNohXGj0bzo7Z+Yh73DxscP0N2gptFAJF20xQTJu Fga9i/IAJnKkmfgM2SuRqwTD9Fl8imTqTBpyN6UI= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id t2G00UUQ020108; Sun, 15 Mar 2015 20:00:30 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Sun, 15 Mar 2015 20:00:30 -0400 (EDT) From: Paul Wouters To: John R Levine In-Reply-To: Message-ID: References: <20150314032550.26364.qmail@ary.lan> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: dane@ietf.org Subject: Re: [dane] Comments on draft-ietf-dane-openpgpkey-02 (fwd) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Mar 2015 00:07:27 -0000 On Sun, 15 Mar 2015, John R Levine wrote: >> What's the logic behind not mentioning a possible known problem for >> implementors of OPENPGPKEY? > > Because we have no workable solutions for it. I do not find that an acceptable reason to not mention a known problem in the document. It is clearly something implementors need to be aware of. > As I've said before, the reality that mail systems do fuzzy matching on > incoming addresses, but not in a way that is at all consistent, is a big > problem. It is such a big problem that we should not even mention it in the document? > I don't think it makes sense to try to advance OPENPGPKEY or SMIMEA > or _mailbox until we and the people who know about mail figure out what to do > about it. I'm asking them to take a look. This is a 20 year old problem. I see no reason why that 20 year old problem needs to stop the advancements of the OPENPGPKEY or SMIMEA RRtypes. It would be great if these people would want to help with a replacement text for Section 3.1. Paul From nobody Sun Mar 15 17:09: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 709EA1A1BE6 for ; Sun, 15 Mar 2015 17:09:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ztbCYuHn__4b for ; Sun, 15 Mar 2015 17:09:47 -0700 (PDT) Received: from orthanc.ca (orthanc.ca [IPv6:2607:f2f8:abf8::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 406261A1BE7 for ; Sun, 15 Mar 2015 17:09:47 -0700 (PDT) Received: from [192.168.42.6] (d66-183-211-183.bchsia.telus.net [66.183.211.183]) (authenticated bits=0) by orthanc.ca (8.14.7/8.14.7) with ESMTP id t2G09iTi098930 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 15 Mar 2015 17:09:45 -0700 (PDT) (envelope-from lyndon@orthanc.ca) Content-Type: multipart/signed; boundary="Apple-Mail=_62776AB2-AD5B-471F-B00B-ADBC0B0F4552"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Lyndon Nerenberg In-Reply-To: Date: Sun, 15 Mar 2015 17:09:43 -0700 Message-Id: References: <20150314032550.26364.qmail@ary.lan> To: John R Levine X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: Paul Wouters , dane@ietf.org Subject: Re: [dane] Comments on draft-ietf-dane-openpgpkey-02 (fwd) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Mar 2015 00:09:48 -0000 --Apple-Mail=_62776AB2-AD5B-471F-B00B-ADBC0B0F4552 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Mar 15, 2015, at 4:52 PM, John R Levine wrote: > As I've said before, the reality that mail systems do fuzzy matching = on incoming addresses, but not in a way that is at all consistent, is a = big problem. I don't think it makes sense to try to advance OPENPGPKEY = or SMIMEA or _mailbox until we and the people who know about mail figure = out what to do about it. I'm asking them to take a look. Fuzzy matching on "mailboxes" bites in several places, far beyond email. = While way out of scope of everything being discussed here, I think the = idea of having a cut point handoff from the domain certification, to the = 'user' certification, is something we can't ignore. Sendmail's plus-addressing scheme is a deployed example of that sort of = usage. Given lyndon+mumble@orthanc.ca, we have all the bits to validate = the RHS of the @, and the initial token of the LHS. But with IoT = smacking us in the face, sub-personal locators are very quickly going to = become a fact of life. How to deal with the bits starting at the '+' is = scary. And out of context here. But it can't be ignored. --lyndon --Apple-Mail=_62776AB2-AD5B-471F-B00B-ADBC0B0F4552 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----- iQIcBAEBAgAGBQJVBh9HAAoJEG8PnXiV/JnUzmIQAK4m6LVXQuTv5Ie7ol8Ehd0W dLEE4qS+MSAbI0iH3PFhGkf2rTQ6fA52b5d+ydHzyyAX/y1+cs69K+zmwLOUIA8c sF6HIt6A2Fi9mId14Itn7nWNSofrOz3gyU/XNdhAfC7uTPoFwGy7Iaf92Zv33vc+ ykgU2Z192cxJBFoBrZoK/mcdAMSpPEtXIxvJzTZO++BbZNerFbqdpMOdReTFrJyN SWZDdNkuYopB5jVZDl82SIw7lwqyGqAU466v4u5W8L+KM1rrAWC5jyKFBmjJR6zS 2mvcGPBnv6Tu/RyhlTvvV2FrQlmwMPWc2jCS5JLTaxehAijgTj3nLE0wkAaYDlZw mhzafS9FDvhzZ2CONV7Ph8ChygX21m9ukX+zng/NtIINdgLsjBFtG4Y6Bz7k+tgz oQPD+GQMXrzIh0cVoAGmnRadbxdX9QE3rkHCgrzKguXPXS/WL0Z7oqIBhM2ppANl iG2gImd0pz1/LS6uc4JltLdFQNACgh1evF7ZJV88uZS5p2LVK/Yf5MddUtwED2Yi SpmxHiewLUStTqxLf/o73hTsHTHmnJ/5tUF7bXEV7IAPqAiZoZsuMKRL6spMlq5t wQIjagIAwGuS8cRbsC+C+U418Km0SAzFK3g85nr3BNJuq18puHq3UtKGVrj0dAXu XxqX/BH7pnP7935SvG8z =m7mU -----END PGP SIGNATURE----- --Apple-Mail=_62776AB2-AD5B-471F-B00B-ADBC0B0F4552-- From nobody Sun Mar 15 17: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 9A5701A1DBE for ; Sun, 15 Mar 2015 17:57:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.063 X-Spam-Level: X-Spam-Status: No, score=0.063 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, J_CHICKENPOX_15=0.6, J_CHICKENPOX_45=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2xupqEXG1r90 for ; Sun, 15 Mar 2015 17:57:53 -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 5F4A11A1DBD for ; Sun, 15 Mar 2015 17:57:53 -0700 (PDT) Received: (qmail 69040 invoked from network); 16 Mar 2015 00:57:51 -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=10daf.55062a8f.k1503; bh=jTcV+fiRI/2mG9bxC4QCyjZF36Yu8xPhnOtJ9+ydPIk=; b=WO2slZnk3NZpIRXVXUTY7vuXNoOGPqgGXLh1JjzQbOX3DD99L56TF8yVVB2vFkjKT3GC1PK7BNgHeEprqC9cXNT0eXDJPVsfnAnB6IAOjjP9DUvR9P8kkn8gXwgLRHUoLYVEDPIb3RQkFcxMlOr15+P6z4NiGf+gjAhRXnspsyjdU2SFv/VpmDyn3GHqE0LMY5xIuzKJnlJXSPTNnBCmWMzZqKmYvP/Jne3ItlRsEblz+4OzndlO02h9UAdV1eed 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=10daf.55062a8f.k1503; bh=jTcV+fiRI/2mG9bxC4QCyjZF36Yu8xPhnOtJ9+ydPIk=; b=MqmiBdOJh35ykwMP/T3nLnQWduU68cbULJL+sGkTsQSYcku8ov0s8XDNon9+J7MeeyEg8wOH2J88/hYo4mob3iYQKd4UNZSc8oij+HqLnFUampIRSfpzLsKimzukC21S70o5kTU7dHNd6HdRezyMR6YX/eu+HhkvoSDjmEZLHJtPfi0EcFKWKYTQ1GU0Ee7yjsyMyi9aH8elyK1qwrow2b2pewKZXRtfOVnudvg3WJM4qUZ4ToJxwYKFgjJDfmxF 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; 16 Mar 2015 00:57:51 -0000 Date: 15 Mar 2015 20:57:50 -0400 Message-ID: From: "John R Levine" To: "Lyndon Nerenberg" In-Reply-To: References: <20150314032550.26364.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] Comments on draft-ietf-dane-openpgpkey-02 (fwd) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Mar 2015 00:57:54 -0000 > Fuzzy matching on "mailboxes" bites in several places, far beyond email. While way out of scope of everything being discussed here, I think the idea of having a cut point handoff from the domain certification, to the 'user' certification, is something we can't ignore. Right. As I said before, it's a big can of worms. If we think it needs to be addressed at all, we need to pull it out of the current drafts (such as section 3 of the openpgp draft) and deal with it directly. > Sendmail's plus-addressing scheme is a deployed example of that sort of > usage. There's a huge list of them, case folding, ignoring some dots, ignoring all dots, various sorts of LDAP things to match john.smith, johnsmith, jsmith, and j.smith, often data dependent so jsmith only works if it only matches on e address. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. From nobody Mon Mar 16 08:19:22 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE7081A1B71 for ; Mon, 16 Mar 2015 08:19:20 -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 Yj8NC1416_LJ for ; Mon, 16 Mar 2015 08:19:19 -0700 (PDT) Received: from ore.jhcloos.com (ore.jhcloos.com [198.147.23.85]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97BC41A8765 for ; Mon, 16 Mar 2015 08:19:19 -0700 (PDT) Received: by ore.jhcloos.com (Postfix, from userid 10) id BF5EC1E492; Mon, 16 Mar 2015 15:19:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=ore14; t=1426519158; bh=B5ofVFPeBT9Zx16qDukK2xS/7ctsxO/cv4odTUB5FV8=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=QxjlEKAqtyERPtGLJFsGhWaCX33mMYwe68vrkUmEKW/WLTzkceKjXOyDKqkXURnLr fq5Iyj7P68dhcFdwpIz9egcLFA6wlMLrzTc32tQer4iMzEdBAJRJ34xZtcry7zBYze zCuodZUTG09k8NJFub/2LSjL1BakCxfcX3C9vvf8= Received: by carbon.jhcloos.org (Postfix, from userid 500) id EFCC31009E15E; Mon, 16 Mar 2015 15:18:30 +0000 (UTC) From: James Cloos To: Paul Wouters In-Reply-To: (Paul Wouters's message of "Sun, 15 Mar 2015 20:00:30 -0400 (EDT)") References: <20150314032550.26364.qmail@ary.lan> 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: Mon, 16 Mar 2015 11:18:30 -0400 Message-ID: Lines: 19 MIME-Version: 1.0 Content-Type: text/plain X-Hashcash: 1:28:150316:paul@nohats.ca::16IYqKWOCCAVNhHD:008PC2h X-Hashcash: 1:28:150316:johnl@taugh.com::nE+TwfBLQCZDnuNj:01cCp8 X-Hashcash: 1:28:150316:dane@ietf.org::NURfhGfRTHhcOVv3:000760Yb Archived-At: Cc: John R Levine , dane@ietf.org Subject: Re: [dane] Comments on draft-ietf-dane-openpgpkey-02 (fwd) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Mar 2015 15:19:21 -0000 JL>> As I've said before, the reality that mail systems do fuzzy JL>> matching on incoming addresses, but not in a way that is at JL>> all consistent, is a big problem. PW> It is such a big problem that we should not even mention it in PW> the document? I have to agree with Paul on this issue; Section 3.1 does not hurt the draft and should not prevent its publication as an RFC. I'm not as certain whether the language is ideal, and a separate followup document further discussing the issue is not a bad idea. But there is nothing wrong with this document noting the issue's existance. -JimC -- James Cloos OpenPGP: 0x997A9F17ED7DAEA6 From nobody Mon Mar 16 19:05: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 4061C1ACDE3 for ; Mon, 16 Mar 2015 19:05: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 5bcqDLVl9tco for ; Mon, 16 Mar 2015 19:05: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 BA2A21ACDE0 for ; Mon, 16 Mar 2015 19:05:11 -0700 (PDT) Received: (qmail 69858 invoked from network); 17 Mar 2015 02:05:10 -0000 Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 17 Mar 2015 02:05:10 -0000 Date: 17 Mar 2015 02:04:48 -0000 Message-ID: <20150317020448.32776.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] Comments on draft-ietf-dane-openpgpkey-02 (fwd) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Mar 2015 02:05:13 -0000 >PW> It is such a big problem that we should not even mention it in >PW> the document? Yes, it is. You have no idea. The stuff in section 3 of the openpgpkey draft is trying to canonicalize mailbox names, i.e., given some mailbox name, find the "real" mailbox name that it corresponds to. This is an extremely difficult problem that people have been scratching their heads about literally for decades with no success. With the advent of EAI, mailboxes can be arbitrary UTF-8 rather than ASCII, which makes the already intractable problem of what's equivalent to what much harder. For example, folding upper and lower case in ASCII is easy, while in EAI it pretty much impossible for a variety of reasons. One new problem (not the hardest) is that the case folding rules are language specific -- the way you fold accented characters in Turkish is different from the way you do it in French, and it's even different between European French and Canadian French. You cannot tell by looking at a mailbox name what language it is. Unless you are vastly smarter than everyone else who has looked at this problem, you're not going to solve it any time soon. Every approach suggested so far is something we're aware of and is known not to work when applied to the complex mess that is Internet e-mail. If you want to use hashes to represent mailbox names, you either have to completely punt on variant names, which the users will hate, or stop here, talk to people who understand the subtle reality of mail and see if there's any way to come up with something that works. As I've said before, if you try to advance a draft with language anything like what's in section 3.1, it will be shot down in IETF last call and again in the IESG, neither time by me. I realize this isn't what you want to hear, but you've dived into a swamp. You may not recognize it as a swamp, but trust me, that's where you are. R's, John From nobody Mon Mar 16 19:17:48 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F6D51A905B for ; Mon, 16 Mar 2015 19:17:47 -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 ylg_RA7eSa-2 for ; Mon, 16 Mar 2015 19:17:45 -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 F15071A904A for ; Mon, 16 Mar 2015 19:17:44 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3l5dSN46bcz1HF; Tue, 17 Mar 2015 03:17:40 +0100 (CET) Authentication-Results: mx.nohats.ca; dkim=pass (1024-bit key) header.d=nohats.ca header.i=@nohats.ca header.b=d5DoVu8P 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 1xMCBNOB-oT6; Tue, 17 Mar 2015 03:17:39 +0100 (CET) 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, 17 Mar 2015 03:17:39 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 904A380416; Mon, 16 Mar 2015 22:17:38 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1426558658; bh=+/czrCDySH1ewgRKPqzARdKTaGsCylnJhYNJMCpn6fs=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=d5DoVu8P3hYVALEpCZSYkhKN+HFPtfHbcX8UU4KVdHnoi/33euOcK0hreWOMQTXse N4dAVBwayIICs4yI8gsJgD2IEVrugJh3/XSD4Wqx09rVlSelDiEwhgNyiNOpNzDO1I YL/jV4yW+wgIqHe4WTvavRV47MDKB9dLPW67YRSk= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id t2H2HbV3028211; Mon, 16 Mar 2015 22:17:37 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Mon, 16 Mar 2015 22:17:37 -0400 (EDT) From: Paul Wouters To: John Levine In-Reply-To: <20150317020448.32776.qmail@ary.lan> Message-ID: References: <20150317020448.32776.qmail@ary.lan> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: dane@ietf.org Subject: Re: [dane] Comments on draft-ietf-dane-openpgpkey-02 (fwd) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Mar 2015 02:17:47 -0000 On Mon, 17 Mar 2015, John Levine wrote: >> PW> It is such a big problem that we should not even mention it in >> PW> the document? Note how I wrote "mention", not "solve". > Yes, it is. You have no idea. You say I cannot "mention" it. > Unless you are vastly smarter than everyone else who has looked at > this problem, you're not going to solve it any time soon. I am not trying to "solve" it. I just want to "mention" it. > As I've said before, if you try to advance a draft with language > anything like what's in section 3.1, it will be shot down in IETF last > call and again in the IESG, neither time by me. Which is why I asked you if the text just "mentioning" the problem is okay or not. If this problem is such a taboo that we cannot even mention it, it is the IETF process that needs fixing, not Section 3.1. That said, since you seem to be in the know about what text leads to failure, it would be good to know what text you think is least likely to lead to failure (without saying "none" which is not an acceptable choice to me and others) Paul From nobody Mon Mar 16 23:13: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 727401A006F for ; Mon, 16 Mar 2015 23:13:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.2 X-Spam-Level: * X-Spam-Status: No, score=1.2 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_21=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 S1iQ6GQPdN2U for ; Mon, 16 Mar 2015 23:13:18 -0700 (PDT) Received: from m3.myinfrastructure.org (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 D7F0E1A001A for ; Mon, 16 Mar 2015 23:13:17 -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 m3.myinfrastructure.org (Postfix) with ESMTPS id 9DAD87FC79 for ; Tue, 17 Mar 2015 07:13:14 +0100 (CET) Received: from csmobile4.home.strotmann.de.strotmann.de (unknown [IPv6:2001:4dd0:ff00:809d:6236:ddff:fe64:4f92]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by debian01.home.strotmann.de (Postfix) with ESMTPSA id E1C6F20006B for ; Tue, 17 Mar 2015 07:13:13 +0100 (CET) References: <20150313182334.24823.qmail@ary.lan> From: Carsten Strotmann To: dane@ietf.org In-reply-to: <20150313182334.24823.qmail@ary.lan> Date: Tue, 17 Mar 2015 07:13:11 +0100 Message-ID: <87bnjsdudk.fsf@csmobile4.home.strotmann.de> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [dane] Names of mailbox records in draft-ietf-dane-smime and 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, 17 Mar 2015 06:13:19 -0000 Hi, John Levine writes: > I see that in dane-openpgpkey, the name on the record is > > ._openpgpkey.domain > > and in dane-smime, the name is: > > ._smimecert.domain > > These are two different names for the same mailbox. Since they use > the same hash, wouldn't it be a better idea for both of them and any > future RRs that use hashed mailboxes to use the same name? > > ._mailbox.domain > > There's no confusion between the two, since they're different RR > types. The tree walking attacks are no different, since the attacker > knows the small set of _token names that might be in use either way. > being able to delegate subdomains for "_openpgpkey" and "_smimecert" adds operational flexibility. Already during test implementations of the drafts, I found it helpful to be able to delegate the two domains to a different set of nameservers, into differnt zones with different ACLs (and TSIG-Keys for dynamic updating owned by different people). I see that in corporate environments PGP and S/MIME are managed by separate teams/entities (S/MIME being the "official" supported protocol, PGP being the "defacto" used protocol by the IT team). Having different domains to delegate really would ease implementation in some scenarios. The price for the added flexibility is not too high. Carsten Strotmann -- Sent with my mu4e From nobody Tue Mar 17 06:11: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 41DC21A00BE for ; Tue, 17 Mar 2015 06:11:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZdWX5VWntRxV for ; Tue, 17 Mar 2015 06:10:57 -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 75C951A03F9 for ; Tue, 17 Mar 2015 06:10:57 -0700 (PDT) Received: by oifu20 with SMTP id u20so183023oif.0 for ; Tue, 17 Mar 2015 06:10:57 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:thread-topic:thread-index :date:message-id:references:in-reply-to:accept-language :content-language:user-agent:content-type:content-id :content-transfer-encoding:mime-version; bh=rrerrpwwaSzh3dDX5Pgy9YkMCXO4p2QYE4j+zAFDWqc=; b=PBdzIaaw98IL68Oq7zGNhtLbxzEVKjYnWiRuj2pNzjJpwh+jdjXv3euJWQYGtKJf2k p/Ch0IGdVKRsbs9PTlOmnD+hbQS6IUH/TUxwDzA0cLtRUotz0JhUKYfDoRfXttBzv2yJ rNl2de9liBGoP+x8XCtEIOVxwcBXlccD/Bo08HercDOYEPh+l+jkYL+vxCyYTv1iAExS D5hYQ6rNRSGy2GRkBPKwx9c2HRLmq6JXZato4hq8xmbYrp/Ep7vxzjob05hJ9OJ6goBd p5UorAk++lLp77No1WDwBBDUXXXKsESOcEvx/3zOeDvD8jCCH+qs81Y1DPGvqgNyagfF AVsA== X-Gm-Message-State: ALoCoQklScgDcuJSSfuV7OqAZrzkectOLRgylw3FoVCaKOjOO3Mdh5ifEgeYY02j3BYcdqsSMmXh3man6A143Wi9h5D9v9T4sw== X-Received: by 10.140.234.2 with SMTP id f2mr85063062qhc.63.1426597856899; Tue, 17 Mar 2015 06:10:56 -0700 (PDT) Received: from brn1lxmailout02.verisign.com (brn1lxmailout02.verisign.com. [72.13.63.42]) by mx.google.com with ESMTPS id gt4sm3670328qcb.3.2015.03.17.06.10.56 (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 17 Mar 2015 06:10:56 -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 t2HDAuvb032681 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 17 Mar 2015 09:10:56 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by BRN1WNEXCHM01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Tue, 17 Mar 2015 09:10:55 -0400 From: "Wiley, Glen" To: John R Levine Thread-Topic: [dane] Payment association records Thread-Index: AQHQW4ClIQaNAKPSFUqV1JxlK/mNZJ0ZnR6AgADuB/6AAGCIgIAFxPeA Date: Tue, 17 Mar 2015 13:10:22 +0000 Message-ID: References: <20150312210723.16146.qmail@ary.lan> <641EE49757824F4BBE5F863B22FDDBF23C454BA9@BRN1WNEXMBX01.vcorp.ad.vrsn.com> 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.8.150116 x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <99D98CF79C2A5044ACB6849D43BAE83C@verisign.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "dane@ietf.org" Subject: Re: [dane] Payment association records X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 17 Mar 2015 13:11:00 -0000 On 3/13/15, 1:04 PM, "John R Levine" wrote: >> In the PMTA draft I offered the same locator approach as SMIMEA, >>however=20 >> also mention that that is one of many possible means for locating the >> record. It is not hard to image use cases in which a recipient would >> want to expose multiple payment associations that don't necessarily >> correspond to a mailbox. > >There's two separate questions here -- one is what name to use in the >DNS,=20 >and the other is what sort of RR to put there. My point is that if the >name corresponds to a hashed mailbox, the sensible name is >._mailbox.domain, regardless of what RRs one uses. If you want to >publish PMTA records that don't correspond to a mailbox, that's no >problem, use the same record with different names. For obvious reasons, >it would not be great to have some _pmta names being mailboxes and some >being something else. I see what you are driving at. Locating records becomes more uniform in the case of identifiers that map directly to email. One of the points we made in the draft was that hashed email user names is a Possible but not exclusive means for locating the payment association. It Certainly helps reduce friction between parties but I would like to not Constrain future use cases, I can imagine other locating mechanisms that are Tied to something other than an email address. One question for the WG then is whether it makes sense to take your suggestion To the other records under discussion (SMIME, OPENPGPKEY). > >> Do you feel IBAN should be an exemplar? > >Yes, both because it's very widely used, and it brings in the important >issue of payment systems that handle multiple currencies. I think you'll >find that ACH and Bitcoin are fairly unusual in that they are each single >currency. Thanks for highlighting that issue. We=B9ll probably use that in a future Version of the draft. > >Regards, >John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY >Please consider the environment before reading this e-mail. From nobody Tue Mar 17 06:13: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 8C8631A0470 for ; Tue, 17 Mar 2015 06:13:55 -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 J90v00tRwN0B for ; Tue, 17 Mar 2015 06:13:53 -0700 (PDT) Received: from mail-oi0-f99.google.com (mail-oi0-f99.google.com [209.85.218.99]) (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 3C8011A046D for ; Tue, 17 Mar 2015 06:13:51 -0700 (PDT) Received: by oiba3 with SMTP id a3so183497oib.2 for ; Tue, 17 Mar 2015 06:13:50 -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=WMNIHONFYuf77fBULy2YQjMJp7vvY7EDjTYt4Kqfq+w=; b=g6uVnmAqQ6min4BGjiTS5zMtHyoUvqUuGWWRIYCO7HUryeR7uaaoTQK2EunjrPKWAT WVikxeYITxqfgBIZy53KWJH5TcxldoGl/7O1wXIKCOiiOV7s/AskhJJUAyPOnX1MivPP +J6Up7mBZdPoxMppcMJxyyHTGWP7k7iU0Qh6SruBTEo81d7wxEg5j+sJjFlxrTCVFECx dlgA3h8Eky2CdEtvyzpAwdtqMushaodQjMasw0NwjVd8IBzeczsaSZwLJZ3CbBzkPwep cBD7H2qm7iXUJZlclbANC0givQsETLRXFtzhEG1BCrHqs+SBlr/T2ztU/unYWU563/9K OFIg== X-Gm-Message-State: ALoCoQlQ8HkxHfOSssao1twbQ+oJu39mqZUVMiUmXcp1rYc9IRbFiujESjs3M2ZapW4O2lLvGRtoQoxqHx9zLbv+2b2kIMThcw== X-Received: by 10.140.145.3 with SMTP id 3mr85611150qhr.42.1426598030677; Tue, 17 Mar 2015 06:13:50 -0700 (PDT) Received: from brn1lxmailout01.verisign.com (brn1lxmailout01.verisign.com. [72.13.63.41]) by mx.google.com with ESMTPS id jy4sm3710430qcb.0.2015.03.17.06.13.50 (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 17 Mar 2015 06:13:50 -0700 (PDT) X-Relaying-Domain: verisign.com Received: from brn1wnexcas02.vcorp.ad.vrsn.com (brn1wnexcas02 [10.173.152.206]) by brn1lxmailout01.verisign.com (8.13.8/8.13.8) with ESMTP id t2HDDnnm006942 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 17 Mar 2015 09:13:50 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas02.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Tue, 17 Mar 2015 09:13:49 -0400 From: "Wiley, Glen" To: Paul Hoffman , "" Thread-Topic: [dane] Names of mailbox records in draft-ietf-dane-smime and draft-ietf-dane-openpgpkey Thread-Index: AQHQXbrq3cCkm4z1X0CebonWTq/OV50bGw+AgAWR7oA= Date: Tue, 17 Mar 2015 13:13:15 +0000 Message-ID: References: <20150313182334.24823.qmail@ary.lan> <33E881E6-A73B-4EC3-AAD9-E07B82C21D83@vpnc.org> In-Reply-To: <33E881E6-A73B-4EC3-AAD9-E07B82C21D83@vpnc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.8.150116 x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="us-ascii" Content-ID: <8C888D96A2094C409ABB31BF240419B8@verisign.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [dane] Names of mailbox records in draft-ietf-dane-smime and 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, 17 Mar 2015 13:13:55 -0000 On 3/13/15, 4:10 PM, "Paul Hoffman" wrote: > >> On Mar 13, 2015, at 11:23 AM, John Levine wrote: >>=20 >> I see that in dane-openpgpkey, the name on the record is >>=20 >> ._openpgpkey.domain >>=20 >> and in dane-smime, the name is: >>=20 >> ._smimecert.domain >>=20 >> These are two different names for the same mailbox. Since they use >> the same hash, wouldn't it be a better idea for both of them and any >> future RRs that use hashed mailboxes to use the same name? >>=20 >> ._mailbox.domain > >This could go either way. If the WG thinks that the user, or someone >responsible for the user, will add and change DNS records for that user, >your proposal would clearly be better because you could delegate the user >to a new subzone. On the other hand, if the WG thinks that the security >admin will be the one adding and changing records for a particular type >of mail security, then the design we are using now is better. I lean >towards the second, but can see the merit of the first now that people >are thinking of using this for things other than just mail security. I would like to suggest that we need to begin considering the need for users to directly affect the records that refer to them. For example you want a user to be able to manage their own public key without getting the zone administrator involved directly. One way to do this is to use a system that proxies for the zone administrator, but the bottom line is that as we move toward user specific data in the DNS we need to begin thinking about things a little differently. > >--Paul Hoffman >_______________________________________________ >dane mailing list >dane@ietf.org >https://www.ietf.org/mailman/listinfo/dane From nobody Tue Mar 17 06:18: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 5DB021A06FD for ; Tue, 17 Mar 2015 06:17:53 -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 ErlVGNVsG_R3 for ; Tue, 17 Mar 2015 06:17:48 -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 C2C7C1A049A for ; Tue, 17 Mar 2015 06:17:48 -0700 (PDT) Received: by oiba3 with SMTP id a3so185986oib.2 for ; Tue, 17 Mar 2015 06:17:48 -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=4dLMqC6XKI+25fqhUmjHX2NnrprJsrLfPI5PS+BdlJQ=; b=G4/YzHCkw7oWWNAXQweOB+Jv5O/WEvjAa+Uod83LDT3UhrpNbR+vQm2scexl2vJWFc p2DBWbqek/Vv77G2t9JIuubp4SpOuEm3vRVimr44Nr8XNE4ukpFNbOHNgX4omrbCh+Gq 6AVf1Ef7YP3KsR6wPLcpkHMxfj5I/EHIwlnEwUYyYwrAZ13JX+9V6xmHAd/OcXuDZdGz srUvOWMSF1pFlY/dYymTb0MxF/K0s3wNDLy8JzRRYi3pdcnDeEnfFclLgJcxioeCk79f UJ5OIhMYP+ZZGHN2aCRj+Kf1Akjg1/Bzeiv50pBY/GAplxx8Fm8E+G5dQKSunVs8h07r Jxew== X-Gm-Message-State: ALoCoQktpA+B0k9AaNiWFCrwJbE/0qi/DK5H03eH4THmVTRkgAaBBljKe6IgvIQNGhZL+f+wSPDGLqK2RU7ft7c+OQ0b6Nnh7A== X-Received: by 10.55.31.82 with SMTP id f79mr87953524qkf.31.1426598268275; Tue, 17 Mar 2015 06:17:48 -0700 (PDT) Received: from brn1lxmailout02.verisign.com (brn1lxmailout02.verisign.com. [72.13.63.42]) by mx.google.com with ESMTPS id gt4sm3674911qcb.3.2015.03.17.06.17.48 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 17 Mar 2015 06:17:48 -0700 (PDT) X-Relaying-Domain: verisign.com Received: from brn1wnexcas02.vcorp.ad.vrsn.com (brn1wnexcas02 [10.173.152.206]) by brn1lxmailout02.verisign.com (8.13.8/8.13.8) with ESMTP id t2HDHlvj001037 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 17 Mar 2015 09:17:47 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas02.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Tue, 17 Mar 2015 09:17:47 -0400 From: "Wiley, Glen" To: "dane@ietf.org" Thread-Topic: [dane] Names of mailbox records in draft-ietf-dane-smime and draft-ietf-dane-openpgpkey Thread-Index: AQHQXbrq3cCkm4z1X0CebonWTq/OV50bGw+AgADGfwCABMyNgA== Date: Tue, 17 Mar 2015 13:17:13 +0000 Message-ID: References: <20150313182334.24823.qmail@ary.lan> <33E881E6-A73B-4EC3-AAD9-E07B82C21D83@vpnc.org> <20150314080047.GO18819@mournblade.imrryr.org> In-Reply-To: <20150314080047.GO18819@mournblade.imrryr.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.8.150116 x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [dane] Names of mailbox records in draft-ietf-dane-smime and 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, 17 Mar 2015 13:17:53 -0000 On 3/14/15, 4:00 AM, "Viktor Dukhovni" wrote: >On Fri, Mar 13, 2015 at 01:10:21PM -0700, Paul Hoffman wrote: > >> This could go either way. If the WG thinks that the user, or >> someone responsible for the user, will add and change DNS records >> for that user, your proposal would clearly be better because you >> could delegate the user to a new subzone. On the other hand, if >> the WG thinks that the security admin will be the one adding and >> changing records for a particular type of mail security, then the >> design we are using now is better. I lean towards the second, but >> can see the merit of the first now that people are thinking of >> using this for things other than just mail security. > >I think this mental model of tools that update the DNS is too naive. >It seems to assume that the tools can make decisions based only >on the requestor credentials and the owner name of the RRset to >be added. I agree enthusiastically. > >I think it is far more likely that administrators and users will >be interacting with a middle-ware management system that enables >them to add and remove keys and *that* system will be able to >publish all the requisite records on behalf of either individual >users or administrators. This is exactly the direction I think things need to head to move DANE adoption forward into the mainstream. > >So the structure of the DNS namespace should be optimized for >clarity/simplicity, rather than a presumed set of management tools >(e.g. direct authorization to inject records via dynamic update into >a particular portion of the namespace). >=20 >--=20 > Viktor. > >_______________________________________________ >dane mailing list >dane@ietf.org >https://www.ietf.org/mailman/listinfo/dane From nobody Tue Mar 17 06:20: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 30D461A066B for ; Tue, 17 Mar 2015 06:20:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.137 X-Spam-Level: X-Spam-Status: No, score=-1.137 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tvUmt-nCeDPw for ; Tue, 17 Mar 2015 06:20:11 -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 041DC1A064C for ; Tue, 17 Mar 2015 06:20:10 -0700 (PDT) Received: (qmail 55659 invoked from network); 17 Mar 2015 13:20:10 -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=d96a.55082a0a.k1503; bh=c7sfBWBfP3tYzw1NBwOVo8uU1VVm4FfvVPFAw3XmV28=; b=CBH1XHY4Fit+8FwSva4Z06d81T6rHl7I5aP4xnPGaoUIi1/OyheVLLm9BIjuavDEzsgksJmqayLsjMvfSr9+pmQSKhXqpjBvwllriWofpRIykOWyMCMpEz8QNFbD/456vWcRy0EzFKK5Xhglst1S8mr2p8ARVZZRuCcjBkuS32Njh77fQgLlspx4i0NUzvtzkpHkRabKlWKw2cgpsDLzEtDMrDJd00FEdv8pxo5d3qtEMVSkqgueMwkeRDqU9CW+ 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=d96a.55082a0a.k1503; bh=c7sfBWBfP3tYzw1NBwOVo8uU1VVm4FfvVPFAw3XmV28=; b=pAnueZ8nuLMzzB/Pgv4i+Hc7R8TmA5CF87x+mL1jC2CZDeu2i8fy043BTIZYxAQ6kg7+ONe/OvXocXDh3LrtcKWlBobqvVPelRqlr1Z5Hj6pZo7QHsHz2B+mvJvibBZ7Q1WSPOTszQGodmm8wlfkYCmfsNZ+eC06iKC22R9jIfef8rjLOiEGIiDuZzAbc9yqTlN47qnuESMBouRHe/bmTX3uycEwQdOFPgjAUwCCI0ZFsld4C899rKqxWwG0D/Mx 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; 17 Mar 2015 13:20:09 -0000 Date: 17 Mar 2015 09:20:08 -0400 Message-ID: From: "John R Levine" To: "Wiley, Glen" In-Reply-To: References: <20150312210723.16146.qmail@ary.lan> <641EE49757824F4BBE5F863B22FDDBF23C454BA9@BRN1WNEXMBX01.vcorp.ad.vrsn.com> 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] Payment association records X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 17 Mar 2015 13:20:12 -0000 > One of the points we made in the draft was that hashed email user names > is a Possible but not exclusive means for locating the payment > association. It Certainly helps reduce friction between parties but I > would like to not Constrain future use cases, I can imagine other > locating mechanisms that are Tied to something other than an email > address. That's no problem, just use a different name for a different locator, e.g., 123456._duns.domain if you wanted to look up by DUNS number. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. From nobody Tue Mar 17 08:23: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 C16F61A1EED for ; Tue, 17 Mar 2015 08:23:36 -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 P6yi77nLuqOn for ; Tue, 17 Mar 2015 08:23:35 -0700 (PDT) Received: from mail-qg0-f97.google.com (mail-qg0-f97.google.com [209.85.192.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 735801A1C06 for ; Tue, 17 Mar 2015 08:23:35 -0700 (PDT) Received: by qgdz107 with SMTP id z107so292425qgd.1 for ; Tue, 17 Mar 2015 08:23:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:thread-topic:thread-index :date:message-id:references:in-reply-to:accept-language :content-language:user-agent:content-type:content-id :content-transfer-encoding:mime-version; bh=gQ5Ogq5BD+5ovIbunvV1m+/M0Jwka7K+lcVif2/4o4w=; b=fsXU+Pd0CWwX6UneA47M/oI78biwfgXhb18PCDaed0m7K/9NnaHt+BFRnJLhAHmQ8/ Uq4pxHOxx4XdGPuzPYla8hzhVkPZV6OskHHLa9AchYqzBH+XsUlO1nuvPce1Uv9mxcEx j47pdiQSfxHO2jkUrQFp6FFuzRcFdCAKHYXAePf1gqsxHr9s7SvCpkOo2c2/wDKSpOGj ErrCw7d5y9qK+WQO/jK6WmLtbjduYJOT+JCkIGl7IfDWME3UTUbts3J05a/pDgXaUpr1 pKdzh1qaZJDEyVUKdby3iRnNB50fyBdWqbpHbAGuixCLivS2zLZetEwxCPcd4ZHLaHW0 Wh9w== X-Gm-Message-State: ALoCoQlSAwP1/xS99xYfIB1Ll5B5CffxwwFTgvcLDVV+kkMkrwh6ikdAOta/MocaRi04r+VEpDLmhmqHslOZiI1BiBsMTkEQWA== X-Received: by 10.140.233.78 with SMTP id e75mr83501012qhc.92.1426605814705; Tue, 17 Mar 2015 08:23:34 -0700 (PDT) Received: from brn1lxmailout02.verisign.com (brn1lxmailout02.verisign.com. [72.13.63.42]) by mx.google.com with ESMTPS id gt4sm3761973qcb.3.2015.03.17.08.23.34 (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 17 Mar 2015 08:23:34 -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 t2HFNY1X016833 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 17 Mar 2015 11:23:34 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by BRN1WNEXCHM01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Tue, 17 Mar 2015 11:23:33 -0400 From: "Wiley, Glen" To: John R Levine Thread-Topic: [dane] Payment association records Thread-Index: AQHQW4ClIQaNAKPSFUqV1JxlK/mNZJ0ZnR6AgADuB/6AAGCIgIAFxPeAgABFlgD//997gA== Date: Tue, 17 Mar 2015 15:23:00 +0000 Message-ID: References: <20150312210723.16146.qmail@ary.lan> <641EE49757824F4BBE5F863B22FDDBF23C454BA9@BRN1WNEXMBX01.vcorp.ad.vrsn.com> 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.8.150116 x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "dane@ietf.org" Subject: Re: [dane] Payment association records X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 17 Mar 2015 15:23:36 -0000 On 3/17/15, 9:20 AM, "John R Levine" wrote: >> One of the points we made in the draft was that hashed email user names >> is a Possible but not exclusive means for locating the payment >> association. It Certainly helps reduce friction between parties but I >> would like to not Constrain future use cases, I can imagine other >> locating mechanisms that are Tied to something other than an email >> address. > >That's no problem, just use a different name for a different locator, >e.g., 123456._duns.domain if you wanted to look up by DUNS number. Exactly, although I suspect you could even loose the _ label as well. You could use something like weekendsubscription.mynewspaper.com > >Regards, >John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY >Please consider the environment before reading this e-mail. From nobody Tue Mar 17 09:46: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 0C4FB1A8772 for ; Tue, 17 Mar 2015 09:46:29 -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 M717Si_dLQWA for ; Tue, 17 Mar 2015 09:46:28 -0700 (PDT) Received: from homiemail-a72.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 3F89A1A877E for ; Tue, 17 Mar 2015 09:46:28 -0700 (PDT) Received: from homiemail-a72.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a72.g.dreamhost.com (Postfix) with ESMTP id D94D46B0083; Tue, 17 Mar 2015 09:46:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=QizBjpBIDvb8uI XU1VF3ku9j54w=; b=NkLClwbFuKn1XUszPaOxnh3HWMNJqTFh7kpVEdaZSpVDFr V5F+EnQcuOoiYTZAtg0nwhPmlJwVoWMI3QhQqrMc8pz1r4Q7eS7EV5gfg7X4gbgm I8IKS1SHBRC6NAJSWbfJj6cjh5aRWGT++3BvTMKb4oj+0ZbK+BQAjOe6gDApU= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a72.g.dreamhost.com (Postfix) with ESMTPA id DC4F26B003E; Tue, 17 Mar 2015 09:46:26 -0700 (PDT) Date: Tue, 17 Mar 2015 11:46:24 -0500 From: Nico Williams To: "Wiley, Glen" Message-ID: <20150317164623.GI3479@localhost> References: <20150313182334.24823.qmail@ary.lan> <33E881E6-A73B-4EC3-AAD9-E07B82C21D83@vpnc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: Paul Hoffman , "" Subject: Re: [dane] Names of mailbox records in draft-ietf-dane-smime and 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, 17 Mar 2015 16:46:29 -0000 On Tue, Mar 17, 2015 at 01:13:15PM +0000, Wiley, Glen wrote: > I would like to suggest that we need to begin considering the need for > users to directly affect the records that refer to them. For example you > want a user to be able to manage their own public key without getting the > zone administrator involved directly. One way to do this is to use a > system that proxies for the zone administrator, but the bottom line is > that as we move toward user specific data in the DNS we need to begin > thinking about things a little differently. It'd be nice if there was a decent authorization model for DNS updates. In practice one has to use a proxy to implement authorization for DNS updates. This is a topic for a different working group, but DANE brings this problem to the foreground as administrators have to delegate authority over TLSA RR contents to the owners of the associated end entities (in this case: the end entities themselves). Without a standard mechanism for delegation of authority DANE will be difficult to use in enterprise systems (where TLSA RRs for servers may not matter so much, but user S/MIME certs will probably matter more). I suspect that proprietary and/or IMAP (with extensions) email services will end up acting as the proxies in this case. ("Obviously" one might want to store authorization information in DNS itself, but the moment one brings user groups into the picture, things get custom/complicated.) Nico -- From nobody Tue Mar 17 10:08:41 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90A5F1A1B4B for ; Tue, 17 Mar 2015 10:08:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.147 X-Spam-Level: X-Spam-Status: No, score=-0.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_15=0.6, J_CHICKENPOX_45=0.6] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id twmLzvgJkAOy for ; Tue, 17 Mar 2015 10:08:37 -0700 (PDT) Received: from proper.com (Opus1.Proper.COM [207.182.41.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B86AB1A1AB6 for ; Tue, 17 Mar 2015 10:08:37 -0700 (PDT) Received: from [10.20.30.101] (50-1-51-95.dsl.dynamic.fusionbroadband.com [50.1.51.95]) (authenticated bits=0) by proper.com (8.15.1/8.14.9) with ESMTPSA id t2HH8aPm039339 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 17 Mar 2015 10:08:37 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: proper.com: Host 50-1-51-95.dsl.dynamic.fusionbroadband.com [50.1.51.95] claimed to be [10.20.30.101] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Paul Hoffman In-Reply-To: Date: Tue, 17 Mar 2015 10:08:36 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20150314032550.26364.qmail@ary.lan> To: dane WG list X-Mailer: Apple Mail (2.2070.6) Archived-At: Subject: Re: [dane] Comments on draft-ietf-dane-openpgpkey-02 (fwd) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Mar 2015 17:08:38 -0000 On Mar 15, 2015, at 5:57 PM, John R Levine wrote: >=20 >> Fuzzy matching on "mailboxes" bites in several places, far beyond = email. While way out of scope of everything being discussed here, I = think the idea of having a cut point handoff from the domain = certification, to the 'user' certification, is something we can't = ignore. >=20 > Right. As I said before, it's a big can of worms. If we think it = needs to be addressed at all, we need to pull it out of the current = drafts (such as section 3 of the openpgp draft) and deal with it = directly. >=20 >> Sendmail's plus-addressing scheme is a deployed example of that sort = of usage. >=20 > There's a huge list of them, case folding, ignoring some dots, = ignoring all dots, various sorts of LDAP things to match john.smith, = johnsmith, jsmith, and j.smith, often data dependent so jsmith only = works if it only matches on e address. Historically, "the draft pretends the problem doesn't exist" causes ugly = late surprises in the IESG, and then (often?) more convoluted RFCs. = Having said that, John has a good point that the current wording sounds = like it says "here are a few problems, and here is a potential = solution". Section 3.1 would be better worded as: 3.1. Email address variants Some email service providers and email software perform automatic = mappings of the LHS of email addresses based on special characters. = This makes finding OPENPGPKEY record for a particular name that might be = mapped impossible because there is no complete set of mappings and, = worse, some common mappings conflict with each other. It might be tempting for software that implements DNS lookup for the = OPENPGPKEY RRtype to try to perform similar mappings while trying to = find a particular OPENPGPKEY record. This SHOULD NOT be done because = some mapping attempts might retrieve the key for the wrong user, = depending on the mapping rules of the service provider or software = platform. --Paul Hoffman= From nobody Tue Mar 17 10: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 B70641A1B43 for ; Tue, 17 Mar 2015 10:08:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.862 X-Spam-Level: X-Spam-Status: No, score=0.862 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iMSxyOn5CwhF for ; Tue, 17 Mar 2015 10:08:49 -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 817801A1AB6 for ; Tue, 17 Mar 2015 10:08:49 -0700 (PDT) Received: (qmail 88287 invoked from network); 17 Mar 2015 17:08:48 -0000 Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 17 Mar 2015 17:08:48 -0000 Date: 17 Mar 2015 17:08:26 -0000 Message-ID: <20150317170826.33792.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] Names of mailbox records in draft-ietf-dane-smime and 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, 17 Mar 2015 17:08:50 -0000 >I would like to suggest that we need to begin considering the need for >users to directly affect the records that refer to them. ... In many cases it would indeed be useful to let people publish their own keys. But I would strongly caution against designing the publication mechanism around what seems convenient at the moment with the DNS software people are familiar with. That approach has led to some rather unfortunate designs, with SPF TXT records as the poster child. If you want to provide a way for people to publish public keys for their e-mail addresses, add a key publishing extension to POP and IMAP. MUAs already need to know the private keys, so they know the public keys, too. They already know how to talk to POP and IMAP servers, they already have the user credentials to sign into those servers, and in my experience, whoever runs the POP and IMAP servers already knows what e-mail addresses correspond to those credentials. Then do NOT attempt to specify how the keys get from POP or IMAP into the DNS provisioning system and into the DNS. There's a zillion provisioning systems, most of which are awful, but which have to be upgraded anyway if they're going to handle OPENPGPKEY and SMIMEA and other new record types. R's, John From nobody Tue Mar 17 11:57: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 0DB251A885F for ; Tue, 17 Mar 2015 11:57:22 -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 jy5acEMPMnwy for ; Tue, 17 Mar 2015 11:57:17 -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 0438A1A871B for ; Tue, 17 Mar 2015 11:57:16 -0700 (PDT) Received: by qgea108 with SMTP id a108so469942qge.3 for ; Tue, 17 Mar 2015 11:57:16 -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=x5ZN55CmSpeJ1QXORAgfidNS003p2Seq56Hk9VseuFQ=; b=B6SyknwszMOJDUJIfg0e5EmnpgOJTMHdT58b0yH7Di2EjVOIBdChH1GDsNzUPPZUFS V0aaT9BfXrEsab0uesmpegOMtK/decHoywkWNOvNE6txnwiIAcb4S7bxV9PGjBUszTsG uYzYOSpmUrYWqxVz5F3QLx5xe1fqrciCg2Y8U5RKbDXauuPI3aRyC3lwrpGyf1F2DxfQ Xkw1mHyofViZkTPvfAvFz02TbgI5abt1zu2Es99LWS4gqHG+P+ZnHj9LgscdzTd0n3+Y UTVRI3b7ejlghC3RksRgxrtCCh77FqnGpmSvP35WQ5vDRk2Jugcf1MKQCNGK3pdoiWcp +XRg== X-Gm-Message-State: ALoCoQkXhDZ+oanM+4LKLJBYlfg8cVmWEipWXO1gPqpakAB2cM//o+8nlO6qk8H/4WPfLl/pt5ZDhCjoPkxuYfdr40qE+yiHlA== X-Received: by 10.55.51.77 with SMTP id z74mr65063866qkz.84.1426618636109; Tue, 17 Mar 2015 11:57:16 -0700 (PDT) Received: from brn1lxmailout02.verisign.com (brn1lxmailout02.verisign.com. [72.13.63.42]) by mx.google.com with ESMTPS id jy4sm3947493qcb.0.2015.03.17.11.57.15 (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 17 Mar 2015 11:57:16 -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 t2HIvFde010218 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 17 Mar 2015 14:57:15 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by BRN1WNEXCHM01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Tue, 17 Mar 2015 14:57:15 -0400 From: "Wiley, Glen" To: John Levine , "dane@ietf.org" Thread-Topic: [dane] Names of mailbox records in draft-ietf-dane-smime and draft-ietf-dane-openpgpkey Thread-Index: AQHQXbrq3cCkm4z1X0CebonWTq/OV50bGw+AgAWR7oCAAISSAP//22MA Date: Tue, 17 Mar 2015 18:56:40 +0000 Message-ID: References: <20150317170826.33792.qmail@ary.lan> In-Reply-To: <20150317170826.33792.qmail@ary.lan> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.8.150116 x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="us-ascii" Content-ID: <664242C0B60C504BA7A5BFB48EB0FC5C@verisign.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [dane] Names of mailbox records in draft-ietf-dane-smime and 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, 17 Mar 2015 18:57:22 -0000 While I agree that this is probably out of scope for the DANE WG it is a Very important part of promoting DANE and seeing adoption increase outside The expert user circles. One of things we want to talk about next week is building tools that address What the group feels are necessary elements that might be missing or Impeding adoption for DANE. On 3/17/15, 1:08 PM, "John Levine" wrote: >>I would like to suggest that we need to begin considering the need for >>users to directly affect the records that refer to them. ... > >In many cases it would indeed be useful to let people publish their >own keys. But I would strongly caution against designing the >publication mechanism around what seems convenient at the moment with >the DNS software people are familiar with. That approach has led to >some rather unfortunate designs, with SPF TXT records as the poster >child. > >If you want to provide a way for people to publish public keys for >their e-mail addresses, add a key publishing extension to POP and >IMAP. MUAs already need to know the private keys, so they know the >public keys, too. They already know how to talk to POP and IMAP >servers, they already have the user credentials to sign into those >servers, and in my experience, whoever runs the POP and IMAP servers >already knows what e-mail addresses correspond to those credentials. > >Then do NOT attempt to specify how the keys get from POP or IMAP into >the DNS provisioning system and into the DNS. There's a zillion >provisioning systems, most of which are awful, but which have to be >upgraded anyway if they're going to handle OPENPGPKEY and SMIMEA and >other new record types. > >R's, >John From nobody Tue Mar 17 12:49: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 830ED1A88BF for ; Tue, 17 Mar 2015 12:49:41 -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 gHd7G6FKYvjf for ; Tue, 17 Mar 2015 12:49:36 -0700 (PDT) Received: from mail.sys4.de (mail.sys4.de [194.126.158.139]) (using TLSv1.1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 648431A88B9 for ; Tue, 17 Mar 2015 12:49:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sys4.de; h= in-reply-to:content-transfer-encoding:content-disposition :content-type:content-type:mime-version:references:message-id :subject:subject:from:from:date:date; s=mail201310; t= 1426621774; x=1428436175; bh=mbMaKU1UBSetiZwwnx7FHnua6Rx0YZ82/ZO J52j1F1k=; b=KhU2/h42Z7dBIWNJXk4X0ToEqZ9tm/dN8nuQDy9Vl9rUSPItmgX 2Qj8u2j3REe0TosQmM0Rf7Ko2rgUxlXKVzO0oDGcXyJRej/6chJA0bkXY7WuTp6l ohb6G1lAFt/FXfJ7v07cYbDlSQmabsxmP38calw2LMVAgLVL5mTiD0Q787vSRLFb 0+1k4mHoW/raBdaP0FGHdnCYwxa6Lsk7aAV6Y4eMm/kg3S/y/KquA3DdLZXvqFxN BGeu5316H77ViP+4IgMMHbSV1oi8aj0RUn39uiKOHm1+35lAlyKyHCbtmbocuipK 7x3mSxSNpUrjWSiFol98cbIPPt0ydyMWpbA== X-Virus-Scanned: Debian amavisd-new at mail.sys4.de Received: from sys4.de (ipb21b19f6.dynamic.kabel-deutschland.de [178.27.25.246]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.sys4.de (Postfix) with ESMTPSA id 3l64p64C5Rzf for ; Tue, 17 Mar 2015 20:49:34 +0100 (CET) Date: Tue, 17 Mar 2015 20:49:30 +0100 From: Patrick Ben Koetter To: dane@ietf.org Message-ID: <20150317194929.GA31259@sys4.de> References: <20150314032550.26364.qmail@ary.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Archived-At: Subject: Re: [dane] Comments on draft-ietf-dane-openpgpkey-02 (fwd) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Mar 2015 19:49:41 -0000 * Paul Hoffman : > Section 3.1 would be better worded as: > > 3.1. Email address variants > > Some email service providers and email software perform automatic mappings of the LHS of email addresses based on special characters. This makes finding OPENPGPKEY record for a particular name that might be mapped impossible because there is no complete set of mappings and, worse, some common mappings conflict with each other. > > It might be tempting for software that implements DNS lookup for the OPENPGPKEY RRtype to try to perform similar mappings while trying to find a particular OPENPGPKEY record. This SHOULD NOT be done because some mapping attempts might retrieve the key for the wrong user, depending on the mapping rules of the service provider or software platform. +1 p@rick -- [*] sys4 AG https://sys4.de, +49 (89) 30 90 46 64 Franziskanerstraße 15, 81669 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein From nobody Tue Mar 17 13:11: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 94A741A88E8 for ; Tue, 17 Mar 2015 13:11:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.912 X-Spam-Level: X-Spam-Status: No, score=-6.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id omT7hAB90gXB for ; Tue, 17 Mar 2015 13:11:44 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (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 408131A88E7 for ; Tue, 17 Mar 2015 13:11:41 -0700 (PDT) Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t2HKBeDj022182 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Tue, 17 Mar 2015 16:11:40 -0400 Received: from pspacek.brq.redhat.com ([10.40.204.43]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t2HKBbYv021577 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Tue, 17 Mar 2015 16:11:39 -0400 Message-ID: <55088A79.8070201@redhat.com> Date: Tue, 17 Mar 2015 21:11:37 +0100 From: Petr Spacek Organization: Red Hat User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: dane@ietf.org References: <54EF3A7D.6070809@redhat.com> <8CB4E1AD-35C6-4A92-97ED-CC2853C2896C@vpnc.org> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26 Archived-At: Subject: Re: [dane] Start of WGLC for draft-ietf-dane-openpgpkey: objection about keyring format documentation X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 17 Mar 2015 20:11:46 -0000 Hello! I'm sorry for being very late, I had to do some $DAILYJOB. First of all, thank you for incorporating the feedback! On 9.3.2015 04:10, Paul Wouters wrote: > On Sun, 8 Mar 2015, Paul Hoffman wrote: > >> Proposal: this draft should specify that the contents of the RDATA is a >> single public key, defined in Section 5.5.1.1 of RFC 4880. Are there common >> cases where this is not sufficient? > > I'm okay with that. Will put into the -02 version. Finally I had some time to review -02 version of the text and I think that it would deserve some more attention: Currently we have: > 2.2. The OPENPGPKEY RDATA wire format > The RDATA Wire Format consists of a single OpenPGP public key as > defined in Section 5.5.1.1 of [RFC4880]. Note that this format is > without ASCII armor or base64 encoding. http://tools.ietf.org/html/rfc4880#section-5.5.1.1 says: > 5.5.1.1. Public-Key Packet (Tag 6) > A Public-Key packet starts a series of packets that forms an OpenPGP > key (sometimes called an OpenPGP certificate). Well, formulation 'starts a series of packets that forms an OpenPGP key' is not very informative and contradicts Paul's assumption about 'single public key' mentioned above. Series of what? Let's see what OpenPGP 1.4.19 exports. It is sequence of: :public key packet: :user ID packet: :signature packet: :public sub key packet: :signature packet: which is pretty convoluted sequence of packets. Also, http://tools.ietf.org/html/rfc4880#section-5.5.1.2 says this: > ... By convention, the top-level key > provides signature services, and the subkeys provide encryption > services. Blindly using top-level key from first public key packet would violate crypto protocol enforced by PGP (and doing so could have undesired effects as you should never ever use one key to do encryption/decryption and signing...). I would say that for the purpose of OPENPGPKEY we do not need user IDs because, after all, we are going to use DNS for user id -> key mapping. The next problem is that by stripping all the 'signature' packets we would lose preferences like preferred hashing algorithms, key flags etc. which are stored in signature packet. Also, I would like to see clarification to the actual rdata encoding. Having said all that, I would like to discuss this variant of section 2.2: 2.2. The OPENPGPKEY RDATA wire format The RDATA Wire Format consists of a single OpenPGP public-subkey packet as defined in Section 5.5.1.2 of [RFC4880]. The rdata MUST NOT contain any other packets. Tools generating rdata must respect Key Flags as specified in section 5.2.3.21 of [RFC4880] and export only keys with flags appropriate for e-mail encryption communication. Rdata MUST be encoded according to Section 4 of [RFC4880], including the full packet header. Note that this format is without ASCII armor or base64 encoding. The open question is if really should strip all the signature packets as it discards all the keyflags, algorithm preferences etc. I'm attaching output from pgpdump below so you can see what information is in which packets of typical public key export. For pure encryption we need only Public Subkey Packet (tag 14) and nothing else. Old: Public Key Packet(tag 6)(269 bytes) Ver 4 - new Public key creation time - Fri Feb 15 09:25:33 CET 2013 Pub alg - RSA Encrypt or Sign(pub 1) RSA n(2048 bits) - ... RSA e(17 bits) - ... Old: User ID Packet(tag 13)(32 bytes) User ID - Petr Spacek Old: Signature Packet(tag 2)(318 bytes) Ver 4 - new Sig type - Positive certification of a User ID and Public Key packet(0x13). Pub alg - RSA Encrypt or Sign(pub 1) Hash alg - SHA1(hash 2) Hashed Sub: signature creation time(sub 2)(4 bytes) Time - Fri Feb 15 09:25:33 CET 2013 Hashed Sub: key flags(sub 27)(1 bytes) Flag - This key may be used to certify other keys Flag - This key may be used to sign data Hashed Sub: key expiration time(sub 9)(4 bytes) Time - Sun Mar 17 09:25:33 CET 2013 Hashed Sub: preferred symmetric algorithms(sub 11)(5 bytes) Sym alg - AES with 256-bit key(sym 9) Sym alg - AES with 192-bit key(sym 8) Sym alg - AES with 128-bit key(sym 7) Sym alg - CAST5(sym 3) Sym alg - Triple-DES(sym 2) Hashed Sub: preferred hash algorithms(sub 21)(5 bytes) Hash alg - SHA256(hash 8) Hash alg - SHA1(hash 2) Hash alg - SHA384(hash 9) Hash alg - SHA512(hash 10) Hash alg - SHA224(hash 11) Hashed Sub: preferred compression algorithms(sub 22)(3 bytes) Comp alg - ZLIB (comp 2) Comp alg - BZip2(comp 3) Comp alg - ZIP (comp 1) Hashed Sub: features(sub 30)(1 bytes) Flag - Modification detection (packets 18 and 19) Hashed Sub: key server preferences(sub 23)(1 bytes) Flag - No-modify Sub: issuer key ID(sub 16)(8 bytes) Key ID - 0x3F8A1B3A9A7C8D08 Hash left 2 bytes - 27 b1 RSA m^d mod n(2048 bits) - ... -> PKCS-1 Old: Public Subkey Packet(tag 14)(269 bytes) Ver 4 - new Public key creation time - Fri Feb 15 09:25:33 CET 2013 Pub alg - RSA Encrypt or Sign(pub 1) RSA n(2048 bits) - ... RSA e(17 bits) - ... Old: Signature Packet(tag 2)(293 bytes) Ver 4 - new Sig type - Subkey Binding Signature(0x18). Pub alg - RSA Encrypt or Sign(pub 1) Hash alg - SHA1(hash 2) Hashed Sub: signature creation time(sub 2)(4 bytes) Time - Fri Feb 15 09:25:33 CET 2013 Hashed Sub: key flags(sub 27)(1 bytes) Flag - This key may be used to encrypt communications Flag - This key may be used to encrypt storage Hashed Sub: key expiration time(sub 9)(4 bytes) Time - Sun Mar 17 09:25:33 CET 2013 Sub: issuer key ID(sub 16)(8 bytes) Key ID - 0x3F8A1B3A9A7C8D08 Hash left 2 bytes - 0f f1 RSA m^d mod n(2047 bits) - ... -> PKCS-1 -- Petr Spacek @ Red Hat From nobody Tue Mar 17 14:03: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 052B71A88E7 for ; Tue, 17 Mar 2015 14:03:36 -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 qqXCLI1jfvy7 for ; Tue, 17 Mar 2015 14:03:30 -0700 (PDT) Received: from mail-ie0-x235.google.com (mail-ie0-x235.google.com [IPv6:2607:f8b0:4001:c03::235]) (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 DCA321A88E4 for ; Tue, 17 Mar 2015 14:03:26 -0700 (PDT) Received: by ieclw3 with SMTP id lw3so21972674iec.2 for ; Tue, 17 Mar 2015 14:03:26 -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=X+154ZILCYJ8Ind/TVV47kRrH1ILUElW5KNB/k6V6Rw=; b=B0IEuRfCvLW6ftKZee+80ze3GAaZwUY16YTg+63fmTuyDCsH1N8yev8DHDINEfjyOh j4KWwPdZNynb2ughzIcjRsG3wQYNxcK+3ht7VMYAcU4JHwG7pB44WifLAuYnHFK9S0XZ vDSASLxRQzrfgCPdTn+JNvDPB8nYKC3XGBpNn70VF1x5Mywt0JGECWKcDgQIiz3lH/40 ci+AokQpLdOvnKeJUF+s86LNimBcXDTRTWP72wF7CEBKVhiRFRpjpFHu2dViixM80mSS MshhWIMHmtbosOBfF1hxMEXQ+oOtvE64Q4NuWtSSfMizTytgAd8C5Mm3ifN+ye2AlqGR SqNg== MIME-Version: 1.0 X-Received: by 10.107.3.164 with SMTP id e36mr80924273ioi.70.1426626206331; Tue, 17 Mar 2015 14:03:26 -0700 (PDT) Received: by 10.64.57.201 with HTTP; Tue, 17 Mar 2015 14:03:26 -0700 (PDT) In-Reply-To: <55088A79.8070201@redhat.com> References: <54EF3A7D.6070809@redhat.com> <8CB4E1AD-35C6-4A92-97ED-CC2853C2896C@vpnc.org> <55088A79.8070201@redhat.com> Date: Tue, 17 Mar 2015 14:03:26 -0700 Message-ID: From: Brian Dickson To: Petr Spacek Content-Type: multipart/alternative; boundary=001a113ecf1c4198e30511824c32 Archived-At: Cc: "dane@ietf.org" Subject: Re: [dane] Start of WGLC for draft-ietf-dane-openpgpkey: objection about keyring format documentation X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 17 Mar 2015 21:03:36 -0000 --001a113ecf1c4198e30511824c32 Content-Type: text/plain; charset=UTF-8 On Tue, Mar 17, 2015 at 1:11 PM, Petr Spacek wrote: > Hello! > > Currently we have: > > > 2.2. The OPENPGPKEY RDATA wire format > > The RDATA Wire Format consists of a single OpenPGP public key as > > defined in Section 5.5.1.1 of [RFC4880]. Note that this format is > > without ASCII armor or base64 encoding. > > http://tools.ietf.org/html/rfc4880#section-5.5.1.1 says: > > 5.5.1.1. Public-Key Packet (Tag 6) > > A Public-Key packet starts a series of packets that forms an OpenPGP > > key (sometimes called an OpenPGP certificate). > > Blindly using top-level key from first public key packet would violate > crypto > protocol enforced by PGP (and doing so could have undesired effects as you > should never ever use one key to do encryption/decryption and signing...). > > I would say that for the purpose of OPENPGPKEY we do not need user IDs > because, after all, we are going to use DNS for user id -> key mapping. Maybe yes, maybe no. Do "people" (a generalization for sure) use their PGP/GPG keys as a defacto mapping of mailboxes, via their user IDs? If so, then maybe this is at least a partial solution to the "mailbox aliases / case-folding" problem. Perhaps stripping out IDs which do not fall in the parent domain's namespace, and publishing the OPENPGPKEY at all owner names corresponding to the hash(LHS(user id)), would be a useful thing? (This is analogous to the in-addr.arpa/ip6.arpa PTRs vs A/AAAA records, and loose name-based validation. Except with added crypto goop.) > The next problem is that by stripping all the 'signature' packets we would > lose preferences like preferred hashing algorithms, key flags etc. which > are > stored in signature packet. > I think the question of what to include/exclude ties to the general PGP usage questions: Is the need/intent to have these PGP keys operate entirely stand-alone? Do these DANE keys only augment, or entirely duplicate, keys published in public key sites? Does stripping some content out, in the DANE context, cause conflicts or breakage, compared to other key sources (such as a local keyring with signatures etc.)? Would there be some "fluff" that can be stripped without breaking things? If the same key is found in multiple DANE locations, but each partially stripped, to what degree would simply merging the keys' "packets" result in "correct" keys? If the same key is found in its entirety, but maybe some components differ (like sigs), because of different publication dates, would a blind merge be okay? I think these might need to be answered to be sure the right RDATA choices are made. Thanks, Brian --001a113ecf1c4198e30511824c32 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Mar 17, 2015 at 1:11 PM, Petr Spacek <pspacek@redhat.com&= gt; wrote:
Hello!

Currently we have:

> 2.2. The OPENPGPKEY RDATA wire format
>=C2=A0 =C2=A0 The RDATA Wire Format consists of a single OpenPGP public= key as
>=C2=A0 =C2=A0 defined in Section 5.5.1.1 of [RFC4880].=C2=A0 Note that = this format is
>=C2=A0 =C2=A0 without ASCII armor or base64 encoding.

http://tools.ietf.org/html/rfc4880#section-5.5.1.1 says:
> 5.5.1.1. Public-Key Packet (Tag 6)
>=C2=A0 =C2=A0 A Public-Key packet starts a series of packets that forms= an OpenPGP
>=C2=A0 =C2=A0 key (sometimes called an OpenPGP certificate).

Blindly using top-level key from first public key packet would violate cryp= to
protocol enforced by PGP (and doing so could have undesired effects as you<= br> should never ever use one key to do encryption/decryption and signing...).<= br>
I would say that for the purpose of OPENPGPKEY we do not need user IDs
because, after all, we are going to use DNS for user id -> key mapping.<= /blockquote>

Maybe yes, maybe no.
Do "peo= ple" (a generalization for sure) use their PGP/GPG keys as a defacto m= apping of mailboxes, via their user IDs?

If so, th= en maybe this is at least a partial solution to the "mailbox aliases /= case-folding" problem.

Perhaps stripping out= IDs which do not fall in the parent domain's namespace, and publishing= the OPENPGPKEY at all owner names corresponding to the hash(LHS(user id)),= would be a useful thing?

(This is analogous to th= e in-addr.arpa/ip6.arpa PTRs vs A/AAAA records, and loose name-based valida= tion. Except with added crypto goop.)

=C2=A0
=
The next problem is that by stripping all the 'signature' packets w= e would
lose preferences like preferred hashing algorithms, key flags etc. which ar= e
stored in signature packet.

I think the= question of what to include/exclude ties to the general PGP usage question= s:
Is the need/intent to have these PGP keys operate entirely sta= nd-alone?=C2=A0
Do these DANE keys only augment, or entirely dupl= icate, keys published in public key sites?
Does stripping some co= ntent out, in the DANE context, cause conflicts or breakage, compared to ot= her key sources (such as a local keyring with signatures etc.)?
W= ould there be some "fluff" that can be stripped without breaking = things?
If the same key is found in multiple DANE locations, but = each partially stripped, to what degree would simply merging the keys' = "packets" result in "correct" keys?
If the sa= me key is found in its entirety, but maybe some components differ (like sig= s), because of different publication dates, =C2=A0would a blind merge be ok= ay?

I think these might need to be answered to be = sure the right RDATA choices are made.

Thanks,
=
Brian
--001a113ecf1c4198e30511824c32-- From nobody Tue Mar 17 15:26:22 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB8011A1BA3 for ; Tue, 17 Mar 2015 15:26:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.999 X-Spam-Level: X-Spam-Status: No, score=-3.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, GB_I_LETTER=-2, 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 olpiXwd0i5Ht for ; Tue, 17 Mar 2015 15:26:17 -0700 (PDT) Received: from mail-ie0-x22c.google.com (mail-ie0-x22c.google.com [IPv6:2607:f8b0:4001:c03::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DEAD1A1B5F for ; Tue, 17 Mar 2015 15:26:17 -0700 (PDT) Received: by iecsl2 with SMTP id sl2so23613344iec.1 for ; Tue, 17 Mar 2015 15:26:16 -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=OuIBVdMCBNnHAz+FzXwLRZP5+OVLM6iqxDF45yvYuf0=; b=Wtw3opUQ+GWp5rJ66NI0X9O1Z0VwCTXN7vORO3TiHEVcTHzGYpYfBh/4PYMnclVhNi EYaZoAAx4b+fE+tS4wj5dY9fhnLzVBhNn4XZsnnN9K3VCwVOXjMbyYP0dc28NN/VCV1G byUXyRO2NNZ5TVsonEZnnwTLHs1XJyttwQ80rG2sZprnLTCCF93iolmRL+eeqMBI4nHt gXGTmOk6VTh8HgW49Prx+eAwGnBht/7MP7UdY4W0HsX7ff/IuH228k3J77unSlLGuu9s +jFotC2WkPZtu9oaw1RL6zXolJDg4JVffG3nqD9uMukRdWQmrAcCR0LZnyubfMnWbu/G 6ysQ== MIME-Version: 1.0 X-Received: by 10.42.87.131 with SMTP id y3mr35874091icl.45.1426631176726; Tue, 17 Mar 2015 15:26:16 -0700 (PDT) Received: by 10.64.57.201 with HTTP; Tue, 17 Mar 2015 15:26:16 -0700 (PDT) In-Reply-To: <20150317020448.32776.qmail@ary.lan> References: <20150317020448.32776.qmail@ary.lan> Date: Tue, 17 Mar 2015 15:26:16 -0700 Message-ID: From: Brian Dickson To: John Levine Content-Type: multipart/alternative; boundary=20cf30223f9983b22c05118374c9 Archived-At: Cc: "dane@ietf.org" Subject: Re: [dane] Comments on draft-ietf-dane-openpgpkey-02 (fwd) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Mar 2015 22:26:21 -0000 --20cf30223f9983b22c05118374c9 Content-Type: text/plain; charset=UTF-8 On Mon, Mar 16, 2015 at 7:04 PM, John Levine wrote: > > The stuff in section 3 of the openpgpkey draft is trying to > canonicalize mailbox names, i.e., given some mailbox name, find the > "real" mailbox name that it corresponds to. > I think this can be summarized as a "publication vs discovery" problem. Keys get published in DNS at specific locations, corresponding to hashes of usernames. That is publication. The username-equivalence problem is a discovery problem. My suggestion is, standardize a PLACE (label) at which the email crowd can iteratively codify their equivalence rules. This puts the onus on them (the email folks), and gives them all the control they need. Publishing the applicable "rules" at a well-known location under a parent domain, facilitates discovery, without needing to implement anything within DNS. The specifics (what to codify and how to implement) are things the publishers (email providers and smtp providers) and the consumers (email clients) can work out, on their own and without involving the DNS folks. There is no specific need to uniqueness among the rules, even -- the same mapping could have more than one name/code-point, even if it is sub-optimal. E.g. different ISO-whatever country codes, might utilize the same mappings, and those mappings might also be shared by regional entities (like Quebec, or New Brunswick, in Canada). There may be a desire to have "vanity" names for the same mappings, e.g. GOOGLE and YAHOO. There may be related groups of rule sets, like GOOGLE_FR, GOOGLE_DE, where combinations of simple mappings are applied (lowercase, remove dots, trim +, and then apply language-specific mappings). We don't need (or want, IMHO) to develop those encodings, merely incorporate them by reference. (The email folks can fight those battles.) As an example, consider a new RRTYPE, of priority and rule, published at _mboxrule. _mboxcanon.example.com IN MBOXRULE 1 LC_ASCII _mboxcanon.example.com IN MBOXRULE 2 FR_CA_NOACCENT _mboxcanon.example.net IN MBOXRULE 1 NO_DOTS _mboxcanon.example.net IN MBOXRULE 2 NO_PLUS_SUFFIX 8 bits of priority, and 16 bits of enumerated rules (from an IANA table), is likely sufficient as a first cut, unless anyone has a better idea. (Suggestion: reserve some code points for experimental, and some for local use, however those might get implemented.) If a given domain has "fuzzy" stuff, then they still have the ABILITY to publish the same (user) keys at multiple hashed owner locations (equivalent usernames, e.g. firstname.lastname and 8-letter-username), for the enumerated variants. It does not need to be the case that the entire problem space be solved (all possible mailbox mappings). The ability to standardize and apply "sane" (well-defined, simple, context-free and content-agnostic) rules, might encourage adoption of such rules, and facilitate a sufficiently-high level of interop, as to justify deployment of these rules, and OPENPGPKEY & SMIME generally. > One new > problem (not the hardest) is that the case folding rules are language > specific -- the way you fold accented characters in Turkish is > different from the way you do it in French, and it's even different > between European French and Canadian French. You cannot tell by > looking at a mailbox name what language it is. > No, but if there is a well-known location that lists the applicable rules, you _can_ tell what those rules are, just by looking at that well-known (domain-wide) rule. The specifics of _what_ each rule is, and who is "authoritative" for a given rule, are thankfully out of scope for dnsop. Unless you are vastly smarter than everyone else who has looked at > this problem, you're not going to solve it any time soon. Every > approach suggested so far is something we're aware of and is known not > to work when applied to the complex mess that is Internet e-mail. If > you want to use hashes to represent mailbox names, you either have to > completely punt on variant names, which the users will hate, or stop > here, talk to people who understand the subtle reality of mail and see > if there's any way to come up with something that works. > I am suggesting we do both - punt on solving it, and providing just enough rope to the email community. _THE_ main thing is to recognize that there can be many case-folding rules, and that it does not need to be unified. At best, providing ways to publish the applicable set(s) of rules, and maybe a way to prioritize their use in case of conflicting elements within the rules, should be sufficient. I strongly suggest that those rules get published by the email folks, as an IANA registry or set of registries (well-known and local). > I realize this isn't what you want to hear, but you've dived into a > swamp. You may not recognize it as a swamp, but trust me, that's > where you are. > No, we are standing at the edge of the swamp, admiring the guts of those fighting the alligators. Brian --20cf30223f9983b22c05118374c9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Mar 16, 2015 at 7:04 PM, John Levine <johnl@taugh.com> wrote:

The stuff in section 3 of the openpgpkey draft is trying to
canonicalize mailbox names, i.e., given some mailbox name, find the
"real" mailbox name that it corresponds to.=C2=A0

I think this can be summarized as a "publication= vs discovery" problem.

Keys get published in= DNS at specific locations, corresponding to hashes of usernames. That is p= ublication.=C2=A0

The username-equivalence problem= is a discovery problem.

My suggestion is, standar= dize a PLACE (label) at which the email crowd can iteratively codify their = equivalence rules.

This puts the onus on them (the= email folks), and gives them all the control they need.

Publishing the applicable "rules" at a well-known location= under a parent domain, facilitates discovery, without needing to implement= anything within DNS.

The specifics (what to codif= y and how to implement) are things the publishers (email providers and smtp= providers) and the consumers (email clients) can work out, on their own an= d without involving the DNS folks. There is no specific need to uniqueness = among the rules, even -- the same mapping could have more than one name/cod= e-point, even if it is sub-optimal. E.g. different ISO-whatever country cod= es, might utilize the same mappings, and those mappings might also be share= d by regional entities (like Quebec, or New Brunswick, in Canada). There ma= y be a desire to have "vanity" names for the same mappings, e.g. = GOOGLE and YAHOO. There may be related groups of rule sets, like GOOGLE_FR,= GOOGLE_DE, where combinations of simple mappings are applied (lowercase, r= emove dots, trim +, and then apply language-specific mappings).
<= br>
We don't need (or want, IMHO) to develop those encodings,= merely incorporate them by reference.
(The email folks can fight= those battles.)

As an example, consider a new RRT= YPE, of priority and rule, published at _mboxrule.

_mboxcanon.example.com =C2=A0= IN MBOXRULE 1 LC_ASCII
_= mboxcanon.example.com =C2=A0IN MBOXRULE 2 FR_CA_NOACCENT

=
_mboxcanon.example.net =C2=A0IN MBOXRULE 2 NO_PLUS_SUFFIX
=

8 bits of priority, and 16 bits of enumerated rules (fr= om an IANA table), is likely sufficient as a first cut, unless anyone has a= better idea.
(Suggestion: reserve some code points for experimen= tal, and some for local use, however those might get implemented.)

If a given domain has "fuzzy" stuff, then they s= till have the ABILITY to publish the same (user) keys at multiple hashed ow= ner locations (equivalent usernames, e.g. firstname.lastname and 8-letter-u= sername), for the enumerated variants.

It does not= need to be the case that the entire problem space be solved (all possible = mailbox mappings). The ability to standardize and apply "sane" (w= ell-defined, simple, context-free and content-agnostic) rules, might encour= age adoption of such rules, and facilitate a sufficiently-high level of int= erop, as to justify deployment of these rules, and OPENPGPKEY & SMIME g= enerally.
=C2=A0
One new
problem (not the hardest) is that the case folding rules are language
specific -- the way you fold accented characters in Turkish is
different from the way you do it in French, and it's even different
between European French and Canadian French.=C2=A0 You cannot tell by
looking at a mailbox name what language it is.

No, but if there is a well-known location that lists the applicable= rules, you _can_ tell what those rules are, just by looking at that well-k= nown (domain-wide) rule.

The specifics of _what_ e= ach rule is, and who is "authoritative" for a given rule, are tha= nkfully out of scope for dnsop.

Unless you are vastly smarter than everyone else who has looked at
this problem, you're not going to solve it any time soon.=C2=A0 Every approach suggested so far is something we're aware of and is known not<= br> to work when applied to the complex mess that is Internet e-mail.=C2=A0 If<= br> you want to use hashes to represent mailbox names, you either have to
completely punt on variant names, which the users will hate, or stop
here, talk to people who understand the subtle reality of mail and see
if there's any way to come up with something that works.

I am suggesting we do both - punt on solving it, and = providing just enough rope to the email community.

_THE_ main thing is to recognize that there can be many case-folding rules= , and that it does not need to be unified.

At best= , providing ways to publish the applicable set(s) of rules, and maybe a way= to prioritize their use in case of conflicting elements within the rules, = should be sufficient.

I strongly suggest that thos= e rules get published by the email folks, as an IANA registry or set of reg= istries (well-known and local).


I realize this isn't what you want to hear, but you've dived into a=
swamp.=C2=A0 You may not recognize it as a swamp, but trust me, that's<= br> where you are.=C2=A0

No, we are standing at the edge of the swamp, admiring the guts of tho= se fighting the alligators.

Brian
--20cf30223f9983b22c05118374c9-- From nobody Tue Mar 17 16:47: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 2F3EE1A1BD9 for ; Tue, 17 Mar 2015 16:47:48 -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 hM0kkFVlf0Ll for ; Tue, 17 Mar 2015 16:47:47 -0700 (PDT) Received: from proper.com (Opus1.Proper.COM [207.182.41.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B7421A1BC2 for ; Tue, 17 Mar 2015 16:47:47 -0700 (PDT) Received: from [10.20.30.101] (50-1-51-95.dsl.dynamic.fusionbroadband.com [50.1.51.95]) (authenticated bits=0) by proper.com (8.15.1/8.14.9) with ESMTPSA id t2HNliqG062589 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 17 Mar 2015 16:47:45 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: proper.com: Host 50-1-51-95.dsl.dynamic.fusionbroadband.com [50.1.51.95] claimed to be [10.20.30.101] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Paul Hoffman In-Reply-To: Date: Tue, 17 Mar 2015 16:47:43 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <86E5E940-34F4-4931-8926-2366EA86BE95@vpnc.org> References: <20150317020448.32776.qmail@ary.lan> To: Brian Dickson X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: "dane@ietf.org" Subject: Re: [dane] Comments on draft-ietf-dane-openpgpkey-02 (fwd) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Mar 2015 23:47:48 -0000 On Mar 17, 2015, at 3:26 PM, Brian Dickson = wrote: > My suggestion is, standardize a PLACE (label) at which the email crowd = can iteratively codify their equivalence rules. This is a suggestion to APPSAWG, not DANE. The email crowd has this = problem (literally) decades before DANE was born. If the email crowd = devises such a place, DANE can use it in the same way that regular email = uses it. --Paul Hoffman (Disclaimer: I was director of the Internet Mail Consortium from 1996 to = 2002)= From nobody Tue Mar 17 19:46: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 79A9A1A8A45 for ; Tue, 17 Mar 2015 19:46:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.037 X-Spam-Level: X-Spam-Status: No, score=-1.037 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id czR0RjyQsBLd for ; Tue, 17 Mar 2015 19:46:09 -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 3D39D1A8A43 for ; Tue, 17 Mar 2015 19:46:08 -0700 (PDT) Received: (qmail 67777 invoked from network); 18 Mar 2015 02:46:07 -0000 Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 18 Mar 2015 02:46:07 -0000 Date: 18 Mar 2015 00:13:00 -0000 Message-ID: <20150318001300.34285.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.hoffman@vpnc.org Subject: Re: [dane] Comments on draft-ietf-dane-openpgpkey-02 (fwd) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Mar 2015 02:46:10 -0000 >3.1. Email address variants > >Some email service providers and email software perform automatic mappings of the LHS of >email addresses based on special characters. This makes finding OPENPGPKEY record for a >particular name that might be mapped impossible because there is no complete set of >mappings and, worse, some common mappings conflict with each other. > >It might be tempting for software that implements DNS lookup for the OPENPGPKEY RRtype to >try to perform similar mappings while trying to find a particular OPENPGPKEY record. This >SHOULD NOT be done because some mapping attempts might retrieve the key for the wrong >user, depending on the mapping rules of the service provider or software platform. Looks fine. Here's some minor editorial suggestions: I'd suggest taking out "based on special characters", since the most common mapping is case folding. The standard term for the LHS is local-part, so you might as well use that and reference RFC 5321, sec 2.3.11 where it's defined. Also, the SHOULD NOT would better be MUST NOT, to be consistent with RFC 5321 which says "the local-part MUST be interpreted and assigned semantics only by the host specified in the domain part of the address." (If you have a private agreement with someone and you have knowledge of their internal mappings, you can do whatever you want, but of course private agreements are outside the scope of standards.) Having said all that, how useful do people think this will be if it doesn't allow the local-part fuzz that mail systems provide? If the addresses to be looked up are picked mechanically from incoming mail headers, it'd likely work fine. If typed in from business cards, it could be pretty frustrating. R's, John From nobody Wed Mar 18 07:47: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 1B09C1A09C9 for ; Wed, 18 Mar 2015 07:47:53 -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 kG88_zwY2LtX for ; Wed, 18 Mar 2015 07:47:52 -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 C8CED1A066C for ; Wed, 18 Mar 2015 07:47:46 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3l6Z3M5mRSz9Q7; Wed, 18 Mar 2015 15:47:43 +0100 (CET) Authentication-Results: mx.nohats.ca; dkim=pass (1024-bit key) header.d=nohats.ca header.i=@nohats.ca header.b=FyZEYFge 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 1lQ1PGAjDyJB; Wed, 18 Mar 2015 15:47:41 +0100 (CET) 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, 18 Mar 2015 15:47:41 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id AA34B80416; Wed, 18 Mar 2015 10:47:40 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1426690060; bh=4jrqC7ZJwEOuyO6pQWw4Egv/5ePX/W5a2Y65u1t9jdE=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=FyZEYFge9zmcsgOl7wkMWJkmMmTZOSoTj8F4WRrsQdOgAiJSxnaR/37RFTaILwRRA 3B+8tplhPjCXpfLGQZBDTNiecZuyQlh8TSIZtOk3OJ8sxmSwNBcTDzXM5x17UXGsQq o7N8qBMnzLuZreM3ZYA019ywryiZnOcgAX38gbag= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id t2IElccR002594; Wed, 18 Mar 2015 10:47:39 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Wed, 18 Mar 2015 10:47:38 -0400 (EDT) From: Paul Wouters To: John Levine In-Reply-To: <20150318001300.34285.qmail@ary.lan> Message-ID: References: <20150318001300.34285.qmail@ary.lan> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: paul.hoffman@vpnc.org, dane@ietf.org Subject: Re: [dane] Comments on draft-ietf-dane-openpgpkey-02 (fwd) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Mar 2015 14:47:53 -0000 On Tue, 18 Mar 2015, John Levine wrote: > > I'd suggest taking out "based on special characters", since the most > common mapping is case folding. The standard term for the LHS is > local-part, so you might as well use that and reference RFC 5321, sec > 2.3.11 where it's defined. > > Also, the SHOULD NOT would better be MUST NOT, to be consistent with > RFC 5321 which says "the local-part MUST be interpreted and assigned > semantics only by the host specified in the domain part of the > address." > > (If you have a private agreement with someone and you have knowledge > of their internal mappings, you can do whatever you want, but of > course private agreements are outside the scope of standards.) With this, we've gone a full circle. It feels strange to me to write a MUST NOT, knowing that implementors will need to do this in practise. But I guess I could live with it if the consensus moves this way, but to me that seems only because I know the MUST NOT will be violated. > Having said all that, how useful do people think this will be if it > doesn't allow the local-part fuzz that mail systems provide? If the > addresses to be looked up are picked mechanically from incoming mail > headers, it'd likely work fine. If typed in from business cards, it > could be pretty frustrating. Or even typed in on an iphone for which you have an existing contact with a lower case name, and it stupidly Uppercases it anyway when you type. Paul From nobody Wed Mar 18 08:06: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 468991A1A47 for ; Wed, 18 Mar 2015 08:06:07 -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 YuqeW5xbAXvP for ; Wed, 18 Mar 2015 08:06:06 -0700 (PDT) Received: from proper.com (Opus1.Proper.COM [207.182.41.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 573751A1A3B for ; Wed, 18 Mar 2015 08:06:06 -0700 (PDT) Received: from [10.20.30.101] (50-1-51-95.dsl.dynamic.fusionbroadband.com [50.1.51.95]) (authenticated bits=0) by proper.com (8.15.1/8.14.9) with ESMTPSA id t2IF64Gb094441 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 18 Mar 2015 08:06:05 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: proper.com: Host 50-1-51-95.dsl.dynamic.fusionbroadband.com [50.1.51.95] claimed to be [10.20.30.101] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Paul Hoffman In-Reply-To: Date: Wed, 18 Mar 2015 08:06:04 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20150318001300.34285.qmail@ary.lan> To: Paul Wouters X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: John Levine , dane@ietf.org Subject: Re: [dane] Comments on draft-ietf-dane-openpgpkey-02 (fwd) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Mar 2015 15:06:07 -0000 On Mar 18, 2015, at 7:47 AM, Paul Wouters wrote: >=20 > On Tue, 18 Mar 2015, John Levine wrote: >=20 >>=20 >> I'd suggest taking out "based on special characters", since the most >> common mapping is case folding. The standard term for the LHS is >> local-part, so you might as well use that and reference RFC 5321, sec >> 2.3.11 where it's defined. >>=20 >> Also, the SHOULD NOT would better be MUST NOT, to be consistent with >> RFC 5321 which says "the local-part MUST be interpreted and assigned >> semantics only by the host specified in the domain part of the >> address." >>=20 >> (If you have a private agreement with someone and you have knowledge >> of their internal mappings, you can do whatever you want, but of >> course private agreements are outside the scope of standards.) >=20 > With this, we've gone a full circle. It feels strange to me to write a > MUST NOT, knowing that implementors will need to do this in practise. >=20 > But I guess I could live with it if the consensus moves this way, but = to > me that seems only because I know the MUST NOT will be violated. At first I bristled at John's proposed change, but he's right that RFC = 5321 is completely clear on this topic, and it is a full standard. And, = yes, lots of SMTP applications probably violate the MUST NOT as well, = but that doesn't change it. --Paul Hoffman= From nobody Wed Mar 18 08:23:17 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E5791A1A6F for ; Wed, 18 Mar 2015 08:23:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.137 X-Spam-Level: X-Spam-Status: No, score=-1.137 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x4UOjdFxo5rT for ; Wed, 18 Mar 2015 08:23:14 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F5201A1A4D for ; Wed, 18 Mar 2015 08:23:14 -0700 (PDT) Received: (qmail 21447 invoked from network); 18 Mar 2015 15:23:13 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=53c6.55099861.k1503; bh=zbgh5J66duyLt/3C5N1Dm+zrjAm9Pwk5eqUaV0uLLhQ=; b=a6MRLc3GpGBN0iFaHQBcDlqd3GlhlmQwHdgnayMvgQccD5tdmrMsED1TaKzzIbwNS+XunpAWNTQ5sFik3eFexjgM6FwcOSV1KRtKFkm1zhnWiuVd7YSg3CsrLlDlVY4az7MEH9GrLe3wzqc2QYXErcwKnlFenrocEY2vihnxLtsN2v9pmPB3+wa6UfHt3rolC9ETw/ZUnAWAWlquIcwB7ffnU5eFE4ichAZgQ6yKUaNRQf8NJkThItea6xcQOBx3 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=53c6.55099861.k1503; bh=zbgh5J66duyLt/3C5N1Dm+zrjAm9Pwk5eqUaV0uLLhQ=; b=rRGiNSpD764xC439A352cM3J8VTDKvlMAjB65K0ynhOGJT75oIwAMtACqKp1tn1VP/VZ8BSxl8y/b21QOWaBdSoBO9ycYTRzTZ4NPfgWVF21O+TiFYF+mSkmDCzS7MYDb/837YS1QktTUkHCe8si7Xvp+8KbMQ3Uw/M/mWCINqFpVkf17jMtPG0O9Xv650gTBh1Jjf+/ANfU+QV+lO9HWWphLKaRKn+VQBXl2rES5AMGjeSiJOuLusG3g0aV7l+o 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; 18 Mar 2015 15:23:13 -0000 Date: 18 Mar 2015 11:23:12 -0400 Message-ID: From: "John R Levine" To: "Paul Hoffman" In-Reply-To: References: <20150318001300.34285.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: Paul Wouters , dane@ietf.org Subject: Re: [dane] Comments on draft-ietf-dane-openpgpkey-02 (fwd) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Mar 2015 15:23:15 -0000 >> But I guess I could live with it if the consensus moves this way, but to >> me that seems only because I know the MUST NOT will be violated. > At first I bristled at John's proposed change, but he's right that RFC > 5321 is completely clear on this topic, and it is a full standard. And, > yes, lots of SMTP applications probably violate the MUST NOT as well, > but that doesn't change it. In my experience, people who write mail software understand the opaque mailbox rule, and try pretty hard to follow it. Some cheat and do case folding to match Bob@domain to BOB@domain, but I can't think of any that match bob+foo@domain or b.ob@domain to bob@domain, other than the MTA that actually knows what the addresses mean. I can't emphasize strongly enough that any design that depends on people guessing addresses is fatally flawed. If, as you're saying, this one does, it'll just be kicked back until it's redesigned to take out the need to guess. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. From nobody Wed Mar 18 09:24:50 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6AE51A6F3C for ; Wed, 18 Mar 2015 09:24:48 -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 5dvHgPUvXQnE for ; Wed, 18 Mar 2015 09:24:42 -0700 (PDT) Received: from mail-we0-f173.google.com (mail-we0-f173.google.com [74.125.82.173]) (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 60FC41A1AFC for ; Wed, 18 Mar 2015 09:24:42 -0700 (PDT) Received: by wetk59 with SMTP id k59so36510314wet.3 for ; Wed, 18 Mar 2015 09:24: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:cc:content-type; bh=J5CvlZhcq69nil2m124fn53OeGDEvsuEkPSXlgsUjCo=; b=NR/vsj6fSlmAASuevhvnlJhXpxmfFeR0PJ6zXG67dYquCId+Ts1cwxI458Oc8TubPE gh38PyU0uoD9X5wbVgsnxdgVkaVFKJUw2FchJ+cWpf1ssPKqhw9Fxboz+D6KBBbQH5i6 oR58q4QAmhOWMYYOrGXeRF/KVWZqGdyJG7zpoTDAx+wpC6vKqgpntc/jn7HmORd1vJjc r/nQIPsA5l6PV+PPmw5GwBUWHhUmWgJplxUfrhPBfyK+pvE9OvqqKtE4vlDUVACkifiX KHOla2xK4fUeu2eL6rYYGJNuyMb3x5stsdLtJVGrjk7sM4OsKPGMtZxg4GcvB/OiSKBR UmtQ== X-Gm-Message-State: ALoCoQkdo7CPy4rv0YCuVb4tCyI5P8bDzcXAzuIEKvFoGpYG6+xg5Fo8pUpveYFTvPggmxSGf9pP MIME-Version: 1.0 X-Received: by 10.180.91.107 with SMTP id cd11mr8051990wib.61.1426695881091; Wed, 18 Mar 2015 09:24:41 -0700 (PDT) Received: by 10.194.110.97 with HTTP; Wed, 18 Mar 2015 09:24:40 -0700 (PDT) In-Reply-To: References: <20150318001300.34285.qmail@ary.lan> Date: Wed, 18 Mar 2015 12:24:40 -0400 Message-ID: From: Warren Kumari To: Paul Wouters Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: John Levine , Paul Hoffman , "" Subject: Re: [dane] Comments on draft-ietf-dane-openpgpkey-02 (fwd) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Mar 2015 16:24:49 -0000 [ Random top post ] So, it feels like we are approaching a compromise / consensus on this bit (which is good, because this part was the bit we were least in agreement on) Let's give this a bit more time to settle, then I'm planning on a very short WGLC, restricted just to this question, and with a "We'll assume you are OK with this, unless you say otherwise". W On Wed, Mar 18, 2015 at 10:47 AM, Paul Wouters wrote: > On Tue, 18 Mar 2015, John Levine wrote: > >> >> I'd suggest taking out "based on special characters", since the most >> common mapping is case folding. The standard term for the LHS is >> local-part, so you might as well use that and reference RFC 5321, sec >> 2.3.11 where it's defined. >> >> Also, the SHOULD NOT would better be MUST NOT, to be consistent with >> RFC 5321 which says "the local-part MUST be interpreted and assigned >> semantics only by the host specified in the domain part of the >> address." >> >> (If you have a private agreement with someone and you have knowledge >> of their internal mappings, you can do whatever you want, but of >> course private agreements are outside the scope of standards.) > > > With this, we've gone a full circle. It feels strange to me to write a > MUST NOT, knowing that implementors will need to do this in practise. > > But I guess I could live with it if the consensus moves this way, but to > me that seems only because I know the MUST NOT will be violated. > >> Having said all that, how useful do people think this will be if it >> doesn't allow the local-part fuzz that mail systems provide? If the >> addresses to be looked up are picked mechanically from incoming mail >> headers, it'd likely work fine. If typed in from business cards, it >> could be pretty frustrating. > > > Or even typed in on an iphone for which you have an existing contact > with a lower case name, and it stupidly Uppercases it anyway when you > type. > > Paul > > > _______________________________________________ > 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 Wed Mar 18 09:45:53 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BF541A7015 for ; Wed, 18 Mar 2015 09:45:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mTuQ_5wZ-AZq for ; Wed, 18 Mar 2015 09:45:47 -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 D71461A82E2 for ; Wed, 18 Mar 2015 09:45:45 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 86924282FCE; Wed, 18 Mar 2015 16:45:44 +0000 (UTC) Date: Wed, 18 Mar 2015 16:45:44 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20150318164544.GG3223@mournblade.imrryr.org> References: <20150318001300.34285.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] Comments on draft-ietf-dane-openpgpkey-02 (fwd) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Mar 2015 16:45:52 -0000 On Wed, Mar 18, 2015 at 12:24:40PM -0400, Warren Kumari wrote: > [ Random top post ] > So, it feels like we are approaching a compromise / consensus on this > bit (which is good, because this part was the bit we were least in > agreement on) > > Let's give this a bit more time to settle, then I'm planning on a very > short WGLC, restricted just to this question, and with a "We'll > assume you are OK with this, unless you say otherwise". Was consensus reached on the _prefix for the sha224 hashes? Distinct for SMIMEA, OPENPGPKEY, ... or unified? -- Viktor. From nobody Wed Mar 18 16:57:17 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2A401A6FDB for ; Wed, 18 Mar 2015 16:57:15 -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 GRKTGTjbR5yX for ; Wed, 18 Mar 2015 16:57:13 -0700 (PDT) Received: from mail-wi0-f182.google.com (mail-wi0-f182.google.com [209.85.212.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 6F7C01A1B9C for ; Wed, 18 Mar 2015 16:57:13 -0700 (PDT) Received: by wibdy8 with SMTP id dy8so103670577wib.0 for ; Wed, 18 Mar 2015 16:57: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:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=AxRTUEzqkOtAn3TmK5MtsN1p6SauE5qY+G/tmK7GXMc=; b=VE70LesXUxDZmaGcdxSg66bqKOYYT3lK4zVSsIZtOD49oBg+OZSJULWKSeSmiYNzCz arTAE/rtX1VrRZ6Fxck0qRWNhfO39TFa9sO2Hq3dNOCHQAjCm9ya6xwCuxlspYmsYs2r ir/vpf7uVLtoVXjnsWjzDkz2Cpl2bzJ5NzdjqVPuVS9BtucUZBk7ZSKJm+RrWtXb/aKz f+pHQzsgDg9Iyo/XUZEqZ6ZT7QbD7rRejuMLagNBw8/a1MtrwiPIQcelSgb2bvzSgCV+ mfvDICOMiSPtlIiAbWPZc5CWCxmn5RxHe08v/xL/YkIIbImpybvBJk9PRjvD7wi02MAy jR2Q== X-Gm-Message-State: ALoCoQnRn5CaEhpV+y6okQHS7NPmOpZkInUWAs7sQeTIbfjK+6faIpQF+L/89SfOm73yPyW8BT7V MIME-Version: 1.0 X-Received: by 10.194.92.169 with SMTP id cn9mr67250158wjb.61.1426723032134; Wed, 18 Mar 2015 16:57:12 -0700 (PDT) Received: by 10.194.110.97 with HTTP; Wed, 18 Mar 2015 16:57:11 -0700 (PDT) In-Reply-To: References: <20150318001300.34285.qmail@ary.lan> Date: Wed, 18 Mar 2015 19:57:11 -0400 Message-ID: From: Warren Kumari To: Paul Wouters Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: John Levine , Paul Hoffman , "" Subject: Re: [dane] Comments on draft-ietf-dane-openpgpkey-02 (fwd) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Mar 2015 23:57:15 -0000 Ok, so there are still a number of outstanding things we need to figure out on not just this draft, but the whole approach when it comes to mail addresses. It seems that I may have been overoptimistic about the LHS of the email address (and possibly the _prefix / DNAME solution), and if we can just hand-wave this away... Olafur and I will chat, but I think that we need some assistance from Apps folk, and to have a proper discussion of this in the F2F meeting... Apologies to all for yanking you around. on the plus side, the network in Dallas is starting tom come together nicely... W On Wed, Mar 18, 2015 at 12:24 PM, Warren Kumari wrote: > [ Random top post ] > So, it feels like we are approaching a compromise / consensus on this > bit (which is good, because this part was the bit we were least in > agreement on) > > Let's give this a bit more time to settle, then I'm planning on a very > short WGLC, restricted just to this question, and with a "We'll > assume you are OK with this, unless you say otherwise". > > W > > On Wed, Mar 18, 2015 at 10:47 AM, Paul Wouters wrote: >> On Tue, 18 Mar 2015, John Levine wrote: >> >>> >>> I'd suggest taking out "based on special characters", since the most >>> common mapping is case folding. The standard term for the LHS is >>> local-part, so you might as well use that and reference RFC 5321, sec >>> 2.3.11 where it's defined. >>> >>> Also, the SHOULD NOT would better be MUST NOT, to be consistent with >>> RFC 5321 which says "the local-part MUST be interpreted and assigned >>> semantics only by the host specified in the domain part of the >>> address." >>> >>> (If you have a private agreement with someone and you have knowledge >>> of their internal mappings, you can do whatever you want, but of >>> course private agreements are outside the scope of standards.) >> >> >> With this, we've gone a full circle. It feels strange to me to write a >> MUST NOT, knowing that implementors will need to do this in practise. >> >> But I guess I could live with it if the consensus moves this way, but to >> me that seems only because I know the MUST NOT will be violated. >> >>> Having said all that, how useful do people think this will be if it >>> doesn't allow the local-part fuzz that mail systems provide? If the >>> addresses to be looked up are picked mechanically from incoming mail >>> headers, it'd likely work fine. If typed in from business cards, it >>> could be pretty frustrating. >> >> >> Or even typed in on an iphone for which you have an existing contact >> with a lower case name, and it stupidly Uppercases it anyway when you >> type. >> >> Paul >> >> >> _______________________________________________ >> 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 -- 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 Mar 19 15:02: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 2EDB61B2AF4 for ; Thu, 19 Mar 2015 15:02:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.954 X-Spam-Level: X-Spam-Status: No, score=0.954 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.793, 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 bMCqUuuzqlOR for ; Thu, 19 Mar 2015 15:02:27 -0700 (PDT) Received: from mail.hardakers.net (unknown [IPv6:2001:470:1f00:187::1]) by ietfa.amsl.com (Postfix) with ESMTP id 79CBA1B2AF2 for ; Thu, 19 Mar 2015 15:02:27 -0700 (PDT) Received: from localhost (50-1-19-38.dsl.dynamic.fusionbroadband.com [50.1.19.38]) by mail.hardakers.net (Postfix) with ESMTPSA id 819B321DF9; Thu, 19 Mar 2015 15:02:26 -0700 (PDT) From: Wes Hardaker To: Viktor Dukhovni References: <2772BE49-FDEC-4C33-AFE8-33E66B6ABBCF@ogud.com> <20150125055400.GJ8034@mournblade.imrryr.org> Date: Thu, 19 Mar 2015 15:02:25 -0700 In-Reply-To: <20150125055400.GJ8034@mournblade.imrryr.org> (Viktor Dukhovni's message of "Sun, 25 Jan 2015 05:54:00 +0000") Message-ID: <0lsid0ve6m.fsf@wjh.hardakers.net> User-Agent: Gnus/5.130012 (Ma Gnus v0.12) Emacs/24.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: DANE WG Subject: Re: [dane] Agenda items for Dallas X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 19 Mar 2015 22:02:28 -0000 Viktor Dukhovni writes: > Speaking of LC, we seem to have lost all momentum on the SMTP and > SRV drafts, lets get those moving again please, together or > separately. I'll be in Dallas and agree completely that these need to go forward. There is no reason to have them hanging around at this point. > Finally, I've a lot more operational experience now, and have twice > asked for feedback on the notion of adding some of the observations > to the SMTP or ops drafts, but there's been no feedback on that. I'd actually collect it and publish it as a BCP later. We're already too late on the above to delay them for adding more text that will require another lengthy WGLC. -- Wes Hardaker Parsons From nobody Thu Mar 19 15:47:44 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6D1E1B2AF8 for ; Thu, 19 Mar 2015 15:47:41 -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 r7Ag1BhKS7to for ; Thu, 19 Mar 2015 15:47:40 -0700 (PDT) Received: from mail-ie0-f182.google.com (mail-ie0-f182.google.com [209.85.223.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 7E6D41A90EB for ; Thu, 19 Mar 2015 15:47:36 -0700 (PDT) Received: by ieclw3 with SMTP id lw3so78946726iec.2 for ; Thu, 19 Mar 2015 15:47:36 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=E6wp4jMXmI5L0U8try41uaGK+zxX01sBmq00AuOUfyg=; b=QM/tnCr2oQ33TIUss7iNDR/Qtn++aDJNWza4CYylXahnyVEps0sO75dcreY53xE4zN EkJq69e9lWc/Wctgtge38oCmMt4+9IChoqHCCtPJ0bfKRhR6/YhnUOX0b89VkR6up+Rl Mpfoz8BZmAR/NvcpLwe5BAFkhFbbZuufSild9emTipkO66TG8lMLVOYBKzGDJTwQDoQ2 l2wGmSw7GLD9FlBnGIV7wHrWeIL1QZLpBe4m1RhuWGoigMHa9qQ3SzamGyz/a9b9KJI5 1TovSFYApDBBMRGE6GBark8Zx1BnP2ZcErK6JKEnXH222hZGh31xEh8g5jPv+Le+WLph Y9jw== X-Gm-Message-State: ALoCoQmcbbKag6EJagnbp4bOoFHkp65O0FSzEv8TfXlbbM8DncaxVJ84rbnCRmS1bhs1kxvhXA9r X-Received: by 10.107.138.88 with SMTP id m85mr96089956iod.35.1426805255927; Thu, 19 Mar 2015 15:47:35 -0700 (PDT) Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id x9sm274974igl.2.2015.03.19.15.47.34 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 19 Mar 2015 15:47:34 -0700 (PDT) Message-ID: <550B5205.100@andyet.net> Date: Thu, 19 Mar 2015 16:47:33 -0600 From: Peter Saint-Andre - &yet User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Wes Hardaker , Viktor Dukhovni References: <2772BE49-FDEC-4C33-AFE8-33E66B6ABBCF@ogud.com> <20150125055400.GJ8034@mournblade.imrryr.org> <0lsid0ve6m.fsf@wjh.hardakers.net> In-Reply-To: <0lsid0ve6m.fsf@wjh.hardakers.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: DANE WG Subject: Re: [dane] Agenda items for Dallas X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 19 Mar 2015 22:47:42 -0000 On 3/19/15 4:02 PM, Wes Hardaker wrote: > Viktor Dukhovni writes: > >> Speaking of LC, we seem to have lost all momentum on the SMTP and >> SRV drafts, lets get those moving again please, together or >> separately. > > I'll be in Dallas and agree completely that these need to go forward. > There is no reason to have them hanging around at this point. AFAIK these are ready and are awaiting shepherd writeups or other actions by the Chairs before IETF Last Call... Peter -- Peter Saint-Andre https://andyet.com/ From nobody Thu Mar 19 16:07: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 B96E11A0007 for ; Thu, 19 Mar 2015 16:07:12 -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 j_Uc2CpP3Q53 for ; Thu, 19 Mar 2015 16:07:11 -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 5D5841A0004 for ; Thu, 19 Mar 2015 16:07:11 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 1268C283011; Thu, 19 Mar 2015 23:07:10 +0000 (UTC) Date: Thu, 19 Mar 2015 23:07:10 +0000 From: Viktor Dukhovni To: DANE WG Message-ID: <20150319230709.GO4309@mournblade.imrryr.org> References: <2772BE49-FDEC-4C33-AFE8-33E66B6ABBCF@ogud.com> <20150125055400.GJ8034@mournblade.imrryr.org> <0lsid0ve6m.fsf@wjh.hardakers.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0lsid0ve6m.fsf@wjh.hardakers.net> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [dane] Agenda items for Dallas 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, 19 Mar 2015 23:07:12 -0000 On Thu, Mar 19, 2015 at 03:02:25PM -0700, Wes Hardaker wrote: > > Finally, I've a lot more operational experience now, and have twice > > asked for feedback on the notion of adding some of the observations > > to the SMTP or ops drafts, but there's been no feedback on that. > > I'd actually collect it and publish it as a BCP later. We're already > too late on the above to delay them for adding more text that will > require another lengthy WGLC. I agree about SMTP not changing at this point. But we have not yet started LC for OPs, and more operational issues could well be added to it, if "ops" is still the right name for the draft... -- Viktor. From nobody Thu Mar 19 16:25: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 924371A005A for ; Thu, 19 Mar 2015 16:25:18 -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 oVHbw1kgdVgq for ; Thu, 19 Mar 2015 16:25:16 -0700 (PDT) Received: from mail-oi0-f41.google.com (mail-oi0-f41.google.com [209.85.218.41]) (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 82EA11A0045 for ; Thu, 19 Mar 2015 16:24:59 -0700 (PDT) Received: by oigv203 with SMTP id v203so78287948oig.3 for ; Thu, 19 Mar 2015 16:24:59 -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:cc:content-type; bh=IFAc+5MVx+kq6QjAEqSNCm7YPcqDSnuuXOrE9rv8cWE=; b=NM/IGRwv42etoFp2HiqcoU2EYvidCBuw5gkpCDlRcyHQbcIygQH4otV9sWu/HFj84j pUzus750BNg5AZzPcfpzIXwDPZXRUE82TMbJct55Yud/NGfyi9NjqceuV4TqKmd6JOwz CwFHaRwkSeqf5UC3V4JTWdp2zhxhB84J4wGbttLhy+gqUPmpZS+yvYchhzP74pHM6RRF HkjQ9/rMeAiaTCGOyx9p4+wAi1UvVPzbCfD+kfO3kqDQvQcaIzXx6A5kMLhUsIPaNxfZ yqHF17gbmGoH0u4Pp46xeLSKs70R4bhYd0NM9YRxHISD4k6SAB8WrfdoTvCOFGzSY5nE 9kkw== X-Gm-Message-State: ALoCoQk7qz3OjCEiTbnvkIQLreY2R2IYctEFMqoCDoLgOhqILFNbn3EbES17H1sdx4MQ9VdRWLrx MIME-Version: 1.0 X-Received: by 10.202.198.76 with SMTP id w73mr31983282oif.74.1426807498914; Thu, 19 Mar 2015 16:24:58 -0700 (PDT) Received: by 10.202.79.86 with HTTP; Thu, 19 Mar 2015 16:24:58 -0700 (PDT) In-Reply-To: References: <20150318001300.34285.qmail@ary.lan> Date: Thu, 19 Mar 2015 18:24:58 -0500 Message-ID: From: Warren Kumari To: Paul Wouters Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: John Levine , Paul Hoffman , "" Subject: Re: [dane] Comments on draft-ietf-dane-openpgpkey-02 (fwd) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Mar 2015 23:25:18 -0000 Ok, so we are asking Paul to submit the updated draft once the window opens, so that we have a clear slate. We are also planning on having a discussion at the face to face meeting on how we will deal with the LHS of email addresses in DANE. The outcome of this discussion may / will influence the contents of this, and possibly other documents. We need a single, clean way to deal with finding associated with an email address, not one per document... W On Wed, Mar 18, 2015 at 6:57 PM, Warren Kumari wrote: > Ok, so there are still a number of outstanding things we need to > figure out on not just this draft, but the whole approach when it > comes to mail addresses. > > It seems that I may have been overoptimistic about the LHS of the > email address (and possibly the _prefix / DNAME solution), and if we > can just hand-wave this away... > > Olafur and I will chat, but I think that we need some assistance from > Apps folk, and to have a proper discussion of this in the F2F > meeting... > > Apologies to all for yanking you around. on the plus side, the network > in Dallas is starting tom come together nicely... > > W > > On Wed, Mar 18, 2015 at 12:24 PM, Warren Kumari wrote: >> [ Random top post ] >> So, it feels like we are approaching a compromise / consensus on this >> bit (which is good, because this part was the bit we were least in >> agreement on) >> >> Let's give this a bit more time to settle, then I'm planning on a very >> short WGLC, restricted just to this question, and with a "We'll >> assume you are OK with this, unless you say otherwise". >> >> W >> >> On Wed, Mar 18, 2015 at 10:47 AM, Paul Wouters wrote: >>> On Tue, 18 Mar 2015, John Levine wrote: >>> >>>> >>>> I'd suggest taking out "based on special characters", since the most >>>> common mapping is case folding. The standard term for the LHS is >>>> local-part, so you might as well use that and reference RFC 5321, sec >>>> 2.3.11 where it's defined. >>>> >>>> Also, the SHOULD NOT would better be MUST NOT, to be consistent with >>>> RFC 5321 which says "the local-part MUST be interpreted and assigned >>>> semantics only by the host specified in the domain part of the >>>> address." >>>> >>>> (If you have a private agreement with someone and you have knowledge >>>> of their internal mappings, you can do whatever you want, but of >>>> course private agreements are outside the scope of standards.) >>> >>> >>> With this, we've gone a full circle. It feels strange to me to write a >>> MUST NOT, knowing that implementors will need to do this in practise. >>> >>> But I guess I could live with it if the consensus moves this way, but to >>> me that seems only because I know the MUST NOT will be violated. >>> >>>> Having said all that, how useful do people think this will be if it >>>> doesn't allow the local-part fuzz that mail systems provide? If the >>>> addresses to be looked up are picked mechanically from incoming mail >>>> headers, it'd likely work fine. If typed in from business cards, it >>>> could be pretty frustrating. >>> >>> >>> Or even typed in on an iphone for which you have an existing contact >>> with a lower case name, and it stupidly Uppercases it anyway when you >>> type. >>> >>> Paul >>> >>> >>> _______________________________________________ >>> 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 > > > > -- > 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 -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf From nobody Fri Mar 20 07:39: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 354611AC40E for ; Fri, 20 Mar 2015 07:39:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.912 X-Spam-Level: X-Spam-Status: No, score=-6.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uLaFG7jfAaoT for ; Fri, 20 Mar 2015 07:39:31 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (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 75B251AC3E7 for ; Fri, 20 Mar 2015 07:39:31 -0700 (PDT) Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t2KEdUSf010706 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Fri, 20 Mar 2015 10:39:30 -0400 Received: from pspacek.brq.redhat.com (pspacek.brq.redhat.com [10.34.128.7]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t2KEdRNL003339 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Fri, 20 Mar 2015 10:39:28 -0400 Message-ID: <550C311F.1040709@redhat.com> Date: Fri, 20 Mar 2015 15:39:27 +0100 From: Petr Spacek Organization: Red Hat User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Warren Kumari , Paul Wouters References: <20150318001300.34285.qmail@ary.lan> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 Archived-At: Cc: John Levine , Paul Hoffman , "" Subject: Re: [dane] Comments on draft-ietf-dane-openpgpkey-02 (fwd) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Mar 2015 14:39:33 -0000 On 18.3.2015 17:24, Warren Kumari wrote: > [ Random top post ] > So, it feels like we are approaching a compromise / consensus on this > bit (which is good, because this part was the bit we were least in > agreement on) Warren and list, I believe that the RDATA format is still underspecified which seems like a major problem to me: Please see http://www.ietf.org/mail-archive/web/dane/current/msg07390.html Petr Spacek @ Red Hat > Let's give this a bit more time to settle, then I'm planning on a very > short WGLC, restricted just to this question, and with a "We'll > assume you are OK with this, unless you say otherwise". > > W > > On Wed, Mar 18, 2015 at 10:47 AM, Paul Wouters wrote: >> On Tue, 18 Mar 2015, John Levine wrote: >> >>> >>> I'd suggest taking out "based on special characters", since the most >>> common mapping is case folding. The standard term for the LHS is >>> local-part, so you might as well use that and reference RFC 5321, sec >>> 2.3.11 where it's defined. >>> >>> Also, the SHOULD NOT would better be MUST NOT, to be consistent with >>> RFC 5321 which says "the local-part MUST be interpreted and assigned >>> semantics only by the host specified in the domain part of the >>> address." >>> >>> (If you have a private agreement with someone and you have knowledge >>> of their internal mappings, you can do whatever you want, but of >>> course private agreements are outside the scope of standards.) >> >> >> With this, we've gone a full circle. It feels strange to me to write a >> MUST NOT, knowing that implementors will need to do this in practise. >> >> But I guess I could live with it if the consensus moves this way, but to >> me that seems only because I know the MUST NOT will be violated. >> >>> Having said all that, how useful do people think this will be if it >>> doesn't allow the local-part fuzz that mail systems provide? If the >>> addresses to be looked up are picked mechanically from incoming mail >>> headers, it'd likely work fine. If typed in from business cards, it >>> could be pretty frustrating. >> >> >> Or even typed in on an iphone for which you have an existing contact >> with a lower case name, and it stupidly Uppercases it anyway when you >> type. >> >> Paul From nobody Fri Mar 20 12:28: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 07ED71B2FA8 for ; Fri, 20 Mar 2015 12:28: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] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b4pVt8yGn1Bx for ; Fri, 20 Mar 2015 12:28: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 5F72D1B2FA0 for ; Fri, 20 Mar 2015 12:28:17 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 49DBF282FCE; Fri, 20 Mar 2015 19:28:16 +0000 (UTC) Date: Fri, 20 Mar 2015 19:28:16 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20150320192816.GI3380@mournblade.imrryr.org> References: <20150318001300.34285.qmail@ary.lan> <550C311F.1040709@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <550C311F.1040709@redhat.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [dane] Comments on draft-ietf-dane-openpgpkey-02 (fwd) 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, 20 Mar 2015 19:28:19 -0000 On Fri, Mar 20, 2015 at 03:39:27PM +0100, Petr Spacek wrote: > On 18.3.2015 17:24, Warren Kumari wrote: > > [ Random top post ] > > So, it feels like we are approaching a compromise / consensus on this > > bit (which is good, because this part was the bit we were least in > > agreement on) > > Warren and list, I believe that the RDATA format is still underspecified which > seems like a major problem to me: Please see > http://www.ietf.org/mail-archive/web/dane/current/msg07390.html Thanks for the reminder. I think we should at least explore the question of what exactly does go into the RRDATA. What parts of a PGP public key should publishers include or exclude? Will stating a more precise definition improve interoperability? Should the interchange form for such "out of band" PGP public keys be defined in some other document. I've seen messages to the effect that there's some interest in re-chartering the PGP working group... -- Viktor. From nobody Fri Mar 20 14:49: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 1FC9C1A9086 for ; Fri, 20 Mar 2015 14:49:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iueOByys-oot for ; Fri, 20 Mar 2015 14:49:53 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0FBA11A9083 for ; Fri, 20 Mar 2015 14:49:52 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3l7zKV4lPbzCCR for ; Fri, 20 Mar 2015 22:49:50 +0100 (CET) Authentication-Results: mx.nohats.ca; dkim=pass (1024-bit key) header.d=nohats.ca header.i=@nohats.ca header.b=ImhBX8Vb 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 AtCjV6ZgYhqG for ; Fri, 20 Mar 2015 22:49:48 +0100 (CET) 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 ; Fri, 20 Mar 2015 22:49:48 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 027C4803E0 for ; Fri, 20 Mar 2015 17:49:47 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1426888188; bh=IVmVcf43npbC9E8XffzrEAzp5XWclhX30JgIEH9UN/U=; h=Date:From:To:Subject:In-Reply-To:References; b=ImhBX8VbZCRE5gNTUon0smuMPrsbrGYXZabc2ixCYZeDHhXGn+7F6Yktp4RJXDVZW oN7nKzmj4C715Z4aeM1QA4sTGsLHIlWttRflQrDQo+pr7wGsOdClS1hpCLi/H7SeaP SNCfAv8Gzdx3tDC2Tfinj65kAWVyL567eXg8H+Co= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id t2KLnlqX031591 for ; Fri, 20 Mar 2015 17:49:47 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Fri, 20 Mar 2015 17:49:47 -0400 (EDT) From: Paul Wouters To: dane@ietf.org In-Reply-To: <20150320192816.GI3380@mournblade.imrryr.org> Message-ID: References: <20150318001300.34285.qmail@ary.lan> <550C311F.1040709@redhat.com> <20150320192816.GI3380@mournblade.imrryr.org> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [dane] Comments on draft-ietf-dane-openpgpkey-02 (fwd) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Mar 2015 21:49:55 -0000 On Fri, 20 Mar 2015, Viktor Dukhovni wrote: >> seems like a major problem to me: Please see >> http://www.ietf.org/mail-archive/web/dane/current/msg07390.html > > Thanks for the reminder. I think we should at least explore the > question of what exactly does go into the RRDATA. IMHO, we already state that clearly in the latest text proposed to this list, referencing the exact section of the openpgp RFC. The latest proposed text was: The RDATA Presentation Format, as visible in textual zone files, consists of a single OpenPGP public key as defined in Section 5.5.1.1. of [RFC4880] encoded in Base64 [RFC4648] > What parts of > a PGP public key should publishers include or exclude? Will stating > a more precise definition improve interoperability? Why should we decide any of this? As long as it is a valid openpgp Public-Key Packet (Tag 6) > Should the interchange form for such "out of band" PGP public keys > be defined in some other document. gpg and other tools have managed to do fine with openpgp public key rings all over the place. In files, on key servers, via hpk or http. The interchange format is called RFC 4880. > I've seen messages to the > effect that there's some interest in re-chartering the PGP working > group... All the more reason for us not to cherry-pick items of the public key ring packet and leave it up to a new RFC updating 4880 to reflect updates for modern openpgp use. By referencing RFC 4880, we will get those updates by the new RFC that updates 4880. Paul From nobody Sat Mar 21 15:59: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 B644C1A904C for ; Sat, 21 Mar 2015 15:59:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.267 X-Spam-Level: X-Spam-Status: No, score=-2.267 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q_QyDrrMhws4 for ; Sat, 21 Mar 2015 15:59:06 -0700 (PDT) Received: from smtp140.dfw.emailsrvr.com (smtp140.dfw.emailsrvr.com [67.192.241.140]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 932951A889D for ; Sat, 21 Mar 2015 15:59:06 -0700 (PDT) Received: from smtp26.relay.dfw1a.emailsrvr.com (localhost.localdomain [127.0.0.1]) by smtp26.relay.dfw1a.emailsrvr.com (SMTP Server) with ESMTP id BFFE1280163; Sat, 21 Mar 2015 18:59:05 -0400 (EDT) Received: by smtp26.relay.dfw1a.emailsrvr.com (Authenticated sender: ogud-AT-ogud.com) with ESMTPSA id 7C45E28015B; Sat, 21 Mar 2015 18:59:04 -0400 (EDT) X-Sender-Id: ogud@ogud.com Received: from [10.59.2.92] ([UNAVAILABLE]. [65.205.30.226]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:465 (trex/5.4.2); Sat, 21 Mar 2015 22:59:05 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Olafur Gudmundsson In-Reply-To: <20150313182334.24823.qmail@ary.lan> Date: Sat, 21 Mar 2015 18:59:03 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <60065E20-9D0F-4B7F-B7F3-26531590A663@ogud.com> References: <20150313182334.24823.qmail@ary.lan> To: John Levine X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: dane@ietf.org Subject: Re: [dane] Names of mailbox records in draft-ietf-dane-smime and 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: Sat, 21 Mar 2015 22:59:07 -0000 > On Mar 13, 2015, at 2:23 PM, John Levine wrote: >=20 > I see that in dane-openpgpkey, the name on the record is >=20 > ._openpgpkey.domain >=20 > and in dane-smime, the name is: >=20 > ._smimecert.domain >=20 > These are two different names for the same mailbox. Since they use > the same hash, wouldn't it be a better idea for both of them and any > future RRs that use hashed mailboxes to use the same name? >=20 > ._mailbox.domain Depends on how the systems are operated, Operator can use DNAME to make = the two names be there same=20 i.e _smimecert. DNAME _openpgpkey.=20 Not sure if having multiple namespaces for keying is a good idea or not.=20= Olafur From nobody Sat Mar 21 17:15: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 8495E1A9082 for ; Sat, 21 Mar 2015 17:15:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.038 X-Spam-Level: X-Spam-Status: No, score=-1.038 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 lFjTmZCn-Hgv for ; Sat, 21 Mar 2015 17:15:45 -0700 (PDT) Received: from oj.bangj.com (amt0.gin.ntt.net [129.250.11.170]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 398BA1A907E for ; Sat, 21 Mar 2015 17:15:45 -0700 (PDT) Received: from dhcp-896b.meeting.ietf.org (dhcp-896b.meeting.ietf.org [31.133.137.107]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by oj.bangj.com (Postfix) with ESMTPSA id CE92F2B7B for ; Sat, 21 Mar 2015 20:11:18 -0400 (EDT) From: Tom Pusateri X-Pgp-Agent: GPGMail 2.5b6 Content-Type: multipart/signed; boundary="Apple-Mail=_CBAC8E98-B530-4D3E-9184-C00EE3A002B5"; protocol="application/pgp-signature"; micalg=pgp-sha256 Date: Sat, 21 Mar 2015 19:15:42 -0500 Message-Id: <9654EDBC-2F05-4369-BF2C-1FADEC3E2382@bangj.com> To: dane@ietf.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) X-Mailer: Apple Mail (2.2070.6) Archived-At: Subject: [dane] review of draft-ietf-dane-srv-11 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 22 Mar 2015 00:15:46 -0000 --Apple-Mail=_CBAC8E98-B530-4D3E-9184-C00EE3A002B5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Since a recent draft Stuart and I posted depends on this technology = (https://tools.ietf.org/html/draft-ietf-dnssd-push-00), I thought I = would do a careful review of draft-ietf-dane-srv-11. Overall, the document is in really good shape. I found it to be clear = and well conceived. The appropriate references makes it easy to follow = and fill in the blanks of unfamiliar technologies. I carefully read the document to help find any nits that need addressed. = There aren't many, but I found two. Neither of these are major issues. 1. Section 3.4, first paragraph, last sentence. "This affects the use = TLS as follows:". Maybe this is missing the word "of" before TLS? 2. Appendix A.2 _xmpp-client.example.com. Shouldn't this be? _xmpp-client._tcp.example.com. That's all I could find. Thanks, Tom --Apple-Mail=_CBAC8E98-B530-4D3E-9184-C00EE3A002B5 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQEcBAEBCAAGBQJVDgmuAAoJEPk0GMVmUuYMg5sH/2Wvxv5/Uwq3dpPpvT1CcYZr 4IKpbyXBoTJfmybAxUlj7neM2A8bC0EM91T8tUVSu2Cu/H+Yi9bkke2gc9h92bhV j+yraimfo97dTNTiGbyKQsQiH0VLEDitOJLOEpVQcZQ5NSZzg7ASgB3lYrPmnKya NZJ3szgQWh+8/7W+s/etFjIFkZlSBjptPfFheRuEaitkhKAE5z4dOL6atoi0+/uj 7yav5Pb203TgSqd5z3IB7XqamoHQdDqzc9Pwru6nHGOahkIYmehITYvueNNI90CV 40jrUNWPBwoyg1URxZEfCES6+LDDdnHSQOvLnu3Pve6Xnj1Th7TS6qzMJDeF5qg= =ZHZb -----END PGP SIGNATURE----- --Apple-Mail=_CBAC8E98-B530-4D3E-9184-C00EE3A002B5-- From nobody Sat Mar 21 20:08: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 12D601A0158 for ; Sat, 21 Mar 2015 20:08:18 -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 ce2JD3AkfL4I for ; Sat, 21 Mar 2015 20:08:16 -0700 (PDT) Received: from mail-ie0-f181.google.com (mail-ie0-f181.google.com [209.85.223.181]) (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 986C81A0122 for ; Sat, 21 Mar 2015 20:08:16 -0700 (PDT) Received: by iedfl3 with SMTP id fl3so17435691ied.1 for ; Sat, 21 Mar 2015 20:08:16 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=YtQ2qCXeri2VgRbp4woA5NYlouVW9QLIm9lPaWicsfE=; b=N0i62Qq90Y9UMlkXHd7tCz6fkRpwFi/nDV43Ts1YNQoVd959Pdv3oJU9r5+7jLH+Jf 3HxtCX3SgEM+nTQ6M+VCBIyLWRSipnU7fhZrNeIz4Ki4K0lWuIX1QcFSFUdv3xbqq0pp Itdn2QoJohDrTvj3hCx5Ea3KgFGN8Kd9BKc5uAyv6q9nFK+saKsQWQ1gVKucGGIgW6f0 RpthiiEXQCMIxWsc6jPhJn8yzBKutAA5qgQsOdq+qN+eLwqjt7/OhoUybEn2eiG9y5Bo nfDe6UAn0VVyno3ImTg51U+ybzjnudjGrnrKJybUeodWw1NHT5s8LVXuwNRtXqD6jbxW 2vLg== X-Gm-Message-State: ALoCoQn/JJUIyLPFTV8UkYJnPTnWNTW+geXYrNYGwgHaixJQXDwIeYijI4TuQIF9tkD0oxIryJAG X-Received: by 10.50.124.133 with SMTP id mi5mr6370688igb.13.1426993695948; Sat, 21 Mar 2015 20:08:15 -0700 (PDT) Received: from [10.0.0.12] (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id n7sm2747140iga.13.2015.03.21.20.08.15 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 21 Mar 2015 20:08:15 -0700 (PDT) References: <9654EDBC-2F05-4369-BF2C-1FADEC3E2382@bangj.com> Mime-Version: 1.0 (1.0) In-Reply-To: <9654EDBC-2F05-4369-BF2C-1FADEC3E2382@bangj.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <7F30DB90-5209-4C1E-B65F-6E38EC188A06@andyet.net> X-Mailer: iPhone Mail (12D508) From: Peter Saint-Andre Date: Sat, 21 Mar 2015 21:08:13 -0600 To: Tom Pusateri Archived-At: Cc: "dane@ietf.org" Subject: Re: [dane] review of draft-ietf-dane-srv-11 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 22 Mar 2015 03:08:18 -0000 Hi Tom, thanks for the review. I'm glad you didn't find any major issues. W= e'll fix those nits.=20 > On Mar 21, 2015, at 6:15 PM, Tom Pusateri wrote: >=20 > Since a recent draft Stuart and I posted depends on this technology (https= ://tools.ietf.org/html/draft-ietf-dnssd-push-00), I thought I would do a car= eful review of draft-ietf-dane-srv-11. >=20 > Overall, the document is in really good shape. I found it to be clear and w= ell conceived. The appropriate references makes it easy to follow and fill i= n the blanks of unfamiliar technologies. >=20 > I carefully read the document to help find any nits that need addressed. T= here aren't many, but I found two. Neither of these are major issues. >=20 >=20 > 1. Section 3.4, first paragraph, last sentence. "This affects the use TLS a= s follows:". Maybe this is missing the word "of" before TLS? >=20 > 2. Appendix A.2 > _xmpp-client.example.com. >=20 > Shouldn't this be? >=20 > _xmpp-client._tcp.example.com. >=20 > That's all I could find. >=20 > Thanks, > Tom >=20 > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane From nobody Mon Mar 23 07:56: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 35FF11A8BC0; Mon, 23 Mar 2015 07:56:05 -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 lWWzxBR_5ADO; Mon, 23 Mar 2015 07:56:03 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 10B9C1A8F37; Mon, 23 Mar 2015 07:56:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 5.12.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150323145602.3047.71249.idtracker@ietfa.amsl.com> Date: Mon, 23 Mar 2015 07:56:02 -0700 Archived-At: Cc: dane@ietf.org Subject: [dane] I-D Action: draft-ietf-dane-srv-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: Mon, 23 Mar 2015 14:56:05 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS-based Authentication of Named Entities Working Group of the IETF. Title : Using DNS-Based Authentication of Named Entities (DANE) TLSA Records with SRV Records Authors : Tony Finch Matthew Miller Peter Saint-Andre Filename : draft-ietf-dane-srv-12.txt Pages : 14 Date : 2015-03-23 Abstract: The DANE specification (RFC 6698) describes how to use TLSA resource records secured by DNSSEC (RFC 4033) to associate a server's connection endpoint with its TLS certificate. However, application protocols that use SRV records (RFC 2782) to indirectly name the target server connection endpoints for a service domain cannot apply the rules from RFC 6698. Therefore this document provides guidelines that enable such protocols to locate and use TLSA records. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dane-srv/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dane-srv-12 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-dane-srv-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 Mon Mar 23 11: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 611DC1AD353 for ; Mon, 23 Mar 2015 11:56:30 -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 taYOtoO-VaSG for ; Mon, 23 Mar 2015 11:56:29 -0700 (PDT) Received: from smtp84.iad3a.emailsrvr.com (smtp84.iad3a.emailsrvr.com [173.203.187.84]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D98AD1AD2C0 for ; Mon, 23 Mar 2015 11:56:25 -0700 (PDT) Received: from smtp27.relay.iad3a.emailsrvr.com (localhost.localdomain [127.0.0.1]) by smtp27.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 27620180432 for ; Mon, 23 Mar 2015 14:56:25 -0400 (EDT) Received: from app39.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by smtp27.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 16B1C1803E0 for ; Mon, 23 Mar 2015 14:56:25 -0400 (EDT) X-Sender-Id: ogud@ogud.com Received: from app39.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by 0.0.0.0:25 (trex/5.4.2); Mon, 23 Mar 2015 18:56:25 GMT Received: from ogud.com (localhost.localdomain [127.0.0.1]) by app39.wa-webapps.iad3a (Postfix) with ESMTP id 06257380044 for ; Mon, 23 Mar 2015 14:56:25 -0400 (EDT) Received: by apps.rackspace.com (Authenticated sender: ogud@ogud.com, from: ogud@ogud.com) with HTTP; Mon, 23 Mar 2015 14:56:25 -0400 (EDT) Date: Mon, 23 Mar 2015 14:56:25 -0400 (EDT) From: "Olafur Gudmundsson" To: dane@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_20150323145625000000_86860" Importance: Normal X-Priority: 3 (Normal) X-Type: html X-Auth-ID: ogud@ogud.com Message-ID: <1427136985.022113221@apps.rackspace.com> X-Mailer: webmail/11.3.13-RC Archived-At: Subject: [dane] =?utf-8?q?Remote_participation_experiment_during_DANE?= X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 18:56:30 -0000 ------=_20150323145625000000_86860 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =0AThe chairs volunteered the meeting for a remote participant experiment. = =0A =0AExperiment 1: Two queues =E2=80=94 a virtual queue and an actual (in= -room) queue=0ARemote attendees will log into the Meetecho platform and wil= l have a virtual mic line that they can enter if they have a question or co= mment. In-room participants will continue to use normal mic lines. This mea= ns that there will be a minimum of two queues =E2=80=94 one physical in-roo= m queue and one virtual =E2=80=94 and the chair (or delegate) will need to = move back and forth between the two, giving people turns. When someone in t= he virtual queue has a turn, Meetecho will inject their audio the room so t= hat they can speak directly to/with everyone in the actual meeting room.=0A= We want to encourage remote participation in the meeting. =0AAfter the meet= ing we will post a short survey on how the experiment went. =0AOlafur (for = chairs) ------=_20150323145625000000_86860 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

The chairs volunteered the= meeting for a remote participant experiment. 

=0A

=  

=0A

Experiment 1: Two queues =E2=80=94 a virtual = queue and an actual (in-room) queue

=0A
Remote attendees will log into the Meetech= o platform and will have a virtual mic line that they can enter if they hav= e a question or comment. In-room participants will continue to use normal m= ic lines. This means that there will be a minimum of two queues =E2=80=94 o= ne physical in-room queue and one virtual =E2=80=94 and the chair (or deleg= ate) will need to move back and forth between the two, giving people turns.= When someone in the virtual queue has a turn, Meetecho will inject their a= udio the room so that they can speak directly to/with everyone in the actua= l meeting room.
=0A
We want to encourage remote participation in the meeting.&nb= sp;
=0A
After the meeting we will post a short survey on how the experiment went= . 
=0A
Olafur (for chairs) 
 ------=_20150323145625000000_86860-- From nobody Mon Mar 23 16:33:43 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E915B1A1EF9 for ; Mon, 23 Mar 2015 16:33:40 -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 6IdjC-BsHjeC for ; Mon, 23 Mar 2015 16:33:38 -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 B840C1A1EF5 for ; Mon, 23 Mar 2015 16:33:38 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3l9sTp6pyyzCLD for ; Tue, 24 Mar 2015 00:33:34 +0100 (CET) Authentication-Results: mx.nohats.ca; dkim=pass (1024-bit key) header.d=nohats.ca header.i=@nohats.ca header.b=ntZOr4gf 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 DM-e5664gvv3 for ; Tue, 24 Mar 2015 00:33:33 +0100 (CET) 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, 24 Mar 2015 00:33:33 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id DD1C880416 for ; Mon, 23 Mar 2015 19:33:32 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1427153612; bh=c3IB1RZA3xHVygxSdefmkeCPjhPcpmJ/d1X2DUko+dI=; h=Date:From:To:Subject; b=ntZOr4gfIJolqrwAVkW23cB40u42ik/aYYwlhzaPhSbteAzXe+P7DlBNJZ6zobS1M kaAyVkMlzRPpVRNojd7GUAMVLrb/YSfG3JiMmbEYgTO+vkXbNDXsT3Voer2vMUpP6T kMl9ahjJK4mQWzCsA7QpY4b7aGXUesP0iUPZw0gE= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id t2NNXW0I029696 for ; Mon, 23 Mar 2015 19:33:32 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Mon, 23 Mar 2015 19:33:32 -0400 (EDT) From: Paul Wouters To: dane WG list Message-ID: User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Archived-At: Subject: [dane] FYI: OpenKeychain - Keys in DNSSEC/DANE X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 23:33:41 -0000 https://github.com/open-keychain/open-keychain/wiki/Google-Summer-of-Code-2015#keys-in-dnssecdane Keys in DNSSEC/DANE Brief explanation: Together with the XMPP Standards Foundation (XSF), see their GSoC idea, we would like to extend the MiniDNS library with DNSSEC support to allow the retrieval of OpenPGP keys from DNS entries. [...] From nobody Tue Mar 24 03:08: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 999491A1A0B for ; Tue, 24 Mar 2015 03:08:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.912 X-Spam-Level: X-Spam-Status: No, score=-6.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0-GEWoIaqeLg for ; Tue, 24 Mar 2015 03:08:04 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9F1A1A19E4 for ; Tue, 24 Mar 2015 03:08:04 -0700 (PDT) Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (Postfix) with ESMTPS id D6495A10A3 for ; Tue, 24 Mar 2015 10:08:03 +0000 (UTC) Received: from pspacek.brq.redhat.com (pspacek.brq.redhat.com [10.34.128.7]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t2OA82Lu017519 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Tue, 24 Mar 2015 06:08:03 -0400 Message-ID: <55113781.7010903@redhat.com> Date: Tue, 24 Mar 2015 11:08:01 +0100 From: Petr Spacek Organization: Red Hat User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: dane@ietf.org References: <20150318001300.34285.qmail@ary.lan> <550C311F.1040709@redhat.com> <20150320192816.GI3380@mournblade.imrryr.org> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26 Archived-At: Subject: Re: [dane] Comments on draft-ietf-dane-openpgpkey-02 (fwd) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2015 10:08:06 -0000 On 20.3.2015 22:49, Paul Wouters wrote: > On Fri, 20 Mar 2015, Viktor Dukhovni wrote: > >>> seems like a major problem to me: Please see >>> http://www.ietf.org/mail-archive/web/dane/current/msg07390.html >> >> Thanks for the reminder. I think we should at least explore the >> question of what exactly does go into the RRDATA. > > IMHO, we already state that clearly in the latest text proposed to > this list, referencing the exact section of the openpgp RFC. The > latest proposed text was: > > The RDATA Presentation Format, as visible in textual zone files, > consists of a single OpenPGP public key as defined in > Section 5.5.1.1. of [RFC4880] encoded in Base64 [RFC4648] > >> What parts of >> a PGP public key should publishers include or exclude? Will stating >> a more precise definition improve interoperability? > > Why should we decide any of this? As long as it is a valid openpgp > Public-Key Packet (Tag 6) I'm not convinced that RFC4880 section 5.5.1.1. clearly defines what clients should expect. The RFC 4880 section 5.5.1.1. in its entirety follows: """ 5.5.1.1. Public-Key Packet (Tag 6) A Public-Key packet starts a series of packets that forms an OpenPGP key (sometimes called an OpenPGP certificate). """ >> Should the interchange form for such "out of band" PGP public keys >> be defined in some other document. > > gpg and other tools have managed to do fine with openpgp public key > rings all over the place. In files, on key servers, via hpk or http. > The interchange format is called RFC 4880. That is an important but kind of invalid point: Of course you can implement an interoperable OpenPGP implementation if you can read what GnuPG does. Still, I'm not convinced that RDATA format specification should be 'do what GnuPG did back in 2015'. Maybe I'm wrong and RFC 4880 defines exactly what packets client should expect - in that case it would be nice to add a reference to particular section in RFC 4880 so implementors have clear entry point and are not confused as I am. >> I've seen messages to the >> effect that there's some interest in re-chartering the PGP working >> group... > > All the more reason for us not to cherry-pick items of the public > key ring packet and leave it up to a new RFC updating 4880 to > reflect updates for modern openpgp use. By referencing RFC 4880, > we will get those updates by the new RFC that updates 4880. That is certainly an option if WG is okay with issuing RDATA format definition which will be unclear at the time of issue. -- Petr Spacek @ Red Hat From nobody Tue Mar 24 15:07: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 EABBA1A1B40 for ; Tue, 24 Mar 2015 15:07:35 -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, 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 YIr8vvjsvULS for ; Tue, 24 Mar 2015 15:07:31 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0688.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:688]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B2D71A1B1E for ; Tue, 24 Mar 2015 15:07:20 -0700 (PDT) Received: from BLUPR06MB820.namprd06.prod.outlook.com (10.141.23.11) by BLUPR06MB819.namprd06.prod.outlook.com (10.141.22.28) with Microsoft SMTP Server (TLS) id 15.1.118.21; Tue, 24 Mar 2015 22:07:01 +0000 Received: from BLUPR06MB820.namprd06.prod.outlook.com ([10.141.23.11]) by BLUPR06MB820.namprd06.prod.outlook.com ([10.141.23.11]) with mapi id 15.01.0118.021; Tue, 24 Mar 2015 22:07:01 +0000 From: Dan York To: Olafur Gudmundsson Thread-Topic: [dane] Remote participation experiment during DANE Thread-Index: AQHQZZsYUXxxZHCKwEOvUZbPZiLPc50sMn0A Date: Tue, 24 Mar 2015 22:07:01 +0000 Message-ID: <45B759CE-7D26-4ED8-8611-B8C2500FE5B3@isoc.org> References: <1427136985.022113221@apps.rackspace.com> In-Reply-To: <1427136985.022113221@apps.rackspace.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [74.69.229.215] authentication-results: ogud.com; dkim=none (message not signed) header.d=none; x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR06MB819; x-microsoft-antispam-prvs: x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10009020)(979002)(377454003)(24454002)(69234005)(76176999)(82746002)(16799955002)(33656002)(19580405001)(83716003)(77156002)(62966003)(106116001)(16236675004)(87936001)(86362001)(19580395003)(54356999)(2656002)(110136001)(122556002)(99286002)(15975445007)(77096005)(102836002)(92566002)(2950100001)(40100003)(2900100001)(50986999)(15395725005)(19617315012)(36756003)(46102003)(66066001)(104396002)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR06MB819; H:BLUPR06MB820.namprd06.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(5002010); SRVR:BLUPR06MB819; BCL:0; PCL:0; RULEID:; SRVR:BLUPR06MB819; x-forefront-prvs: 0525BB0ADF Content-Type: multipart/alternative; boundary="_000_45B759CE7D264ED88611B8C2500FE5B3isocorg_" MIME-Version: 1.0 X-OriginatorOrg: isoc.org X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Mar 2015 22:07:01.2294 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 89f84dfb-7285-4810-bc4d-8b9b5794554f X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR06MB819 Archived-At: Cc: IETF DANE Mailinglist Subject: Re: [dane] Remote participation experiment during DANE X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2015 22:07:36 -0000 --_000_45B759CE7D264ED88611B8C2500FE5B3isocorg_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RllJLCAgTWVldGVjaG8gaGFzIHNvbWUgaW5mb3JtYXRpb24gYW5kIHF1aWNrIHZpZGVvIHR1dG9y aWFscyBhYm91dCB0aGVzZSBtaWMgcXVldWUgZXhwZXJpbWVudHM6DQoNCmh0dHA6Ly9pZXRmOTIu Y29uZi5tZWV0ZWNoby5jb20vaW5kZXgucGhwL1VNUElSRV9Qcm9qZWN0DQoNCg0KT24gTWFyIDIz LCAyMDE1LCBhdCAyOjU2IFBNLCBPbGFmdXIgR3VkbXVuZHNzb24gPG9ndWRAb2d1ZC5jb208bWFp bHRvOm9ndWRAb2d1ZC5jb20+PiB3cm90ZToNCg0KVGhlIGNoYWlycyB2b2x1bnRlZXJlZCB0aGUg bWVldGluZyBmb3IgYSByZW1vdGUgcGFydGljaXBhbnQgZXhwZXJpbWVudC4NCg0KDQoNCkV4cGVy aW1lbnQgMTogVHdvIHF1ZXVlcyDigJQgYSB2aXJ0dWFsIHF1ZXVlIGFuZCBhbiBhY3R1YWwgKGlu LXJvb20pIHF1ZXVlDQpSZW1vdGUgYXR0ZW5kZWVzIHdpbGwgbG9nIGludG8gdGhlIE1lZXRlY2hv IHBsYXRmb3JtIGFuZCB3aWxsIGhhdmUgYSB2aXJ0dWFsIG1pYyBsaW5lIHRoYXQgdGhleSBjYW4g ZW50ZXIgaWYgdGhleSBoYXZlIGEgcXVlc3Rpb24gb3IgY29tbWVudC4gSW4tcm9vbSBwYXJ0aWNp cGFudHMgd2lsbCBjb250aW51ZSB0byB1c2Ugbm9ybWFsIG1pYyBsaW5lcy4gVGhpcyBtZWFucyB0 aGF0IHRoZXJlIHdpbGwgYmUgYSBtaW5pbXVtIG9mIHR3byBxdWV1ZXMg4oCUIG9uZSBwaHlzaWNh bCBpbi1yb29tIHF1ZXVlIGFuZCBvbmUgdmlydHVhbCDigJQgYW5kIHRoZSBjaGFpciAob3IgZGVs ZWdhdGUpIHdpbGwgbmVlZCB0byBtb3ZlIGJhY2sgYW5kIGZvcnRoIGJldHdlZW4gdGhlIHR3bywg Z2l2aW5nIHBlb3BsZSB0dXJucy4gV2hlbiBzb21lb25lIGluIHRoZSB2aXJ0dWFsIHF1ZXVlIGhh cyBhIHR1cm4sIE1lZXRlY2hvIHdpbGwgaW5qZWN0IHRoZWlyIGF1ZGlvIHRoZSByb29tIHNvIHRo YXQgdGhleSBjYW4gc3BlYWsgZGlyZWN0bHkgdG8vd2l0aCBldmVyeW9uZSBpbiB0aGUgYWN0dWFs IG1lZXRpbmcgcm9vbS4NCldlIHdhbnQgdG8gZW5jb3VyYWdlIHJlbW90ZSBwYXJ0aWNpcGF0aW9u IGluIHRoZSBtZWV0aW5nLg0KQWZ0ZXIgdGhlIG1lZXRpbmcgd2Ugd2lsbCBwb3N0IGEgc2hvcnQg c3VydmV5IG9uIGhvdyB0aGUgZXhwZXJpbWVudCB3ZW50Lg0KT2xhZnVyIChmb3IgY2hhaXJzKQ0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCmRhbmUgbWFp bGluZyBsaXN0DQpkYW5lQGlldGYub3JnPG1haWx0bzpkYW5lQGlldGYub3JnPg0KaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kYW5lDQoNCi0tDQpEYW4gWW9yaw0KU2VuaW9y IENvbnRlbnQgU3RyYXRlZ2lzdCwgSW50ZXJuZXQgU29jaWV0eQ0KeW9ya0Bpc29jLm9yZzxtYWls dG86eW9ya0Bpc29jLm9yZz4gICArMS04MDItNzM1LTE2MjQNCkphYmJlcjogeW9ya0BqYWJiZXIu aXNvYy5vcmc8bWFpbHRvOnlvcmtAamFiYmVyLmlzb2Mub3JnPg0KU2t5cGU6IGRhbnlvcmsgICBo dHRwOi8vdHdpdHRlci5jb20vZGFueW9yaw0KDQpodHRwOi8vd3d3LmludGVybmV0c29jaWV0eS5v cmcvZGVwbG95MzYwLw0KDQoNCg0K --_000_45B759CE7D264ED88611B8C2500FE5B3isocorg_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KRllJLCAmbmJzcDtNZWV0ZWNobyBo YXMgc29tZSBpbmZvcm1hdGlvbiBhbmQgcXVpY2sgdmlkZW8gdHV0b3JpYWxzIGFib3V0IHRoZXNl IG1pYyBxdWV1ZSBleHBlcmltZW50czoNCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9k aXY+DQo8ZGl2IGNsYXNzPSIiPjxhIGhyZWY9Imh0dHA6Ly9pZXRmOTIuY29uZi5tZWV0ZWNoby5j b20vaW5kZXgucGhwL1VNUElSRV9Qcm9qZWN0IiBjbGFzcz0iIj5odHRwOi8vaWV0ZjkyLmNvbmYu bWVldGVjaG8uY29tL2luZGV4LnBocC9VTVBJUkVfUHJvamVjdDwvYT48L2Rpdj4NCjxkaXYgY2xh c3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4N CjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXY+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBj bGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+T24gTWFyIDIzLCAyMDE1LCBhdCAyOjU2IFBNLCBPbGFm dXIgR3VkbXVuZHNzb24gJmx0OzxhIGhyZWY9Im1haWx0bzpvZ3VkQG9ndWQuY29tIiBjbGFzcz0i Ij5vZ3VkQG9ndWQuY29tPC9hPiZndDsgd3JvdGU6PC9kaXY+DQo8YnIgY2xhc3M9IkFwcGxlLWlu dGVyY2hhbmdlLW5ld2xpbmUiPg0KPGRpdiBjbGFzcz0iIj48Zm9udCBmYWNlPSJhcmlhbCIgc2l6 ZT0iMiIgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBweDsgcGFkZGluZzogMHB4OyBm b250LWZhbWlseTogYXJpYWw7IGZvbnQtc2l6ZTogMTBwdDsgd29yZC13cmFwOiBicmVhay13b3Jk OyIgY2xhc3M9IiI+DQpUaGUgY2hhaXJzIHZvbHVudGVlcmVkIHRoZSBtZWV0aW5nIGZvciBhIHJl bW90ZSBwYXJ0aWNpcGFudCBleHBlcmltZW50LiZuYnNwOzwvZGl2Pg0KPHAgc3R5bGU9Im1hcmdp bjowO3BhZGRpbmc6MDtmb250LWZhbWlseTogYXJpYWw7IGZvbnQtc2l6ZTogMTBwdDsgd29yZC13 cmFwOiBicmVhay13b3JkOyIgY2xhc3M9IiI+DQombmJzcDs8L3A+DQo8ZGl2IHN0eWxlPSJtYXJn aW46IDBweDsgcGFkZGluZzogMHB4OyBmb250LWZhbWlseTogYXJpYWw7IGZvbnQtc2l6ZTogMTBw dDsgd29yZC13cmFwOiBicmVhay13b3JkOyIgY2xhc3M9IiI+DQpFeHBlcmltZW50IDE6IFR3byBx dWV1ZXMg4oCUIGEgdmlydHVhbCBxdWV1ZSBhbmQgYW4gYWN0dWFsIChpbi1yb29tKSBxdWV1ZTwv ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwcHg7IHBhZGRpbmc6IDBweDsgZm9udC1mYW1pbHk6 IEhlbHZldGljYTsiIGNsYXNzPSIiPlJlbW90ZSBhdHRlbmRlZXMgd2lsbCBsb2cgaW50byB0aGUg TWVldGVjaG8gcGxhdGZvcm0gYW5kIHdpbGwgaGF2ZSBhIHZpcnR1YWwgbWljIGxpbmUgdGhhdCB0 aGV5IGNhbiBlbnRlciBpZiB0aGV5IGhhdmUgYSBxdWVzdGlvbiBvciBjb21tZW50LiBJbi1yb29t IHBhcnRpY2lwYW50cyB3aWxsIGNvbnRpbnVlIHRvIHVzZQ0KIG5vcm1hbCBtaWMgbGluZXMuIFRo aXMgbWVhbnMgdGhhdCB0aGVyZSB3aWxsIGJlIGEgbWluaW11bSBvZiB0d28gcXVldWVzIOKAlCBv bmUgcGh5c2ljYWwgaW4tcm9vbSBxdWV1ZSBhbmQgb25lIHZpcnR1YWwg4oCUIGFuZCB0aGUgY2hh aXIgKG9yIGRlbGVnYXRlKSB3aWxsIG5lZWQgdG8gbW92ZSBiYWNrIGFuZCBmb3J0aCBiZXR3ZWVu IHRoZSB0d28sIGdpdmluZyBwZW9wbGUgdHVybnMuIFdoZW4gc29tZW9uZSBpbiB0aGUgdmlydHVh bCBxdWV1ZSBoYXMNCiBhIHR1cm4sIE1lZXRlY2hvIHdpbGwgaW5qZWN0IHRoZWlyIGF1ZGlvIHRo ZSByb29tIHNvIHRoYXQgdGhleSBjYW4gc3BlYWsgZGlyZWN0bHkgdG8vd2l0aCBldmVyeW9uZSBp biB0aGUgYWN0dWFsIG1lZXRpbmcgcm9vbS48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMHB4 OyBwYWRkaW5nOiAwcHg7IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IiBjbGFzcz0iIj5XZSB3YW50 IHRvIGVuY291cmFnZSByZW1vdGUgcGFydGljaXBhdGlvbiBpbiB0aGUgbWVldGluZy4mbmJzcDs8 L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMHB4OyBwYWRkaW5nOiAwcHg7IGZvbnQtZmFtaWx5 OiBIZWx2ZXRpY2E7IiBjbGFzcz0iIj5BZnRlciB0aGUgbWVldGluZyB3ZSB3aWxsIHBvc3QgYSBz aG9ydCBzdXJ2ZXkgb24gaG93IHRoZSBleHBlcmltZW50IHdlbnQuJm5ic3A7PC9kaXY+DQo8ZGl2 IHN0eWxlPSJtYXJnaW46IDBweDsgcGFkZGluZzogMHB4OyBmb250LWZhbWlseTogSGVsdmV0aWNh OyIgY2xhc3M9IiI+T2xhZnVyIChmb3IgY2hhaXJzKSZuYnNwOzwvZGl2Pg0KPC9mb250Pl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyIGNsYXNzPSIiPg0K ZGFuZSBtYWlsaW5nIGxpc3Q8YnIgY2xhc3M9IiI+DQo8YSBocmVmPSJtYWlsdG86ZGFuZUBpZXRm Lm9yZyIgY2xhc3M9IiI+ZGFuZUBpZXRmLm9yZzwvYT48YnIgY2xhc3M9IiI+DQpodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RhbmU8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwv YmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYg YXBwbGUtY29udGVudC1lZGl0ZWQ9InRydWUiIGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0iZm9udC1m YW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsgYmFja2dyb3VuZC1j b2xvcjogcmdiKDI1NSwgMjU1LCAyNTUpOyIgY2xhc3M9IiI+DQotLTwvZGl2Pg0KPGRpdiBzdHls ZT0iZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsgYmFj a2dyb3VuZC1jb2xvcjogcmdiKDI1NSwgMjU1LCAyNTUpOyIgY2xhc3M9IiI+DQo8Zm9udCBmYWNl PSJDYWxpYnJpLHNhbnMtc2VyaWYiIGNsYXNzPSIiPkRhbiBZb3JrPC9mb250PjwvZGl2Pg0KPGRp diBzdHlsZT0iZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRw eDsgYmFja2dyb3VuZC1jb2xvcjogcmdiKDI1NSwgMjU1LCAyNTUpOyIgY2xhc3M9IiI+DQo8Zm9u dCBmYWNlPSJDYWxpYnJpLHNhbnMtc2VyaWYiIGNsYXNzPSIiPlNlbmlvciBDb250ZW50IFN0cmF0 ZWdpc3QsIEludGVybmV0IFNvY2lldHk8L2ZvbnQ+PC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZh bWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNHB4OyBiYWNrZ3JvdW5kLWNv bG9yOiByZ2IoMjU1LCAyNTUsIDI1NSk7IiBjbGFzcz0iIj4NCjxmb250IGZhY2U9IkNhbGlicmks c2Fucy1zZXJpZiIgY2xhc3M9IiI+PGEgaHJlZj0ibWFpbHRvOnlvcmtAaXNvYy5vcmciIGNsYXNz PSIiPnlvcmtAaXNvYy5vcmc8L2E+Jm5ic3A7Jm5ic3A7ICYjNDM7MS04MDItNzM1LTE2MjQ8L2Zv bnQ+PC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsg Zm9udC1zaXplOiAxNHB4OyBiYWNrZ3JvdW5kLWNvbG9yOiByZ2IoMjU1LCAyNTUsIDI1NSk7IiBj bGFzcz0iIj4NCjxmb250IGZhY2U9IkNhbGlicmksc2Fucy1zZXJpZiIgY2xhc3M9IiI+SmFiYmVy OiZuYnNwOzxhIGhyZWY9Im1haWx0bzp5b3JrQGphYmJlci5pc29jLm9yZyIgY2xhc3M9IiI+eW9y a0BqYWJiZXIuaXNvYy5vcmc8L2E+Jm5ic3A7PC9mb250PjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9u dC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsgYmFja2dyb3Vu ZC1jb2xvcjogcmdiKDI1NSwgMjU1LCAyNTUpOyIgY2xhc3M9IiI+DQo8Zm9udCBmYWNlPSJDYWxp YnJpLHNhbnMtc2VyaWYiIGNsYXNzPSIiPlNreXBlOiBkYW55b3JrICZuYnNwOyZuYnNwOzxhIGhy ZWY9Imh0dHA6Ly90d2l0dGVyLmNvbS9kYW55b3JrIiBjbGFzcz0iIj5odHRwOi8vdHdpdHRlci5j b20vZGFueW9yazwvYT48L2ZvbnQ+PC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTogQ2Fs aWJyaSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNHB4OyBiYWNrZ3JvdW5kLWNvbG9yOiByZ2Io MjU1LCAyNTUsIDI1NSk7IiBjbGFzcz0iIj4NCjxmb250IGZhY2U9IkNhbGlicmksc2Fucy1zZXJp ZiIgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9mb250PjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9u dC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsgYmFja2dyb3Vu ZC1jb2xvcjogcmdiKDI1NSwgMjU1LCAyNTUpOyIgY2xhc3M9IiI+DQo8Zm9udCBmYWNlPSJDYWxp YnJpLHNhbnMtc2VyaWYiIGNsYXNzPSIiPjxhIGhyZWY9Imh0dHA6Ly93d3cuaW50ZXJuZXRzb2Np ZXR5Lm9yZy9kZXBsb3kzNjAvIiBjbGFzcz0iIj5odHRwOi8vd3d3LmludGVybmV0c29jaWV0eS5v cmcvZGVwbG95MzYwLzwvYT4mbmJzcDs8L2ZvbnQ+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxmb250 IGZhY2U9IkNhbGlicmksc2Fucy1zZXJpZiIgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9mb250 PjwvZGl2Pg0KPC9kaXY+DQo8YnIgY2xhc3M9IkFwcGxlLWludGVyY2hhbmdlLW5ld2xpbmUiPg0K PC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_45B759CE7D264ED88611B8C2500FE5B3isocorg_-- From nobody Tue Mar 24 15:50: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 8C45D1A8F3B for ; Tue, 24 Mar 2015 15:50:19 -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 LsQfn0Yld4EC for ; Tue, 24 Mar 2015 15:50:17 -0700 (PDT) Received: from mail-oi0-f97.google.com (mail-oi0-f97.google.com [209.85.218.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8B391ACCEB for ; Tue, 24 Mar 2015 15:50:15 -0700 (PDT) Received: by oiav63 with SMTP id v63so231814oia.1 for ; Tue, 24 Mar 2015 15:50:15 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:thread-topic:thread-index :date:message-id:accept-language:content-language:content-type :mime-version; bh=WvLmlCEz442C8HctT98EcaJ4Q6zS0kzoFpXd4U+w2zo=; b=PwqggkqqbpqMUR4b1cZprbHHSUxkkuDtBp2l0c/tc6mlPv61IWG/g7ySMBmNzPLVsk /GhHqdrin2NdgHzOYnSRapXnwFshLLFlhqH52eEgbHY78+GyywOP040smyEWsAQZd2Ms FXZxcbbBB7nvyFefec5dFBkJh3Z3rU+4KDBaYYll/8fWShfx8L/ek0wC/t31/3F6t8v3 GN+GHngqY/YTq3bcJ7Zcy/frgzlmzjGi1L/pDxfCRiWteltOHJElJl9OmZrVbWnaFbEO DYB1FglJ0/wc26pgVbr7sGVAs31Hr1paid+TTwRJIALCicyJHmle/CPxSFBfhI6asgY4 ZNSg== X-Gm-Message-State: ALoCoQklRr6d6lvrZbeVqcBV+glJxf+bRxR/Po8a8tWzdCZLwfhGonk6EP47/xHzODjp39RpfBiYT5ocg2C8Ef6q4CsA6k9iUQ== X-Received: by 10.140.81.74 with SMTP id e68mr8230971qgd.41.1427237415225; Tue, 24 Mar 2015 15:50:15 -0700 (PDT) Received: from brn1lxmailout02.verisign.com (brn1lxmailout02.verisign.com. [72.13.63.42]) by mx.google.com with ESMTPS id cd6sm156979qcb.2.2015.03.24.15.50.14 (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 24 Mar 2015 15:50:15 -0700 (PDT) X-Relaying-Domain: verisign.com Received: from brn1wnexcas02.vcorp.ad.vrsn.com (brn1wnexcas02 [10.173.152.206]) by brn1lxmailout02.verisign.com (8.13.8/8.13.8) with ESMTP id t2OMoB5h018091 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 24 Mar 2015 18:50:12 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas02.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Tue, 24 Mar 2015 18:50:11 -0400 From: "Osterweil, Eric" To: dane WG list Thread-Topic: IPSECA Thread-Index: AQHQZoTinYEJkFr5c0a1jug9i2S9ww== Date: Tue, 24 Mar 2015 22:50:11 +0000 Message-ID: <9735F7C2-D87A-4A33-9302-49C54A644EDA@verisign.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: multipart/signed; boundary="Apple-Mail=_5E460BA1-08DE-418C-94D5-EDA6E964C97D"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Archived-At: Subject: [dane] IPSECA X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 24 Mar 2015 22:50:19 -0000 --Apple-Mail=_5E460BA1-08DE-418C-94D5-EDA6E964C97D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hey Chairs & WG folk, Given the discussion on milestones re: IPSEC DANE work at the beginning = of the DANE session today we=92d like to request working group adoption = of the existing IPSECA document: https://tools.ietf.org/html/draft-osterweil-dane-ipsec-02 We=92ve been working on a couple of different flavors of implementation. = We=92re hoping to push those out soon too and it=92s already benefited = from a great deal of discussion here, and we believe it=92s definitely = ready to become a WG product. Can the chairs please progress as appropriate? Thanks, Eric= --Apple-Mail=_5E460BA1-08DE-418C-94D5-EDA6E964C97D Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIN7DCCBmAw ggVIoAMCAQICEHaFyweo4MwP0sVNjzk1sxIwDQYJKoZIhvcNAQEFBQAwgcoxCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0aG9yaXplZCB1c2Ug b25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMiBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0 aW9uIEF1dGhvcml0eSAtIEczMB4XDTExMDYwNzAwMDAwMFoXDTIxMDYwNjIzNTk1OVowgckxCzAJ BgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50 ZWMgVHJ1c3QgTmV0d29yazE1MDMGA1UECxMsQ2xhc3MgMiBNYW5hZ2VkIFBLSSBJbmRpdmlkdWFs IFN1YnNjcmliZXIgQ0ExQzBBBgNVBAMTOlN5bWFudGVjIENsYXNzIDIgU2hhcmVkIEludGVybWVk aWF0ZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQC3+D8MK4MjIIWmTUkBUTra3VAzvuMEpDo+o2FmTDTC6HRwdUmlt0ns3bOSnN15DeK5+rg5PL6F 44zvbXmjprcIv5xMvj6YjqzbfJor7AUoMF8pGzNNRNVw6FYimaY+nUJb6yOnY50tLLAuPxjzKc0a NomEksdXcFtwheY4oXxQ4zc4iGVba8s5KgSxgqoZBP+gfz+j25FFdmaja/OFI15O2YVddaegFffB AHTg5cqUQmWawjd6i6hQrL+XdGd30TKnr43Lk6klQrQwGnQK4iUQEMt0Z1UPyxT8QVAKpHxNCwv5 Bak1+UWnMfGAu6LJPs52OeEq/3ZQ5+hRIt8tz7gzAgMBAAGjggI/MIICOzASBgNVHRMBAf8ECDAG AQH/AgEAMDQGA1UdHwQtMCswKaAnoCWGI2h0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTItZzMu Y3JsMA4GA1UdDwEB/wQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRVmVyaVNpZ25NUEtJ LTItNTYwHQYDVR0OBBYEFNhIKahfKheS4vqee+9vYIP4uLjcMIHwBgNVHSMEgegwgeWhgdCkgc0w gcoxCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4gLSBGb3Ig YXV0aG9yaXplZCB1c2Ugb25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMiBQdWJsaWMgUHJp bWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEczghBhcMtJjF+YRSnnsKbZUFt6MDQGCCsG AQUFBwEBBCgwJjAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AudmVyaXNpZ24uY29tMGwGA1UdIARl MGMwYQYLYIZIAYb4RQEHFwIwUjAmBggrBgEFBQcCARYaaHR0cDovL3d3dy5zeW1hdXRoLmNvbS9j cHMwKAYIKwYBBQUHAgIwHBoaaHR0cDovL3d3dy5zeW1hdXRoLmNvbS9ycGEwDQYJKoZIhvcNAQEF BQADggEBAKYqmwdAyez/s4joRdo00RcPKC23pYVnMc3B5tUphjis4vBZGwzhoUXOJHjvacGwTGGi SNloT7r+dVQ3ulhp6sF2pTZC6p5meJAg2ZVqJHlUzd5aGoo7rhiVctAl2NJGvjQwp4Ce8VbOIB5s Z8lNT3mHieIugNae7SZhZaID0MXi8yi5K0lpgmfs1ek0pC7cYiKkhU1I42oClPLN/eRnyEm8qtXH 5zzeh7EQa10HXBnka6D0T5nL3LVbDMwy+WrkdMAqWDd5s/vNwzRv4XbdEAcAY4sHTicXkkebDr7e DROFEfyiL2V9zDqsHlRrVmfE7qWHIiMXK3BWw/Gud1wnwTkwggeEMIIGbKADAgECAhBcCMgDVFpl hwRR0TZyMUgoMA0GCSqGSIb3DQEBBQUAMIHJMQswCQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50 ZWMgQ29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdvcmsxNTAzBgNVBAsT LENsYXNzIDIgTWFuYWdlZCBQS0kgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBMUMwQQYDVQQDEzpT eW1hbnRlYyBDbGFzcyAyIFNoYXJlZCBJbnRlcm1lZGlhdGUgQ2VydGlmaWNhdGUgQXV0aG9yaXR5 MB4XDTE0MDQxMDAwMDAwMFoXDTE1MDQxMDIzNTk1OVowczEmMCQGCSqGSIb3DQEJARYXZW9zdGVy d2VpbEB2ZXJpc2lnbi5jb20xGDAWBgNVBAMMD09zdGVyd2VpbCwgRXJpYzEWMBQGA1UECwwNRU5U RVJQUklTRSBJVDEXMBUGA1UECgwOVmVyaVNpZ24sIEluYy4wggEiMA0GCSqGSIb3DQEBAQUAA4IB DwAwggEKAoIBAQCmK2/yLaprGu39usXztz6N7uLYDoKN4MNaDFGGj1eYfMkIfb6LDoYBs9qcnINg 8in4NxGwVQGIJU5AE/1wHe/V1qavpHEO2mVxRq94cBF0P8ETPpM1yhwBhU4QKhjNEDj9wov8RXzO hjqPy/uknZvBxfobQx22vhnEKpf7QEN0zfLDJON3tyYwsnrFZkmop4ni4ANI7ev5uqcI05ED7vSh K9AHAVjzjr2QvtmvqHAkOnpHgqkWJWhuw4f9Gx+8LmbC3tl8oxF7+E7WEwKTQG56BV0uR6PN/o0S O7VSbDCZyNoxxrjzw+CesWsigi2NvC5DnhkKlxP+JSfJxMDu+7MDAgMBAAGjggO7MIIDtzAMBgNV HRMBAf8EAjAAMA4GA1UdDwEB/wQEAwIFoDAWBgNVHSUBAf8EDDAKBggrBgEFBQcDBDAdBgNVHQ4E FgQUVoVKaC1xEPB9EWKq3dWrwskIufkwUAYDVR0RBEkwR4EXZW9zdGVyd2VpbEB2ZXJpc2lnbi5j b22gLAYKKwYBBAGCNxQCA6AeDBxlb3N0ZXJ3ZWlsQHZjb3JwLmFkLnZyc24uY29tMB8GA1UdIwQY MBaAFNhIKahfKheS4vqee+9vYIP4uLjcMIIBcQYIKwYBBQUHAQEEggFjMIIBXzAnBggrBgEFBQcw AYYbaHR0cDovL3BraS1vY3NwLnN5bWF1dGguY29tMIIBMgYIKwYBBQUHMAKGggEkbGRhcDovL2Rp cmVjdG9yeS52ZXJpc2lnbi5jb20vQ04lMjAlM0QlMjBTeW1hbnRlYyUyMENsYXNzJTIwMiUyMFNo YXJlZCUyMEludGVybWVkaWF0ZSUyMENlcnRpZmljYXRlJTIwQXV0aG9yaXR5JTJDT1UlMjAlM0Ql MjBDbGFzcyUyMDIlMjBNYW5hZ2VkJTIwUEtJJTIwSW5kaXZpZHVhbCUyMFN1YnNjcmliZXIlMjBD QSUyQ09VJTIwJTNEJTIwU3ltYW50ZWMlMjBUcnVzdCUyME5ldHdvcmslMkNPJTIwJTNEJTIwU3lt YW50ZWMlMjBDb3Jwb3JhdGlvbiUyQ0MlMjAlM0QlMjBVUz9jQUNlcnRpZmljYXRlO2JpbmFyeTBd BgNVHR8EVjBUMFKgUKBOhkxodHRwOi8vcGtpLWNybC5zeW1hdXRoLmNvbS9jYV8wN2JiN2Q2NDc3 Y2Y0ZjZiZTk2YWYxYjM2Y2FiZDMxNi9MYXRlc3RDUkwuY3JsMGwGA1UdIARlMGMwYQYLYIZIAYb4 RQEHFwIwUjAmBggrBgEFBQcCARYaaHR0cDovL3d3dy5zeW1hdXRoLmNvbS9jcHMwKAYIKwYBBQUH AgIwHBoaaHR0cDovL3d3dy5zeW1hdXRoLmNvbS9ycGEwQgYJKoZIhvcNAQkPBDUwMzAKBggqhkiG 9w0DBzALBglghkgBZQMEAQIwCwYJYIZIAWUDBAEWMAsGCWCGSAFlAwQBKjAsBgpghkgBhvhFARAD BB4wHAYSYIZIAYb4RQEQAQICAQGL8cYJFgYyNDc2NjQwOQYKYIZIAYb4RQEQBQQrMCkCAQAWJGFI UjBjSE02THk5d2Eya3RjbUV1YzNsdFlYVjBhQzVqYjIwPTANBgkqhkiG9w0BAQUFAAOCAQEAXFTS ZEP9la6QYPlo6ybMEEpxVOADx082WRGtrYoU9ZEaC2IlxmwI9JprNfBlIy8FtyJAuWKBbe9/XKJF cukb2HNS0httHUIcSTfMEsAyc99/ba/SoMlhtvko/nCvx5brzhpQwop6AgMv9v5V7F1GUFO7db8L LSs1gIZYI8IeudznJOQGUBFGe0aJhA4cD/3OIZyItWpNtn94i1GJUFPMjYhGcy/r0fUQY/KFLwOi M6bT/m1RwAJKJI/mON/OshdzylAYqKOPoFTJD4qrbrpij1r1+e1VHKklAxTd+nOg9J1L0yRwlEDS 1boeOxqNXGnEYAa54k0ZWPh+8dFemteaLjGCBE0wggRJAgEBMIHeMIHJMQswCQYDVQQGEwJVUzEd MBsGA1UEChMUU3ltYW50ZWMgQ29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5l dHdvcmsxNTAzBgNVBAsTLENsYXNzIDIgTWFuYWdlZCBQS0kgSW5kaXZpZHVhbCBTdWJzY3JpYmVy IENBMUMwQQYDVQQDEzpTeW1hbnRlYyBDbGFzcyAyIFNoYXJlZCBJbnRlcm1lZGlhdGUgQ2VydGlm aWNhdGUgQXV0aG9yaXR5AhBcCMgDVFplhwRR0TZyMUgoMAkGBSsOAwIaBQCgggJDMBgGCSqGSIb3 DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1MDMyNDIyNTAxMFowIwYJKoZIhvcN AQkEMRYEFCThQckWWq9q2GFRkY2MGxeJ2Mn6MIHvBgkrBgEEAYI3EAQxgeEwgd4wgckxCzAJBgNV BAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50ZWMg VHJ1c3QgTmV0d29yazE1MDMGA1UECxMsQ2xhc3MgMiBNYW5hZ2VkIFBLSSBJbmRpdmlkdWFsIFN1 YnNjcmliZXIgQ0ExQzBBBgNVBAMTOlN5bWFudGVjIENsYXNzIDIgU2hhcmVkIEludGVybWVkaWF0 ZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkCEFwIyANUWmWHBFHRNnIxSCgwgfEGCyqGSIb3DQEJEAIL MYHhoIHeMIHJMQswCQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMgQ29ycG9yYXRpb24xHzAd BgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdvcmsxNTAzBgNVBAsTLENsYXNzIDIgTWFuYWdlZCBQ S0kgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBMUMwQQYDVQQDEzpTeW1hbnRlYyBDbGFzcyAyIFNo YXJlZCBJbnRlcm1lZGlhdGUgQ2VydGlmaWNhdGUgQXV0aG9yaXR5AhBcCMgDVFplhwRR0TZyMUgo MA0GCSqGSIb3DQEBAQUABIIBAHzRTM9U2nOUq9b9vrLL167YQLDne733qeEmE87jRyjr1fjIuyxN CUvIko0ONoEW7VjRTD8vZm6MnA2dgJ1Tdp3Oja0IhRiyXPDhsDUxp7KdY/14gKjFpxfPmGA0Nbo4 lv2ibE13js73U4Soyq7T9XzUbSd4YRooLv4gDVzp+xFZEeBXQWwEM8SvLejVqsHv6QwyN/yP+uCO mjylePvL/P1cze9+Wgp/zDWWUJAwZ0e8JTWVGw7qA7XOa0mm9RT2WnMgyk1SE2z7OPCT3utmTve6 QIac9lQtl+1aFhy6hjJ6V1nctPVi5VRTv4+OVecW+DbMw1O1T0nlZX4fmGwT9qEAAAAAAAA= --Apple-Mail=_5E460BA1-08DE-418C-94D5-EDA6E964C97D-- From nobody Wed Mar 25 08:32: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 926791B2A15 for ; Wed, 25 Mar 2015 08:32:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6icamH8Oa-5E for ; Wed, 25 Mar 2015 08:32:22 -0700 (PDT) Received: from mango.plexis.eu (mango.plexis.eu [IPv6:2a01:7c8:aaae:3e2::1]) by ietfa.amsl.com (Postfix) with ESMTP id 062DC1A87BB for ; Wed, 25 Mar 2015 08:32:06 -0700 (PDT) Received: from aardbei.mobile.plexis.eu (HSI-KBW-46-237-220-35.hsi.kabel-badenwuerttemberg.de [46.237.220.35]) by mango.plexis.eu (Postfix) with ESMTPSA id 8EC9412D for ; Wed, 25 Mar 2015 16:32:03 +0100 (CET) Message-ID: <5512D4F3.70803@powerdns.com> Date: Wed, 25 Mar 2015 16:32:03 +0100 From: Pieter Lexis Organization: PowerDNS User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: dane@ietf.org Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [dane] A novel idea on the local-part problem for both SMIMEA and 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: Wed, 25 Mar 2015 15:32:25 -0000 Hi WG, This whole local-part problem (aliases, folding and authority) has been nagging in the back of my head the last couple of days. And I realized this might be an issue that shouldn't be solved on the DNS-side of things. Even though the DNS is a very nice, sturdy and fast protcol, I feel it is not flexible (enough) for the things we are trying to do with it. We've not reached the limit of the protocol, but what we're trying to do feels like a hack. The local part issues we're running into are essentially part of a larger discovery problem that should not be solved in the DNS. Now, the IETF has standardized a mechanism to do discovery like this in the form of webfinger, RFC7033[1]. This would allow an MTA/MUA to lookup the full recipient address (in the format given by the end user) at the webfinger server of that domain. This server could do the casefolding/aliasing using the defined 'aliases' field in the response body. This allows also for easy expansion of e.g. the user+tag@example.com addresses, as webfinger can return the canonical address (user@example.com in this case) as the 'subject' in the response body (see section 4.4.1 of RFC7033). Webfinger also allows 'properties' to be set in the response body, allowing it to send the public key in the response. Webfinger is standardized to use HTTPS only, we could further strengthen this by requiring a TLSA record for the host the MTA/MUA is connection to. Using Webfinger has several advantages and disadvantages, off the top of my head: Advantages: - No hashing involved - Usage of existing technology (and providing a use-case for it) - Administration of both SMIMEA and OPENPGPKEY information can still be done by different entities within an organisation - No weird shoe-horning things into DNS - Casefolding can be resolved by the receiving end in a dynamic fashion Disadvantages: - MTAs will need to talk HTTPS - It's not DANE (more like 'DNS-Assisted') - It kind-of defeats the purpose of this WG - No NSEC3-like protection from address leakage (see sections 9.2 and 9.3 of RFC7033) I assume there'll be a lot of comments on this, what are your ideas about this? Best regards, Pieter Lexis 1 - https://tools.ietf.org/html/rfc7033 From nobody Wed Mar 25 08:43: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 2F3371B2A77 for ; Wed, 25 Mar 2015 08:43:52 -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 YLu_FJaf95rU for ; Wed, 25 Mar 2015 08:43:50 -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 8414C1B2A69 for ; Wed, 25 Mar 2015 08:43:50 -0700 (PDT) Received: by ore.jhcloos.com (Postfix, from userid 10) id 456321EC3B; Wed, 25 Mar 2015 15:43:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=ore14; t=1427298230; bh=Ijcp/H1F4Z1jenzXC2upzgUnqPbK6joFaeHCGTgeeKE=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=VsuawG1ArfDhP4OH3juMQ1TKXjwxL4aNeeLoTxWkoKpGEVXZ9LsxSLST8Q0QC+Hzw /088JeK3DGhlyYixCeCgMDygQIitVYa3/E55IKpSfqHtOc1pGRH85Awc07PZwedFXp cLgEXada5zkD4PkVZz5HdcyiSyV0isWS60ini5bw= Received: by carbon.jhcloos.org (Postfix, from userid 500) id 46852106FC0A0; Wed, 25 Mar 2015 15:40:13 +0000 (UTC) From: James Cloos To: dane WG list In-Reply-To: <9735F7C2-D87A-4A33-9302-49C54A644EDA@verisign.com> (Eric Osterweil's message of "Tue, 24 Mar 2015 22:50:11 +0000") References: <9735F7C2-D87A-4A33-9302-49C54A644EDA@verisign.com> User-Agent: Gnus/5.130012 (Ma Gnus v0.12) Emacs/25.0.50 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC Copyright: Copyright 2015 James Cloos OpenPGP: 0x997A9F17ED7DAEA6; url=https://jhcloos.com/public_key/0x997A9F17ED7DAEA6.asc OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B 63E7 997A 9F17 ED7D AEA6 Date: Wed, 25 Mar 2015 11:40:13 -0400 Message-ID: Lines: 17 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Hashcash: 1:28:150325:dane@ietf.org::zMgCwW5l9kkZZQu1:000JmFGa X-Hashcash: 1:28:150325:eosterweil@verisign.com::whzzVBQyZ+swvXgl:0000000000000000000000000000000000000/3apD Archived-At: Subject: Re: [dane] IPSECA X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 25 Mar 2015 15:43:52 -0000 I support the wg adopting this draft. It needs a bit of work and discussion; such work is relevant here and worth doing. In §2.1.2 it has what looks like a copy-paste error, where it labels Selector 2 as DANE-TA, whereas in both rfc 6698 and the acronyms draft that is unassigned. The IPSECA record here is identical to a TLSA except only in name. If it does not need anything more than TLSA offers, why not just use TLSA? (Even if the answer is that that is the only way to signal ipsec vs tls, it needs discussion.) -JimC -- James Cloos OpenPGP: 0x997A9F17ED7DAEA6 From nobody Wed Mar 25 08:56: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 08D651A87B1 for ; Wed, 25 Mar 2015 08:56:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DG9F3yQUL1xH for ; Wed, 25 Mar 2015 08:55:58 -0700 (PDT) Received: from mail-qg0-f99.google.com (mail-qg0-f99.google.com [209.85.192.99]) (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 BE5B21A87E3 for ; Wed, 25 Mar 2015 08:55:57 -0700 (PDT) Received: by qgea108 with SMTP id a108so722315qge.3 for ; Wed, 25 Mar 2015 08:55:57 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:thread-topic:thread-index :date:message-id:references:in-reply-to:accept-language :content-language:content-type:mime-version; bh=XSTB0+FEVwq9AzzwVqdGsjM8NTiFHufSvMWzRtU3x/c=; b=K585PeZbNiJ8iOWeO+id53zdsS0ST9NIlZ6kaYK9EqpabM4RFIPNj0LnjkVlxu0ZzQ y/2udz68boLzKD6DD5X7u4B+Ocl7XlK29YgiYTC9Dj6IO8vimMEr6v58JI5o1gdQdZfj CMoTiFg10ozZDM9zW87gWIgahagQe8rXnrZLaTi2iGedCInBk5g2E4IA7qKTpPCt/lQf kOcYWQ/mBpVGtI63n6rlYSg6JNEsw2CoxqxGu6kjTlBySDw6xlYLp+Zw5bZrS4YOiUi3 w7zaA1Fyx4BU6W9Yqo8JLukBoQITRaM+q0R366EsA/HHvLHQGbkn4OjW7bZDHU98T5vT E0Yg== X-Gm-Message-State: ALoCoQlOMhbhr/XRZ5DcJ8lpvuXOYfoINsA95cW+Mhar99mkML9jFRk46Asl26fbHO9XVSL3GQzTs6jwlgouxQG/JD7ft96hWQ== X-Received: by 10.55.26.209 with SMTP id l78mr19922540qkh.60.1427298956947; Wed, 25 Mar 2015 08:55:56 -0700 (PDT) Received: from brn1lxmailout02.verisign.com (brn1lxmailout02.verisign.com. [72.13.63.42]) by mx.google.com with ESMTPS id gt4sm602714qcb.3.2015.03.25.08.55.56 (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 25 Mar 2015 08:55:56 -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 t2PFtupE005462 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 25 Mar 2015 11:55:56 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Wed, 25 Mar 2015 11:55:56 -0400 From: "Osterweil, Eric" To: James Cloos Thread-Topic: [dane] IPSECA Thread-Index: AQHQZoTinYEJkFr5c0a1jug9i2S9w50tV/iHgABGVwA= Date: Wed, 25 Mar 2015 15:55:56 +0000 Message-ID: <467C27BF-19FD-4409-A44E-C9A9652B024C@verisign.com> References: <9735F7C2-D87A-4A33-9302-49C54A644EDA@verisign.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: multipart/signed; boundary="Apple-Mail=_44C5B2BF-1D67-422A-8B7C-620BDE0C21ED"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Archived-At: Cc: dane WG list Subject: Re: [dane] IPSECA X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 25 Mar 2015 15:56:00 -0000 --Apple-Mail=_44C5B2BF-1D67-422A-8B7C-620BDE0C21ED Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Mar 25, 2015, at 10:40 AM, James Cloos wrote: > I support the wg adopting this draft. >=20 > It needs a bit of work and discussion; such work is relevant here and > worth doing. >=20 > In =A72.1.2 it has what looks like a copy-paste error, where it labels > Selector 2 as DANE-TA, whereas in both rfc 6698 and the acronyms draft > that is unassigned. Oops. . . Fixing it. > The IPSECA record here is identical to a TLSA except only in name. > If it does not need anything more than TLSA offers, why not just use > TLSA? (Even if the answer is that that is the only way to signal = ipsec > vs tls, it needs discussion.) My 0.02 is that having different record types for different protocols = gives us very useful flexibility (both if the RRs may need to evolve, = and during DNS resolution). It is, on the other hand, interesting that = the IPSECA looks this way. It was from wg feedback that we pulled the = gateway information out (which the IPSECKEY RR has). There seemed to be = a potential MitM attack vector in there. Regardless, I think we want to = follow the wg=92s direction on these issues. Thanks for the feedback! Eric= --Apple-Mail=_44C5B2BF-1D67-422A-8B7C-620BDE0C21ED Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIN7DCCBmAw ggVIoAMCAQICEHaFyweo4MwP0sVNjzk1sxIwDQYJKoZIhvcNAQEFBQAwgcoxCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0aG9yaXplZCB1c2Ug b25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMiBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0 aW9uIEF1dGhvcml0eSAtIEczMB4XDTExMDYwNzAwMDAwMFoXDTIxMDYwNjIzNTk1OVowgckxCzAJ BgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50 ZWMgVHJ1c3QgTmV0d29yazE1MDMGA1UECxMsQ2xhc3MgMiBNYW5hZ2VkIFBLSSBJbmRpdmlkdWFs IFN1YnNjcmliZXIgQ0ExQzBBBgNVBAMTOlN5bWFudGVjIENsYXNzIDIgU2hhcmVkIEludGVybWVk aWF0ZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQC3+D8MK4MjIIWmTUkBUTra3VAzvuMEpDo+o2FmTDTC6HRwdUmlt0ns3bOSnN15DeK5+rg5PL6F 44zvbXmjprcIv5xMvj6YjqzbfJor7AUoMF8pGzNNRNVw6FYimaY+nUJb6yOnY50tLLAuPxjzKc0a NomEksdXcFtwheY4oXxQ4zc4iGVba8s5KgSxgqoZBP+gfz+j25FFdmaja/OFI15O2YVddaegFffB AHTg5cqUQmWawjd6i6hQrL+XdGd30TKnr43Lk6klQrQwGnQK4iUQEMt0Z1UPyxT8QVAKpHxNCwv5 Bak1+UWnMfGAu6LJPs52OeEq/3ZQ5+hRIt8tz7gzAgMBAAGjggI/MIICOzASBgNVHRMBAf8ECDAG AQH/AgEAMDQGA1UdHwQtMCswKaAnoCWGI2h0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTItZzMu Y3JsMA4GA1UdDwEB/wQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRVmVyaVNpZ25NUEtJ LTItNTYwHQYDVR0OBBYEFNhIKahfKheS4vqee+9vYIP4uLjcMIHwBgNVHSMEgegwgeWhgdCkgc0w gcoxCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4gLSBGb3Ig YXV0aG9yaXplZCB1c2Ugb25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMiBQdWJsaWMgUHJp bWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEczghBhcMtJjF+YRSnnsKbZUFt6MDQGCCsG AQUFBwEBBCgwJjAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AudmVyaXNpZ24uY29tMGwGA1UdIARl MGMwYQYLYIZIAYb4RQEHFwIwUjAmBggrBgEFBQcCARYaaHR0cDovL3d3dy5zeW1hdXRoLmNvbS9j cHMwKAYIKwYBBQUHAgIwHBoaaHR0cDovL3d3dy5zeW1hdXRoLmNvbS9ycGEwDQYJKoZIhvcNAQEF BQADggEBAKYqmwdAyez/s4joRdo00RcPKC23pYVnMc3B5tUphjis4vBZGwzhoUXOJHjvacGwTGGi SNloT7r+dVQ3ulhp6sF2pTZC6p5meJAg2ZVqJHlUzd5aGoo7rhiVctAl2NJGvjQwp4Ce8VbOIB5s Z8lNT3mHieIugNae7SZhZaID0MXi8yi5K0lpgmfs1ek0pC7cYiKkhU1I42oClPLN/eRnyEm8qtXH 5zzeh7EQa10HXBnka6D0T5nL3LVbDMwy+WrkdMAqWDd5s/vNwzRv4XbdEAcAY4sHTicXkkebDr7e DROFEfyiL2V9zDqsHlRrVmfE7qWHIiMXK3BWw/Gud1wnwTkwggeEMIIGbKADAgECAhBcCMgDVFpl hwRR0TZyMUgoMA0GCSqGSIb3DQEBBQUAMIHJMQswCQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50 ZWMgQ29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdvcmsxNTAzBgNVBAsT LENsYXNzIDIgTWFuYWdlZCBQS0kgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBMUMwQQYDVQQDEzpT eW1hbnRlYyBDbGFzcyAyIFNoYXJlZCBJbnRlcm1lZGlhdGUgQ2VydGlmaWNhdGUgQXV0aG9yaXR5 MB4XDTE0MDQxMDAwMDAwMFoXDTE1MDQxMDIzNTk1OVowczEmMCQGCSqGSIb3DQEJARYXZW9zdGVy d2VpbEB2ZXJpc2lnbi5jb20xGDAWBgNVBAMMD09zdGVyd2VpbCwgRXJpYzEWMBQGA1UECwwNRU5U RVJQUklTRSBJVDEXMBUGA1UECgwOVmVyaVNpZ24sIEluYy4wggEiMA0GCSqGSIb3DQEBAQUAA4IB DwAwggEKAoIBAQCmK2/yLaprGu39usXztz6N7uLYDoKN4MNaDFGGj1eYfMkIfb6LDoYBs9qcnINg 8in4NxGwVQGIJU5AE/1wHe/V1qavpHEO2mVxRq94cBF0P8ETPpM1yhwBhU4QKhjNEDj9wov8RXzO hjqPy/uknZvBxfobQx22vhnEKpf7QEN0zfLDJON3tyYwsnrFZkmop4ni4ANI7ev5uqcI05ED7vSh K9AHAVjzjr2QvtmvqHAkOnpHgqkWJWhuw4f9Gx+8LmbC3tl8oxF7+E7WEwKTQG56BV0uR6PN/o0S O7VSbDCZyNoxxrjzw+CesWsigi2NvC5DnhkKlxP+JSfJxMDu+7MDAgMBAAGjggO7MIIDtzAMBgNV HRMBAf8EAjAAMA4GA1UdDwEB/wQEAwIFoDAWBgNVHSUBAf8EDDAKBggrBgEFBQcDBDAdBgNVHQ4E FgQUVoVKaC1xEPB9EWKq3dWrwskIufkwUAYDVR0RBEkwR4EXZW9zdGVyd2VpbEB2ZXJpc2lnbi5j b22gLAYKKwYBBAGCNxQCA6AeDBxlb3N0ZXJ3ZWlsQHZjb3JwLmFkLnZyc24uY29tMB8GA1UdIwQY MBaAFNhIKahfKheS4vqee+9vYIP4uLjcMIIBcQYIKwYBBQUHAQEEggFjMIIBXzAnBggrBgEFBQcw AYYbaHR0cDovL3BraS1vY3NwLnN5bWF1dGguY29tMIIBMgYIKwYBBQUHMAKGggEkbGRhcDovL2Rp cmVjdG9yeS52ZXJpc2lnbi5jb20vQ04lMjAlM0QlMjBTeW1hbnRlYyUyMENsYXNzJTIwMiUyMFNo YXJlZCUyMEludGVybWVkaWF0ZSUyMENlcnRpZmljYXRlJTIwQXV0aG9yaXR5JTJDT1UlMjAlM0Ql MjBDbGFzcyUyMDIlMjBNYW5hZ2VkJTIwUEtJJTIwSW5kaXZpZHVhbCUyMFN1YnNjcmliZXIlMjBD QSUyQ09VJTIwJTNEJTIwU3ltYW50ZWMlMjBUcnVzdCUyME5ldHdvcmslMkNPJTIwJTNEJTIwU3lt YW50ZWMlMjBDb3Jwb3JhdGlvbiUyQ0MlMjAlM0QlMjBVUz9jQUNlcnRpZmljYXRlO2JpbmFyeTBd BgNVHR8EVjBUMFKgUKBOhkxodHRwOi8vcGtpLWNybC5zeW1hdXRoLmNvbS9jYV8wN2JiN2Q2NDc3 Y2Y0ZjZiZTk2YWYxYjM2Y2FiZDMxNi9MYXRlc3RDUkwuY3JsMGwGA1UdIARlMGMwYQYLYIZIAYb4 RQEHFwIwUjAmBggrBgEFBQcCARYaaHR0cDovL3d3dy5zeW1hdXRoLmNvbS9jcHMwKAYIKwYBBQUH AgIwHBoaaHR0cDovL3d3dy5zeW1hdXRoLmNvbS9ycGEwQgYJKoZIhvcNAQkPBDUwMzAKBggqhkiG 9w0DBzALBglghkgBZQMEAQIwCwYJYIZIAWUDBAEWMAsGCWCGSAFlAwQBKjAsBgpghkgBhvhFARAD BB4wHAYSYIZIAYb4RQEQAQICAQGL8cYJFgYyNDc2NjQwOQYKYIZIAYb4RQEQBQQrMCkCAQAWJGFI UjBjSE02THk5d2Eya3RjbUV1YzNsdFlYVjBhQzVqYjIwPTANBgkqhkiG9w0BAQUFAAOCAQEAXFTS ZEP9la6QYPlo6ybMEEpxVOADx082WRGtrYoU9ZEaC2IlxmwI9JprNfBlIy8FtyJAuWKBbe9/XKJF cukb2HNS0httHUIcSTfMEsAyc99/ba/SoMlhtvko/nCvx5brzhpQwop6AgMv9v5V7F1GUFO7db8L LSs1gIZYI8IeudznJOQGUBFGe0aJhA4cD/3OIZyItWpNtn94i1GJUFPMjYhGcy/r0fUQY/KFLwOi M6bT/m1RwAJKJI/mON/OshdzylAYqKOPoFTJD4qrbrpij1r1+e1VHKklAxTd+nOg9J1L0yRwlEDS 1boeOxqNXGnEYAa54k0ZWPh+8dFemteaLjGCBE0wggRJAgEBMIHeMIHJMQswCQYDVQQGEwJVUzEd MBsGA1UEChMUU3ltYW50ZWMgQ29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5l dHdvcmsxNTAzBgNVBAsTLENsYXNzIDIgTWFuYWdlZCBQS0kgSW5kaXZpZHVhbCBTdWJzY3JpYmVy IENBMUMwQQYDVQQDEzpTeW1hbnRlYyBDbGFzcyAyIFNoYXJlZCBJbnRlcm1lZGlhdGUgQ2VydGlm aWNhdGUgQXV0aG9yaXR5AhBcCMgDVFplhwRR0TZyMUgoMAkGBSsOAwIaBQCgggJDMBgGCSqGSIb3 DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1MDMyNTE1NTU0MlowIwYJKoZIhvcN AQkEMRYEFM8PBxnJed0MdlUnT7YX+Fuikr/9MIHvBgkrBgEEAYI3EAQxgeEwgd4wgckxCzAJBgNV BAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50ZWMg VHJ1c3QgTmV0d29yazE1MDMGA1UECxMsQ2xhc3MgMiBNYW5hZ2VkIFBLSSBJbmRpdmlkdWFsIFN1 YnNjcmliZXIgQ0ExQzBBBgNVBAMTOlN5bWFudGVjIENsYXNzIDIgU2hhcmVkIEludGVybWVkaWF0 ZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkCEFwIyANUWmWHBFHRNnIxSCgwgfEGCyqGSIb3DQEJEAIL MYHhoIHeMIHJMQswCQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMgQ29ycG9yYXRpb24xHzAd BgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdvcmsxNTAzBgNVBAsTLENsYXNzIDIgTWFuYWdlZCBQ S0kgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBMUMwQQYDVQQDEzpTeW1hbnRlYyBDbGFzcyAyIFNo YXJlZCBJbnRlcm1lZGlhdGUgQ2VydGlmaWNhdGUgQXV0aG9yaXR5AhBcCMgDVFplhwRR0TZyMUgo MA0GCSqGSIb3DQEBAQUABIIBADZodGOuARlU6Y/QP8U/ckiV5JetQoPEDLRoabdNLf4veZ6iWyss wC5ttgWJW+iV+w5Ic1j+2mq6G1PZeQhtJFgffg1Eir81QpkhL6VY8Zs4bY/8dgD73fVmjllqqXcm tMiTK+H7CmdKh85L5V65Dwamx2DsGrPjd9/OkH+eUxl/Uof46fYG6exwkZeQRCViIFq8h6xNWrMP Kb2SFxcIr8IP64edwflMKOA6y93mqFnLkskDgTEAAvtK8MKFxWqPWnkK5SuAVBC8Yq9MvTPjKD+I oPXjasIpLKxeQ16o1yMojzU31ouPH8V4hK/SgKgmRAWYTXkMpOadzj4gp1ZDTesAAAAAAAA= --Apple-Mail=_44C5B2BF-1D67-422A-8B7C-620BDE0C21ED-- From nobody Wed Mar 25 08:58: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 57B2E1A87E8 for ; Wed, 25 Mar 2015 08:58:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.367 X-Spam-Level: X-Spam-Status: No, score=-101.367 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, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 1X-s6eY4rkwp for ; Wed, 25 Mar 2015 08:58:49 -0700 (PDT) Received: from gproxy4-pub.mail.unifiedlayer.com (gproxy4-pub.mail.unifiedlayer.com [69.89.23.142]) by ietfa.amsl.com (Postfix) with SMTP id A49001A8831 for ; Wed, 25 Mar 2015 08:58:48 -0700 (PDT) Received: (qmail 14064 invoked by uid 0); 25 Mar 2015 15:58:48 -0000 Received: from unknown (HELO cmgw2) (10.0.90.83) by gproxy4.mail.unifiedlayer.com with SMTP; 25 Mar 2015 15:58:48 -0000 Received: from box514.bluehost.com ([74.220.219.114]) by cmgw2 with id 7ryi1q00b2UhLwi01rylHz; Wed, 25 Mar 2015 09:58:46 -0600 X-Authority-Analysis: v=2.1 cv=XvNpZz19 c=1 sm=1 tr=0 a=9W6Fsu4pMcyimqnCr1W0/w==:117 a=9W6Fsu4pMcyimqnCr1W0/w==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=XuYyiiJQKFMA:10 a=jPJDawAOAc8A:10 a=IkcTkHD0fZMA:10 a=ieNpE_y6AAAA:8 a=XYUc-DgfXtMA:10 a=G3-J1MMgUXwA:10 a=emO1SXQWCLwA:10 a=QIhr-27iAAAA:8 a=QYw9It01stxFOEqyLEIA:9 a=qIm5XpwJ3d6h5GBo:21 a=329v36SYPsWHZdwV:21 a=QEXdDO2ut3YA:10 a=qDo74OdbLMIA:10 a=9jDjnVP-S04A:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:To:MIME-Version:From:Date:Message-ID; bh=HxQADGl+emo058HkQh/8czWP9WiFYJKGydNU2X0pdJA=; b=kUjPB04aQqsgwrL9jTCKiFc+Ayv2ptfscmHt3uppc9jJvfoj97bolZlGC7JVMpyBiF8Qt6ZjGmTIA3iBfzrh21c9G6pvw6gyTTDLPrZAdq316xc2kEE3pslk0UExeJVq; Received: from [31.133.128.60] (port=43772) by box514.bluehost.com with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1Yanhc-0005Tl-7u for dane@ietf.org; Wed, 25 Mar 2015 09:58:44 -0600 Message-ID: <5512DB2D.7030209@KingsMountain.com> Date: Wed, 25 Mar 2015 08:58:37 -0700 From: =JeffH User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: IETF DANE WG list Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 31.133.128.60 authed with jeff.hodges+kingsmountain.com} Archived-At: Subject: [dane] =?utf-8?q?wrt_How_to_look_up_KEY=E2=80=99s_for_Email_addre?= =?utf-8?q?sses?= X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 25 Mar 2015 15:58:51 -0000 just a quick core-dump here to build on my comments at the mic yesterday = in=20 the DANE session regarding the "How to look up KEY=E2=80=99s for Email ad= dresses"=20 topic.. i would restate the topic as "given an email address, lookup a public key= (s)=20 that may be mapped to it" some of us have been around this overall block before back in the=20 mid-to-late '90s. note that formally, an email addr is an "addr-spec": addr-spec =3D local-part "@" domain [RFC5322] the values of local-parts are typically based on "natural names", eg of=20 people. Natural names are syntactically messy and they change over time,= =20 thus so do typical email addr local-part values. from my personal perspective, based on past experience, here's what I thi= nk=20 would be viable for standardization from a high-level non-DANE-specific=20 perspective.. ### 1. given email addr of "foobar@example.org" 2. find a "local-part lookup service" at "example.org" [eg using SRV loo= kup=20 in DNS] 3. query example.org's local-part lookup service for info (eg public key)= =20 mapped to "foobar" 4. this results in an answer (eg public key) or not [eg "not found" statu= s code] ### Thus, the Really Hard Parts -- which involve looking up info mapped to=20 local-parts (and all the backend support infrastructure) that are not=20 amenable to standardization (i.e. they are "site-specific") -- are buried= =20 behind/below the "local-part lookup service" (this is where, classically= ,=20 when one is mapping 'natural names' to identifiers and other attributes, = registry and directory services are employed). For a case-history example of the considerations, infrastructure, name & = attribute mapping, etc. of directory service deployment -- which supports= a=20 local-part lookup service for a directory-enabled MTA, see.. Registry & Directory Infrastructure: A Case History the local-part lookup is described on slide 16. names and identifiers characteristics are on slide 15. backend support infrastructure: slides 12, 13, 14 overall themes/philosophies begin on slide 20 DANE wg might conceivably define how to place subject's public keys in=20 secure DNS mapped to some identifier, but to me it doesn't seem that any = of=20 the other potentially-standardizable solution portions are appropriate fo= r=20 the DANE wg. there have been various approaches to step 2 (above) over the years and I= 'm=20 not up-to-speed on the attempts since about year 2000, so won't attempt=20 point to any, but suggest others who are interested to research it (and n= ot=20 just within the RFC corpus) HTH, =3DJeffH From nobody Wed Mar 25 09:30: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 E3CCD1A8927 for ; Wed, 25 Mar 2015 09:30:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.1 X-Spam-Level: X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_21=0.6, J_CHICKENPOX_47=0.6, J_CHICKENPOX_57=0.6] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FQFy2ksrvW0o for ; Wed, 25 Mar 2015 09:30: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 326031A1AA6 for ; Wed, 25 Mar 2015 09:30:46 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id EB6AB282FC0; Wed, 25 Mar 2015 16:30:44 +0000 (UTC) Date: Wed, 25 Mar 2015 16:30:44 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20150325163044.GJ21586@mournblade.imrryr.org> References: <9735F7C2-D87A-4A33-9302-49C54A644EDA@verisign.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9735F7C2-D87A-4A33-9302-49C54A644EDA@verisign.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [dane] IPSECA X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2015 16:30:54 -0000 On Tue, Mar 24, 2015 at 10:50:11PM +0000, Osterweil, Eric wrote: > Given the discussion on milestones re: IPSEC DANE work at the beginning > of the DANE session today we?d like to request working group adoption of > the existing IPSECA document: > > https://tools.ietf.org/html/draft-osterweil-dane-ipsec-02 I find the abstract and introduction to be an impenetrable jumble of obstruse jargon. These need radical surgery to make them clear and concise. EXAMPLE: The suggested usage of this document is to aid in discovering where OE IPsec tunnels exist, and to act as an out of band verification substrate that can validate the certificates received during IPsec key exchange. First attempt at making it better: This document explains how to use DANE/DNSSEC to discover OE IPsec tunnels along with the associated authentication keys. Why is so much of the focus on DNS confidentiality? Is this the primary use-case for opportunistic IPSEC? Is IPSEC in fact likely to be used to add confidentiality to DNS? Is that what the document is about? Once the jargon is simplified, the technical content is rather light. There is no detailed discussion of whether this is intended to provide protection against passive attacks only, or also active attacks. The text about what to do with "bogus" responses is unclear. Finally, what I think is the biggest issue: --- IPSEC and forward DNS [ The below was explained to me by Paul Wouters in London, thanks Paul. Any mistakes in the below are mine, so if I've got the wrong end of the stick, that's not Paul's fault. ] Creating IPSEC security associations based on forward DNS names is rather problematic. There is no discussion of the associated issues. Suppose we have: ns1.saint.example. IN A 192.0.2.1 _53.saint.example. IN IPSECA 0 1 1 serving the saint.example domain. Clients secure their connections to this nameserver by creating an IPSEC association with 192.0.2.1 using the given key material. Along comes: ns1.evil.example. IN A 192.0.2.1 _53.evil.example. IN IPSECA 3 1 1 publishing the same IP address as a nameserver for his own evil.example domain. Now clients create a replacement IPSEC tunnel to 192.0.2.1 (there can only be one) and suddenly evil.example is free to intercept saint.example's traffic. The many-to-one mapping from DNS domain names to IP addresses, makes it unsafe to derive IPSEC keys from "forward" domain names. -- Viktor. From nobody Wed Mar 25 09:44: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 9BDB61A8974 for ; Wed, 25 Mar 2015 09:44:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.366 X-Spam-Level: X-Spam-Status: No, score=-1.366 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, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XM_xNtQ9H5jn for ; Wed, 25 Mar 2015 09:44:23 -0700 (PDT) Received: from homiemail-a86.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id C10061A8ACB for ; Wed, 25 Mar 2015 09:44:22 -0700 (PDT) Received: from homiemail-a86.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a86.g.dreamhost.com (Postfix) with ESMTP id 2E2C936006A; Wed, 25 Mar 2015 09:44:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=i3mb1P2SjY/tQI T3QasYuQdEXvs=; b=CILrzyDutmzLADxAQ3RxHcdUwFATnh3/R4R9Ai55i7TloF CVZsLTwjyp1CLx9bdPWUYVAHNSw3EkM738eLgMOlIAltW/IA/wLEOu9bbv9WC7Ww B7LiDvuZYJ0If6cyz8L5WJfoABiQ5jAvUAUiBJQ+1WbFrZwvuqb6jpNSFrh/c= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a86.g.dreamhost.com (Postfix) with ESMTPA id 243D436007C; Wed, 25 Mar 2015 09:44:20 -0700 (PDT) Date: Wed, 25 Mar 2015 11:44:19 -0500 From: Nico Williams To: =JeffH Message-ID: <20150325164417.GA10960@localhost> References: <5512DB2D.7030209@KingsMountain.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5512DB2D.7030209@KingsMountain.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: IETF DANE WG list Subject: Re: [dane] =?utf-8?q?wrt_How_to_look_up_KEY=E2=80=99s__for_Email_addr?= =?utf-8?q?esses?= X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 25 Mar 2015 16:44:24 -0000 On Wed, Mar 25, 2015 at 08:58:37AM -0700, =JeffH wrote: > some of us have been around this overall block before back in the > mid-to-late '90s. Oh yes, I remember sendmail fuzzy matching. > from my personal perspective, based on past experience, here's what > I think would be viable for standardization from a high-level > non-DANE-specific perspective.. > > ### > 1. given email addr of "foobar@example.org" > > 2. find a "local-part lookup service" at "example.org" [eg using > SRV lookup in DNS] And how to authenticate the service using DANE. > 3. query example.org's local-part lookup service for info (eg public > key) mapped to "foobar" > > 4. this results in an answer (eg public key) or not [eg "not found" status code] > ### Yes. A lookup service. And if we're going to do this, then there's no much point to putting local-part -> public keys in DNS. Problem: DNS (even with DNSPRIV) is much more light-weight than any service that uses TLS. Solution: Make a light-weight lookup (idempotent) protocol. To start we could use TLS. (Since we're talking about a lookup protocol, there are TLS features that are not needed, such as replay protection, session resumption, and so on. At minimum server authentication [via public keys published in the DNS] and confidentiality and integrity protection are all that's needed.) Nico -- From nobody Wed Mar 25 09:57: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 8E9C21A89BB for ; Wed, 25 Mar 2015 09:57:31 -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 7F_2nELeDs91 for ; Wed, 25 Mar 2015 09:57:31 -0700 (PDT) Received: from homiemail-a105.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id F196D1A8965 for ; Wed, 25 Mar 2015 09:57:30 -0700 (PDT) Received: from homiemail-a105.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a105.g.dreamhost.com (Postfix) with ESMTP id 7E53C2005E805; Wed, 25 Mar 2015 09:57:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=OGjjILbjvb/i89 Fs5s6S+FHmu9w=; b=AspGSLTuYddlclGOTs7jugaEqM+uRSQZKkkZya05yd8wPy X7X7GV4PxF3jqvwWZ4dQR5urd6E8SVj4JZ8dp6xx0SkzGtOITkQFS5M+Mf6ZFL27 xong1/XxQJmOplUoHX6AW0Gd+1rqzUM3B9kdKxd3B8wtqjo8N+/cFRbnmKiug= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a105.g.dreamhost.com (Postfix) with ESMTPA id 101842005E80A; Wed, 25 Mar 2015 09:57:29 -0700 (PDT) Date: Wed, 25 Mar 2015 11:57:29 -0500 From: Nico Williams To: Pieter Lexis Message-ID: <20150325165728.GB10960@localhost> References: <5512D4F3.70803@powerdns.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5512D4F3.70803@powerdns.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: dane@ietf.org Subject: Re: [dane] A novel idea on the local-part problem for both SMIMEA and 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: Wed, 25 Mar 2015 16:57:31 -0000 On Wed, Mar 25, 2015 at 04:32:03PM +0100, Pieter Lexis wrote: > Disadvantages: > - MTAs will need to talk HTTPS > - It's not DANE (more like 'DNS-Assisted') > - It kind-of defeats the purpose of this WG > - No NSEC3-like protection from address leakage (see sections 9.2 and > 9.3 of RFC7033) No, if you discover the lookup service using DNSSEC and the service's public keys with DANE, then the lookup service is as an extension of the DNS, and it can provide secure non-existence answers. Nico -- From nobody Wed Mar 25 10:17: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 76DCB1A8A0E for ; Wed, 25 Mar 2015 10:17:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.667 X-Spam-Level: X-Spam-Status: No, score=-101.667 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, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 YLOjYsgb8dUr for ; Wed, 25 Mar 2015 10:17:48 -0700 (PDT) Received: from gproxy10-pub.mail.unifiedlayer.com (gproxy10-pub.mail.unifiedlayer.com [69.89.20.226]) by ietfa.amsl.com (Postfix) with SMTP id AB05F1A8793 for ; Wed, 25 Mar 2015 10:17:48 -0700 (PDT) Received: (qmail 31539 invoked by uid 0); 25 Mar 2015 17:17:46 -0000 Received: from unknown (HELO CMOut01) (10.0.90.82) by gproxy10.mail.unifiedlayer.com with SMTP; 25 Mar 2015 17:17:46 -0000 Received: from box514.bluehost.com ([74.220.219.114]) by CMOut01 with id 7tHe1q00g2UhLwi01tHhWD; Wed, 25 Mar 2015 11:17:44 -0600 X-Authority-Analysis: v=2.1 cv=OYILUHjY c=1 sm=1 tr=0 a=9W6Fsu4pMcyimqnCr1W0/w==:117 a=9W6Fsu4pMcyimqnCr1W0/w==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=XuYyiiJQKFMA:10 a=IkcTkHD0fZMA:10 a=ieNpE_y6AAAA:8 a=XYUc-DgfXtMA:10 a=G3-J1MMgUXwA:10 a=emO1SXQWCLwA:10 a=QIhr-27iAAAA:8 a=UshfCQFWOzZvRfmILYcA:9 a=QEXdDO2ut3YA:10 a=9jDjnVP-S04A:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:To:MIME-Version:From:Date:Message-ID; bh=3kH1Wqw0uy4RSxGPLxCpzg9gePnvLoFt4APx1/T/2Y0=; b=cDb1EyqIPTcwqw5fiSUI9yAT6rM8lfJXN/9vPRJgGJRJWpnNr+7pw+DFtheo6RXuFCNfnlQeuf7jFm4fcduH14J/sPPzsCO1nOnZ1dhVYzAtCfllIUITtMykS54fGRKB; Received: from [31.133.128.60] (port=43927) by box514.bluehost.com with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1Yaow0-0003HT-Bj for dane@ietf.org; Wed, 25 Mar 2015 11:17:40 -0600 Message-ID: <5512EDAE.9020306@KingsMountain.com> Date: Wed, 25 Mar 2015 10:17:34 -0700 From: =JeffH User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: IETF DANE WG list Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 31.133.128.60 authed with jeff.hodges+kingsmountain.com} Archived-At: Subject: Re: [dane] wrt How to look up Keys for Email addresses X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 25 Mar 2015 17:17:49 -0000 >> ### >> 3. query example.org's local-part lookup service for info (eg public >> key) mapped to "foobar" >> >> 4. this results in an answer (eg public key) or not [eg "not found" status code] >> ### > > Yes. A lookup service. And if we're going to do this, then there's no > much point to putting local-part -> public keys in DNS. yes, possibly. even if the keys were stored in DNS (for whatever reason(s)), i would suggest doing it as.. immutable-opaque-identifier -> public key ..and then the lookup service knows the mapping of.. local-part -> immutable-opaque-identifier ..and thus can return the key. > Problem: DNS (even with DNSPRIV) is much more light-weight than any > service that uses TLS. > > Solution: Make a light-weight lookup (idempotent) protocol. well, we already have at least one that will work (and I'm speaking from explicit hands-on operational impl & deployment experience) and perhaps others, i would suggest re-use rather than re-invent. =JeffH From nobody Wed Mar 25 10:43: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 EE00F1A88E2 for ; Tue, 24 Mar 2015 08:45: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] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n0KKoqcOVKco for ; Tue, 24 Mar 2015 08:45:19 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E50561A8935 for ; Tue, 24 Mar 2015 08:45:16 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 5.12.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150324154516.6047.26180.idtracker@ietfa.amsl.com> Date: Tue, 24 Mar 2015 08:45:16 -0700 From: IETF Secretariat Archived-At: X-Mailman-Approved-At: Wed, 25 Mar 2015 10:43:38 -0700 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, 24 Mar 2015 15:45:20 -0000 Changed milestone "Advance DANE SRV document to IESG", resolved as "Done". URL: http://datatracker.ietf.org/wg/dane/charter/ From nobody Wed Mar 25 10:43: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 B7C071A88E2 for ; Tue, 24 Mar 2015 08:45:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aQBCNR0KbPjR for ; Tue, 24 Mar 2015 08:45:49 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B68D91A8934 for ; Tue, 24 Mar 2015 08:45:48 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 5.12.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150324154548.12132.90304.idtracker@ietfa.amsl.com> Date: Tue, 24 Mar 2015 08:45:48 -0700 From: IETF Secretariat Archived-At: X-Mailman-Approved-At: Wed, 25 Mar 2015 10:43:43 -0700 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, 24 Mar 2015 15:45:50 -0000 Changed milestone "Advance DANE SMTP document to IESG", resolved as "Done". URL: http://datatracker.ietf.org/wg/dane/charter/ From nobody Wed Mar 25 10:55: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 E85911AC3F3 for ; Wed, 25 Mar 2015 10:55:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_22=0.6] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IkRRgRA2rh6o for ; Wed, 25 Mar 2015 10:55:23 -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 C032D1ABD3E for ; Wed, 25 Mar 2015 10:55:23 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 6145A283015; Wed, 25 Mar 2015 17:55:22 +0000 (UTC) Date: Wed, 25 Mar 2015 17:55:22 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20150325175522.GL21586@mournblade.imrryr.org> References: <5512D4F3.70803@powerdns.com> <20150325165728.GB10960@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150325165728.GB10960@localhost> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [dane] A novel idea on the local-part problem for both SMIMEA and OPENPGPKEY? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2015 17:55:25 -0000 On Wed, Mar 25, 2015 at 11:57:29AM -0500, Nico Williams wrote: > > - It kind-of defeats the purpose of this WG No, not really. DANE secures the location of the lookup service. > > - No NSEC3-like protection from address leakage (see sections 9.2 and > > 9.3 of RFC7033) > > No, if you discover the lookup service using DNSSEC and the service's > public keys with DANE, then the lookup service is as an extension of the > DNS, and it can provide secure non-existence answers. One way to understand that is to think this a new type of DNS delegation, instead of NS+DS records securely delegating queries to an authoritative server that still speaks DNS, you have TLSA (or similar if the lookup protocol is over something more light-weight than TLS) RRs that delegate the lookup to an authoritative server that speaks a different protocol. Either way, queries from the client go to the domain that controls the names. Either way, there's scope for "directory harvesting attacks". If we don't force the queries into the DNS: * We don't explode DNS caches with negative TTL replies for 100's of millions of user names. * We can eliminate hashing (needed to deal with case folding and limits on DNS label lengths). * Eliminating hashing makes it possible for the owner domain to perform lookup key canonicalization. -- Viktor. From nobody Wed Mar 25 11:10: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 D9D3D1ACDE4 for ; Wed, 25 Mar 2015 11:10:07 -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 O2xmAx3vv8Nr for ; Wed, 25 Mar 2015 11:10:05 -0700 (PDT) Received: from homiemail-a16.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id AF99D1A8906 for ; Wed, 25 Mar 2015 11:10:05 -0700 (PDT) Received: from homiemail-a16.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a16.g.dreamhost.com (Postfix) with ESMTP id 1D90B5080D2; Wed, 25 Mar 2015 11:10:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=iVY1PpkuKZ/hJL sdwRd0GlKzxz8=; b=BonwiNCzl9l8lSpU+CHwjCccf2aQGHBRe8umiJPJLxr+XQ BFmYZMfaomUx+DOEQsG/K7NIO4ad+dX6s37+asLNkuqnxAt3V8XIATLdKY7Izwmt gsYKIZpRkNOoE4qhqhrelD/7b4PjCDhGlqrpQl6eWSe4IIUGZPIeZI9jN/RH8= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a16.g.dreamhost.com (Postfix) with ESMTPA id E19605080BB; Wed, 25 Mar 2015 11:10:02 -0700 (PDT) Date: Wed, 25 Mar 2015 13:10:01 -0500 From: Nico Williams To: "Osterweil, Eric" Message-ID: <20150325181000.GC10960@localhost> References: <9735F7C2-D87A-4A33-9302-49C54A644EDA@verisign.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9735F7C2-D87A-4A33-9302-49C54A644EDA@verisign.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: dane WG list Subject: Re: [dane] IPSECA X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 25 Mar 2015 18:10:08 -0000 On Tue, Mar 24, 2015 at 10:50:11PM +0000, Osterweil, Eric wrote: > https://tools.ietf.org/html/draft-osterweil-dane-ipsec-02 You need to explain a lot of details about how the PAD, SPD, and SAD are manipulated to obtain secure behavior. In particular, simply adding PAD entries (with the IPSECA keys) identified by IP address (so that traditional IPsec implementations just work) would result in a catastrophic security failure: each zone answering forward A & IPSECA lookups could give you their keys for someone else's IP address! You don't mention the PAD nor the SAD, so I assume that you missed their significance when reading RFC4301. You really need to study the IPsec architecture [RFC4301] closely and carefully. Also, any work like this absolutely needs review from whatever WG has IPsec as its remit. What you need to do is state that the client must follow a sequence of steps like this[*]: 0. Lookup the peer's IP address and IPSECA RRs by forward name 1. insert a PAD entry identified by the peer's FQDN (NOT IP address!) 2. request an IKE_SA between the local and remote peer 3. atomically obtain/lock a 5-tuple (with that peer) not currently in use by other processes/sockets on the system 4. setup a *narrow* SA pair for that 5-tuple, and insert the SA pair into the SAD 5. add narrow entries to the SPD for that 5-tuple to PROTECT 6. connect() your socket (even with UDP, of course) 7. use the connected socket 8. tear down the socket, SPD and SAD entries; the PAD entry can stay as long as the RR's TTL says. Or something along those lines. That's just the conceptual part. Then you need to figure out how applications will cause this dance to happen -- the API. Perhaps you'll need to add a socket option for requesting the use of IPsec with narrow SA pairs and a specific peer ID and public keys. Without a socket option for this (or a pseudo address family that relieves applications of the need to do DNS lookups) the most likely API scenario (perhaps for a PoC) would be that the application must use PF_KEY to talk to the IKE daemon to get it to do a lot of the above sequence of steps. But then you have to worry about how to tear down state when the application crashes. Once you have a proof of concept you need to test that it does not fall to the attack described above. Setup two forward names pointing to the same IP address and with different public keys, then race clients and show that they always get their traffic protected by SAs with the correct peer ID. In particular, the peer should not have the private keys for the "attacker"'s name, and so clients trying to speak to the attacker always fail. [*] This is a suggestion as a starting point, and to illustrate the complexities involved. I only just thought that up in a few minutes; there could be mistakes there too. Nico -- From nobody Wed Mar 25 11:22: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 7D7F21ABD3E for ; Wed, 25 Mar 2015 11:22:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.166 X-Spam-Level: X-Spam-Status: No, score=-0.166 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 Nuy1jh9C8Y7P for ; Wed, 25 Mar 2015 11:22:45 -0700 (PDT) Received: from homiemail-a95.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id EA3561A8792 for ; Wed, 25 Mar 2015 11:22:44 -0700 (PDT) Received: from homiemail-a95.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a95.g.dreamhost.com (Postfix) with ESMTP id 3DF071E0E5; Wed, 25 Mar 2015 11:19:40 -0700 (PDT) Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a95.g.dreamhost.com (Postfix) with ESMTPA id 7EE6A1E1B4; Wed, 25 Mar 2015 11:16:47 -0700 (PDT) Date: Wed, 25 Mar 2015 13:16:46 -0500 From: Nico Williams To: "Osterweil, Eric" Message-ID: <20150325181645.GD10960@localhost> References: <9735F7C2-D87A-4A33-9302-49C54A644EDA@verisign.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9735F7C2-D87A-4A33-9302-49C54A644EDA@verisign.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: dane WG list Subject: Re: [dane] IPSECA X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 25 Mar 2015 18:22:45 -0000 I do not support inclusion of this work item in this WG. The DANE-ish aspects of this work are much simpler than the IPsec ones. I will support inclusion of this work in an IPsec-specific WG (IPsecme, or perhaps HIP) when a new version of the individual submission I-D is submitted that addresses the substantive comments I just posted. Even then, review from this WG would be a good idea. Nico -- From nobody Wed Mar 25 11:34: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 41AEE1AC3CE for ; Wed, 25 Mar 2015 11:34:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lUuhM_qC2Y0i for ; Wed, 25 Mar 2015 11:34:07 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85FB41A8792 for ; Wed, 25 Mar 2015 11:34:07 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3lBylH61DMzpH; Wed, 25 Mar 2015 19:34:03 +0100 (CET) Authentication-Results: mx.nohats.ca; dkim=pass (1024-bit key) header.d=nohats.ca header.i=@nohats.ca header.b=kJ11rmIQ 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 b6HZTqva2sV3; Wed, 25 Mar 2015 19:34:02 +0100 (CET) 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, 25 Mar 2015 19:34:02 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id CDDE882F56; Wed, 25 Mar 2015 14:34:01 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1427308441; bh=zL1tIEiu2D9tRcg3Yal+H5aLEnA/yeTEg5gTZ/yoLsQ=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=kJ11rmIQ6QwKxEXS22PAu0KcNvmLZtlaTVK8iMrV5p3pjBqInLCoUNkQrQsbfPe1w OEGPcOhRdpvABlg+wSHzd6030iLvG3LE1W+PO1Af+Y+KTXI16Ah6ETkz1fD78YyEJf Ievq4YQUWqWjiChnZdwi1+Ts2ZKj/0OfAKR/ux7U= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id t2PIY1CA014496; Wed, 25 Mar 2015 14:34:01 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Wed, 25 Mar 2015 14:34:01 -0400 (EDT) From: Paul Wouters To: Nico Williams In-Reply-To: <20150325165728.GB10960@localhost> Message-ID: References: <5512D4F3.70803@powerdns.com> <20150325165728.GB10960@localhost> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: dane WG list Subject: Re: [dane] A novel idea on the local-part problem for both SMIMEA and 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: Wed, 25 Mar 2015 18:34:09 -0000 On Wed, 25 Mar 2015, Nico Williams wrote: > On Wed, Mar 25, 2015 at 04:32:03PM +0100, Pieter Lexis wrote: >> Disadvantages: >> - MTAs will need to talk HTTPS >> - It's not DANE (more like 'DNS-Assisted') >> - It kind-of defeats the purpose of this WG >> - No NSEC3-like protection from address leakage (see sections 9.2 and >> 9.3 of RFC7033) > > No, if you discover the lookup service using DNSSEC and the service's > public keys with DANE, then the lookup service is as an extension of the > DNS, and it can provide secure non-existence answers. If the lookup service is on port X, and the attacker blocks port X, you do not know whether there is a service interruption or an active attack. Any lookup mechanism must remain within the DNS. Paul From nobody Wed Mar 25 11:36: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 16D091B29EE for ; Wed, 25 Mar 2015 11:36:33 -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 E3Qdqr1dkgav for ; Wed, 25 Mar 2015 11:36:31 -0700 (PDT) Received: from homiemail-a85.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id B75DC1B29D5 for ; Wed, 25 Mar 2015 11:36:31 -0700 (PDT) Received: from homiemail-a85.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a85.g.dreamhost.com (Postfix) with ESMTP id 11E2DBBA078; Wed, 25 Mar 2015 11:36:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=F8uc9bwZcU4Qsq 6KRYzIpxWFwss=; b=Mc++nH+rImyPgc3AZiNKujdURN+m1ZN6Ce2yFvWAO8vm+8 9bKQixYBP8A9568i3c12B3PHgiSl2TWiDDDP5bAF9lfX+eJHt+o1tx1Ej4LApb9q b5II5RYMw+ovMcOISng9VBBmxK0S2OypNZyS/rZE2pNlxwb1P2czEX0A+bGxs= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a85.g.dreamhost.com (Postfix) with ESMTPA id 75BC6BBA088; Wed, 25 Mar 2015 11:36:27 -0700 (PDT) Date: Wed, 25 Mar 2015 13:36:26 -0500 From: Nico Williams To: Paul Wouters Message-ID: <20150325183625.GE10960@localhost> References: <5512D4F3.70803@powerdns.com> <20150325165728.GB10960@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: dane WG list Subject: Re: [dane] A novel idea on the local-part problem for both SMIMEA and 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: Wed, 25 Mar 2015 18:36:33 -0000 On Wed, Mar 25, 2015 at 02:34:01PM -0400, Paul Wouters wrote: > If the lookup service is on port X, and the attacker blocks port X, you > do not know whether there is a service interruption or an active attack. How is that different from the attacker blocking DNS? > Any lookup mechanism must remain within the DNS. This lookup service would be like an extension of DNS. From nobody Wed Mar 25 11:38: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 24F1E1B2A07 for ; Wed, 25 Mar 2015 11:38: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 byMl1nY6QNF1 for ; Wed, 25 Mar 2015 11:38:23 -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 1FE9A1B2A10 for ; Wed, 25 Mar 2015 11:38:18 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3lByr70HV3zGXC for ; Wed, 25 Mar 2015 19:38:15 +0100 (CET) Authentication-Results: mx.nohats.ca; dkim=pass (1024-bit key) header.d=nohats.ca header.i=@nohats.ca header.b=lT+tGWEB 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 o8xQNNcW_Ms7 for ; Wed, 25 Mar 2015 19:38:13 +0100 (CET) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS for ; Wed, 25 Mar 2015 19:38:12 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 8956B803E0 for ; Wed, 25 Mar 2015 14:30:00 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1427308200; bh=wQR/n7G///vNcZ4tsQamMoW8pwx89ZFGVW6erKX4Q2A=; h=Date:From:To:Subject:In-Reply-To:References; b=lT+tGWEBK8DEiEah5XSvV/opGd3X4p4V9xhtc0+3AAlhG2E8h4Tbd+VkxjwkkLI91 /XuAqJDWXoT4EeRbr9fTrWrunlSI1zP/49AUs6epJTvPQqZoqAWrY5HeKDf1pIe/AK BP4v9eyvr2Rb3d5y9qEG8tBHH8V+g+IGkNTvVKuE= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id t2PITxoK011145 for ; Wed, 25 Mar 2015 14:30:00 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Wed, 25 Mar 2015 14:29:59 -0400 (EDT) From: Paul Wouters To: dane WG list In-Reply-To: <9735F7C2-D87A-4A33-9302-49C54A644EDA@verisign.com> Message-ID: References: <9735F7C2-D87A-4A33-9302-49C54A644EDA@verisign.com> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8BIT Archived-At: Subject: Re: [dane] IPSECA X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 25 Mar 2015 18:38:26 -0000 On Tue, 24 Mar 2015, Osterweil, Eric wrote: > Given the discussion on milestones re: IPSEC DANE work at the beginning of the DANE session today we’d like to request working group adoption of the existing IPSECA document: > https://tools.ietf.org/html/draft-osterweil-dane-ipsec-02 > > We’ve been working on a couple of different flavors of implementation. We’re hoping to push those out soon too and it’s already benefited from a great deal of discussion here, and we believe it’s definitely ready to become a WG product. TL;DR - This document makes a straight copy of the TLSA record and assumes host based IKE/IPsec works like application based TLS. It handwaves the IKE protocol and isn't clear why it is limiting itself to DNS, or what DNS traffic it wants to protect or how it could ever do a secure bootstrap. It still does not support NAT'ed clients or (DNS) servers and does not explain the AUTH and ID payload that the client is supposed to send during IKE. It does not explain what traffic selectors are used on the IPsec SAs. It provides no defense against DOS attacks. It suffers from a great disconnect with the IPsecME Working Group. I do not support adopting this document. I have reviewed this document before and most of my concerns still stand: https://www.ietf.org/mail-archive/web/dane/current/msg06436.html It's good to see that my conversation with Eric resulted in the removal of the insecure gateway option. But more serious fundamental problems remain in this draft. Specifically: 1) Limiting the scope of IPsec protection using DANE to only one protocol or one application makes no sense in an IPsec context. 2) This draft is not sure if it wants to be generic (IPSECA vs IPSECDNSA) or specific (IPSECA on _53.* == IPSECDNSA) 3) If you want to protect DNS using IPsec, just use an IPsec host-to-host tunnel and have the DNS server filter port <> 53. That allows for this method to be usable for endusers with the technical knowledge of watching netflix on any currently deployed device (iphone, android, windows, OSX, Linux, etc without needing any new RFC or patents. Google could use publish an IPSECKEY with "." gateway in the reverse of 8.8.8.8 and the forward of dns.google.com. 4) _53.example.com makes no sense. Is this UDP, TCP or both. Are traffic selectors in use? Are you aware traffic selectors cannot have 2 protocols and that you will end up requiring multiple child SA's? 5) IPSECA is basically the same as the TLSA record. It incorrectly assumes that X.509 is the only method of authentication desired. 6) It takes about "interaction" with the SPD without understanding or specification. It does not clarify what the IKE daemon is supposed to do - or if it intends to extend the PF_KEY API. 7) Hoes does this document support the clients remaining anonymous? It fails to specify the IKE negotiation and AUTH and ID payloads involved. Section 1.1 "This can be especially complicated if different IPsec certificates need to be discovered for different services that are running on the same IP address." What is an "IPsec certificate"? Why do you need more than one? What AUTH method does the client use to (not) identify itself? How are traffic selectors negotiated? ANY to 53 ? "This can become complicated if certificates are learned solely by the IP addresses of networked-services. " [and all of section 1.2] dns.google.com. IN IPSECKEY ...... This section, which is the justification of this document is based on the misconception that public IPsec keys can currently only be discovered by IP address. "The advantages of using DANE for IPsec OE " What is "DANE for IPsec OE" ? I guess OE means Opportunistic Encryption. Note the lack of "for DNS" in the description here. Are we talking about DNS or generic _XXX.example.com protection? "Such as, the automatic deauthorization of certificates that happens when they are removed from a DNS zone" There is no text describing what clients should do once they learned this certificate from DNS and connect. Isn't it valid until its X.509 signature if certain Usage Types that include PKIX validation are used? Section 1.3: "using a specific key exchange protocol, like [RFC2409], [RFC5996], etc." RFC2409 is suggesting using IKEv1. IKEv1 has been obsoleted by IKEv2 since RFC 4305 in 2005. The IPsecME WG has a very strict policy that no new documents related to IKEv1 be published. (again this illustrates the disconnect of the authors of this document and the IPsecME WG) "when it receives a referral it SHOULD query name servers for corresponding IPSECA resource records." What is "receives a referral" ? Is this suggesting the client implementing this document attempts to talk IPsec to every new NS record target it receives? Or is it meant to talk about a DHCP Nameserver option? The end of the document suddenly talks about protecting authoritative servers in the example section, so I think it means when it receives a delegation via NS. If so, how will it find IPSECA records _to_ that server without first talking to that server in the clear? Is this record support to live in the parent like the DS record? If not, how does the DNS server and IKE/IPsec server interact when the record is received to kick start the IPsec encryption? And how does a new query get handled when the IPSECA record expired from the local cache? "that resolver SHOULD follow its configurations and setup an SPD entry," This is really just handwaving, "and it should do some IPsec magic". This really needs to say what IKE parameters are being negotiated and what outcome is expected. And what to do when the IKE negotiation fails and what to do during IKE negotiation and how the DNS server and IKE server can possibly coordinate these actions. "Note, this document does not specify a new, or any modifications to any existing, IPsec key exchange protocols." "Rather, after adding an SPD and after a successful tunnel establishment, the credentials used for the Security Association with the name server SHOULD be cross-checked with the IPSECA resource record(s)." First of all, one does not "add an SPD entry". Second of all, if you reach the point in the IKE protocol where you update the SPD/SAD database, it means the kernel is told to encrypt/decrypt packets. That is, the IPsec tunnel is fully up and running. There is no more IKE to be done. Saying one should THEN cross-check the X.509 AUTH payloads of IKE is completely invalid AND a serious breach of the IKE protocol. "When using IPSECA resource records to verify OE tunnels, clients MUST perform full DNSSEC validation of the DNSSEC chain of trust that leads to IPSECA RRs." If using IPsec fails, the DNS client is going to send cleartext packets anyway. Wouldn't a non-DNSSEC IPSECA record provide more privacy than just defaulting to clear? [Hint, read draft-ipsecme-ikev2--auth-null and RFC 7435] "certificate association for [IPsec]" "If the DNSSEC validation state on the response to the request for the [IPSECA] RRSet is bogus, this MUST cause IPsec not to be started or, if the IPsec negotiation is already in progress, MUST cause the connection to be aborted." The use of "certificate association for [IPsec]", "IPsec not to be started" and "IPsec negotiation" again shows the workings of IKE versus IPsec are not understood. "Trust anchors (which may be distributed during dynamic host configuration)" I guess that would be a whole set of RFC's in itself. How can one securely obtain trust anchors via DHCP? Because the DNSOPS and HOMENET people would also love to get that going. "The intuition behind this reasons that if the first (configuration) step was already where the local resolver was configured, then the security of the DNS transactions already hinged on learning the valid resolver this way. " Here, the document suggest that after describing all these security MUST's related to DNSSEC, the whole chain of trust starts with a completely insecure DHCP packet. Again, you might as well just do draft-ipsecme-ikev2--auth-null at that point. This undermines all the previous security requirements required in this section. "So, this step is already used to convey trusted configurations (bootstrapping)." Uhm no. No one has ever claimed DHCP is "trusted". "Adversaries attempting to subvert an end host have only the narrow attack window that is associated with learning configurations. " Uhm no. And even so.. Section 2 "The IPSECA resource record is modeled heavily off of the IPSECKEY RR" That is no longer true with the removal of the gateway option. The only things left now are TLSA items. In fact, it's now identical to a TLSA record and the new IANA registry created by this document would also be an unnecessary duplication. Section 2.1 References to ietf-dane-registry-acronyms should be updated to be RFC 7218 Section 2.2 This does not show the presentation format. Note that there is not even a section describing the wire format. Section 2.3 See above regarding completely missing the traffic selectors and multiple Child SA's issues. Section 2.4: "They MAY be used in verifying Security Associations, but a protocol to do this is beyond the scope of this document." I do not understand what is being said here. Section 2.4.1: Suppose a DNS zone example.com is served by the name servers ns1.example.com and ns2.example.com. If the zone operators want to advertise their willingness to offer OE to their name servers using IKEv2 [RFC5996], then the following domain names MUST be placed under the example.com zone Ok, so now out of nowhere we are talking about Authoritative Servers, and not recursive ones. That would require its own section with a very important component on security and how to prevent DOS attacks. Not only that, note the "under". To talk securely to ns1.nohats.ca, you need to talk insecurely to ns1.nohats.ca to get the IPSECA record, where upon you will get almost all records related to nohats.ca in the clear. In other words, by the time your tunnel is setup, 90% of the DNS traffic has already happened in clear text. (Unless you want to put the IPSECA record in the parent zone like the DS record - if you want to do that, you'll have to go to dnsops) This example illustrates how a zone MAY indicate where an SPD entry and SA establishment endpoints exist for its name servers (note, they are not required to be the name servers themselves). So if these are not the nameservers themselves, where do I send the port 53 query to? This is probably an artifact of the now removed gateway option. "the IPsec certificate" IPsec has no certificates. You mean IKE. Section 3 First of all, this section completely misses the bootstrap issue or how one is to lookup IPSECA records if one is trying to setup IPsec to its only DNS server. If a resolver enables OE, but no (or relatively few) name servers provision IPSECA records, then no IPsec tunnels will be established, and the load will remain static (or marginally increase). This is a weird statement. "If we are not successful in deploying this as a standard, there will be no scalability issues" If an authoritative name server provisions IPSECA record, it will only result in additional load if querying resolvers are configured to attempt OE. And again. "If nothing bad happens and we don't deploy much, we're good". Using white-listing techniques (such as those used during pilot deployments of AAAA records) would allow authoritative name servers to only return IPSECA responses to clients that have been white-listed. Hoes does that work when the zones are (as is mandated by this document) DNSSEC signed? You would be returning BOGUS results or need to have two signed zones to return signed answers. Which any attacker could then replay to the user to force them onto the clear text version of DNS. This section is completely missing the actual DOS and load issues that can be expected to happen. Section 4 Any future use or modification of an IANA registry for that resource record will have similar effects on this resource record. This only shows again that this document should not be defining IPSECA which is just a copy of TLSA. Section 5 This section does not actually address the real concerns. It does not talk about fallback to clear versus hard fail. It does not talk about handling thousands of IKE SAs and IPsec SAs. Conclusion As I stated to the dane chairs before and again during yesterday's meeting, there are IPsec people working on updating/replacing the IPSECKEY RFC. However, proper implementation runs into various complicated issues, mostly related to NAT and failure modes, that the authors of this draft have not addressed - and frankly needs a lot of discussion in the IPsecME working group and not so much in the DANE working group. There are good reasons the Libreswan Project has been working on this for a few months _without_ submitting a draft. For example, as part of moving towards an actual real solution, the libreswan IPsec team submitted the following draft to the IPsecME WG: https://tools.ietf.org/html/draft-antony-ipsecme-oppo-nat-00 The split of IKE and IPsec and the fact that applications are not necessarily aware of the security of the transport when IPsec is used makes me think that work for this belongs much more in the IPsecME WG than in the DANE WG. This draft is clearly written by people that lack enough understanding of IKE and IPsec. Creating a solution for IPsec that only protects DNS makes no sense. IKE and IPsec is not application level based, but host based. Additionally, this document mixes up authoritative and recursive DNS server protection, resulting in something that works for neither. Having been heavily involved in IPsec and DNSSEC for the last 15 years within the IETF and the opensource community in general, I do not appreciate the author's inappropriate joking about patents to me in the hallway - especially when this document gives the appearance of being just a quick attempt at justifying a pending patent, instead of the authors actually talking to the IPsec community in an attempt to write something that is actually deployable and secure. I do not support adopting this document. Paul From nobody Wed Mar 25 11:38: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 B78AC1B2A07 for ; Wed, 25 Mar 2015 11:38:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.81 X-Spam-Level: X-Spam-Status: No, score=-0.81 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_47=0.6, J_CHICKENPOX_57=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 sTiX3ea9wqiv for ; Wed, 25 Mar 2015 11:38: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 5C0A91B2A5A for ; Wed, 25 Mar 2015 11:38:30 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3lByrP0G3KzB4w for ; Wed, 25 Mar 2015 19:38:28 +0100 (CET) Authentication-Results: mx.nohats.ca; dkim=pass (1024-bit key) header.d=nohats.ca header.i=@nohats.ca header.b=WCjk1KFT 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 UHOf9ITcmtLL for ; Wed, 25 Mar 2015 19:38:28 +0100 (CET) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS for ; Wed, 25 Mar 2015 19:38:28 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 42DC9803E0 for ; Wed, 25 Mar 2015 14:38:27 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1427308707; bh=R1/L22L/O2hgaSl8i56AeATO/wm6UhipxzA+9SmUnZc=; h=Date:From:To:Subject:In-Reply-To:References; b=WCjk1KFTj6c/KuMN+zRfs/StJR5+JfsLYvne/tLNN9UBpPCkw0FvNdzv9yME+64Kg rlmn6DQ2SWTMmubQhBfGDHOHR43P3Mj26MHjb3hg/3YU1t9xQ0o9CXiGvn+N1MSPe5 rU7OoAp9xl71EqrS7IHQRZjGdNgk9MqWCDaG94Jk= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id t2PIcRqw018067 for ; Wed, 25 Mar 2015 14:38:27 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Wed, 25 Mar 2015 14:38:27 -0400 (EDT) From: Paul Wouters To: dane@ietf.org In-Reply-To: <20150325163044.GJ21586@mournblade.imrryr.org> Message-ID: References: <9735F7C2-D87A-4A33-9302-49C54A644EDA@verisign.com> <20150325163044.GJ21586@mournblade.imrryr.org> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [dane] IPSECA X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 25 Mar 2015 18:38:31 -0000 On Wed, 25 Mar 2015, Viktor Dukhovni wrote: > Finally, what I think is the biggest issue: > > --- IPSEC and forward DNS > > [ The below was explained to me by Paul Wouters in London, > thanks Paul. Any mistakes in the below are mine, so if I've > got the wrong end of the stick, that's not Paul's fault. ] > > Creating IPSEC security associations based on forward DNS names > is rather problematic. There is no discussion of the associated > issues. Suppose we have: > > ns1.saint.example. IN A 192.0.2.1 > _53.saint.example. IN IPSECA 0 1 1 > > serving the saint.example domain. Clients secure their connections > to this nameserver by creating an IPSEC association with 192.0.2.1 > using the given key material. Along comes: > > ns1.evil.example. IN A 192.0.2.1 > _53.evil.example. IN IPSECA 3 1 1 > > publishing the same IP address as a nameserver for his own evil.example > domain. Now clients create a replacement IPSEC tunnel to 192.0.2.1 > (there can only be one) and suddenly evil.example is free to > intercept saint.example's traffic. Actually, you cannot intercept the traffic. Assuming the real IKE daemon on 192.0.2.1 is configured with the "saint key", the client will see that the server fails authentication. But this does provide a denial of service against both the client and the saint server. And if the client would fail to clear based on evil.example, than it could potentially cause all saint traffic to end up in the clear as wel. Paul From nobody Wed Mar 25 11: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 93FC11AC3D3 for ; Wed, 25 Mar 2015 11:42:54 -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 jBbjyYiPN4uN for ; Wed, 25 Mar 2015 11:42:53 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 812841A8792 for ; Wed, 25 Mar 2015 11:42:50 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3lByxP0Q0szGXC; Wed, 25 Mar 2015 19:42:49 +0100 (CET) Authentication-Results: mx.nohats.ca; dkim=pass (1024-bit key) header.d=nohats.ca header.i=@nohats.ca header.b=kOqFK3T0 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 FIfkX8crV9A7; Wed, 25 Mar 2015 19:42:48 +0100 (CET) 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, 25 Mar 2015 19:42:48 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 469F9803E0; Wed, 25 Mar 2015 14:42:47 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1427308967; bh=RE74gafaDZ12dGTYYj/apHmXSGcku1e/ZAAErRi15u0=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=kOqFK3T01RHji75SrxYvI0YiTIQW0FavoQ3Bw8CJkMU+jHDAM34JuAw6SEBrSguHw q84iWrryfDyjA4o4uw/edAU3W3A/vIQo3g38CWLxXodLW3fL7fYtCuazSvqyV7nbz+ vUpRLTZA9TCQ9Bcgi8YeuRIuIDBkazg4BJlS0TKA= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id t2PIgknt021748; Wed, 25 Mar 2015 14:42:46 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Wed, 25 Mar 2015 14:42:46 -0400 (EDT) From: Paul Wouters To: Pieter Lexis In-Reply-To: <5512D4F3.70803@powerdns.com> Message-ID: References: <5512D4F3.70803@powerdns.com> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: dane@ietf.org Subject: Re: [dane] A novel idea on the local-part problem for both SMIMEA and 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: Wed, 25 Mar 2015 18:42:54 -0000 On Wed, 25 Mar 2015, Pieter Lexis wrote: > Now, the IETF has standardized a mechanism to do discovery like this in > the form of webfinger, RFC7033[1]. This would allow an MTA/MUA to lookup > the full recipient address (in the format given by the end user) at the > webfinger server of that domain. This server could do the > casefolding/aliasing using the defined 'aliases' field in the response body. Any email address oracle service will find its biggest consumer to be spammers. I do not think anyone will deploy such on oracle/service. Paul From nobody Wed Mar 25 12:25:22 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD5F61A8A45 for ; Wed, 25 Mar 2015 12:25: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 OaDbtLslRoLO for ; Wed, 25 Mar 2015 12:25:21 -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 D07EE1A6EFB for ; Wed, 25 Mar 2015 12:25:20 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3lBztP49cpzGXD; Wed, 25 Mar 2015 20:25:17 +0100 (CET) Authentication-Results: mx.nohats.ca; dkim=pass (1024-bit key) header.d=nohats.ca header.i=@nohats.ca header.b=CMXO6ehu 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 jCWHDIIR57MH; Wed, 25 Mar 2015 20:25:16 +0100 (CET) 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, 25 Mar 2015 20:25:16 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id B984780416; Wed, 25 Mar 2015 15:25:15 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1427311515; bh=cMXrhPxM9PWHTryf8ekXdTJ9AtZxPD8cZvLP8aemPPE=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=CMXO6ehuCRTe1Tp1W4iugKbhI92cLKTUDi9HDJm0NjPqpRAJW4caHM/BAkVW5ED/3 pm9xIDCpoSsH/efJgZHN4BLot3OOXtBoONy0Il3MW/hr9aaMhYjCp2NoqtlVbtzNVZ 16pjy91dXN90hvjNiuwggb0GJ0Iity/3aOSeNt+c= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id t2PJPFp3024754; Wed, 25 Mar 2015 15:25:15 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Wed, 25 Mar 2015 15:25:15 -0400 (EDT) From: Paul Wouters To: Nico Williams In-Reply-To: <20150325183625.GE10960@localhost> Message-ID: References: <5512D4F3.70803@powerdns.com> <20150325165728.GB10960@localhost> <20150325183625.GE10960@localhost> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: dane WG list Subject: Re: [dane] A novel idea on the local-part problem for both SMIMEA and 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: Wed, 25 Mar 2015 19:25:22 -0000 On Wed, 25 Mar 2015, Nico Williams wrote: > On Wed, Mar 25, 2015 at 02:34:01PM -0400, Paul Wouters wrote: >> If the lookup service is on port X, and the attacker blocks port X, you >> do not know whether there is a service interruption or an active attack. > > How is that different from the attacker blocking DNS? We have a security policy for "indeterminate" and "bogus". That is, we know we are under attack. Having a TCP connection just "not work" does not have that property. Additionally, DNSSEC as a transport has a much better penetration rate than a new auxiliary protocol on a new unknown port. Additionally, an SMTP extension using port 25 is out because many ISP's do not allow you to connect to port 25 on the internet and force you to go through their port 25 instead. Paul From nobody Wed Mar 25 13:03: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 17B361A8A97 for ; Wed, 25 Mar 2015 13:03:44 -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 sD60YnAGpgjz for ; Wed, 25 Mar 2015 13:03:43 -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 C9F5B1A1A54 for ; Wed, 25 Mar 2015 13:03:42 -0700 (PDT) Received: (qmail 99405 invoked from network); 25 Mar 2015 20:03:41 -0000 Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 25 Mar 2015 20:03:41 -0000 Date: 25 Mar 2015 20:03:19 -0000 Message-ID: <20150325200319.43775.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] email oracle and lookup, was A novel idea X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 25 Mar 2015 20:03:44 -0000 >Any email address oracle service will find its biggest consumer to be >spammers. I do not think anyone will deploy such on oracle/service. This is certainly true. The SMTP protocol has always had oracle commands VRFY (does this address exist?) and EXPN (what are the real address(es) for this address?) The number of MTAs that currently provide support either of those rounds to zero. On the other hand, I think that a lookup service that takes an address and returns a key would be workable. Yeah, spammers will try to scrape addresses from it, but it's the same attack as RCPT TO probing and we have workable defenses against that. R's, John From nobody Wed Mar 25 13:06:43 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5203F1B29E7 for ; Wed, 25 Mar 2015 13:06:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.162 X-Spam-Level: * X-Spam-Status: No, score=1.162 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, 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 315vWirIJ_vA for ; Wed, 25 Mar 2015 13:06:41 -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 66BC71B2A0A for ; Wed, 25 Mar 2015 13:06:41 -0700 (PDT) Received: (qmail 99931 invoked from network); 25 Mar 2015 20:06:40 -0000 Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 25 Mar 2015 20:06:40 -0000 Date: 25 Mar 2015 20:06:18 -0000 Message-ID: <20150325200618.43798.qmail@ary.lan> From: "John Levine" To: dane@ietf.org In-Reply-To: <20150325164417.GA10960@localhost> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dane] =?utf-8?q?wrt_How_to_look_up_KEY=E2=80=99s__for_Email_addr?= =?utf-8?q?esses?= X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 25 Mar 2015 20:06:42 -0000 >Problem: DNS (even with DNSPRIV) is much more light-weight than any > service that uses TLS. You're going to use the result to send mail messages. Why does the lookup need to be a lot faster than sending the mail message? R's, John From nobody Wed Mar 25 13:17: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 7FDD31AC3BC for ; Wed, 25 Mar 2015 13:17:10 -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 Q1mcugdeAK47 for ; Wed, 25 Mar 2015 13:17:06 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 330581A8ABB for ; Wed, 25 Mar 2015 13:17:06 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 1E1F5283015; Wed, 25 Mar 2015 20:17:05 +0000 (UTC) Date: Wed, 25 Mar 2015 20:17:05 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20150325201704.GM21586@mournblade.imrryr.org> References: <20150325200319.43775.qmail@ary.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150325200319.43775.qmail@ary.lan> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [dane] email oracle and lookup, was A novel idea X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2015 20:17:10 -0000 On Wed, Mar 25, 2015 at 08:03:19PM -0000, John Levine wrote: > >Any email address oracle service will find its biggest consumer to be > >spammers. I do not think anyone will deploy such on oracle/service. The key acquisition protocol in no way changes the fact that existence of keys discloses existence of addresses. It makes NO difference what protocol is used to find the address -> key mapping. Using something other than DNS just makes it easier to rate control clients, because they are not proxied by their ISP's DNS cache. > On the other hand, I think that a lookup service that takes an address > and returns a key would be workable. Yeah, spammers will try to > scrape addresses from it, but it's the same attack as RCPT TO probing > and we have workable defenses against that. Actually, for the spammer, the DNS is a more attractive oracle, because queries are cheaper and proxied by ISP caches. -- Viktor. From nobody Wed Mar 25 13:19: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 67C5C1A9008 for ; Wed, 25 Mar 2015 13:19:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.366 X-Spam-Level: X-Spam-Status: No, score=-1.366 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, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZeC-ASs50KxU for ; Wed, 25 Mar 2015 13:19:36 -0700 (PDT) Received: from homiemail-a16.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 6975F1A8738 for ; Wed, 25 Mar 2015 13:19:36 -0700 (PDT) Received: from homiemail-a16.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a16.g.dreamhost.com (Postfix) with ESMTP id 09F5A50808D; Wed, 25 Mar 2015 13:19:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=Dxc7Gt+kXODkOF BxfxNjV2TjCtE=; b=WQ2Me2rGO9HKp6eVwFczyVSNEcQJBdVDgesBt4p3jA4B4c hQxtD27F1iaFj67wYwg6OF3V8ibDeiKmTb2HngaahvRJMBxysoGn32g+YzSfv7ff D35g6XuYpSZKuI7fJrTyqtZeADa9bt6zh/77LluXDfNHmec3V2gXIrj/3kAmY= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a16.g.dreamhost.com (Postfix) with ESMTPA id 3160050805F; Wed, 25 Mar 2015 13:19:33 -0700 (PDT) Date: Wed, 25 Mar 2015 15:19:33 -0500 From: Nico Williams To: John Levine Message-ID: <20150325201932.GF10960@localhost> References: <20150325164417.GA10960@localhost> <20150325200618.43798.qmail@ary.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150325200618.43798.qmail@ary.lan> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: dane@ietf.org Subject: Re: [dane] =?utf-8?q?wrt_How_to_look_up_KEY=E2=80=99s__for_Email_addr?= =?utf-8?q?esses?= X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 25 Mar 2015 20:19:37 -0000 On Wed, Mar 25, 2015 at 08:06:18PM -0000, John Levine wrote: > >Problem: DNS (even with DNSPRIV) is much more light-weight than any > > service that uses TLS. > > You're going to use the result to send mail messages. Why does the > lookup need to be a lot faster than sending the mail message? Good point. Never mind that. From nobody Wed Mar 25 13:30:48 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94B5F1B2B83 for ; Wed, 25 Mar 2015 13:30:47 -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 Z24xx6uAa2BW for ; Wed, 25 Mar 2015 13:30:45 -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 54CDF1B2B79 for ; Wed, 25 Mar 2015 13:30:45 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3lC1Kr47wJzGXD for ; Wed, 25 Mar 2015 21:30:40 +0100 (CET) Authentication-Results: mx.nohats.ca; dkim=pass (1024-bit key) header.d=nohats.ca header.i=@nohats.ca header.b=u1npFuE0 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 5V4BbecEh17v for ; Wed, 25 Mar 2015 21:30:38 +0100 (CET) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS for ; Wed, 25 Mar 2015 21:30:38 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 4E16B80A01 for ; Wed, 25 Mar 2015 16:30:37 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1427315437; bh=eeWSNz0Vki796WtOWAKJtcMi4W6SRWFyjqWCcgT5utk=; h=Date:From:To:Subject:In-Reply-To:References; b=u1npFuE00w3Dlh0OQt0xx9jUddBRLYkBQKCWnuC2j6wlANxt2usoRt591gLz+WIDG uLmhzLmaegaCiEuu3jIpWkh2+J3Ot9Vn4JewCqSWPgFUqgDgYsh763aayGaeVJ+Eym TX9w/9gS+2f2cnEMHeiVRZIH3WBw7dpN/F5ZdlNc= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id t2PKUaCA014822 for ; Wed, 25 Mar 2015 16:30:37 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Wed, 25 Mar 2015 16:30:36 -0400 (EDT) From: Paul Wouters To: dane@ietf.org In-Reply-To: <20150325201704.GM21586@mournblade.imrryr.org> Message-ID: References: <20150325200319.43775.qmail@ary.lan> <20150325201704.GM21586@mournblade.imrryr.org> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [dane] email oracle and lookup, was A novel idea X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 25 Mar 2015 20:30:47 -0000 On Wed, 25 Mar 2015, Viktor Dukhovni wrote: > It makes NO difference what protocol is used to find the address > -> key mapping. Using something other than DNS just makes it easier > to rate control clients, because they are not proxied by their > ISP's DNS cache. You mean it makes it easier to DDOS with a botnet. Either it will be some UDP protocol with no state, vulnerable to spoofing, or it will be some TCP protocol with state, vulnerable to resource starvation. Attacks will just take out the oracle to induce plaintext, or will spoof causing a lockout of real clients inducing those end up using plaintext. >> On the other hand, I think that a lookup service that takes an address >> and returns a key would be workable. Yeah, spammers will try to >> scrape addresses from it, but it's the same attack as RCPT TO probing >> and we have workable defenses against that. > > Actually, for the spammer, the DNS is a more attractive oracle, > because queries are cheaper and proxied by ISP caches. Recursors and Authoritative servers supporting OPENPGPKEY or SMIME could rate limit the sending of NSEC3 chains if there are too requests for non-existing records - causing them to need to go back to the current RCPT TO practise. Paul From nobody Wed Mar 25 13:46: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 D2BCF1A1B34 for ; Wed, 25 Mar 2015 13:46:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BCg2xPJSwsVc for ; Wed, 25 Mar 2015 13:45:59 -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 4CCC61A00D8 for ; Wed, 25 Mar 2015 13:45:59 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id EC791283015; Wed, 25 Mar 2015 20:45:57 +0000 (UTC) Date: Wed, 25 Mar 2015 20:45:57 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20150325204557.GN21586@mournblade.imrryr.org> References: <20150325200319.43775.qmail@ary.lan> <20150325201704.GM21586@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] email oracle and lookup, was A novel idea X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2015 20:46:01 -0000 On Wed, Mar 25, 2015 at 04:30:36PM -0400, Paul Wouters wrote: > On Wed, 25 Mar 2015, Viktor Dukhovni wrote: > > >It makes NO difference what protocol is used to find the address > >-> key mapping. Using something other than DNS just makes it easier > >to rate control clients, because they are not proxied by their > >ISP's DNS cache. > > You mean it makes it easier to DDOS with a botnet. Either it will > be some UDP protocol with no state, vulnerable to spoofing, or > it will be some TCP protocol with state, vulnerable to resource > starvation. We've designed the protocol yet. The server can be UDP/stateless, and yet not be subject to spoofing, and can vend client cookies (for example) to protect against origin spoofing. The issues you raise are important when considering the choice/design of the protocol. > Attacks will just take out the oracle to induce plaintext, or will > spoof causing a lockout of real clients inducing those end up using > plaintext. Taking out the oracle will not induce plaintext any more than performing the same attack on the authoritative DNS server for the domain. User keys would have very short TTLs (positive and negative, to address cache explosion), so a large fraction of queries will go end-to-end from the MUA to the authoritative server. > >Actually, for the spammer, the DNS is a more attractive oracle, > >because queries are cheaper and proxied by ISP caches. > > Recursors and Authoritative servers supporting OPENPGPKEY or SMIME could > rate limit the sending of NSEC3 chains if there are too [many] requests for > non-existing records - causing them to need to go back to the current > RCPT TO practise. Will the recursive servers do that? In practice they'll not have any code to support these RR types specifically, the new RR types will just be handled by the generic RR code. Any harvesting defense is I think more likely to be deployed effectively at the target server, rather than by thousands of proxies operated by 3rd parties. -- Viktor. From nobody Wed Mar 25 14:00: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 4E9641B2C11 for ; Wed, 25 Mar 2015 14:00:53 -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 xfYyhAtAPPWD for ; Wed, 25 Mar 2015 14:00:52 -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 9458B1A0058 for ; Wed, 25 Mar 2015 14:00:51 -0700 (PDT) Received: from homiemail-a103.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a103.g.dreamhost.com (Postfix) with ESMTP id 4A0272005E626 for ; Wed, 25 Mar 2015 14:00:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:subject:message-id:references:mime-version:content-type :in-reply-to; s=cryptonector.com; bh=gMfVDS8YJ8SzXPhKkdSWv6K9KVg =; b=tpDEdWsn2/UGxWJPi2SHAnnGgOSG5nsUhfCBAmBakDD54ftZa+0BUdJ/zwN A8hRa3CYNeadyGg3JGh4jolBozHoeHPxETB+VpytM8VW5yS31+WGT0+56+JicCEi 38tdPXysbCpVU+VFigGnh6fYHQGiu4eGkpnu38bFgnUhzt04= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a103.g.dreamhost.com (Postfix) with ESMTPA id E690B2005E625 for ; Wed, 25 Mar 2015 14:00:50 -0700 (PDT) Date: Wed, 25 Mar 2015 16:00:49 -0500 From: Nico Williams To: dane@ietf.org Message-ID: <20150325210048.GG10960@localhost> References: <20150325200319.43775.qmail@ary.lan> <20150325201704.GM21586@mournblade.imrryr.org> <20150325204557.GN21586@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150325204557.GN21586@mournblade.imrryr.org> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [dane] email oracle and lookup, was A novel idea X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 25 Mar 2015 21:00:53 -0000 On Wed, Mar 25, 2015 at 08:45:57PM +0000, Viktor Dukhovni wrote: > On Wed, Mar 25, 2015 at 04:30:36PM -0400, Paul Wouters wrote: > > On Wed, 25 Mar 2015, Viktor Dukhovni wrote: > > Attacks will just take out the oracle to induce plaintext, or will > > spoof causing a lockout of real clients inducing those end up using > > plaintext. > > Taking out the oracle will not induce plaintext any more than > performing the same attack on the authoritative DNS server for the > domain. User keys would have very short TTLs (positive and negative, > to address cache explosion), so a large fraction of queries will > go end-to-end from the MUA to the authoritative server. Not only that, but it will be easier for MUAs to give the user feedback as to what went wrong in such a protocol than in DNS. > > Recursors and Authoritative servers supporting OPENPGPKEY or SMIME could > > rate limit the sending of NSEC3 chains if there are too [many] requests for > > non-existing records - causing them to need to go back to the current > > RCPT TO practise. Not having to worry about zone walking for this is a plus. Nico -- From nobody Wed Mar 25 14:17: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 F34ED1A00D8 for ; Wed, 25 Mar 2015 14:17:42 -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 Ci3VNIUDx5VK for ; Wed, 25 Mar 2015 14:17: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 B21E61A0058 for ; Wed, 25 Mar 2015 14:17:41 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 9B39F283015; Wed, 25 Mar 2015 21:17:40 +0000 (UTC) Date: Wed, 25 Mar 2015 21:17:40 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20150325211740.GO21586@mournblade.imrryr.org> References: <5512D4F3.70803@powerdns.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5512D4F3.70803@powerdns.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [dane] A novel idea on the local-part problem for both SMIMEA and OPENPGPKEY? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2015 21:17:43 -0000 On Wed, Mar 25, 2015 at 04:32:03PM +0100, Pieter Lexis wrote: > Now, the IETF has standardized a mechanism to do discovery like this in > the form of webfinger, RFC7033[1]. This would allow an MTA/MUA to lookup > the full recipient address (in the format given by the end user) at the > webfinger server of that domain. This server could do the > casefolding/aliasing using the defined 'aliases' field in the response body. THe problem with canonicalizing addresses (akin to EXPN) is that most sites simply won't want to publish this data. Returning a key is very different from returning a "canonical address". Any alternative protocol should just return the SMIME or PGP key for the address, and avoid returning any intermediate "canonical" addresses used to locate those. -- Viktor. From nobody Wed Mar 25 14:58: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 CFD981A8AA4 for ; Wed, 25 Mar 2015 14:58:54 -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 8ocB96ALQRxH for ; Wed, 25 Mar 2015 14:58:53 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 258051A87C3 for ; Wed, 25 Mar 2015 14:58:53 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3lC3HX5rTqzDYj for ; Wed, 25 Mar 2015 22:58:48 +0100 (CET) Authentication-Results: mx.nohats.ca; dkim=pass (1024-bit key) header.d=nohats.ca header.i=@nohats.ca header.b=n3XmH8aT 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 Tsb4iqWti8qH for ; Wed, 25 Mar 2015 22:58:47 +0100 (CET) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS for ; Wed, 25 Mar 2015 22:58:47 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 3A0B6803E0 for ; Wed, 25 Mar 2015 17:58:46 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1427320726; bh=yV1JFZm/nzaA2yYghfFRUT5pHSErSG1LxxAbVU5JIo8=; h=Date:From:To:Subject:In-Reply-To:References; b=n3XmH8aTOq5RawQmcHIRNw5Av/JrYgqjDRdPjbOeIV/+ICuz5f9pC+A8Ruulpwcp9 ShQtPBbd9n4qgqdoLqzBJIeyWvNLfOgsnGSarWHDldPhjSnkIPvpOI+4hVToDEtiVY 1R+xOwR2JAT3G0WBTSlUWS5ndqiwZJn1IPWZD0nk= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id t2PLwjaY023069 for ; Wed, 25 Mar 2015 17:58:46 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Wed, 25 Mar 2015 17:58:45 -0400 (EDT) From: Paul Wouters To: dane@ietf.org In-Reply-To: <20150325211740.GO21586@mournblade.imrryr.org> Message-ID: References: <5512D4F3.70803@powerdns.com> <20150325211740.GO21586@mournblade.imrryr.org> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [dane] A novel idea on the local-part problem for both SMIMEA and 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: Wed, 25 Mar 2015 21:58:55 -0000 On Wed, 25 Mar 2015, Viktor Dukhovni wrote: > THe problem with canonicalizing addresses (akin to EXPN) is that > most sites simply won't want to publish this data. Returning a > key is very different from returning a "canonical address". > > Any alternative protocol should just return the SMIME or PGP key > for the address, and avoid returning any intermediate "canonical" > addresses used to locate those. You realise the openpgp key will likely contain any correct IDs right? So if your protocol maps Paul@nohats.ca to paul@nohats.ca and returns the pgp key, they will know the "canonical" address. The more helpful you are mapping to a key (like for "pal@nohats.ca" ?) the easier it is to obtain email addresses. Email addresses (like DNS data) are simply not a secret. Those who value hidden email addresses without OPENPGPKEY support can surely continue to operate as they do now. Paul From nobody Wed Mar 25 15:12: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 341691A039A for ; Wed, 25 Mar 2015 15:12:17 -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 OTIfEFE-i-xZ for ; Wed, 25 Mar 2015 15:12:15 -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 975D91A0390 for ; Wed, 25 Mar 2015 15:12:15 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3lC3b05k2SzGXD; Wed, 25 Mar 2015 23:12:12 +0100 (CET) Authentication-Results: mx.nohats.ca; dkim=pass (1024-bit key) header.d=nohats.ca header.i=@nohats.ca header.b=Z6S2OEAt 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 1HlaWFaQrdBy; Wed, 25 Mar 2015 23:12:11 +0100 (CET) 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, 25 Mar 2015 23:12:11 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id D36B5803E0; Wed, 25 Mar 2015 18:12:10 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1427321530; bh=GvsVzsgAqA0GpBaBzO3mg990ZOV00x4fStJ4cUtGByM=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=Z6S2OEAtmAVKFSFlPT416yGKI69tKultZup+m1HMQz0eM+z6MEQAw7WOHqKJgoB5q WOgo34WsE7u+30luxH/qJIcp2r2yyTjbnuzajKxQrzMwVBIqSNyoWy48v33sdQM8mo PJFIg/wqJXRB4F0IzQ4U7wORvhqzzKtm0Me2A3Ss= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id t2PMCAOI001983; Wed, 25 Mar 2015 18:12:10 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Wed, 25 Mar 2015 18:12:10 -0400 (EDT) From: Paul Wouters To: Nico Williams In-Reply-To: <20150325210048.GG10960@localhost> Message-ID: References: <20150325200319.43775.qmail@ary.lan> <20150325201704.GM21586@mournblade.imrryr.org> <20150325204557.GN21586@mournblade.imrryr.org> <20150325210048.GG10960@localhost> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: dane@ietf.org Subject: Re: [dane] email oracle and lookup, was A novel idea X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 25 Mar 2015 22:12:17 -0000 On Wed, 25 Mar 2015, Nico Williams wrote: > > On Wed, Mar 25, 2015 at 08:45:57PM +0000, Viktor Dukhovni wrote: >> On Wed, Mar 25, 2015 at 04:30:36PM -0400, Paul Wouters wrote: >>> On Wed, 25 Mar 2015, Viktor Dukhovni wrote: >>> Attacks will just take out the oracle to induce plaintext, or will >>> spoof causing a lockout of real clients inducing those end up using >>> plaintext. >> >> Taking out the oracle will not induce plaintext any more than >> performing the same attack on the authoritative DNS server for the >> domain. DNS servers are pretty good at withstanding attacks. Entire business models have sprouted up deploying this. We have redundant DNS servers and redundant MX hosts. So it's basically mandatory to run redundant oracle servers. This whole oracle idea is gaining FTE's pretty fast in both design and implementation and it is an insane cost for a pretty imaginary use case of typing in an email address that might be wrong which must be corrected. >> User keys would have very short TTLs (positive and negative, >> to address cache explosion), so a large fraction of queries will >> go end-to-end from the MUA to the authoritative server. I think you should let cache management policies be decided by the cache? For privacy reasons, some publishers might want to use a high TTL. Revocation is not much of a problem since most of these keys are years or decades old without people updating those keys before using them again to see if the key was revoked. > Not only that, but it will be easier for MUAs to give the user feedback > as to what went wrong in such a protocol than in DNS. Which user? openpgpkey-milter operates without an interactive user. >>> Recursors and Authoritative servers supporting OPENPGPKEY or SMIME could >>> rate limit the sending of NSEC3 chains if there are too [many] requests for >>> non-existing records - causing them to need to go back to the current >>> RCPT TO practise. > > Not having to worry about zone walking for this is a plus. Again, no one is making this mandatory to deploy. If you rather have your users semi-hidden with plaintext email, keep calm and continue as you are now. If there are people who want to design and deploy oracles, go ahead and write a document. OPENPGPKEY should not _require_ one and still work without any user mapping. And implementations can later be extended to use this new oracle protocol. Paul From nobody Wed Mar 25 15:36: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 0F4CB1A6F39 for ; Wed, 25 Mar 2015 15:36:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.862 X-Spam-Level: X-Spam-Status: No, score=0.862 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AlK-Aq3krzaH for ; Wed, 25 Mar 2015 15:36:43 -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 CA29A1A88D2 for ; Wed, 25 Mar 2015 15:36:42 -0700 (PDT) Received: (qmail 21229 invoked from network); 25 Mar 2015 22:36:40 -0000 Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 25 Mar 2015 22:36:40 -0000 Date: 25 Mar 2015 22:36:18 -0000 Message-ID: <20150325223618.43917.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] email oracle and lookup, was A novel idea X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 25 Mar 2015 22:36:44 -0000 >DNS servers are pretty good at withstanding attacks. Mail servers aren't? We've been under a continuous DDoS from spammers for the past decade and a half. >oracle servers. This whole oracle idea is gaining FTE's pretty fast in >both design and implementation and it is an insane cost for a pretty >imaginary use case of typing in an email address that might be wrong >which must be corrected. At yesterday's session, the "mail crowd" made it pretty clear both that address guessing is not on the table, and the range and usage of variant addresses are far larger than you believe them to be. R's, John From nobody Wed Mar 25 16:11: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 3B7F51A90E8 for ; Wed, 25 Mar 2015 16:11:55 -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 8YRGQhv2crCU for ; Wed, 25 Mar 2015 16:11: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 CBD0E1A82E2 for ; Wed, 25 Mar 2015 16:11:53 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 6B34B283015; Wed, 25 Mar 2015 23:11:52 +0000 (UTC) Date: Wed, 25 Mar 2015 23:11:52 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20150325231152.GP21586@mournblade.imrryr.org> References: <5512D4F3.70803@powerdns.com> <20150325211740.GO21586@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] A novel idea on the local-part problem for both SMIMEA and OPENPGPKEY? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2015 23:11:55 -0000 On Wed, Mar 25, 2015 at 05:58:45PM -0400, Paul Wouters wrote: > >Any alternative protocol should just return the SMIME or PGP key > >for the address, and avoid returning any intermediate "canonical" > >addresses used to locate those. > > You realise the openpgp key will likely contain any correct IDs right? I'm aware of the current design possibly returning usernames in addition to key material. Not clear whether that's a feature, but in any case that happens only for users with keys. I was responding only to a suggestion of running a pure canonicalization service, which would then canonicalize also names with no keys. Similarly SMIME certs often contain email addresses. Though with SMIME (CMS), the recipient info from which key copies are decrypted is identified by "IssuerAndSerialNumber" or "SubjectKeyIdetifier"), so one *can* create certs for SMIME encryption that contain only opaque identity information. I don't know how recipient key copies are identified in PGP. -- Viktor. From nobody Wed Mar 25 16:59: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 8E23A1A8822 for ; Wed, 25 Mar 2015 16:59: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, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Su2kKh-tk2a1 for ; Wed, 25 Mar 2015 16:59:03 -0700 (PDT) Received: from mail-qg0-f99.google.com (mail-qg0-f99.google.com [209.85.192.99]) (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 C69781A92EF for ; Wed, 25 Mar 2015 16:59:02 -0700 (PDT) Received: by qgfl89 with SMTP id l89so1079361qgf.0 for ; Wed, 25 Mar 2015 16:59:02 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:thread-topic:thread-index:date :message-id:references:in-reply-to:accept-language:content-language :content-type:mime-version; bh=nfAnuccC1lKuWZYbyXe92EyPlFFU37B4lNxA9OfxSJc=; b=WZXepSutsqrAPVjrZztwnrThZTfbG3eSapLSTKSLlGD7JVLTDvw6F/K5oGpSkFh8/y eQArhSvGktyOWIk0srKg+FNlO1i4XDwvo0KyMQEDXU2W9SODbo0P8pHenXctu5XGo16G XokHU7qDSjqDPwW7BwC9tiQv16BrqwDpgdnDXupdygYTNny9evdJG5W4Pn4llnV64qT6 w+4PCiTVj+v6yG4As025C6zByJoiHkinm44cfgh6PXvCwTp7J+KjSGn7OoY1WONdysEh ktqRfPDkgxiKzU8qlwudhK0uZAeLB0yeJztHBCTCKkdlvgeNgx8nTZt9jgSRG9nDHFAZ m7ag== X-Gm-Message-State: ALoCoQnhK1vPB/hGpmOuh4NqiK/aJ9R1N62+mHs9imqjfkr3gOee/xtGa+fRCNSvrlW8lqQ7RKuflCdpGUBBnEteAmJAAzd3Pw== X-Received: by 10.55.16.83 with SMTP id a80mr24289238qkh.86.1427327942034; Wed, 25 Mar 2015 16:59:02 -0700 (PDT) Received: from brn1lxmailout02.verisign.com (brn1lxmailout02.verisign.com. [72.13.63.42]) by mx.google.com with ESMTPS id hx9sm164792qcb.3.2015.03.25.16.59.01 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 25 Mar 2015 16:59:02 -0700 (PDT) X-Relaying-Domain: verisign.com Received: from brn1wnexcas02.vcorp.ad.vrsn.com (brn1wnexcas02 [10.173.152.206]) by brn1lxmailout02.verisign.com (8.13.8/8.13.8) with ESMTP id t2PNx1Z7029116 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 25 Mar 2015 19:59:01 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas02.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Wed, 25 Mar 2015 19:59:01 -0400 From: "Osterweil, Eric" To: dane WG list Thread-Topic: [dane] IPSECA Thread-Index: AQHQZoTinYEJkFr5c0a1jug9i2S9ww== Date: Wed, 25 Mar 2015 23:58:59 +0000 Message-ID: <63BED3F2-B829-45C3-B380-37E7C52C53F1@verisign.com> References: <9735F7C2-D87A-4A33-9302-49C54A644EDA@verisign.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: multipart/signed; boundary="Apple-Mail=_50447450-3FA2-4ACE-A104-5EBA73AF019A"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Archived-At: Subject: Re: [dane] IPSECA X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 25 Mar 2015 23:59:07 -0000 --Apple-Mail=_50447450-3FA2-4ACE-A104-5EBA73AF019A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Paul, Nico, and Jim, Thank you all, very much, for your detailed feedback on the IPSECA = draft. The draft authors and I have met and are preparing a very major = overhaul of the current text and our related prototypes. We are = addressing the excellent comments and will have the -03 version out = within four weeks. Thanks again for the feedback! Eric On Mar 25, 2015, at 1:29 PM, Paul Wouters wrote: > On Tue, 24 Mar 2015, Osterweil, Eric wrote: >=20 >> Given the discussion on milestones re: IPSEC DANE work at the = beginning of the DANE session today we=92d like to request working group = adoption of the existing IPSECA document: >> https://tools.ietf.org/html/draft-osterweil-dane-ipsec-02 >>=20 >> We=92ve been working on a couple of different flavors of = implementation. We=92re hoping to push those out soon too and it=92s = already benefited from a great deal of discussion here, and we believe = it=92s definitely ready to become a WG product. >=20 > TL;DR - This document makes a straight copy of the TLSA record and > assumes host based IKE/IPsec works like application based TLS. > It handwaves the IKE protocol and isn't clear why it is = limiting > itself to DNS, or what DNS traffic it wants to protect or how = it > could ever do a secure bootstrap. It still does not support > NAT'ed clients or (DNS) servers and does not explain the AUTH > and ID payload that the client is supposed to send during IKE. > It does not explain what traffic selectors are used on the = IPsec > SAs. It provides no defense against DOS attacks. It suffers = from > a great disconnect with the IPsecME Working Group. I do not > support adopting this document. >=20 > I have reviewed this document before and most of my concerns still > stand: >=20 > https://www.ietf.org/mail-archive/web/dane/current/msg06436.html >=20 > It's good to see that my conversation with Eric resulted in the = removal > of the insecure gateway option. But more serious fundamental problems > remain in this draft. Specifically: >=20 > 1) Limiting the scope of IPsec protection using DANE to only one > protocol or one application makes no sense in an IPsec context. >=20 > 2) This draft is not sure if it wants to be generic (IPSECA vs > IPSECDNSA) or specific (IPSECA on _53.* =3D=3D IPSECDNSA) >=20 > 3) If you want to protect DNS using IPsec, just use an IPsec > host-to-host tunnel and have the DNS server filter port <> 53. > That allows for this method to be usable for endusers with the > technical knowledge of watching netflix on any currently deployed > device (iphone, android, windows, OSX, Linux, etc without needing = any > new RFC or patents. Google could use publish an IPSECKEY with "." > gateway in the reverse of 8.8.8.8 and the forward of dns.google.com. >=20 > 4) _53.example.com makes no sense. Is this UDP, TCP or both. Are = traffic > selectors in use? Are you aware traffic selectors cannot have 2 > protocols and that you will end up requiring multiple child SA's? >=20 > 5) IPSECA is basically the same as the TLSA record. It incorrectly > assumes that X.509 is the only method of authentication desired. >=20 > 6) It takes about "interaction" with the SPD without understanding or > specification. It does not clarify what the IKE daemon is supposed = to > do - or if it intends to extend the PF_KEY API. >=20 > 7) Hoes does this document support the clients remaining anonymous? It > fails to specify the IKE negotiation and AUTH and ID payloads = involved. >=20 > Section 1.1 >=20 > "This can be especially complicated > if different IPsec certificates need to be discovered for different > services that are running on the same IP address." >=20 > What is an "IPsec certificate"? Why do you need more than one? > What AUTH method does the client use to (not) identify itself? > How are traffic selectors negotiated? ANY to 53 ? >=20 > "This can become > complicated if certificates are learned solely by the IP addresses = of > networked-services. " >=20 > [and all of section 1.2] >=20 > dns.google.com. IN IPSECKEY ...... >=20 > This section, which is the justification of this document is based on > the misconception that public IPsec keys can currently only be = discovered > by IP address. >=20 > "The advantages of using DANE for IPsec OE " >=20 > What is "DANE for IPsec OE" ? I guess OE means Opportunistic = Encryption. > Note the lack of "for DNS" in the description here. Are we talking = about > DNS or generic _XXX.example.com protection? >=20 > "Such as, the automatic deauthorization of certificates > that happens when they are removed from a DNS zone" >=20 > There is no text describing what clients should do once they learned > this certificate from DNS and connect. Isn't it valid until its X.509 > signature if certain Usage Types that include PKIX validation are = used? >=20 > Section 1.3: >=20 > "using a specific key exchange protocol, like [RFC2409], [RFC5996], = etc." >=20 > RFC2409 is suggesting using IKEv1. IKEv1 has been obsoleted by IKEv2 > since RFC 4305 in 2005. The IPsecME WG has a very strict policy that > no new documents related to IKEv1 be published. (again this = illustrates > the disconnect of the authors of this document and the IPsecME WG) >=20 > "when it receives a referral it SHOULD query name servers for > corresponding IPSECA resource records." >=20 > What is "receives a referral" ? Is this suggesting the client > implementing this document attempts to talk IPsec to every new NS = record > target it receives? Or is it meant to talk about a DHCP Nameserver > option? The end of the document suddenly talks about protecting > authoritative servers in the example section, so I think it means when > it receives a delegation via NS. If so, how will it find IPSECA = records > _to_ that server without first talking to that server in the clear? Is > this record support to live in the parent like the DS record? If not, > how does the DNS server and IKE/IPsec server interact when the record = is > received to kick start the IPsec encryption? And how does a new query > get handled when the IPSECA record expired from the local cache? >=20 > "that resolver SHOULD follow its configurations and setup an SPD = entry," >=20 > This is really just handwaving, "and it should do some IPsec magic". > This really needs to say what IKE parameters are being negotiated and > what outcome is expected. And what to do when the IKE negotiation > fails and what to do during IKE negotiation and how the DNS server and > IKE server can possibly coordinate these actions. >=20 > "Note, this document does not specify a new, or any modifications > to any existing, IPsec key exchange protocols." >=20 > "Rather, after adding an SPD and after a > successful tunnel establishment, the credentials used for the > Security Association with the name server SHOULD be cross-checked > with the IPSECA resource record(s)." >=20 > First of all, one does not "add an SPD entry". Second of all, if you > reach the point in the IKE protocol where you update the SPD/SAD > database, it means the kernel is told to encrypt/decrypt packets. That > is, the IPsec tunnel is fully up and running. There is no more IKE > to be done. Saying one should THEN cross-check the X.509 AUTH payloads > of IKE is completely invalid AND a serious breach of the IKE protocol. >=20 > "When using IPSECA resource records to verify OE tunnels, clients = MUST > perform full DNSSEC validation of the DNSSEC chain of trust that > leads to IPSECA RRs." >=20 > If using IPsec fails, the DNS client is going to send cleartext = packets > anyway. Wouldn't a non-DNSSEC IPSECA record provide more privacy than > just defaulting to clear? [Hint, read draft-ipsecme-ikev2--auth-null > and RFC 7435] >=20 > "certificate association for [IPsec]" >=20 > "If the DNSSEC validation state on the response to the request = for > the [IPSECA] RRSet is bogus, this MUST cause IPsec not to be > started or, if the IPsec negotiation is already in progress, MUST > cause the connection to be aborted." >=20 > The use of "certificate association for [IPsec]", "IPsec not to be > started" and "IPsec negotiation" again shows the workings of IKE = versus > IPsec are not understood. >=20 > "Trust anchors (which may be distributed during dynamic host = configuration)" >=20 > I guess that would be a whole set of RFC's in itself. How can one > securely obtain trust anchors via DHCP? Because the DNSOPS and HOMENET > people would also love to get that going. >=20 > "The intuition behind this reasons > that if the first (configuration) step was already where the local > resolver was configured, then the security of the DNS transactions > already hinged on learning the valid resolver this way. " >=20 > Here, the document suggest that after describing all these security > MUST's related to DNSSEC, the whole chain of trust starts with a > completely insecure DHCP packet. Again, you might as well just do > draft-ipsecme-ikev2--auth-null at that point. This undermines all the > previous security requirements required in this section. >=20 > "So, this > step is already used to convey trusted configurations > (bootstrapping)." >=20 > Uhm no. No one has ever claimed DHCP is "trusted". >=20 > "Adversaries attempting to subvert an end host have > only the narrow attack window that is associated with learning > configurations. " >=20 > Uhm no. And even so.. >=20 > Section 2 >=20 > "The IPSECA resource record is modeled heavily off of the IPSECKEY = RR" >=20 > That is no longer true with the removal of the gateway option. The = only > things left now are TLSA items. In fact, it's now identical to a TLSA > record and the new IANA registry created by this document would also > be an unnecessary duplication. >=20 > Section 2.1 >=20 > References to ietf-dane-registry-acronyms should be updated to be RFC = 7218 >=20 > Section 2.2 >=20 > This does not show the presentation format. Note that there is not = even > a section describing the wire format. >=20 > Section 2.3 >=20 > See above regarding completely missing the traffic selectors and = multiple Child SA's > issues. >=20 > Section 2.4: >=20 > "They MAY > be used in verifying Security Associations, but a protocol to do = this > is beyond the scope of this document." >=20 > I do not understand what is being said here. >=20 > Section 2.4.1: >=20 > Suppose a DNS zone example.com is served by the name servers > ns1.example.com and ns2.example.com. If the zone operators want to > advertise their willingness to offer OE to their name servers using > IKEv2 [RFC5996], then the following domain names MUST be placed = under > the example.com zone >=20 > Ok, so now out of nowhere we are talking about Authoritative Servers, > and not recursive ones. That would require its own section with a very > important component on security and how to prevent DOS attacks. Not > only that, note the "under". To talk securely to ns1.nohats.ca, you = need > to talk insecurely to ns1.nohats.ca to get the IPSECA record, where = upon > you will get almost all records related to nohats.ca in the clear. In > other words, by the time your tunnel is setup, 90% of the DNS traffic > has already happened in clear text. (Unless you want to put the IPSECA > record in the parent zone like the DS record - if you want to do that, > you'll have to go to dnsops) >=20 > This example illustrates how a zone MAY indicate where an SPD entry > and SA establishment endpoints exist for its name servers (note, = they > are not required to be the name servers themselves). >=20 > So if these are not the nameservers themselves, where do I send the = port > 53 query to? This is probably an artifact of the now removed gateway > option. >=20 > "the IPsec certificate" >=20 > IPsec has no certificates. You mean IKE. >=20 > Section 3 >=20 > First of all, this section completely misses the bootstrap issue or = how > one is to lookup IPSECA records if one is trying to setup IPsec to its > only DNS server. >=20 > If a resolver enables OE, but no (or relatively few) name = servers > provision IPSECA records, then no IPsec tunnels will be > established, and the load will remain static (or marginally > increase). >=20 > This is a weird statement. "If we are not successful in deploying this > as a standard, there will be no scalability issues" >=20 > If an authoritative name server provisions IPSECA record, it = will > only result in additional load if querying resolvers are > configured to attempt OE. >=20 > And again. "If nothing bad happens and we don't deploy much, we're = good". >=20 > Using white-listing techniques (such as those used during pilot > deployments of AAAA records) would allow authoritative name > servers to only return IPSECA responses to clients that have = been > white-listed. >=20 > Hoes does that work when the zones are (as is mandated by this = document) > DNSSEC signed? You would be returning BOGUS results or need to have = two > signed zones to return signed answers. Which any attacker could then > replay to the user to force them onto the clear text version of DNS. >=20 > This section is completely missing the actual DOS and load issues that > can be expected to happen. >=20 > Section 4 >=20 > Any future use or modification of an IANA registry for that resource > record will have similar effects on this resource record. >=20 > This only shows again that this document should not be defining IPSECA > which is just a copy of TLSA. >=20 > Section 5 >=20 > This section does not actually address the real concerns. It does not > talk about fallback to clear versus hard fail. It does not talk about > handling thousands of IKE SAs and IPsec SAs. >=20 >=20 >=20 >=20 >=20 > Conclusion >=20 > As I stated to the dane chairs before and again during yesterday's > meeting, there are IPsec people working on updating/replacing the = IPSECKEY > RFC. However, proper implementation runs into various complicated = issues, > mostly related to NAT and failure modes, that the authors of this = draft > have not addressed - and frankly needs a lot of discussion in the = IPsecME > working group and not so much in the DANE working group. There are = good > reasons the Libreswan Project has been working on this for a few = months > _without_ submitting a draft. >=20 > For example, as part of moving towards an actual real solution, the > libreswan IPsec team submitted the following draft to the IPsecME WG: >=20 > https://tools.ietf.org/html/draft-antony-ipsecme-oppo-nat-00 >=20 > The split of IKE and IPsec and the fact that applications are not > necessarily aware of the security of the transport when IPsec is used > makes me think that work for this belongs much more in the IPsecME WG > than in the DANE WG. This draft is clearly written by people that lack > enough understanding of IKE and IPsec. >=20 > Creating a solution for IPsec that only protects DNS makes no sense. = IKE > and IPsec is not application level based, but host based. = Additionally, > this document mixes up authoritative and recursive DNS server > protection, resulting in something that works for neither. >=20 > Having been heavily involved in IPsec and DNSSEC for the last 15 > years within the IETF and the opensource community in general, I do = not > appreciate the author's inappropriate joking about patents to me in = the > hallway - especially when this document gives the appearance of being = just > a quick attempt at justifying a pending patent, instead of the authors > actually talking to the IPsec community in an attempt to write = something > that is actually deployable and secure. >=20 > I do not support adopting this document. >=20 > Paul >=20 > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane --Apple-Mail=_50447450-3FA2-4ACE-A104-5EBA73AF019A Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIN7DCCBmAw ggVIoAMCAQICEHaFyweo4MwP0sVNjzk1sxIwDQYJKoZIhvcNAQEFBQAwgcoxCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0aG9yaXplZCB1c2Ug b25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMiBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0 aW9uIEF1dGhvcml0eSAtIEczMB4XDTExMDYwNzAwMDAwMFoXDTIxMDYwNjIzNTk1OVowgckxCzAJ BgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50 ZWMgVHJ1c3QgTmV0d29yazE1MDMGA1UECxMsQ2xhc3MgMiBNYW5hZ2VkIFBLSSBJbmRpdmlkdWFs IFN1YnNjcmliZXIgQ0ExQzBBBgNVBAMTOlN5bWFudGVjIENsYXNzIDIgU2hhcmVkIEludGVybWVk aWF0ZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQC3+D8MK4MjIIWmTUkBUTra3VAzvuMEpDo+o2FmTDTC6HRwdUmlt0ns3bOSnN15DeK5+rg5PL6F 44zvbXmjprcIv5xMvj6YjqzbfJor7AUoMF8pGzNNRNVw6FYimaY+nUJb6yOnY50tLLAuPxjzKc0a NomEksdXcFtwheY4oXxQ4zc4iGVba8s5KgSxgqoZBP+gfz+j25FFdmaja/OFI15O2YVddaegFffB AHTg5cqUQmWawjd6i6hQrL+XdGd30TKnr43Lk6klQrQwGnQK4iUQEMt0Z1UPyxT8QVAKpHxNCwv5 Bak1+UWnMfGAu6LJPs52OeEq/3ZQ5+hRIt8tz7gzAgMBAAGjggI/MIICOzASBgNVHRMBAf8ECDAG AQH/AgEAMDQGA1UdHwQtMCswKaAnoCWGI2h0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTItZzMu Y3JsMA4GA1UdDwEB/wQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRVmVyaVNpZ25NUEtJ LTItNTYwHQYDVR0OBBYEFNhIKahfKheS4vqee+9vYIP4uLjcMIHwBgNVHSMEgegwgeWhgdCkgc0w gcoxCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4gLSBGb3Ig YXV0aG9yaXplZCB1c2Ugb25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMiBQdWJsaWMgUHJp bWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEczghBhcMtJjF+YRSnnsKbZUFt6MDQGCCsG AQUFBwEBBCgwJjAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AudmVyaXNpZ24uY29tMGwGA1UdIARl MGMwYQYLYIZIAYb4RQEHFwIwUjAmBggrBgEFBQcCARYaaHR0cDovL3d3dy5zeW1hdXRoLmNvbS9j cHMwKAYIKwYBBQUHAgIwHBoaaHR0cDovL3d3dy5zeW1hdXRoLmNvbS9ycGEwDQYJKoZIhvcNAQEF BQADggEBAKYqmwdAyez/s4joRdo00RcPKC23pYVnMc3B5tUphjis4vBZGwzhoUXOJHjvacGwTGGi SNloT7r+dVQ3ulhp6sF2pTZC6p5meJAg2ZVqJHlUzd5aGoo7rhiVctAl2NJGvjQwp4Ce8VbOIB5s Z8lNT3mHieIugNae7SZhZaID0MXi8yi5K0lpgmfs1ek0pC7cYiKkhU1I42oClPLN/eRnyEm8qtXH 5zzeh7EQa10HXBnka6D0T5nL3LVbDMwy+WrkdMAqWDd5s/vNwzRv4XbdEAcAY4sHTicXkkebDr7e DROFEfyiL2V9zDqsHlRrVmfE7qWHIiMXK3BWw/Gud1wnwTkwggeEMIIGbKADAgECAhBcCMgDVFpl hwRR0TZyMUgoMA0GCSqGSIb3DQEBBQUAMIHJMQswCQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50 ZWMgQ29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdvcmsxNTAzBgNVBAsT LENsYXNzIDIgTWFuYWdlZCBQS0kgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBMUMwQQYDVQQDEzpT eW1hbnRlYyBDbGFzcyAyIFNoYXJlZCBJbnRlcm1lZGlhdGUgQ2VydGlmaWNhdGUgQXV0aG9yaXR5 MB4XDTE0MDQxMDAwMDAwMFoXDTE1MDQxMDIzNTk1OVowczEmMCQGCSqGSIb3DQEJARYXZW9zdGVy d2VpbEB2ZXJpc2lnbi5jb20xGDAWBgNVBAMMD09zdGVyd2VpbCwgRXJpYzEWMBQGA1UECwwNRU5U RVJQUklTRSBJVDEXMBUGA1UECgwOVmVyaVNpZ24sIEluYy4wggEiMA0GCSqGSIb3DQEBAQUAA4IB DwAwggEKAoIBAQCmK2/yLaprGu39usXztz6N7uLYDoKN4MNaDFGGj1eYfMkIfb6LDoYBs9qcnINg 8in4NxGwVQGIJU5AE/1wHe/V1qavpHEO2mVxRq94cBF0P8ETPpM1yhwBhU4QKhjNEDj9wov8RXzO hjqPy/uknZvBxfobQx22vhnEKpf7QEN0zfLDJON3tyYwsnrFZkmop4ni4ANI7ev5uqcI05ED7vSh K9AHAVjzjr2QvtmvqHAkOnpHgqkWJWhuw4f9Gx+8LmbC3tl8oxF7+E7WEwKTQG56BV0uR6PN/o0S O7VSbDCZyNoxxrjzw+CesWsigi2NvC5DnhkKlxP+JSfJxMDu+7MDAgMBAAGjggO7MIIDtzAMBgNV HRMBAf8EAjAAMA4GA1UdDwEB/wQEAwIFoDAWBgNVHSUBAf8EDDAKBggrBgEFBQcDBDAdBgNVHQ4E FgQUVoVKaC1xEPB9EWKq3dWrwskIufkwUAYDVR0RBEkwR4EXZW9zdGVyd2VpbEB2ZXJpc2lnbi5j b22gLAYKKwYBBAGCNxQCA6AeDBxlb3N0ZXJ3ZWlsQHZjb3JwLmFkLnZyc24uY29tMB8GA1UdIwQY MBaAFNhIKahfKheS4vqee+9vYIP4uLjcMIIBcQYIKwYBBQUHAQEEggFjMIIBXzAnBggrBgEFBQcw AYYbaHR0cDovL3BraS1vY3NwLnN5bWF1dGguY29tMIIBMgYIKwYBBQUHMAKGggEkbGRhcDovL2Rp cmVjdG9yeS52ZXJpc2lnbi5jb20vQ04lMjAlM0QlMjBTeW1hbnRlYyUyMENsYXNzJTIwMiUyMFNo YXJlZCUyMEludGVybWVkaWF0ZSUyMENlcnRpZmljYXRlJTIwQXV0aG9yaXR5JTJDT1UlMjAlM0Ql MjBDbGFzcyUyMDIlMjBNYW5hZ2VkJTIwUEtJJTIwSW5kaXZpZHVhbCUyMFN1YnNjcmliZXIlMjBD QSUyQ09VJTIwJTNEJTIwU3ltYW50ZWMlMjBUcnVzdCUyME5ldHdvcmslMkNPJTIwJTNEJTIwU3lt YW50ZWMlMjBDb3Jwb3JhdGlvbiUyQ0MlMjAlM0QlMjBVUz9jQUNlcnRpZmljYXRlO2JpbmFyeTBd BgNVHR8EVjBUMFKgUKBOhkxodHRwOi8vcGtpLWNybC5zeW1hdXRoLmNvbS9jYV8wN2JiN2Q2NDc3 Y2Y0ZjZiZTk2YWYxYjM2Y2FiZDMxNi9MYXRlc3RDUkwuY3JsMGwGA1UdIARlMGMwYQYLYIZIAYb4 RQEHFwIwUjAmBggrBgEFBQcCARYaaHR0cDovL3d3dy5zeW1hdXRoLmNvbS9jcHMwKAYIKwYBBQUH AgIwHBoaaHR0cDovL3d3dy5zeW1hdXRoLmNvbS9ycGEwQgYJKoZIhvcNAQkPBDUwMzAKBggqhkiG 9w0DBzALBglghkgBZQMEAQIwCwYJYIZIAWUDBAEWMAsGCWCGSAFlAwQBKjAsBgpghkgBhvhFARAD BB4wHAYSYIZIAYb4RQEQAQICAQGL8cYJFgYyNDc2NjQwOQYKYIZIAYb4RQEQBQQrMCkCAQAWJGFI UjBjSE02THk5d2Eya3RjbUV1YzNsdFlYVjBhQzVqYjIwPTANBgkqhkiG9w0BAQUFAAOCAQEAXFTS ZEP9la6QYPlo6ybMEEpxVOADx082WRGtrYoU9ZEaC2IlxmwI9JprNfBlIy8FtyJAuWKBbe9/XKJF cukb2HNS0httHUIcSTfMEsAyc99/ba/SoMlhtvko/nCvx5brzhpQwop6AgMv9v5V7F1GUFO7db8L LSs1gIZYI8IeudznJOQGUBFGe0aJhA4cD/3OIZyItWpNtn94i1GJUFPMjYhGcy/r0fUQY/KFLwOi M6bT/m1RwAJKJI/mON/OshdzylAYqKOPoFTJD4qrbrpij1r1+e1VHKklAxTd+nOg9J1L0yRwlEDS 1boeOxqNXGnEYAa54k0ZWPh+8dFemteaLjGCBE0wggRJAgEBMIHeMIHJMQswCQYDVQQGEwJVUzEd MBsGA1UEChMUU3ltYW50ZWMgQ29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5l dHdvcmsxNTAzBgNVBAsTLENsYXNzIDIgTWFuYWdlZCBQS0kgSW5kaXZpZHVhbCBTdWJzY3JpYmVy IENBMUMwQQYDVQQDEzpTeW1hbnRlYyBDbGFzcyAyIFNoYXJlZCBJbnRlcm1lZGlhdGUgQ2VydGlm aWNhdGUgQXV0aG9yaXR5AhBcCMgDVFplhwRR0TZyMUgoMAkGBSsOAwIaBQCgggJDMBgGCSqGSIb3 DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1MDMyNTIzNTkwNFowIwYJKoZIhvcN AQkEMRYEFLuXj4T10JMD94oWccb4zMfUBTtWMIHvBgkrBgEEAYI3EAQxgeEwgd4wgckxCzAJBgNV BAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50ZWMg VHJ1c3QgTmV0d29yazE1MDMGA1UECxMsQ2xhc3MgMiBNYW5hZ2VkIFBLSSBJbmRpdmlkdWFsIFN1 YnNjcmliZXIgQ0ExQzBBBgNVBAMTOlN5bWFudGVjIENsYXNzIDIgU2hhcmVkIEludGVybWVkaWF0 ZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkCEFwIyANUWmWHBFHRNnIxSCgwgfEGCyqGSIb3DQEJEAIL MYHhoIHeMIHJMQswCQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMgQ29ycG9yYXRpb24xHzAd BgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdvcmsxNTAzBgNVBAsTLENsYXNzIDIgTWFuYWdlZCBQ S0kgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBMUMwQQYDVQQDEzpTeW1hbnRlYyBDbGFzcyAyIFNo YXJlZCBJbnRlcm1lZGlhdGUgQ2VydGlmaWNhdGUgQXV0aG9yaXR5AhBcCMgDVFplhwRR0TZyMUgo MA0GCSqGSIb3DQEBAQUABIIBAIVq/gjEDZbpNW2Vuo62UfI4kw9w4KSwxftUOmcHg/pZjMD4ySN/ 0xybO9r+fNpxHg4t1rLdRZ3QlzZFJ2ToJd1bGIrglUGmiGK893mZD/TlY8eGDA4T64AQJdClVjyS Sz8H3trSkOGSCm8ihdkLpTb0+Jtr1PqsgAAO80X2W07PKduGs5MOWB1BYzpvVrKRqUWkLguP5fu3 UR/uqTGB9jnLdNGloc62m6ZQBsXKyCv+xmIeQxmXnKFz9bAI9U/jXN4uxDdF6f/KjOLl/Pfi2ENn qRS2pOVbHXBxnDCkzyAy//qIQ5PetjNDZ8uCPsa8k0m+bFMGIJt8ApSaCPaNN3oAAAAAAAA= --Apple-Mail=_50447450-3FA2-4ACE-A104-5EBA73AF019A-- From nobody Wed Mar 25 16: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 BD9C51A8822 for ; Wed, 25 Mar 2015 16:59:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.566 X-Spam-Level: X-Spam-Status: No, score=-1.566 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 TQ8ApN6Ndlvt for ; Wed, 25 Mar 2015 16:59:20 -0700 (PDT) Received: from homiemail-a64.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 07A4F1A8A90 for ; Wed, 25 Mar 2015 16:59:20 -0700 (PDT) Received: from homiemail-a64.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a64.g.dreamhost.com (Postfix) with ESMTP id C84CF438079; Wed, 25 Mar 2015 16:59:19 -0700 (PDT) Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a64.g.dreamhost.com (Postfix) with ESMTPA id 8429D438072; Wed, 25 Mar 2015 16:59:19 -0700 (PDT) Date: Wed, 25 Mar 2015 18:59:19 -0500 From: Nico Williams To: "Osterweil, Eric" Message-ID: <20150325235917.GI10960@localhost> References: <9735F7C2-D87A-4A33-9302-49C54A644EDA@verisign.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9735F7C2-D87A-4A33-9302-49C54A644EDA@verisign.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: dane WG list Subject: Re: [dane] IPSECA X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 25 Mar 2015 23:59:21 -0000 Also, it appears that part of the motivation for this is to provide confidentiality protection to DNS. The DPRIVE WG is chartered to work on confidentiality protection for DNS queries and responses: http://datatracker.ietf.org/wg/dprive/documents/ Any IPsec-based proposals for DNS confidentiality would seem to belong in DPRIVE WG, not DANE WG. DPRIVE's approach seems to be: secure the stub resolver to recursive resolver connection. IPsec fits in that approach, and all that's needed is traditional IPsec configuration learned from DHCP or DHCP plus DNS. Even then, implementation-wise it's much easier to use TLS[0] as all the current proposals in DPRIVE WG do. For other use cases, IPSECA would only help if it were utterly trivial to use, and -better yet- if it could just be used automatically. But the latter is non-trivial: existing applications use connect() and they don't tell it the name of the server they want to connect to, only an IP address. ISTR hearing someone say that "hey, the system could match lookups to connects", but I don't believe that's a good idea. So you can't have this just happen; new APIs would be required, full stop. [0] Because using IPsec from applications is just ETOOHARD, even for system applications like a name services daemon. Nico -- From nobody Wed Mar 25 18:58: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 04F261A1BF3 for ; Wed, 25 Mar 2015 18:58:37 -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 GL7yPBF8QHJI for ; Wed, 25 Mar 2015 18:58:35 -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 243F11B2B3E for ; Wed, 25 Mar 2015 18:58:29 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3lC8c00StPz9QB; Thu, 26 Mar 2015 02:58:24 +0100 (CET) Authentication-Results: mx.nohats.ca; dkim=pass (1024-bit key) header.d=nohats.ca header.i=@nohats.ca header.b=U42YgY0k 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 HdvwC03DHyDu; Thu, 26 Mar 2015 02:58:21 +0100 (CET) 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, 26 Mar 2015 02:58:21 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 2507D80A01; Wed, 25 Mar 2015 21:58:20 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1427335100; bh=PoQhjNgWt7YfMq/IlqNV0ghjxsK+m2jbJt/Ot2I0vQw=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=U42YgY0kgRbrRx18WCjQxZLYvbwQ99rf4y9+L97KC+AQgx+GJYCp12yW3y9q/9/aP Kgw3631UJPqVW6mC1zNTL4lGy1oMuGQF/yx9K8VtBN44xjT2+sFZzoqHMI7VStbJoO O3DI7ShskNukGOTXklnej9i1EqlcQqtPX6RTcj+g= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id t2Q1wJYK027040; Wed, 25 Mar 2015 21:58:19 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Wed, 25 Mar 2015 21:58:19 -0400 (EDT) From: Paul Wouters To: Nico Williams In-Reply-To: <20150325235917.GI10960@localhost> Message-ID: References: <9735F7C2-D87A-4A33-9302-49C54A644EDA@verisign.com> <20150325235917.GI10960@localhost> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: dane WG list Subject: Re: [dane] IPSECA X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 26 Mar 2015 01:58:37 -0000 On Wed, 25 Mar 2015, Nico Williams wrote: > Any IPsec-based proposals for DNS confidentiality would seem to belong > in DPRIVE WG, not DANE WG. DPRIVE's approach seems to be: secure the > stub resolver to recursive resolver connection. IPsec fits in that > approach, and all that's needed is traditional IPsec configuration > learned from DHCP or DHCP plus DNS. You can already connect using Opportunistic IPsec to oe.libreswan.org using AUTH_NULL, which is as secure as trusting a random key from a random dhcp server. I've added a DNS resolver on it, which is open to anyone that connects with AUTH_NULL IKE/IPsec. Paul From nobody Wed Mar 25 21:38: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 4BEB31A9100 for ; Wed, 25 Mar 2015 21:38:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fdz4XyXlOsLD for ; Wed, 25 Mar 2015 21:38:28 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 40CDB1A9098 for ; Wed, 25 Mar 2015 21:38:28 -0700 (PDT) Received: from [10.9.131.26] (unknown [107.161.181.135]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id B56CC509BB; Thu, 26 Mar 2015 00:38:25 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Sean Leonard In-Reply-To: Date: Wed, 25 Mar 2015 23:38:18 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <40D64A6D-B518-40F2-9556-762839A92A9E@seantek.com> References: <20150318001300.34285.qmail@ary.lan> To: John R Levine , dane@ietf.org X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: Paul Wouters , Paul Hoffman Subject: Re: [dane] Comments on draft-ietf-dane-openpgpkey-02 (fwd) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2015 04:38:30 -0000 On Mar 18, 2015, at 10:23 AM, John R Levine wrote: >>> But I guess I could live with it if the consensus moves this way, = but to >>> me that seems only because I know the MUST NOT will be violated. >=20 >> At first I bristled at John's proposed change, but he's right that = RFC 5321 is completely clear on this topic, and it is a full standard. = And, yes, lots of SMTP applications probably violate the MUST NOT as = well, but that doesn't change it. >=20 > In my experience, people who write mail software understand the opaque = mailbox rule, and try pretty hard to follow it. Some cheat and do case = folding to match Bob@domain to BOB@domain, but I can't think of any that = match bob+foo@domain or b.ob@domain to bob@domain, other than the MTA = that actually knows what the addresses mean. Gmail does not recognize dots as distinguishable characters within = usernames (mailboxes). See https://support.google.com/mail/answer/10313?hl=3Den Therefore user.name@gmail.com, username@gmail.com, and = u.s.e.r.n.a.m.e@gmail.com are equivalent. (It also does case folding.) That would be a 500+ million mailbox software example... Sean From nobody Wed Mar 25 21:53: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 C273C1AC3D5 for ; Wed, 25 Mar 2015 21:53:55 -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 07cy68ucYihS for ; Wed, 25 Mar 2015 21:53:54 -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 2D2341AC3D2 for ; Wed, 25 Mar 2015 21:53:54 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id DE051283015; Thu, 26 Mar 2015 04:53:52 +0000 (UTC) Date: Thu, 26 Mar 2015 04:53:52 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20150326045352.GA17637@mournblade.imrryr.org> References: <20150318001300.34285.qmail@ary.lan> <40D64A6D-B518-40F2-9556-762839A92A9E@seantek.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <40D64A6D-B518-40F2-9556-762839A92A9E@seantek.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [dane] Comments on draft-ietf-dane-openpgpkey-02 (fwd) 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, 26 Mar 2015 04:53:55 -0000 On Wed, Mar 25, 2015 at 11:38:18PM -0500, Sean Leonard wrote: > > In my experience, people who write mail software understand the opaque > > mailbox rule, and try pretty hard to follow it. Some cheat and do case > > folding to match Bob@domain to BOB@domain, but I can't think of any that > > match bob+foo@domain or b.ob@domain to bob@domain, other than the MTA that > > actually knows what the addresses mean. > > Gmail does not recognize dots as distinguishable characters within usernames (mailboxes). > > That would be a 500+ million mailbox software example... That's for *their own* domain, the text you're replying to refers to general address processing that would apply to other people's domains (such as an MUA looking for keys might need to find the keys for variant addresses). So the questions are: * All other things being equal, would domain owners be better off serving the keys via DNS. * How important is the lack of support for variant addresses? Is it actually a problem if email to variant address forms (de-novo email, rather than replies to mail from the canonical form of the address) is sent in the clear for lack of (automatically discoverable) keys? If the first answer is "yes" and the second is "no", then DNS is a clear winner. Otherwise, there are trade-offs to consider. -- Viktor. From nobody Thu Mar 26 06:31:17 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 125901B2CC9 for ; Thu, 26 Mar 2015 06:31:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.137 X-Spam-Level: X-Spam-Status: No, score=-1.137 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2yd3OiS0AXRM for ; Thu, 26 Mar 2015 06:31:15 -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 C6A3B1ACE7A for ; Thu, 26 Mar 2015 06:31:14 -0700 (PDT) Received: (qmail 46262 invoked from network); 26 Mar 2015 13:31:13 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=b4b5.55140a21.k1503; bh=vKxmEeQmXiKFAoQ9yh1qhL0darrJsvYYz412nn5DNW8=; b=TviT/u818zOsYyf9Dkd4dkKXMrwf2S1jQ93pkknK4ZcSooMe+RS1t0GK0O1pOXezn4gn84vHYiksnV+8xBv1+2SLyCjJCmA3Zq7c0mYbQHHQTjmdnBRbIz3oM+h91bRKGAW5EjRj+fbuisyhl+CTpAridv4lqXimjOw+984WfaPvcfKDZfyl1tu9gTgN35CpLp20+rM/BjQ9PTrBSxYFUIWloKVVhN9CLOKApPRmC75jHdXXILUax4y39QjYSg+U 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=b4b5.55140a21.k1503; bh=vKxmEeQmXiKFAoQ9yh1qhL0darrJsvYYz412nn5DNW8=; b=xafRqgHivDiv3Um/xZlSRXAKIDK8Au5a+D6emkePLG0d/mGJ1Ou9nGjkjCPg5Nf9CO3pmwad6oEj6l4CrQ3klGHqvGvmGJVO2zlcqb35+UFBodTr8N8OD+IxFJG7ioxzRj8y80bPDMMFUvJNnejG/PTGs32NV7t1KW9pGef90ayQ/jLKeSP5Hzv3ZHggJ/FqI06m+XE0qu0ABSpU1eLRRCyi0Mcys3pnaXGmKVQtowRFCZUTPb7q8emqP0tmmjuY 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; 26 Mar 2015 13:31:13 -0000 Date: 26 Mar 2015 08:31:12 -0500 Message-ID: From: "John R Levine" To: "Sean Leonard" In-Reply-To: <40D64A6D-B518-40F2-9556-762839A92A9E@seantek.com> References: <20150318001300.34285.qmail@ary.lan> <40D64A6D-B518-40F2-9556-762839A92A9E@seantek.com> 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] Comments on draft-ietf-dane-openpgpkey-02 (fwd) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2015 13:31:16 -0000 > Gmail does not recognize dots as distinguishable characters within usernames (mailboxes). > (It also does case folding.) Right, and the canonical form is whatever you typed when you signed up, e.g., mine has one dot in the middle and no upper case. This just confirms that you can't tell from the outside what an MTA does internally. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. From nobody Thu Mar 26 11:28:43 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C1471AC3E3 for ; Thu, 26 Mar 2015 11:28:41 -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 BVsUxYzmOLx4 for ; Thu, 26 Mar 2015 11:28:40 -0700 (PDT) Received: from smtp76.iad3a.emailsrvr.com (smtp76.iad3a.emailsrvr.com [173.203.187.76]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2EBB1AD291 for ; Thu, 26 Mar 2015 11:28:12 -0700 (PDT) Received: from smtp26.relay.iad3a.emailsrvr.com (localhost.localdomain [127.0.0.1]) by smtp26.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id DC3D78054C; Thu, 26 Mar 2015 14:28:11 -0400 (EDT) Received: by smtp26.relay.iad3a.emailsrvr.com (Authenticated sender: ogud-AT-ogud.com) with ESMTPSA id 93AE680520; Thu, 26 Mar 2015 14:28:11 -0400 (EDT) X-Sender-Id: ogud@ogud.com Received: from dhcp-b661.meeting.ietf.org (dhcp-b661.meeting.ietf.org [31.133.182.97]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:465 (trex/5.4.2); Thu, 26 Mar 2015 18:28:11 GMT From: Olafur Gudmundsson Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 26 Mar 2015 14:28:11 -0400 Message-Id: <8DDBE6CE-7D3A-48AF-B773-21CAACE5687D@ogud.com> To: saag@ietf.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: "" Subject: [dane] DANE summary X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 26 Mar 2015 18:28:41 -0000 DANE had a one hour meeting.=20 doc-status:=20 - 2 WG documents advanced to IESG DANE-SMTP DANE-SRV - 1 document in WGLC OPENPGPKEY=20 - 2 documents pending a WGLC RSN.=20 We had discussion about a document that are proposing new things that = use dane for payment systems.=20 Most of the WG time was spent on a issue raised during the WGLC on = OPENPGPKEY document.=20 The discovery/search of actual email address of the receiver. This is an = old problem that affects all e-mail. We had a fruitful discussion with number of e-mail people providing = information and thoughts.=20 The sense of the room is that this is a big problem but not one that = DANE should be addressing.=20 The group will take under advisement how to focus the document to = express that the approach in the=20 document is Opportunistic, i.e. sender looks up the address it has and = does no other search. DANE has another document that is about OPENPGPKEY-USAGE document and = will have some description on=20 how to improve the probability of finding a OPENPGPKEY record.=20 The working group is updating its milestones, thus right now is a good = time submit new work for consideration.=20 Olafur for chairs From c@cem.me Thu Mar 26 11:33: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 1D6BF1B2A1D for ; Thu, 26 Mar 2015 11:33:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.168 X-Spam-Level: X-Spam-Status: No, score=-1.168 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_DKIM_INVALID=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 1CLy5Y0Vdhxe for ; Thu, 26 Mar 2015 11:33:28 -0700 (PDT) Received: from mail-lb0-x22b.google.com (mail-lb0-x22b.google.com [IPv6:2a00:1450:4010:c04::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B66781A92EA for ; Thu, 26 Mar 2015 11:33:06 -0700 (PDT) Received: by lbcgn8 with SMTP id gn8so47412256lbc.2 for ; Thu, 26 Mar 2015 11:33:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cem.me; s=cem; h=mime-version:date:message-id:subject:from:to:content-type; bh=l0pmU/j9BzgbmJ5WsXH1fJYz0L+dpWafQdj3XpexD0M=; b=ahlvof3REIbyOjy8Wv4YOgszZHS0CjzPjKphzKOEbIyrFi7PJ49pySVNijfRYKoem6 0AXyjGu8HHCdCSLrRD/T+j7p+1qFwkqQgvHwtmW5EpNQL1WPGGFyAWAGvudY0bJE7Tih m3Kngja/BECDWLLeT83DE8RPd92OLz2kg87U4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=l0pmU/j9BzgbmJ5WsXH1fJYz0L+dpWafQdj3XpexD0M=; b=X3U13h0dkyIN+bcGfh47tQSwNATzwrvc0zmNmJwpTVILpbc4aX/LolvIzdUEIfzNb/ L6c+5ouZ2x1xSUPgb63ZIqMy44JymdB1Evm7l+Ddps3R4X+MjvY05L0VD08kRCoTPXK3 bxvv5Eil5ijQKG0GCsZlw48FhtyggVa2Q2gNPNrwJVDWbWFcSi9q4hVoQNtkp9XDCaRX gWXdcbBCQDNjqY31GFKAaWyCQHgH9GgMdZ393HjUd0xyBwWSeYTy+AYNP53ejHO2egdp 2kjKw7QD25b/6h2jx9eroLanR/doWwDpXILU5L8Azm5sipEiQyJMoLeI9fSeB1CWTYIf mJ8w== X-Gm-Message-State: ALoCoQmuf7Nzveu0BQQFgL+en8g+HqIUj1oRj30GIQuxcdwuTxA4itDciFlmP8nfAcDGWVmMn6iF MIME-Version: 1.0 X-Received: by 10.152.243.4 with SMTP id wu4mr14583939lac.33.1427394785221; Thu, 26 Mar 2015 11:33:05 -0700 (PDT) Received: by 10.25.210.6 with HTTP; Thu, 26 Mar 2015 11:33:05 -0700 (PDT) X-Originating-IP: [2001:67c:370:176:e07d:6c2:4d32:5347] Date: Thu, 26 Mar 2015 13:33:05 -0500 Message-ID: From: Carl Mehner To: dane@ietf.org Content-Type: multipart/alternative; boundary=001a1134282c20b4460512353fc8 Archived-At: X-Mailman-Approved-At: Thu, 26 Mar 2015 11:38:53 -0700 Subject: [dane] draft-cem-dane-assertion X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 26 Mar 2015 18:37:30 -0000 --001a1134282c20b4460512353fc8 Content-Type: text/plain; charset=UTF-8 Hello DANE Working Group, At least one browser (Google Chrome) has experimented with DANE, but subsequently removed it "due to lack of use"[0]. There is also a Firefox plugin that will validate DANE records[1]. I submitted a draft to address this, in order to allow sites that want to use DANE the ability to explicitly state their intent and allow UAs to only expend resources on domains where DANE is requested. http://datatracker.ietf.org/doc/draft-cem-dane-assertion/ I believe, if there is interest, that this could fit part of the problem statement of the working group charter: to "create documents that describe how protocol entities can discover and validate these bindings in the execution of specific applications"[2] Those familiar with HSTS[3] and HPKP[4] ought to find many of the directives familiar, there is however a new concept, a 'require' directive. The reason I included this directive was because the way DANE works; if you receive a certificate that is valid via PKIX and do not receive any DANE records, the connection will continue. By using the 'require' directive, the host operator forces the connection to be validated using both PKIX and DANE or solely by using DANE every time. I have also written up some additional thoughts on the subject here: [5] Carl Mehner [0] https://www.imperialviolet.org/2011/06/16/dnssecchrome.html [1] https://www.dnssec-validator.cz [2] https://datatracker.ietf.org/wg/dane/charter [3] https://tools.ietf.org/html/rfc6797 [4] https://tools.ietf.org/html/draft-ietf-websec-key-pinning [5] https://www.cem.me/20141203-hdva.html --001a1134282c20b4460512353fc8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hello DANE Working Group,


= At least one browser (Google Chrome) has experimented with DANE, but subseq= uently removed it "due to lack of use"[0]. There is also a Firefo= x plugin that will validate DANE records[1]. I submitted a draft to address= this, in order to allow sites that want to use DANE the ability to explici= tly state their intent and allow UAs to only expend resources on domains wh= ere DANE is requested.

http://datatracker.ietf.org/doc/draft-cem-dane-assertion/<= /span>


I believe, if there is interest, that this could fi= t part of the problem statement of the working group charter: to "crea= te documents that describe how protocol entities can discover and validate = these bindings in the execution of specific applications"[2]

Those familiar with HSTS[3] and HPKP[4] ought to find many of th= e directives familiar, there is however a new concept, a 'require' = directive. The reason I included this directive was because the way DANE wo= rks; if you receive a certificate that is valid via PKIX and do not receive= any DANE records, the connection will continue. By using the 'require&= #39; directive, the host operator forces the connection to be validated usi= ng both PKIX and DANE or solely by using DANE every time.

I have also w= ritten up some additional thoughts on the subject here: [5]



<= br>
Carl Mehner
--001a1134282c20b4460512353fc8-- From nobody Thu Mar 26 11:58: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 A3D611A8792 for ; Thu, 26 Mar 2015 11:58:14 -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 T88BSR6BXh-x for ; Thu, 26 Mar 2015 11:58:09 -0700 (PDT) Received: from mail-lb0-x235.google.com (mail-lb0-x235.google.com [IPv6:2a00:1450:4010:c04::235]) (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 3DA431A92B4 for ; Thu, 26 Mar 2015 11:58:08 -0700 (PDT) Received: by lbcgn8 with SMTP id gn8so47894020lbc.2 for ; Thu, 26 Mar 2015 11:58:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=9/ng0nC/cFPNHCQvG54f0NLD0YwKV9cJf+D9WeRK3wE=; b=MAmSkOIRZ65dU9WT4WM1sFRRmo/KXfxMT0sUBzK2y0LhebQs8SNfaAPXj2F3vqN5nD hpBqKHCGXaeXXRH/OJmBTBQ3jrGP/pkqLfWvL0rEpdQBcbIVVFTxvZp5N9fLZMhkWra7 7iEY7Cme9w6zFTv5IHwQUIDdETD+dh9s8mEBG41RSREK6okB2cJPi9IYs7lS1Bb/rVYE 5LnnuENm8zXNr0V+lq2svjICF0K9mcvFnr4okwWTvDaBVHNGBgjo4KeX5RAt64Oqir3f reYtZ5GTjeI0gaFc35UYa/gkRVzt88rQUZFuGfceQzPdOHw2LfWj40oa/mSBK/Crh38s DHLQ== X-Received: by 10.152.22.229 with SMTP id h5mr14656015laf.21.1427396286678; Thu, 26 Mar 2015 11:58:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.88.136 with HTTP; Thu, 26 Mar 2015 11:57:46 -0700 (PDT) In-Reply-To: <40D64A6D-B518-40F2-9556-762839A92A9E@seantek.com> References: <20150318001300.34285.qmail@ary.lan> <40D64A6D-B518-40F2-9556-762839A92A9E@seantek.com> From: Doug Montgomery Date: Thu, 26 Mar 2015 14:57:46 -0400 Message-ID: To: Sean Leonard Content-Type: multipart/alternative; boundary=089e0160b6de9f0c3005123598bf Archived-At: Cc: Paul Wouters , John R Levine , Paul Hoffman , dane WG list Subject: Re: [dane] Comments on draft-ietf-dane-openpgpkey-02 (fwd) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2015 18:58:14 -0000 --089e0160b6de9f0c3005123598bf Content-Type: text/plain; charset=UTF-8 I guess I am confused as to why I would want to support either key discovery or distribution for the (500million - 1) versions of my email address that I don't use. My mail agent only generates one version of my from address. I only convey one version in written, oral, and online forms of distribution. I am perfectly happy if it is not possible to discover the 500million-1 variants of my email address that I don't use or exercise but that my mail provider chooses to treat as equivalent. Frankly if it was possible, I would write mail filters to drop those variants on receipt, because they clearly indicate some use of my email address that I did not endorse. For my uses, straight hashing of the form of my address you are presented with is all I want. To be honest, I would consider it an undesirable feature to support the versions of my address that I don't use. Enabling the simple direct function of key retrieval for the addresses we use, in a ubiquitous way would be very powerful. We should leave for future study the issue of key retrieval for the addresses we don't use. dougm On Thu, Mar 26, 2015 at 12:38 AM, Sean Leonard wrote: > > On Mar 18, 2015, at 10:23 AM, John R Levine wrote: > > >>> But I guess I could live with it if the consensus moves this way, but > to > >>> me that seems only because I know the MUST NOT will be violated. > > > >> At first I bristled at John's proposed change, but he's right that RFC > 5321 is completely clear on this topic, and it is a full standard. And, > yes, lots of SMTP applications probably violate the MUST NOT as well, but > that doesn't change it. > > > > In my experience, people who write mail software understand the opaque > mailbox rule, and try pretty hard to follow it. Some cheat and do case > folding to match Bob@domain to BOB@domain, but I can't think of any that > match bob+foo@domain or b.ob@domain to bob@domain, other than the MTA > that actually knows what the addresses mean. > > Gmail does not recognize dots as distinguishable characters within > usernames (mailboxes). > > See > https://support.google.com/mail/answer/10313?hl=en > > Therefore user.name@gmail.com, username@gmail.com, and > u.s.e.r.n.a.m.e@gmail.com are equivalent. > > (It also does case folding.) > > That would be a 500+ million mailbox software example... > > Sean > > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane > -- DougM at Work --089e0160b6de9f0c3005123598bf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I guess I am confused as to why I would want to support ei= ther key discovery or distribution for the (500million - 1) versions of my = email address that I don't use.

My mail agent only g= enerates one version of my from address. =C2=A0 I only convey one version i= n written, oral, and online forms of distribution.

I am perfectly happy if it is not possible to discover the 500million-1 va= riants of my email address that I don't use or exercise but that my mai= l provider chooses to treat as equivalent. =C2=A0 Frankly if it was possibl= e, I would write mail filters to drop those variants on receipt, because th= ey clearly indicate some use of my email address that I did not endorse.

For my uses, straight hashing of the form of my addr= ess you are presented with is all I want.=C2=A0 To be honest, I would consi= der it an undesirable feature to support the versions of my address that I = don't use.=C2=A0

Enabling the simple direct fu= nction of key retrieval for the addresses we use, in a ubiquitous way would= be very powerful. =C2=A0

We should leave for futu= re study the issue of key retrieval for the addresses we don't use.

dougm






On Thu, Mar 26, 2015 at 12:38 AM, Sean Leonard <d= ev+ietf@seantek.com> wrote:

On Mar 18, 2015, at 10:23 AM, John R Levine <johnl@taugh.com> wrote:

>>> But I guess I could live with it if the consensus moves this w= ay, but to
>>> me that seems only because I know the MUST NOT will be violate= d.
>
>> At first I bristled at John's proposed change, but he's ri= ght that RFC 5321 is completely clear on this topic, and it is a full stand= ard. And, yes, lots of SMTP applications probably violate the MUST NOT as w= ell, but that doesn't change it.
>
> In my experience, people who write mail software understand the opaque= mailbox rule, and try pretty hard to follow it.=C2=A0 Some cheat and do ca= se folding to match Bob@domain to BOB@domain, but I can't think of any = that match bob+foo@domain or b.ob@domain to bob@domain, other than the MTA = that actually knows what the addresses mean.

Gmail does not recognize dots as distinguishable characters within u= sernames (mailboxes).

See
https://support.google.com/mail/answer/10313?hl=3Den

Therefore user.name@gmail.com, <= a href=3D"mailto:username@gmail.com">username@gmail.com, and u.s.e.r.n.a.m.e@gmail.com are equiva= lent.

(It also does case folding.)

That would be a 500+ million mailbox software example...

Sean

_______________________________________________
dane mailing list
dane@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/dane



--
=
DougM at Work
--089e0160b6de9f0c3005123598bf-- From nobody Thu Mar 26 12:04: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 4296B1AC3F4 for ; Thu, 26 Mar 2015 12:04:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.537 X-Spam-Level: X-Spam-Status: No, score=-0.537 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, J_CHICKENPOX_54=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iAntcJlNogaL for ; Thu, 26 Mar 2015 12:04: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 A41D81AC401 for ; Thu, 26 Mar 2015 12:02:41 -0700 (PDT) Received: (qmail 95212 invoked from network); 26 Mar 2015 19:02:40 -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=173eb.551457d0.k1503; bh=jMw35/5Iid0CQvH+19CoeuVsvWTV0vvliWeW5RpAcZI=; b=MoijNR/m3Xhs/pmboHCBGCm5ch5YRDH61mIwtEGDBMtVVHMxi7rxrP1q7b3WzdNszrDdaTSS/6FvjQROhm2jOdZmPyysbk73W/y4qcok4wFLZrIGg43UbSYXyQ2lxETzbcgNQLe2ZUSnAS1Yk40JYFUu3MTCZIlFf0CrSMo/BeYPlwRVqKb96HuMQQw8mAZO+tiCGew+K7VVmpgIVonWVJNO2rW6jEuRlprUzYw/Efq7KGsow9+i+xUG9hW+m9iq 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=173eb.551457d0.k1503; bh=jMw35/5Iid0CQvH+19CoeuVsvWTV0vvliWeW5RpAcZI=; b=RI6nzsdpT31JoFKWUWFlwuKrjslUfXLjMA0GeL67RdTsKGuYjW59tQJBKS4LGgjvfDOvTzOJcQ0+FvXg67uJ2NxwpjplVH3nvNZEMKFQN60mNe45DK6g8BrP/AKUJe8K4ZCIEa4HcpqRFeQG0Z9r+K6qAAKfvl1xAs2AbkkP0ldu/0c6ifyMhjOYGrQU+9n25FNIG3F1EJSQSCbgENFPGWgFmIQwpVl3R+lqKoINWUCF/USIxu84BNodO2+sWhaZ 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; 26 Mar 2015 19:02:40 -0000 Date: 26 Mar 2015 14:02:39 -0500 Message-ID: From: "John R Levine" To: "Doug Montgomery" In-Reply-To: References: <20150318001300.34285.qmail@ary.lan> <40D64A6D-B518-40F2-9556-762839A92A9E@seantek.com> User-Agent: Alpine 2.11 (OSX 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Archived-At: Cc: dane WG list Subject: Re: [dane] Comments on draft-ietf-dane-openpgpkey-02 (fwd) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2015 19:04:07 -0000 > I guess I am confused as to why I would want to support either key > discovery or distribution for the (500million - 1) versions of my email > address that I don't use. You may know exactly want versions of your address that you use, but in general, mail systems don't. Google doesn't know whether you spell your address dougmwork or dougm.work or DougmWork or Dougm.work. They might be able to guess based on the incoming mail they've seen, but as we've said over and over, guessing isn't on the table. If you're suggested that every mail user will manually identify which versions of his or her mail address the mail provider should publish, that doesn't seem to scale very well. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. From nobody Thu Mar 26 12:20: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 C3F151B2ADC for ; Thu, 26 Mar 2015 12:20:44 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, J_CHICKENPOX_54=0.6, MANGLED_WORKS=2.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 b0i4g83Wj1Tn for ; Thu, 26 Mar 2015 12:20:43 -0700 (PDT) Received: from mail-la0-x236.google.com (mail-la0-x236.google.com [IPv6:2a00:1450:4010:c03::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2BAEC1B2AB0 for ; Thu, 26 Mar 2015 12:20:43 -0700 (PDT) Received: by lahp7 with SMTP id p7so34825368lah.2 for ; Thu, 26 Mar 2015 12:20:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=QuNyvXv+FTwY/ApoC2OlNvXqrSS+g2oO8EmxXyI2kC4=; b=Xs0nS0WKLIaZsb7epWWJ/+dRz9c3qO+IzsL9JaKR11FrLHGiP71pIanQ0S+us1vIO9 d84a5Sy3yK8xOO4tsP2CS1ez5caTYILVt0s+XkJtPWmBVPz4xSkK8jbWosOM3UbQp6Bn pLNt1VRlmtlCCurNmML5VLK8Am9cQ//JAdTVE+7zvrCFlbEfe5iI/24fkwBntxSjv2Vd McazRvKBQO5D9KE1YHa/kutSppgbWqbbhg4oxsPFYnOrH6xQQ02z1iXgKEb3flInN09Q s8xKiQnVG84UvPjO6seC+4BHsxB5jR0TPtibXvEAxqjO5KYQRVcZGbRIxB0TQCf0bxly v1JA== X-Received: by 10.112.168.163 with SMTP id zx3mr13727086lbb.46.1427397641541; Thu, 26 Mar 2015 12:20:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.88.136 with HTTP; Thu, 26 Mar 2015 12:20:17 -0700 (PDT) In-Reply-To: References: <20150318001300.34285.qmail@ary.lan> <40D64A6D-B518-40F2-9556-762839A92A9E@seantek.com> From: Doug Montgomery Date: Thu, 26 Mar 2015 15:20:17 -0400 Message-ID: To: John R Levine Content-Type: multipart/alternative; boundary=001a11c34ab4609ba2051235e9f4 Archived-At: Cc: dane WG list Subject: Re: [dane] Comments on draft-ietf-dane-openpgpkey-02 (fwd) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2015 19:20:44 -0000 --001a11c34ab4609ba2051235e9f4 Content-Type: text/plain; charset=UTF-8 That problem seems to be O(1). As you noted, I did it once, when I created the address. My mail provider may choose to support all kinds of inbound variants (UID@domain) that I don't even know about. I transmit, document, and exchange exactly 1 version of my address. I would like to publish a key for dougm.work@gmail.com. This seems to scale quite well. I consider it undesirable to publish keys for whatever variants my provider chooses to support for their own reasons. Tomorrow they might decide (for their own reasons) to equate other transformations of the string. I just don't understand the use case for thinking the key retrieval function needs to support all such vendor specific transformations that I don't use. Google never has to figure out the problem you propose. I set my from: address. I would like to publish a key for that. Users trying to validate my signed email will look up the from address I used. If their user agent sees dougm.work@gmail.com and chooses to lookup D.o.U.g.M.w.O.r.k@gmail.com .... well, I am more than happy to have that validation fail. dougm On Thu, Mar 26, 2015 at 3:02 PM, John R Levine wrote: > I guess I am confused as to why I would want to support either key >> discovery or distribution for the (500million - 1) versions of my email >> address that I don't use. >> > > You may know exactly want versions of your address that you use, but in > general, mail systems don't. Google doesn't know whether you spell your > address dougmwork or dougm.work or DougmWork or Dougm.work. They might be > able to guess based on the incoming mail they've seen, but as we've said > over and over, guessing isn't on the table. > > If you're suggested that every mail user will manually identify which > versions of his or her mail address the mail provider should publish, that > doesn't seem to scale very well. > > > Regards, > John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY > Please consider the environment before reading this e-mail. > -- DougM at Work --001a11c34ab4609ba2051235e9f4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
That problem seems to be O(1).=C2=A0 As you noted, I did i= t once, when I created the address. =C2=A0 My mail provider may choose to s= upport all kinds of inbound variants (UID@domain) that I don't even kno= w about. =C2=A0=C2=A0

I transmit, document, and exchange= exactly 1 version of my address. =C2=A0 I would like to publish a key for = dougm.work@gmail.com. =C2=A0 Th= is seems to scale quite well.

I consider it undesi= rable to publish keys for whatever variants my provider chooses to support = for their own reasons.=C2=A0 Tomorrow they might decide (for their own reas= ons) to equate other transformations of the string.

I just don't understand the use case for thinking the key retrieval f= unction needs to support all such vendor specific transformations that I do= n't use.

Google never has to figure out the pr= oblem you propose.=C2=A0 I set my from: address.=C2=A0 I would like to publ= ish a key for that.=C2=A0 Users trying to validate my signed email will loo= k up the from address I used.=C2=A0 If their user agent sees dougm.work@gmail.com and chooses to lookup D.o.U.g.M.w.O.r.k@gmail.com .... well, I am more than happy to have that validation fail.
<= br>
dougm



On Thu, Mar 26, 2015 at 3:02 PM= , John R Levine <johnl@taugh.com> wrote:
I guess I am confused as to why I would want to support either key
discovery or distribution for the (500million - 1) versions of my email
address that I don't use.

 You may know exactly want versions of your address that you use, but in gen= eral, mail systems don't.=C2=A0 Google doesn't know whether you spe= ll your address dougmwork or dougm.work or DougmWork or Dougm.work.=C2=A0 T= hey might be able to guess based on the incoming mail they've seen, but= as we've said over and over, guessing isn't on the table.

If you're suggested that every mail user will manually identify which v= ersions of his or her mail address the mail provider should publish, that d= oesn't seem to scale very well.
=

Regards,
John Levine, johnl@tau= gh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail.



--
=
DougM at Work
--001a11c34ab4609ba2051235e9f4-- From nobody Thu Mar 26 12:30: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 8D1A81B2B2F for ; Thu, 26 Mar 2015 12:30:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.137 X-Spam-Level: X-Spam-Status: No, score=-1.137 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VzfeQl39S7PU for ; Thu, 26 Mar 2015 12:30:07 -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 426961B2AB6 for ; Thu, 26 Mar 2015 12:30:06 -0700 (PDT) Received: (qmail 511 invoked from network); 26 Mar 2015 19:30:04 -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=1fe.55145e3c.k1503; bh=hCChqWEAl063ZhcSv7hG6/KzB/dFENVBxEr89aKdfnU=; b=jVWeQatG+71ta0jmplvEpV5CFWL9f6yzVmW/z2hUl7pUoqv2k5rHcWuhucFw0WRR3Cu5BfwPH27dfFfdAcC3abJIkURlI6EfjFSuXMHk6S78YiRpoG3Tap4l7B4gMGCvhHTZiP/QaNaLAxJ2yCJUZnBS7awtxX+v0unbzLx4nMEGldLOFrQ0332aA1s9uso4CExcfwqBMirS2bkwBZ1VxuU88Z69y/bHHBmVUSmLnRjMXaI92u84nV7osyM+5/E7 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=1fe.55145e3c.k1503; bh=hCChqWEAl063ZhcSv7hG6/KzB/dFENVBxEr89aKdfnU=; b=dWgx/hRBtZwTJXYdsdFNAjl8NAAZxV8351risJc6cb7eQV2QCqKBYTkX2/73EdkknjpNOT4j1sSF8E9QSOLhHlboCzjobcwvkKLetDGBFy4SjraW/GlCqGpE9JSxfjzbSFvDLgu/dDOP8h0kn+yLJCR4tpzNGznX4DrOXwAvqv9i2Wg65BVQyP/S9NqkKzIpE7QSvtiyKtF743V//FrwL4zwFi2jfIAQ2A0FQhSx69HuRkulK1KdEiPm2f1RUGAU 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; 26 Mar 2015 19:30:04 -0000 Date: 26 Mar 2015 14:30:03 -0500 Message-ID: From: "John R Levine" To: "Doug Montgomery" In-Reply-To: References: <20150318001300.34285.qmail@ary.lan> <40D64A6D-B518-40F2-9556-762839A92A9E@seantek.com> User-Agent: Alpine 2.11 (OSX 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: dane WG list Subject: Re: [dane] Comments on draft-ietf-dane-openpgpkey-02 (fwd) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2015 19:30:08 -0000 > I consider it undesirable to publish keys for whatever variants my provider > chooses to support for their own reasons. Tomorrow they might decide (for > their own reasons) to equate other transformations of the string. MTAs have been doing fuzzy matching on local-parts for over 30 years. It's a little late to tell them not to do it. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. From nobody Thu Mar 26 12:42:53 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65F5F1B2AA9 for ; Thu, 26 Mar 2015 12:42:51 -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 dsy-_Fi35j_7 for ; Thu, 26 Mar 2015 12:42:50 -0700 (PDT) Received: from mail-la0-x230.google.com (mail-la0-x230.google.com [IPv6:2a00:1450:4010:c03::230]) (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 5BE841AC529 for ; Thu, 26 Mar 2015 12:42:48 -0700 (PDT) Received: by labe2 with SMTP id e2so54129231lab.3 for ; Thu, 26 Mar 2015 12:42:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=VaW7dKE+Vpp+gtA0m69rwklCFA659XUHxQ1q4J/ydE0=; b=mYuPL7xOTAI6Zrf+N9M/aAVHpRVuAw2zXnkHVhk3oaMas9x10WaekC4mIBCI23rylG 5O0F6xjzb+YG5VQsDf1cBX2cCf6qdbKcx5VeEdJ3/Wuw9vBzovvmdEVLiWqf3mNNd9ZT QjcgpjvcDv+JRisCaFYjhGQvhYe4ZPEvDseahnzyyTyfJsTVrMGH/gYf7GtF5D4WiX+N AI9DMlSah5L2OBuBr7b0DHde9fL0faTSKSrp4dNeyrqVRhcCkybBzI0Bj/TRxrje7O60 OCPON6uHgfFfMBHY9C4LGqi45YD8uUSrzgG106KI+yLajZqadsdX2rbq2AJQg3p2Wu+q FofQ== X-Received: by 10.112.29.36 with SMTP id g4mr6413044lbh.56.1427398966858; Thu, 26 Mar 2015 12:42:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.88.136 with HTTP; Thu, 26 Mar 2015 12:42:25 -0700 (PDT) In-Reply-To: References: <20150318001300.34285.qmail@ary.lan> <40D64A6D-B518-40F2-9556-762839A92A9E@seantek.com> From: Doug Montgomery Date: Thu, 26 Mar 2015 15:42:25 -0400 Message-ID: To: John R Levine Content-Type: multipart/alternative; boundary=001a1133f9945f587b0512363865 Archived-At: Cc: dane WG list Subject: Re: [dane] Comments on draft-ietf-dane-openpgpkey-02 (fwd) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2015 19:42:51 -0000 --001a1133f9945f587b0512363865 Content-Type: text/plain; charset=UTF-8 This seems to be a red herring to me. I did not suggest that the MTA change its behavior at all. How that issue gets conflated with what I thought we were talking about is beyond me. Maybe someone can explain. I request that I be able to publish, and have others lookup the form of my address that I use. Given that the fuzzy matching rules are receiver specific, I find it hard to believe that senders are somehow algorithmically generating variants of my email. But as I noted, if any exist that randomly transform the from address they receive, I am fine with having validation fail. I see this potential failure scenario to be miniscule, or at least smaller than false positive errors by spam filters. dougm On Thu, Mar 26, 2015 at 3:30 PM, John R Levine wrote: > I consider it undesirable to publish keys for whatever variants my provider >> chooses to support for their own reasons. Tomorrow they might decide (for >> their own reasons) to equate other transformations of the string. >> > > MTAs have been doing fuzzy matching on local-parts for over 30 years. It's > a little late to tell them not to do it. > > > Regards, > John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY > Please consider the environment before reading this e-mail. > -- DougM at Work --001a1133f9945f587b0512363865 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
This seems to be a red herring to me.

I= did not suggest that the MTA change its behavior at all. =C2=A0 How that i= ssue gets conflated with what I thought we were talking about is beyond me.= =C2=A0 Maybe someone can explain.

I request that I= be able to publish, and have others lookup the form of my address that I u= se.

Given that the fuzzy matching rules are receiv= er specific, I find it hard to believe that senders are somehow algorithmic= ally generating variants of my email.

But as I not= ed, if any exist that randomly transform the from address they receive, I a= m fine with having validation fail. =C2=A0=C2=A0

I= see this potential failure scenario to be miniscule, or at least smaller t= han false positive errors by spam filters.

dougm

On Thu,= Mar 26, 2015 at 3:30 PM, John R Levine <johnl@taugh.com> wrot= e:
I consider it undesirable to publish keys for whatever variants my provider=
chooses to support for their own reasons.=C2=A0 Tomorrow they might decide = (for
their own reasons) to equate other transformations of the string.

 MTAs have been doing fuzzy matching on local-parts for over 30 years. It= 9;s a little late to tell them not to do it.


Regards,
John Levine, johnl@tau= gh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail.



--
=
DougM at Work
--001a1133f9945f587b0512363865-- From nobody Thu Mar 26 12:46: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 A0E141B2B43 for ; Thu, 26 Mar 2015 12:46:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.856 X-Spam-Level: * X-Spam-Status: No, score=1.856 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_34=0.6, MANGLED_WORKS=2.3, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UAQeQlRgLpfR for ; Thu, 26 Mar 2015 12:46:07 -0700 (PDT) Received: from homiemail-a26.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 6F8511B2B38 for ; Thu, 26 Mar 2015 12:45:40 -0700 (PDT) Received: from homiemail-a26.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a26.g.dreamhost.com (Postfix) with ESMTP id 16FE5B8095 for ; Thu, 26 Mar 2015 12:45:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=WGSg+MWUjMeh8NPJerYi HHsqhp8=; b=w0wyYIDBwamVciIxBNASsEzMBO5YiUx6YtqprcH83z5VCB5ucTQ7 ocRu60aLObdNuZjqQYC3asbFE3+xestiBMwz163uhymb0GEsS0ypFBJqLeJdVFfF bWhpHOdzpk8oVhGbT7S2Zf+ieSGa9hi9LS2u5Q93jTHffevRAaabg2c= Received: from mail-ie0-f174.google.com (mail-ie0-f174.google.com [209.85.223.174]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a26.g.dreamhost.com (Postfix) with ESMTPSA id 0335CB8087 for ; Thu, 26 Mar 2015 12:45:40 -0700 (PDT) Received: by ieclw3 with SMTP id lw3so55079144iec.2 for ; Thu, 26 Mar 2015 12:45:39 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.43.77.6 with SMTP id zg6mr1241430icb.68.1427399139639; Thu, 26 Mar 2015 12:45:39 -0700 (PDT) Received: by 10.64.130.66 with HTTP; Thu, 26 Mar 2015 12:45:39 -0700 (PDT) In-Reply-To: References: <20150318001300.34285.qmail@ary.lan> <40D64A6D-B518-40F2-9556-762839A92A9E@seantek.com> Date: Thu, 26 Mar 2015 14:45:39 -0500 Message-ID: From: Nico Williams To: Doug Montgomery Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: dane WG list Subject: Re: [dane] Comments on draft-ietf-dane-openpgpkey-02 (fwd) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2015 19:46:08 -0000 On Thu, Mar 26, 2015 at 2:20 PM, Doug Montgomery wrote: > That problem seems to be O(1). As you noted, I did it once, when I created > the address. My mail provider may choose to support all kinds of inbound > variants (UID@domain) that I don't even know about. > > I transmit, document, and exchange exactly 1 version of my address. I > would like to publish a key for dougm.work@gmail.com. This seems to scale > quite well. You do. Others use aliases for all sorts of reasons. E.g., joe+dane (some joe's address for posting to this list, say). > I consider it undesirable to publish keys for whatever variants my provider > chooses to support for their own reasons. Tomorrow they might decide (for > their own reasons) to equate other transformations of the string. If you were the sort who likes to use a different sender address (typically an alias of your primary address) for each list, then you would consider it desirable. > Google never has to figure out the problem you propose. I set my from: > address. I would like to publish a key for that. Users trying to validate > my signed email will look up the from address I used. If their user agent > sees dougm.work@gmail.com and chooses to lookup D.o.U.g.M.w.O.r.k@gmail.com > .... well, I am more than happy to have that validation fail. Google does too have to figure out how to canonicalize your aliases: because they chose to apply a fuzzy matching rule of their own design. Google did that because they could. Nico -- From nobody Thu Mar 26 12:58: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 B81111ABD38 for ; Thu, 26 Mar 2015 12:58:23 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, MANGLED_WORKS=2.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 1sK4sWRcdc5E for ; Thu, 26 Mar 2015 12:58:22 -0700 (PDT) Received: from mail-la0-x231.google.com (mail-la0-x231.google.com [IPv6:2a00:1450:4010:c03::231]) (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 033CA1A00E0 for ; Thu, 26 Mar 2015 12:58:18 -0700 (PDT) Received: by labe2 with SMTP id e2so54448479lab.3 for ; Thu, 26 Mar 2015 12:58:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=Q8tU2Vg50aA8n7nfZIAa93aG/V25k50Y4gpxjbbp+1M=; b=IUfWF/zfUvagPo+fEjEZO7paubVBlROTRdYm9MqwLYPnZOMlncgcMYOglLVssP0i3t 6jFI9W4oMdGjcPW7moA0/1V69qhUVp3GlqiDkNKBba3sOfuW3MSizcVwhbzcdodSS1I7 U4oUrGiHjwFgrmwT3A4TSLlrcFHmlwrsE1U+7nb5UD+97YpwwIAASbKoF67CBeL9RZaQ NXNKEPE8FKa4GWbasC1raKac0Qfc/0eKGmDx+f8DqF8+6xIaiyBcSw0eNliztN1joIVr OH2FmxY1f3KO7b7E7v/MmCERKL2lHpfyiY2lhT+sRVhOe5maqwo0pHM/0H1l/gn3C6ng ycmw== X-Received: by 10.112.137.164 with SMTP id qj4mr14725998lbb.17.1427399896550; Thu, 26 Mar 2015 12:58:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.88.136 with HTTP; Thu, 26 Mar 2015 12:57:56 -0700 (PDT) In-Reply-To: References: <20150318001300.34285.qmail@ary.lan> <40D64A6D-B518-40F2-9556-762839A92A9E@seantek.com> From: Doug Montgomery Date: Thu, 26 Mar 2015 15:57:56 -0400 Message-ID: To: Nico Williams Content-Type: multipart/alternative; boundary=089e0115fd1cc954430512366fe8 Archived-At: Cc: dane WG list Subject: Re: [dane] Comments on draft-ietf-dane-openpgpkey-02 (fwd) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2015 19:58:23 -0000 --089e0115fd1cc954430512366fe8 Content-Type: text/plain; charset=UTF-8 For any set of aliases that are manually configured, publishing a key, or CNAME for each of those is of the same order of complexity as establishing the alias itself. When I try to validate the sig for joe+dane@domain.com I will look that up. Unless your user agent generates a fuzzy match variant of your from: address outbound with each email, I am not sure that the scaling problem is. I still fail to see what inbound fuzzy match of local parts has to do with the problem. dougm On Thu, Mar 26, 2015 at 3:45 PM, Nico Williams wrote: > On Thu, Mar 26, 2015 at 2:20 PM, Doug Montgomery > wrote: > > That problem seems to be O(1). As you noted, I did it once, when I > created > > the address. My mail provider may choose to support all kinds of > inbound > > variants (UID@domain) that I don't even know about. > > > > I transmit, document, and exchange exactly 1 version of my address. I > > would like to publish a key for dougm.work@gmail.com. This seems to > scale > > quite well. > > You do. > > Others use aliases for all sorts of reasons. E.g., joe+dane (some > joe's address for posting to this list, say). > > > I consider it undesirable to publish keys for whatever variants my > provider > > chooses to support for their own reasons. Tomorrow they might decide > (for > > their own reasons) to equate other transformations of the string. > > If you were the sort who likes to use a different sender address > (typically an alias of your primary address) for each list, then you > would consider it desirable. > > > Google never has to figure out the problem you propose. I set my from: > > address. I would like to publish a key for that. Users trying to > validate > > my signed email will look up the from address I used. If their user > agent > > sees dougm.work@gmail.com and chooses to lookup > D.o.U.g.M.w.O.r.k@gmail.com > > .... well, I am more than happy to have that validation fail. > > Google does too have to figure out how to canonicalize your aliases: > because they chose to apply a fuzzy matching rule of their own design. > Google did that because they could. > > Nico > -- > -- DougM at Work --089e0115fd1cc954430512366fe8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
For any set of aliases that are manually configured, publi= shing a key, or CNAME for each of those is of the same order of complexity = as establishing the alias itself. =C2=A0

When I try to v= alidate the sig for joe+dane@domai= n.com I will look that up.

Unless your user ag= ent generates a fuzzy match variant of your from: address outbound with eac= h email, I am not sure that the scaling problem is.

I still fail to see what inbound fuzzy match of local parts has to do wit= h the problem.

dougm

On Thu, Mar 26, 2015 at 3:45 PM, Ni= co Williams <nico@cryptonector.com> wrote:
On Thu, Mar 26, 2015 at 2:20 PM, Doug= Montgomery <dougm.work@gmail.co= m> wrote:
> That problem seems to be O(1).=C2=A0 As you noted, I did it once, when= I created
> the address.=C2=A0 =C2=A0My mail provider may choose to support all ki= nds of inbound
> variants (UID@domain) that I don't even know about.
>
> I transmit, document, and exchange exactly 1 version of my address.=C2= =A0 =C2=A0I
> would like to publish a key for dougm.work@gmail.com.=C2=A0 =C2=A0This seems to scale
> quite well.

You do.

Others use aliases for all sorts of reasons.=C2=A0 E.g., joe+dane (some
joe's address for posting to this list, say).

> I consider it undesirable to publish keys for whatever variants my pro= vider
> chooses to support for their own reasons.=C2=A0 Tomorrow they might de= cide (for
> their own reasons) to equate other transformations of the string.

If you were the sort who likes to use a different sender address
(typically an alias of your primary address) for each list, then you
would consider it desirable.

> Google never has to figure out the problem you propose.=C2=A0 I set my= from:
> address.=C2=A0 I would like to publish a key for that.=C2=A0 Users try= ing to validate
> my signed email will look up the from address I used.=C2=A0 If their u= ser agent
> sees dougm.work@gmail.com = and chooses to lookup D.o.U.= g.M.w.O.r.k@gmail.com
> .... well, I am more than happy to have that validation fail.

Google does too have to figure out how to canonicalize your aliases:=
because they chose to apply a fuzzy matching rule of their own design.
Google did that because they could.

Nico
--



--
DougM at Work
--089e0115fd1cc954430512366fe8-- From nobody Thu Mar 26 13:13: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 5A9B71B2E39 for ; Thu, 26 Mar 2015 13:13:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MPEIKllji0Q1 for ; Thu, 26 Mar 2015 13:13:31 -0700 (PDT) Received: from homiemail-a89.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id AA9C11B2E36 for ; Thu, 26 Mar 2015 13:13:31 -0700 (PDT) Received: from homiemail-a89.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a89.g.dreamhost.com (Postfix) with ESMTP id 81271318095 for ; Thu, 26 Mar 2015 13:13:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=yzkiSn50nnYqXGz0eyj4 wnqTlxs=; b=RgiQ03o8hCsw7TdhikRb5D/Hki/bZVQKZtOdrOAsH7RMnEWCzm9p SNbeuVWwJTaCBZhHKxz1Mhq5uH0oOPiXA4je+dCY2P/IJ/89IXjYw7ztvMra/+Dz Pv8IgGRYOYVbBco169GJuSpch6ramK8GdMJ67ia3MwbFD0x/0J8EDx8= Received: from mail-ie0-f176.google.com (mail-ie0-f176.google.com [209.85.223.176]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a89.g.dreamhost.com (Postfix) with ESMTPSA id 5F75C318092 for ; Thu, 26 Mar 2015 13:13:31 -0700 (PDT) Received: by iedm5 with SMTP id m5so55779814ied.3 for ; Thu, 26 Mar 2015 13:13:30 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.50.30.130 with SMTP id s2mr39873828igh.11.1427400810849; Thu, 26 Mar 2015 13:13:30 -0700 (PDT) Received: by 10.64.130.66 with HTTP; Thu, 26 Mar 2015 13:13:30 -0700 (PDT) In-Reply-To: References: <20150318001300.34285.qmail@ary.lan> <40D64A6D-B518-40F2-9556-762839A92A9E@seantek.com> Date: Thu, 26 Mar 2015 15:13:30 -0500 Message-ID: From: Nico Williams To: Doug Montgomery Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: dane WG list Subject: Re: [dane] Comments on draft-ietf-dane-openpgpkey-02 (fwd) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2015 20:13:32 -0000 On Thu, Mar 26, 2015 at 2:57 PM, Doug Montgomery wrote: > For any set of aliases that are manually configured, publishing a key, or > CNAME for each of those is of the same order of complexity as establishing > the alias itself. > > When I try to validate the sig for joe+dane@domain.com I will look that up. + is not configured. They're magic... if your MTAs are configured so anyways. These uses exist precisely because they were a) permitted, b) handy. So now we have to deal with them. > I still fail to see what inbound fuzzy match of local parts has to do with > the problem. It's true that we don't have to specify a lookup service to deal with fuzzy matching. However, the + users will have start manually publishing those. That seems like a pain. Also, using DNS for this opens mail domains to zone walking to find mailboxes, whereas a proper lookup service wouldn't (it would still be an oracle, but there would be no NSEC* to facilitate discovery of all email addresses at the domain). Nico -- From nobody Thu Mar 26 13:37:44 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1B621B2AF7 for ; Thu, 26 Mar 2015 13:37:43 -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 qRgPIeXZ9Qoy for ; Thu, 26 Mar 2015 13:37:42 -0700 (PDT) Received: from mail-qg0-f100.google.com (mail-qg0-f100.google.com [209.85.192.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AFB2C1AD06C for ; Thu, 26 Mar 2015 13:37:38 -0700 (PDT) Received: by qgdz107 with SMTP id z107so1786946qgd.1 for ; Thu, 26 Mar 2015 13:37:38 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:thread-topic:thread-index :date:message-id:references:in-reply-to:accept-language :content-language:content-type:mime-version; bh=ErBRWndDuSTkhla2EpMwWpujNoGkLVy0mBKtQYGYSTM=; b=FO4OrQgRPw933yswOtnz2/SM53RzdFG/vpUu2GF/a0iIHomG3SNcK9XKdIUz5Lvwtk RjIt5Fp5SqMju4X5OV479XjTSzexcg/FwE86ROZ7tHcLzqJSpF5VIB5AUUIO/KfxUoyd jABVK+aGCAeeY4Nqw0YPBxwua+IOwzyn/vVfuMaHjVSMTJD5UBZm2pqdG6FvInYcqIE6 TXEKrm42gQXrD11lq95JJb8YvpFCzCFr45OloHUH1SHBtQ3sFHRu0vxjii0Q064fSl0E qoLnIcoaF3reWIerDENuBKrDkXKx/NETYc+lAmYvWnYziUx6GNv4+438MPCx//CWMROX RJTw== X-Gm-Message-State: ALoCoQlIKzzcV+kr/86NuBzFkXkXdzYEE/rHjD4sEVaOTUACJFaP8yYrBoYjmXDzxBMraZ+EYdmOMiT10aOOh163Bpgjl2xpLA== X-Received: by 10.55.20.35 with SMTP id e35mr32935547qkh.37.1427402258005; Thu, 26 Mar 2015 13:37:38 -0700 (PDT) Received: from brn1lxmailout01.verisign.com (brn1lxmailout01.verisign.com. [72.13.63.41]) by mx.google.com with ESMTPS id cd6sm1426001qcb.2.2015.03.26.13.37.37 (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 26 Mar 2015 13:37:37 -0700 (PDT) X-Relaying-Domain: verisign.com Received: from brn1wnexcas02.vcorp.ad.vrsn.com (brn1wnexcas02 [10.173.152.206]) by brn1lxmailout01.verisign.com (8.13.8/8.13.8) with ESMTP id t2QKbbAc000993 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 26 Mar 2015 16:37:37 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas02.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Thu, 26 Mar 2015 16:37:37 -0400 From: "Osterweil, Eric" To: Nico Williams Thread-Topic: [dane] Comments on draft-ietf-dane-openpgpkey-02 (fwd) Thread-Index: AQHQXfwKBM0/8GmPcUia3XoiZHQl0p0blDkAgAEHPICAAZIHAIAALmeAgAAakQCAAAJygIAABH4AgAAEs4CAAA1yAIACoY8AgAB2lACAAPReAIAABScAgAAEyQCAC954AIAA8CIAgAABXYCAAATtgIAABxeAgAADbgCAAARaAIAABrqA Date: Thu, 26 Mar 2015 20:37:35 +0000 Message-ID: References: <20150318001300.34285.qmail@ary.lan> <40D64A6D-B518-40F2-9556-762839A92A9E@seantek.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: multipart/signed; boundary="Apple-Mail=_4FC57E94-AC55-4DB4-9836-2C92D9113DC6"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Archived-At: Cc: dane WG list Subject: Re: [dane] Comments on draft-ietf-dane-openpgpkey-02 (fwd) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2015 20:37:43 -0000 --Apple-Mail=_4FC57E94-AC55-4DB4-9836-2C92D9113DC6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hey Nico,=20 On Mar 26, 2015, at 3:13 PM, Nico Williams = wrote: > On Thu, Mar 26, 2015 at 2:57 PM, Doug Montgomery = wrote: >> For any set of aliases that are manually configured, publishing a = key, or >> CNAME for each of those is of the same order of complexity as = establishing >> the alias itself. >>=20 >> When I try to validate the sig for joe+dane@domain.com I will look = that up. >=20 > + is not configured. They're magic... if your MTAs are > configured so anyways. These uses exist precisely because they were > a) permitted, b) handy. So now we have to deal with them. Indeed, but I think this a powerful feature that lets users advertise = their intent. If someone wants to add protections to their list = subscriptions, or wants to add different crypto to different email = aliases, then configuring the encr/signing behavior independently is a = feature, not a bug, me thinks. > I still fail to see what inbound fuzzy match of local parts has to do = with >> the problem. >=20 > It's true that we don't have to specify a lookup service to deal with > fuzzy matching. However, the + users will have start > manually publishing those. That seems like a pain. Again, if someone wants to receive encrypted email or have their = signatures verified, it seems reasonable to advertise their intentions = explicitly. I really think this is a feature, not a bug. > Also, using DNS for this opens mail domains to zone walking to find > mailboxes, whereas a proper lookup service wouldn't (it would still be > an oracle, but there would be no NSEC* to facilitate discovery of all > email addresses at the domain). I mentioned a candidate approach to dealing with this at the mic = yesterday. I think this could easily be a domain and MUA configurable = option with some of the proposed enhancements we=92ve coded into SMIMEA, = but I don=92t want to distract this thread too much. Maybe we can start = a new thread for that (over beer, perhaps). ;) Eric= --Apple-Mail=_4FC57E94-AC55-4DB4-9836-2C92D9113DC6 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIN7DCCBmAw ggVIoAMCAQICEHaFyweo4MwP0sVNjzk1sxIwDQYJKoZIhvcNAQEFBQAwgcoxCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0aG9yaXplZCB1c2Ug b25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMiBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0 aW9uIEF1dGhvcml0eSAtIEczMB4XDTExMDYwNzAwMDAwMFoXDTIxMDYwNjIzNTk1OVowgckxCzAJ BgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50 ZWMgVHJ1c3QgTmV0d29yazE1MDMGA1UECxMsQ2xhc3MgMiBNYW5hZ2VkIFBLSSBJbmRpdmlkdWFs IFN1YnNjcmliZXIgQ0ExQzBBBgNVBAMTOlN5bWFudGVjIENsYXNzIDIgU2hhcmVkIEludGVybWVk aWF0ZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQC3+D8MK4MjIIWmTUkBUTra3VAzvuMEpDo+o2FmTDTC6HRwdUmlt0ns3bOSnN15DeK5+rg5PL6F 44zvbXmjprcIv5xMvj6YjqzbfJor7AUoMF8pGzNNRNVw6FYimaY+nUJb6yOnY50tLLAuPxjzKc0a NomEksdXcFtwheY4oXxQ4zc4iGVba8s5KgSxgqoZBP+gfz+j25FFdmaja/OFI15O2YVddaegFffB AHTg5cqUQmWawjd6i6hQrL+XdGd30TKnr43Lk6klQrQwGnQK4iUQEMt0Z1UPyxT8QVAKpHxNCwv5 Bak1+UWnMfGAu6LJPs52OeEq/3ZQ5+hRIt8tz7gzAgMBAAGjggI/MIICOzASBgNVHRMBAf8ECDAG AQH/AgEAMDQGA1UdHwQtMCswKaAnoCWGI2h0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTItZzMu Y3JsMA4GA1UdDwEB/wQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRVmVyaVNpZ25NUEtJ LTItNTYwHQYDVR0OBBYEFNhIKahfKheS4vqee+9vYIP4uLjcMIHwBgNVHSMEgegwgeWhgdCkgc0w gcoxCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4gLSBGb3Ig YXV0aG9yaXplZCB1c2Ugb25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMiBQdWJsaWMgUHJp bWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEczghBhcMtJjF+YRSnnsKbZUFt6MDQGCCsG AQUFBwEBBCgwJjAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AudmVyaXNpZ24uY29tMGwGA1UdIARl MGMwYQYLYIZIAYb4RQEHFwIwUjAmBggrBgEFBQcCARYaaHR0cDovL3d3dy5zeW1hdXRoLmNvbS9j cHMwKAYIKwYBBQUHAgIwHBoaaHR0cDovL3d3dy5zeW1hdXRoLmNvbS9ycGEwDQYJKoZIhvcNAQEF BQADggEBAKYqmwdAyez/s4joRdo00RcPKC23pYVnMc3B5tUphjis4vBZGwzhoUXOJHjvacGwTGGi SNloT7r+dVQ3ulhp6sF2pTZC6p5meJAg2ZVqJHlUzd5aGoo7rhiVctAl2NJGvjQwp4Ce8VbOIB5s Z8lNT3mHieIugNae7SZhZaID0MXi8yi5K0lpgmfs1ek0pC7cYiKkhU1I42oClPLN/eRnyEm8qtXH 5zzeh7EQa10HXBnka6D0T5nL3LVbDMwy+WrkdMAqWDd5s/vNwzRv4XbdEAcAY4sHTicXkkebDr7e DROFEfyiL2V9zDqsHlRrVmfE7qWHIiMXK3BWw/Gud1wnwTkwggeEMIIGbKADAgECAhBcCMgDVFpl hwRR0TZyMUgoMA0GCSqGSIb3DQEBBQUAMIHJMQswCQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50 ZWMgQ29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdvcmsxNTAzBgNVBAsT LENsYXNzIDIgTWFuYWdlZCBQS0kgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBMUMwQQYDVQQDEzpT eW1hbnRlYyBDbGFzcyAyIFNoYXJlZCBJbnRlcm1lZGlhdGUgQ2VydGlmaWNhdGUgQXV0aG9yaXR5 MB4XDTE0MDQxMDAwMDAwMFoXDTE1MDQxMDIzNTk1OVowczEmMCQGCSqGSIb3DQEJARYXZW9zdGVy d2VpbEB2ZXJpc2lnbi5jb20xGDAWBgNVBAMMD09zdGVyd2VpbCwgRXJpYzEWMBQGA1UECwwNRU5U RVJQUklTRSBJVDEXMBUGA1UECgwOVmVyaVNpZ24sIEluYy4wggEiMA0GCSqGSIb3DQEBAQUAA4IB DwAwggEKAoIBAQCmK2/yLaprGu39usXztz6N7uLYDoKN4MNaDFGGj1eYfMkIfb6LDoYBs9qcnINg 8in4NxGwVQGIJU5AE/1wHe/V1qavpHEO2mVxRq94cBF0P8ETPpM1yhwBhU4QKhjNEDj9wov8RXzO hjqPy/uknZvBxfobQx22vhnEKpf7QEN0zfLDJON3tyYwsnrFZkmop4ni4ANI7ev5uqcI05ED7vSh K9AHAVjzjr2QvtmvqHAkOnpHgqkWJWhuw4f9Gx+8LmbC3tl8oxF7+E7WEwKTQG56BV0uR6PN/o0S O7VSbDCZyNoxxrjzw+CesWsigi2NvC5DnhkKlxP+JSfJxMDu+7MDAgMBAAGjggO7MIIDtzAMBgNV HRMBAf8EAjAAMA4GA1UdDwEB/wQEAwIFoDAWBgNVHSUBAf8EDDAKBggrBgEFBQcDBDAdBgNVHQ4E FgQUVoVKaC1xEPB9EWKq3dWrwskIufkwUAYDVR0RBEkwR4EXZW9zdGVyd2VpbEB2ZXJpc2lnbi5j b22gLAYKKwYBBAGCNxQCA6AeDBxlb3N0ZXJ3ZWlsQHZjb3JwLmFkLnZyc24uY29tMB8GA1UdIwQY MBaAFNhIKahfKheS4vqee+9vYIP4uLjcMIIBcQYIKwYBBQUHAQEEggFjMIIBXzAnBggrBgEFBQcw AYYbaHR0cDovL3BraS1vY3NwLnN5bWF1dGguY29tMIIBMgYIKwYBBQUHMAKGggEkbGRhcDovL2Rp cmVjdG9yeS52ZXJpc2lnbi5jb20vQ04lMjAlM0QlMjBTeW1hbnRlYyUyMENsYXNzJTIwMiUyMFNo YXJlZCUyMEludGVybWVkaWF0ZSUyMENlcnRpZmljYXRlJTIwQXV0aG9yaXR5JTJDT1UlMjAlM0Ql MjBDbGFzcyUyMDIlMjBNYW5hZ2VkJTIwUEtJJTIwSW5kaXZpZHVhbCUyMFN1YnNjcmliZXIlMjBD QSUyQ09VJTIwJTNEJTIwU3ltYW50ZWMlMjBUcnVzdCUyME5ldHdvcmslMkNPJTIwJTNEJTIwU3lt YW50ZWMlMjBDb3Jwb3JhdGlvbiUyQ0MlMjAlM0QlMjBVUz9jQUNlcnRpZmljYXRlO2JpbmFyeTBd BgNVHR8EVjBUMFKgUKBOhkxodHRwOi8vcGtpLWNybC5zeW1hdXRoLmNvbS9jYV8wN2JiN2Q2NDc3 Y2Y0ZjZiZTk2YWYxYjM2Y2FiZDMxNi9MYXRlc3RDUkwuY3JsMGwGA1UdIARlMGMwYQYLYIZIAYb4 RQEHFwIwUjAmBggrBgEFBQcCARYaaHR0cDovL3d3dy5zeW1hdXRoLmNvbS9jcHMwKAYIKwYBBQUH AgIwHBoaaHR0cDovL3d3dy5zeW1hdXRoLmNvbS9ycGEwQgYJKoZIhvcNAQkPBDUwMzAKBggqhkiG 9w0DBzALBglghkgBZQMEAQIwCwYJYIZIAWUDBAEWMAsGCWCGSAFlAwQBKjAsBgpghkgBhvhFARAD BB4wHAYSYIZIAYb4RQEQAQICAQGL8cYJFgYyNDc2NjQwOQYKYIZIAYb4RQEQBQQrMCkCAQAWJGFI UjBjSE02THk5d2Eya3RjbUV1YzNsdFlYVjBhQzVqYjIwPTANBgkqhkiG9w0BAQUFAAOCAQEAXFTS ZEP9la6QYPlo6ybMEEpxVOADx082WRGtrYoU9ZEaC2IlxmwI9JprNfBlIy8FtyJAuWKBbe9/XKJF cukb2HNS0httHUIcSTfMEsAyc99/ba/SoMlhtvko/nCvx5brzhpQwop6AgMv9v5V7F1GUFO7db8L LSs1gIZYI8IeudznJOQGUBFGe0aJhA4cD/3OIZyItWpNtn94i1GJUFPMjYhGcy/r0fUQY/KFLwOi M6bT/m1RwAJKJI/mON/OshdzylAYqKOPoFTJD4qrbrpij1r1+e1VHKklAxTd+nOg9J1L0yRwlEDS 1boeOxqNXGnEYAa54k0ZWPh+8dFemteaLjGCBE0wggRJAgEBMIHeMIHJMQswCQYDVQQGEwJVUzEd MBsGA1UEChMUU3ltYW50ZWMgQ29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5l dHdvcmsxNTAzBgNVBAsTLENsYXNzIDIgTWFuYWdlZCBQS0kgSW5kaXZpZHVhbCBTdWJzY3JpYmVy IENBMUMwQQYDVQQDEzpTeW1hbnRlYyBDbGFzcyAyIFNoYXJlZCBJbnRlcm1lZGlhdGUgQ2VydGlm aWNhdGUgQXV0aG9yaXR5AhBcCMgDVFplhwRR0TZyMUgoMAkGBSsOAwIaBQCgggJDMBgGCSqGSIb3 DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1MDMyNjIwMzczNVowIwYJKoZIhvcN AQkEMRYEFB0+qFf07Ro8ynFvp5bTMyfzshb3MIHvBgkrBgEEAYI3EAQxgeEwgd4wgckxCzAJBgNV BAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50ZWMg VHJ1c3QgTmV0d29yazE1MDMGA1UECxMsQ2xhc3MgMiBNYW5hZ2VkIFBLSSBJbmRpdmlkdWFsIFN1 YnNjcmliZXIgQ0ExQzBBBgNVBAMTOlN5bWFudGVjIENsYXNzIDIgU2hhcmVkIEludGVybWVkaWF0 ZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkCEFwIyANUWmWHBFHRNnIxSCgwgfEGCyqGSIb3DQEJEAIL MYHhoIHeMIHJMQswCQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMgQ29ycG9yYXRpb24xHzAd BgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdvcmsxNTAzBgNVBAsTLENsYXNzIDIgTWFuYWdlZCBQ S0kgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBMUMwQQYDVQQDEzpTeW1hbnRlYyBDbGFzcyAyIFNo YXJlZCBJbnRlcm1lZGlhdGUgQ2VydGlmaWNhdGUgQXV0aG9yaXR5AhBcCMgDVFplhwRR0TZyMUgo MA0GCSqGSIb3DQEBAQUABIIBAAsmgUKbbxkt/uIVEku5NGZe930rpunG+/wE5QL8eDt2KKiijRmT qkVcb/yVl3I3GsqAWRQLSaWUcyGEZw9fhAyRlcXplEowxmAKDNqfXOfTH9BjpW+oGDlz/GWIAv7z 9nRvFQPwhS1oJS9raZik/gwdwtVMjqRCnLR0bnCIpHOJ02iLsvjGNXEZlK0iWU7LxNeOb7dZV5kH O6jPpryClM7tbtVeoH2lnmydJxFeCrTof7Ar3f+xTZKi3FqlrJPrKoqZxYXVFJbSzNhRsH9e6Xzh WDDpXZCQuTOfs/nGX+zisji/CwMcbxJ89or2HU8tGZceDrgOcl0GyyVqocQv+5EAAAAAAAA= --Apple-Mail=_4FC57E94-AC55-4DB4-9836-2C92D9113DC6-- From nobody Thu Mar 26 13:50: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 02B551B2F04 for ; Thu, 26 Mar 2015 13:50:20 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KYvDAz_tQNgD for ; Thu, 26 Mar 2015 13:50:17 -0700 (PDT) Received: from mail-pd0-f180.google.com (mail-pd0-f180.google.com [209.85.192.180]) (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 4B1461A89B4 for ; Thu, 26 Mar 2015 13:50:17 -0700 (PDT) Received: by pdnc3 with SMTP id c3so74078782pdn.0 for ; Thu, 26 Mar 2015 13:50:17 -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:cc:content-type; bh=ZxMaoG1SXxDLQLaxVLTByyaVsXG5zfkCtO7W+u2lbEk=; b=Ut5mWIUD8DCcTI9KK7ID47Vr7Y9erzBdensQlDmIgoYrJfGVTSxojOwDWasKPDLIfB FlT+vDVGXBO49fVobyCb1P90twA2WVX4kUgBzfZJJKuOAeImlAnbK0hmqeKyNobBff15 2pTQbD39sf3JZpM8LAfQ0CwACERU6KpKoeb7KnJrwuK0TpOLanCh34sULXyP1nCZT3kT RWKlw6bKKUVshRusHOT2gSWQKCa3uNtQ3NBbL5dHsbVKLzq+vbNi8AZk1Cxu8eHxs+VK rAPaJrXuyrAUc8EhGNn2IuZ+iC+OXajwI5YjALu6wt+d3plofzBGDEUu6MDdEgkJ2I5e lV3g== X-Gm-Message-State: ALoCoQnFmwbDdapr+KsqGIasFLItt+21wlVlmEhm33B0GGLuTJ1CExeRrYKnIsTD5kmw8Fs/wfDx MIME-Version: 1.0 X-Received: by 10.68.223.130 with SMTP id qu2mr30068837pbc.116.1427403016636; Thu, 26 Mar 2015 13:50:16 -0700 (PDT) Received: by 10.70.138.36 with HTTP; Thu, 26 Mar 2015 13:50:16 -0700 (PDT) X-Originating-IP: [31.133.140.104] In-Reply-To: References: <20150318001300.34285.qmail@ary.lan> <40D64A6D-B518-40F2-9556-762839A92A9E@seantek.com> Date: Thu, 26 Mar 2015 15:50:16 -0500 Message-ID: From: George Michaelson To: "Osterweil, Eric" Content-Type: multipart/alternative; boundary=e89a8ffba0ebc221320512372909 Archived-At: Cc: dane WG list Subject: Re: [dane] Comments on draft-ietf-dane-openpgpkey-02 (fwd) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2015 20:50:20 -0000 --e89a8ffba0ebc221320512372909 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Mail systems are exposed to the entire header. The Envelope isn't neccessarily the same as the header (this we know) So absent a wilingness to add a magic third field to the Mail From: field which would be [....hash of PGP] How about we have X- behiour explored in the mail header, which is all safe for now and MUA exposed? When we know how that works, we can move on what we really need, which is envelope level: MAIL FROM: "George is Nuts" PGP-KEY-HASH-HERE -G On Thu, Mar 26, 2015 at 3:37 PM, Osterweil, Eric wrote: > Hey Nico, > > On Mar 26, 2015, at 3:13 PM, Nico Williams wrote: > > > On Thu, Mar 26, 2015 at 2:57 PM, Doug Montgomery > wrote: > >> For any set of aliases that are manually configured, publishing a key, > or > >> CNAME for each of those is of the same order of complexity as > establishing > >> the alias itself. > >> > >> When I try to validate the sig for joe+dane@domain.com I will look > that up. > > > > + is not configured. They're magic... if your MTAs are > > configured so anyways. These uses exist precisely because they were > > a) permitted, b) handy. So now we have to deal with them. > > Indeed, but I think this a powerful feature that lets users advertise > their intent. If someone wants to add protections to their list > subscriptions, or wants to add different crypto to different email aliase= s, > then configuring the encr/signing behavior independently is a feature, no= t > a bug, me thinks. > > > I still fail to see what inbound fuzzy match of local parts has to do > with > >> the problem. > > > > It's true that we don't have to specify a lookup service to deal with > > fuzzy matching. However, the + users will have start > > manually publishing those. That seems like a pain. > > Again, if someone wants to receive encrypted email or have their > signatures verified, it seems reasonable to advertise their intentions > explicitly. I really think this is a feature, not a bug. > > > Also, using DNS for this opens mail domains to zone walking to find > > mailboxes, whereas a proper lookup service wouldn't (it would still be > > an oracle, but there would be no NSEC* to facilitate discovery of all > > email addresses at the domain). > > I mentioned a candidate approach to dealing with this at the mic > yesterday. I think this could easily be a domain and MUA configurable > option with some of the proposed enhancements we=E2=80=99ve coded into SM= IMEA, but > I don=E2=80=99t want to distract this thread too much. Maybe we can star= t a new > thread for that (over beer, perhaps). ;) > > Eric > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane > > --e89a8ffba0ebc221320512372909 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Mail systems are exposed to the entire header. The Envelop= e isn't neccessarily the same as the header (this we know)

So a= bsent a wilingness to add a magic third field to the Mail From: field which= would be [....hash of PGP] How about we have X- behiour explored in the ma= il header, which is all safe for now and MUA exposed?

<= div>When we know how that works, we can move on what we really need, which = is envelope level:

MAIL FROM: "George is Nuts= " <ggm@apnic.net> PGP-KEY-H= ASH-HERE

-G
=
On Thu, Mar 26, 2015 at 3:37 PM, Osterweil, = Eric <eosterweil@verisign.com> wrote:
Hey Nico,

On Mar 26, 2015, at 3:13 PM, Nico Williams <nico@cryptonector.com> wrote:

> On Thu, Mar 26, 2015 at 2:57 PM, Doug Montgomery <dougm.work@gmail.com> wrote:
>> For any set of aliases that are manually configured, publishing a = key, or
>> CNAME for each of those is of the same order of complexity as esta= blishing
>> the alias itself.
>>
>> When I try to validate the sig for joe+dane@domain.com I will look that up.
>
> <name>+<list> is not configured.=C2=A0 They're magic..= . if your MTAs are
> configured so anyways.=C2=A0 These uses exist precisely because they w= ere
> a) permitted, b) handy.=C2=A0 So now we have to deal with them.

Indeed, but I think this a powerful feature that lets users advertis= e their intent.=C2=A0 If someone wants to add protections to their list sub= scriptions, or wants to add different crypto to different email aliases, th= en configuring the encr/signing behavior independently is a feature, not a = bug, me thinks.

> I still fail to see what inbound fuzzy match of local parts has to do = with
>> the problem.
>
> It's true that we don't have to specify a lookup service to de= al with
> fuzzy matching.=C2=A0 However, the <name>+<list> users wil= l have start
> manually publishing those.=C2=A0 That seems like a pain.

Again, if someone wants to receive encrypted email or have their sig= natures verified, it seems reasonable to advertise their intentions explici= tly.=C2=A0 I really think this is a feature, not a bug.

> Also, using DNS for this opens mail domains to zone walking to find > mailboxes, whereas a proper lookup service wouldn't (it would stil= l be
> an oracle, but there would be no NSEC* to facilitate discovery of all<= br> > email addresses at the domain).

I mentioned a candidate approach to dealing with this at the mic yes= terday.=C2=A0 I think this could easily be a domain and MUA configurable op= tion with some of the proposed enhancements we=E2=80=99ve coded into SMIMEA= , but I don=E2=80=99t want to distract this thread too much.=C2=A0 Maybe we= can start a new thread for that (over beer, perhaps). ;)

Eric
_______________________________________________
dane mailing list
dane@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/dane


--e89a8ffba0ebc221320512372909-- From nobody Thu Mar 26 13:53: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 9773A1B2F0D for ; Thu, 26 Mar 2015 13:53:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4nj4DD0kwmaJ for ; Thu, 26 Mar 2015 13:53:01 -0700 (PDT) Received: from homiemail-a16.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id E39FD1B2EC2 for ; Thu, 26 Mar 2015 13:53:00 -0700 (PDT) Received: from homiemail-a16.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a16.g.dreamhost.com (Postfix) with ESMTP id 9BA6F5080BB for ; Thu, 26 Mar 2015 13:53:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=IA5+uLiu8CWQD7NWDrNA2ofXL6k=; b=anA9kSy/M3a Bb6YRKzl8C9NsiI9t1x28V4frIj/S2y602xO6vi8sQ+XFyMtxJe8bQOy/A2zRnGV l/QkzKcp+5ofy7MM4E6TbNo3PY4hRTRxZxdK4B57Rb6/gkfO3t/bvriEVdxNhAEE qJnBqx5rcL+kNYKAwBU0xUOonm0Ip3W0= Received: from mail-ig0-f170.google.com (mail-ig0-f170.google.com [209.85.213.170]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a16.g.dreamhost.com (Postfix) with ESMTPSA id 8C11D50808E for ; Thu, 26 Mar 2015 13:53:00 -0700 (PDT) Received: by igbud6 with SMTP id ud6so3330696igb.1 for ; Thu, 26 Mar 2015 13:53:00 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.42.226.69 with SMTP id iv5mr32670180icb.58.1427403180194; Thu, 26 Mar 2015 13:53:00 -0700 (PDT) Received: by 10.64.130.66 with HTTP; Thu, 26 Mar 2015 13:53:00 -0700 (PDT) In-Reply-To: References: <20150318001300.34285.qmail@ary.lan> <40D64A6D-B518-40F2-9556-762839A92A9E@seantek.com> Date: Thu, 26 Mar 2015 15:53:00 -0500 Message-ID: From: Nico Williams To: "Osterweil, Eric" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: dane WG list Subject: Re: [dane] Comments on draft-ietf-dane-openpgpkey-02 (fwd) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2015 20:53:02 -0000 On Thu, Mar 26, 2015 at 3:37 PM, Osterweil, Eric wrote: > On Mar 26, 2015, at 3:13 PM, Nico Williams wrote: >> + is not configured. They're magic... if your MTAs are >> configured so anyways. These uses exist precisely because they were >> a) permitted, b) handy. So now we have to deal with them. > > Indeed, but I think this a powerful feature that lets users advertise the= ir intent. If someone wants to add protections to their list subscriptions= , or wants to add different crypto to different email aliases, then configu= ring the encr/signing behavior independently is a feature, not a bug, me th= inks. People who do this mostly want to filter into folders based on recipient address. They are able to magically create new sender addresses without doing anything special. >> I still fail to see what inbound fuzzy match of local parts has to do wi= th >>> the problem. >> >> It's true that we don't have to specify a lookup service to deal with >> fuzzy matching. However, the + users will have start >> manually publishing those. That seems like a pain. > > Again, if someone wants to receive encrypted email or have their signatur= es verified, it seems reasonable to advertise their intentions explicitly. = I really think this is a feature, not a bug. A lookup protocol does this, either by applying local rules such as s/[+].*$// or whatever they like. >> Also, using DNS for this opens mail domains to zone walking to find >> mailboxes, whereas a proper lookup service wouldn't (it would still be >> an oracle, but there would be no NSEC* to facilitate discovery of all >> email addresses at the domain). > > I mentioned a candidate approach to dealing with this at the mic yesterda= y. I think this could easily be a domain and MUA configurable option with = some of the proposed enhancements we=E2=80=99ve coded into SMIMEA, but I do= n=E2=80=99t want to distract this thread too much. Maybe we can start a ne= w thread for that (over beer, perhaps). ;) I don't remember it. Can you remind us? Debating the +list thing is more distracting, I think :) Nico -- From nobody Thu Mar 26 13:54: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 5275B1B2F0E for ; Thu, 26 Mar 2015 13:54:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6WM0932DtTpb for ; Thu, 26 Mar 2015 13:54:49 -0700 (PDT) Received: from homiemail-a54.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 9F6D51B2EFA for ; Thu, 26 Mar 2015 13:54:49 -0700 (PDT) Received: from homiemail-a54.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a54.g.dreamhost.com (Postfix) with ESMTP id 7128E400F8E0D for ; Thu, 26 Mar 2015 13:54:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=AYlnge0+ntHjx5dpWYKL UN4hKJA=; b=J60iOsrM/NcGbieCKS61MB4S0xQD2MMoI9oUesECsCo0RUCZqY4Z 4v70m3uXZhkXUr5noVp2TZAvE/B4eMLwrr4gvBcCdWaeChdUiUSYeYP9gVWWsDBO TOTBMJ+jFAVb1mbNti4kZfcPVkvipYFYsL1eMlVr6KM1f4lTOYu8DMo= Received: from mail-ig0-f175.google.com (mail-ig0-f175.google.com [209.85.213.175]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a54.g.dreamhost.com (Postfix) with ESMTPSA id 5ACFF400EE52E for ; Thu, 26 Mar 2015 13:54:49 -0700 (PDT) Received: by igcxg11 with SMTP id xg11so3453641igc.0 for ; Thu, 26 Mar 2015 13:54:49 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.43.77.6 with SMTP id zg6mr1612474icb.68.1427403289116; Thu, 26 Mar 2015 13:54:49 -0700 (PDT) Received: by 10.64.130.66 with HTTP; Thu, 26 Mar 2015 13:54:48 -0700 (PDT) In-Reply-To: References: <20150318001300.34285.qmail@ary.lan> <40D64A6D-B518-40F2-9556-762839A92A9E@seantek.com> Date: Thu, 26 Mar 2015 15:54:48 -0500 Message-ID: From: Nico Williams To: George Michaelson Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: dane WG list Subject: Re: [dane] Comments on draft-ietf-dane-openpgpkey-02 (fwd) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2015 20:54:50 -0000 On Thu, Mar 26, 2015 at 3:50 PM, George Michaelson wrote: > Mail systems are exposed to the entire header. The Envelope isn't > neccessarily the same as the header (this we know) > > So absent a wilingness to add a magic third field to the Mail From: field > which would be [....hash of PGP] How about we have X- behiour explored in > the mail header, which is all safe for now and MUA exposed? > > When we know how that works, we can move on what we really need, which is > envelope level: > > MAIL FROM: "George is Nuts" PGP-KEY-HASH-HERE What problem is this solving? From nobody Thu Mar 26 13: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 62E0B1B2F15 for ; Thu, 26 Mar 2015 13:59:22 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vPnQfsbpHsYr for ; Thu, 26 Mar 2015 13:59:20 -0700 (PDT) Received: from mail-pa0-f47.google.com (mail-pa0-f47.google.com [209.85.220.47]) (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 B93871B2F23 for ; Thu, 26 Mar 2015 13:59:09 -0700 (PDT) Received: by pacwe9 with SMTP id we9so74054061pac.1 for ; Thu, 26 Mar 2015 13:59:09 -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:cc:content-type; bh=2/YfiGzd10XUETOZgCBKjHpxSlPpMMpsMSdWFm9eDXU=; b=THzwhqc7t+6oslU9Vj6K0teJWI+17hkSs29zOkkKuRN9N3iBWCC27uLACtsmhoquEC O7LsYmN7epIpU/WZSCD9Nm3drBXgFHLB8a0whTl4RLcVSXP4G1orLnhckiAvepxB4thH SeQFlgTOaWMeK5nTecJQ7j3j8KG+dRfVMc/WY8L6R8x1ysJoWmSwHFQZHhmC1w7IQPAp 59+Erguc3Iw0s4Gyrl3yC4cBERDkQTrihCfyZ8M+dbg9zxb3rFn1JCTHuZhunLj2Ojlj UBWYazerwnTdbPjVuXmIiviCcYal0gnHA7qNYZL8WSvDRhd2JVrgM2LlGKYi/YYHnUjF d+nA== X-Gm-Message-State: ALoCoQmPATd5p+zhhwaS3wLWlmcTWEfhnHbIt0qG7Ky1nOz6OfATp10lyS3UcGsxT5BKUYiC94I5 MIME-Version: 1.0 X-Received: by 10.70.96.98 with SMTP id dr2mr29755872pdb.96.1427403549371; Thu, 26 Mar 2015 13:59:09 -0700 (PDT) Received: by 10.70.138.36 with HTTP; Thu, 26 Mar 2015 13:59:09 -0700 (PDT) X-Originating-IP: [31.133.140.104] In-Reply-To: References: <20150318001300.34285.qmail@ary.lan> <40D64A6D-B518-40F2-9556-762839A92A9E@seantek.com> Date: Thu, 26 Mar 2015 15:59:09 -0500 Message-ID: From: George Michaelson To: Nico Williams Content-Type: multipart/alternative; boundary=001a11c2d2708305a90512374961 Archived-At: Cc: dane WG list Subject: Re: [dane] Comments on draft-ietf-dane-openpgpkey-02 (fwd) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2015 20:59:22 -0000 --001a11c2d2708305a90512374961 Content-Type: text/plain; charset=UTF-8 If you've never received mail from somebody before you cannot rely on any aspect of lhs@rhs to inform their key. So the game is lost if anyone thinks proscriptive logic around lhs@ is going to be abided by. The discussion in the room was about interpretation of lhs@ I think the sensible path out is to get people to send mail, and include PGP key in the envelope. Any recipient you see this for, you have their PGP ID as a proffer and its associated with their email identity. Which builds your set of recipients which have known PGP ID very quickly once you confirm it out of band. Likewise for lists. Your sender is exposed to the list mailer. Your PGP ID is scraped from Envelope. And, since Envelope is from MTA not MUA, it has some traction for being set by local admin so the local admin LDAP can populate the outbound PGP ID into the MAIL FROM No .sigs required. On Thu, Mar 26, 2015 at 3:54 PM, Nico Williams wrote: > On Thu, Mar 26, 2015 at 3:50 PM, George Michaelson > wrote: > > Mail systems are exposed to the entire header. The Envelope isn't > > neccessarily the same as the header (this we know) > > > > So absent a wilingness to add a magic third field to the Mail From: field > > which would be [....hash of PGP] How about we have X- behiour explored in > > the mail header, which is all safe for now and MUA exposed? > > > > When we know how that works, we can move on what we really need, which is > > envelope level: > > > > MAIL FROM: "George is Nuts" PGP-KEY-HASH-HERE > > What problem is this solving? > --001a11c2d2708305a90512374961 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
If you've never received mail from somebody before you= cannot rely on any aspect of lhs@rhs to inform their key. So the game is l= ost if anyone thinks proscriptive logic around lhs@ is going to be abided b= y.

The discussion in the room was about interpretation o= f lhs@

I think the sensible path out is to get peo= ple to send mail, and include PGP key in the envelope. Any recipient you se= e this for, you have their PGP ID as a proffer and its associated with thei= r email identity. Which builds your set of recipients which have known PGP = ID very quickly once you confirm it out of band.

L= ikewise for lists. Your sender is exposed to the list mailer. Your PGP ID i= s scraped from Envelope.

And, since Envelope is fr= om MTA not MUA, it has some traction for being set by local admin so the lo= cal admin LDAP can populate the outbound PGP ID into the MAIL FROM

No .sigs required.


On Thu, Mar 26, 2015 at 3:54 P= M, Nico Williams <nico@cryptonector.com> wrote:
On Thu, Mar 26, 2015 at 3:50 PM,= George Michaelson <ggm@algebras.org= > wrote:
> Mail systems are exposed to the entire header. The Envelope isn't<= br> > neccessarily the same as the header (this we know)
>
> So absent a wilingness to add a magic third field to the Mail From: fi= eld
> which would be [....hash of PGP] How about we have X- behiour explored= in
> the mail header, which is all safe for now and MUA exposed?
>
> When we know how that works, we can move on what we really need, which= is
> envelope level:
>
> MAIL FROM: "George is Nuts" <ggm@apnic.net> PGP-KEY-HASH-HERE

What problem is this solving?

--001a11c2d2708305a90512374961-- From nobody Thu Mar 26 16:17: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 47E5B1A0E10 for ; Thu, 26 Mar 2015 16:17:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_62=0.6, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2NgvGJJe88hI for ; Thu, 26 Mar 2015 16:17:19 -0700 (PDT) Received: from mail-oi0-f99.google.com (mail-oi0-f99.google.com [209.85.218.99]) (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 72C261A01F7 for ; Thu, 26 Mar 2015 16:17:19 -0700 (PDT) Received: by oigh136 with SMTP id h136so89181oig.2 for ; Thu, 26 Mar 2015 16:17:19 -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:accept-language:content-language:content-type :mime-version; bh=WdgmFiLI0agzX1d3mzj4w9RRlKE5vEYwchAsTQfjmMw=; b=kAVyuYp4YSBTN+X+MQqhY66TiOv4G9vI6zVJWIGmn70RaQDxdTXXPEi+pXWbRaNk2F L508RXjoe8nvUVPqsBaVGgQE2dE857FLqPKeAK7v11Voo++F5wMStMCCOA38hZQu4t0i j3SigtjHm1iZ7pX47frtesE0ktphxQSpW3EWxAwWIjRoHsddkrVwCUjBmiVfk5P4V33J YPVbx6oZexBmRZD9YWUlaC8B+zfaqhIVqVjmhuYTvFKGzvKAaDHJ6pWZIyVOgIWS5b1s UZgDsywby1mbBHtGQ7LBigjpwwnSDfhSCyIqj5uhh3h8PklJDX1KkVC8njMMA13nChvH acjA== X-Gm-Message-State: ALoCoQnZId+wgdgTDk7V16iBXNmBZkytUB5tx1rUfawdAmhv2uko/eAd4cqzE0b1hONgcLlqk4C88Yq804bXD3RAJOIdRfFGnA== X-Received: by 10.55.40.135 with SMTP id o7mr33078907qko.93.1427411838899; Thu, 26 Mar 2015 16:17:18 -0700 (PDT) Received: from brn1lxmailout02.verisign.com (brn1lxmailout02.verisign.com. [72.13.63.42]) by mx.google.com with ESMTPS id hx9sm806848qcb.3.2015.03.26.16.17.18 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 26 Mar 2015 16:17:18 -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 t2QNHHf1027951 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 26 Mar 2015 19:17:18 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Thu, 26 Mar 2015 19:17:17 -0400 From: "Osterweil, Eric" To: dane WG list Thread-Topic: S/MIME email code (libsmaug) Thread-Index: AQHQaBr/5L/wuLrsLEmtuvJ9HZKXyQ== Date: Thu, 26 Mar 2015 23:17:16 +0000 Message-ID: <964601DF-9D6D-4CED-8929-FBC5CCEA2A21@verisign.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: multipart/signed; boundary="Apple-Mail=_DE8D0263-667A-4FF2-8DF5-532FE976CD6B"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Archived-At: Subject: [dane] S/MIME email code (libsmaug) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 26 Mar 2015 23:17:21 -0000 --Apple-Mail=_DE8D0263-667A-4FF2-8DF5-532FE976CD6B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hey wg folks, Thanks for the slot on the agenda this week. I just wanted to drop a = note with pointers from our presentation. Our Thunderbird beta code is = located at: https://github.com/verisign/smaug-tbird-plugin Our S/MIME object security library (libsmaug) is: https://github.com/verisign/smaug Glen and I excited to get folks using it (the SMIMEA generator and a = helpful S/MIME cert generation script are all included and described on = the README.md file(s)). We=92ll be around tonight and tomorrow (and = have a spot at Bits-n-Bytes) if folks want to chat, need some = installation debugging, etc. Thanks! Eric= --Apple-Mail=_DE8D0263-667A-4FF2-8DF5-532FE976CD6B Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIN7DCCBmAw ggVIoAMCAQICEHaFyweo4MwP0sVNjzk1sxIwDQYJKoZIhvcNAQEFBQAwgcoxCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0aG9yaXplZCB1c2Ug b25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMiBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0 aW9uIEF1dGhvcml0eSAtIEczMB4XDTExMDYwNzAwMDAwMFoXDTIxMDYwNjIzNTk1OVowgckxCzAJ BgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50 ZWMgVHJ1c3QgTmV0d29yazE1MDMGA1UECxMsQ2xhc3MgMiBNYW5hZ2VkIFBLSSBJbmRpdmlkdWFs IFN1YnNjcmliZXIgQ0ExQzBBBgNVBAMTOlN5bWFudGVjIENsYXNzIDIgU2hhcmVkIEludGVybWVk aWF0ZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQC3+D8MK4MjIIWmTUkBUTra3VAzvuMEpDo+o2FmTDTC6HRwdUmlt0ns3bOSnN15DeK5+rg5PL6F 44zvbXmjprcIv5xMvj6YjqzbfJor7AUoMF8pGzNNRNVw6FYimaY+nUJb6yOnY50tLLAuPxjzKc0a NomEksdXcFtwheY4oXxQ4zc4iGVba8s5KgSxgqoZBP+gfz+j25FFdmaja/OFI15O2YVddaegFffB AHTg5cqUQmWawjd6i6hQrL+XdGd30TKnr43Lk6klQrQwGnQK4iUQEMt0Z1UPyxT8QVAKpHxNCwv5 Bak1+UWnMfGAu6LJPs52OeEq/3ZQ5+hRIt8tz7gzAgMBAAGjggI/MIICOzASBgNVHRMBAf8ECDAG AQH/AgEAMDQGA1UdHwQtMCswKaAnoCWGI2h0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTItZzMu Y3JsMA4GA1UdDwEB/wQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRVmVyaVNpZ25NUEtJ LTItNTYwHQYDVR0OBBYEFNhIKahfKheS4vqee+9vYIP4uLjcMIHwBgNVHSMEgegwgeWhgdCkgc0w gcoxCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4gLSBGb3Ig YXV0aG9yaXplZCB1c2Ugb25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMiBQdWJsaWMgUHJp bWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEczghBhcMtJjF+YRSnnsKbZUFt6MDQGCCsG AQUFBwEBBCgwJjAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AudmVyaXNpZ24uY29tMGwGA1UdIARl MGMwYQYLYIZIAYb4RQEHFwIwUjAmBggrBgEFBQcCARYaaHR0cDovL3d3dy5zeW1hdXRoLmNvbS9j cHMwKAYIKwYBBQUHAgIwHBoaaHR0cDovL3d3dy5zeW1hdXRoLmNvbS9ycGEwDQYJKoZIhvcNAQEF BQADggEBAKYqmwdAyez/s4joRdo00RcPKC23pYVnMc3B5tUphjis4vBZGwzhoUXOJHjvacGwTGGi SNloT7r+dVQ3ulhp6sF2pTZC6p5meJAg2ZVqJHlUzd5aGoo7rhiVctAl2NJGvjQwp4Ce8VbOIB5s Z8lNT3mHieIugNae7SZhZaID0MXi8yi5K0lpgmfs1ek0pC7cYiKkhU1I42oClPLN/eRnyEm8qtXH 5zzeh7EQa10HXBnka6D0T5nL3LVbDMwy+WrkdMAqWDd5s/vNwzRv4XbdEAcAY4sHTicXkkebDr7e DROFEfyiL2V9zDqsHlRrVmfE7qWHIiMXK3BWw/Gud1wnwTkwggeEMIIGbKADAgECAhBcCMgDVFpl hwRR0TZyMUgoMA0GCSqGSIb3DQEBBQUAMIHJMQswCQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50 ZWMgQ29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdvcmsxNTAzBgNVBAsT LENsYXNzIDIgTWFuYWdlZCBQS0kgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBMUMwQQYDVQQDEzpT eW1hbnRlYyBDbGFzcyAyIFNoYXJlZCBJbnRlcm1lZGlhdGUgQ2VydGlmaWNhdGUgQXV0aG9yaXR5 MB4XDTE0MDQxMDAwMDAwMFoXDTE1MDQxMDIzNTk1OVowczEmMCQGCSqGSIb3DQEJARYXZW9zdGVy d2VpbEB2ZXJpc2lnbi5jb20xGDAWBgNVBAMMD09zdGVyd2VpbCwgRXJpYzEWMBQGA1UECwwNRU5U RVJQUklTRSBJVDEXMBUGA1UECgwOVmVyaVNpZ24sIEluYy4wggEiMA0GCSqGSIb3DQEBAQUAA4IB DwAwggEKAoIBAQCmK2/yLaprGu39usXztz6N7uLYDoKN4MNaDFGGj1eYfMkIfb6LDoYBs9qcnINg 8in4NxGwVQGIJU5AE/1wHe/V1qavpHEO2mVxRq94cBF0P8ETPpM1yhwBhU4QKhjNEDj9wov8RXzO hjqPy/uknZvBxfobQx22vhnEKpf7QEN0zfLDJON3tyYwsnrFZkmop4ni4ANI7ev5uqcI05ED7vSh K9AHAVjzjr2QvtmvqHAkOnpHgqkWJWhuw4f9Gx+8LmbC3tl8oxF7+E7WEwKTQG56BV0uR6PN/o0S O7VSbDCZyNoxxrjzw+CesWsigi2NvC5DnhkKlxP+JSfJxMDu+7MDAgMBAAGjggO7MIIDtzAMBgNV HRMBAf8EAjAAMA4GA1UdDwEB/wQEAwIFoDAWBgNVHSUBAf8EDDAKBggrBgEFBQcDBDAdBgNVHQ4E FgQUVoVKaC1xEPB9EWKq3dWrwskIufkwUAYDVR0RBEkwR4EXZW9zdGVyd2VpbEB2ZXJpc2lnbi5j b22gLAYKKwYBBAGCNxQCA6AeDBxlb3N0ZXJ3ZWlsQHZjb3JwLmFkLnZyc24uY29tMB8GA1UdIwQY MBaAFNhIKahfKheS4vqee+9vYIP4uLjcMIIBcQYIKwYBBQUHAQEEggFjMIIBXzAnBggrBgEFBQcw AYYbaHR0cDovL3BraS1vY3NwLnN5bWF1dGguY29tMIIBMgYIKwYBBQUHMAKGggEkbGRhcDovL2Rp cmVjdG9yeS52ZXJpc2lnbi5jb20vQ04lMjAlM0QlMjBTeW1hbnRlYyUyMENsYXNzJTIwMiUyMFNo YXJlZCUyMEludGVybWVkaWF0ZSUyMENlcnRpZmljYXRlJTIwQXV0aG9yaXR5JTJDT1UlMjAlM0Ql MjBDbGFzcyUyMDIlMjBNYW5hZ2VkJTIwUEtJJTIwSW5kaXZpZHVhbCUyMFN1YnNjcmliZXIlMjBD QSUyQ09VJTIwJTNEJTIwU3ltYW50ZWMlMjBUcnVzdCUyME5ldHdvcmslMkNPJTIwJTNEJTIwU3lt YW50ZWMlMjBDb3Jwb3JhdGlvbiUyQ0MlMjAlM0QlMjBVUz9jQUNlcnRpZmljYXRlO2JpbmFyeTBd BgNVHR8EVjBUMFKgUKBOhkxodHRwOi8vcGtpLWNybC5zeW1hdXRoLmNvbS9jYV8wN2JiN2Q2NDc3 Y2Y0ZjZiZTk2YWYxYjM2Y2FiZDMxNi9MYXRlc3RDUkwuY3JsMGwGA1UdIARlMGMwYQYLYIZIAYb4 RQEHFwIwUjAmBggrBgEFBQcCARYaaHR0cDovL3d3dy5zeW1hdXRoLmNvbS9jcHMwKAYIKwYBBQUH AgIwHBoaaHR0cDovL3d3dy5zeW1hdXRoLmNvbS9ycGEwQgYJKoZIhvcNAQkPBDUwMzAKBggqhkiG 9w0DBzALBglghkgBZQMEAQIwCwYJYIZIAWUDBAEWMAsGCWCGSAFlAwQBKjAsBgpghkgBhvhFARAD BB4wHAYSYIZIAYb4RQEQAQICAQGL8cYJFgYyNDc2NjQwOQYKYIZIAYb4RQEQBQQrMCkCAQAWJGFI UjBjSE02THk5d2Eya3RjbUV1YzNsdFlYVjBhQzVqYjIwPTANBgkqhkiG9w0BAQUFAAOCAQEAXFTS ZEP9la6QYPlo6ybMEEpxVOADx082WRGtrYoU9ZEaC2IlxmwI9JprNfBlIy8FtyJAuWKBbe9/XKJF cukb2HNS0httHUIcSTfMEsAyc99/ba/SoMlhtvko/nCvx5brzhpQwop6AgMv9v5V7F1GUFO7db8L LSs1gIZYI8IeudznJOQGUBFGe0aJhA4cD/3OIZyItWpNtn94i1GJUFPMjYhGcy/r0fUQY/KFLwOi M6bT/m1RwAJKJI/mON/OshdzylAYqKOPoFTJD4qrbrpij1r1+e1VHKklAxTd+nOg9J1L0yRwlEDS 1boeOxqNXGnEYAa54k0ZWPh+8dFemteaLjGCBE0wggRJAgEBMIHeMIHJMQswCQYDVQQGEwJVUzEd MBsGA1UEChMUU3ltYW50ZWMgQ29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5l dHdvcmsxNTAzBgNVBAsTLENsYXNzIDIgTWFuYWdlZCBQS0kgSW5kaXZpZHVhbCBTdWJzY3JpYmVy IENBMUMwQQYDVQQDEzpTeW1hbnRlYyBDbGFzcyAyIFNoYXJlZCBJbnRlcm1lZGlhdGUgQ2VydGlm aWNhdGUgQXV0aG9yaXR5AhBcCMgDVFplhwRR0TZyMUgoMAkGBSsOAwIaBQCgggJDMBgGCSqGSIb3 DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1MDMyNjIzMTcwMVowIwYJKoZIhvcN AQkEMRYEFEN9YYV7G7OgbJoUQCbKcrXY9UsfMIHvBgkrBgEEAYI3EAQxgeEwgd4wgckxCzAJBgNV BAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50ZWMg VHJ1c3QgTmV0d29yazE1MDMGA1UECxMsQ2xhc3MgMiBNYW5hZ2VkIFBLSSBJbmRpdmlkdWFsIFN1 YnNjcmliZXIgQ0ExQzBBBgNVBAMTOlN5bWFudGVjIENsYXNzIDIgU2hhcmVkIEludGVybWVkaWF0 ZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkCEFwIyANUWmWHBFHRNnIxSCgwgfEGCyqGSIb3DQEJEAIL MYHhoIHeMIHJMQswCQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMgQ29ycG9yYXRpb24xHzAd BgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdvcmsxNTAzBgNVBAsTLENsYXNzIDIgTWFuYWdlZCBQ S0kgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBMUMwQQYDVQQDEzpTeW1hbnRlYyBDbGFzcyAyIFNo YXJlZCBJbnRlcm1lZGlhdGUgQ2VydGlmaWNhdGUgQXV0aG9yaXR5AhBcCMgDVFplhwRR0TZyMUgo MA0GCSqGSIb3DQEBAQUABIIBAFYjQaT4/X392oshT94Zj6V5W5EixgoMk31vrztT3x2K7Oszs3qF IfikTn4Q2bYa0pbwkz8gWJ3uOWTf85xBJDwW1cqgLK5tl+xCkoHHg+C5BEGdmNYrLoxp2oXDggyz N5MbvYh08UQK7q/JwuIydjUDFzF0HSF69Gf2l+Em8TvLkcsRf9fqo+Bh8KRSMU5GqYB4nhyBHC// gjvtTT/kIYyRu+3fnfoBxs1+kx4qLctuNjhVusuxMyn2kMfP4gIurR0+8WsMH4ttV/t0kDOeazkZ HviiMNh/mknlLU87ZSJjdPNro54Ns1yE69JTE9YMYGNVRjRSs5l7szOtFyjHZYoAAAAAAAA= --Apple-Mail=_DE8D0263-667A-4FF2-8DF5-532FE976CD6B-- From nobody Fri Mar 27 00:53: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 885221A90AA for ; Fri, 27 Mar 2015 00:53:24 -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_SE=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 e1vc9FNTKQsw for ; Fri, 27 Mar 2015 00:53:22 -0700 (PDT) Received: from spg.kirei.se (spg.kirei.se [91.206.174.9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A7E2C1A90A6 for ; Fri, 27 Mar 2015 00:53:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kirei.se; s=spg20100524; h=received:content-type:mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to:x-mailer; bh=zwi4pVpDQDyxF9xOhLd2R+aSkp15IOoYF/cgMlRqKDg=; b=Sb4arfp48S+Cn8t4vpYIw9fcA16hEb6ri8+pC2T5ZuV9lT8rtsdmelWME8b28FZdyozo7+gZf3b2b PTACjB52a85N4eCTYWeTvEY124hlM/4E6bk8oeybpW0vOhJnVuRZLDEnL8Z1+m0wbpoX0U9a40JEo0 XqzVbbJd4rZfjaOM= Received: from mail.kirei.se (unknown [91.206.174.10]) by spg-relay.kirei.se (Halon Mail Gateway) with ESMTPS; Fri, 27 Mar 2015 08:37:44 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Jakob Schlyter In-Reply-To: Date: Fri, 27 Mar 2015 08:37:43 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20150318001300.34285.qmail@ary.lan> <40D64A6D-B518-40F2-9556-762839A92A9E@seantek.com> To: Nico Williams X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: dane WG list Subject: Re: [dane] Comments on draft-ietf-dane-openpgpkey-02 (fwd) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2015 07:53:24 -0000 On 26 mar 2015, at 21:13, Nico Williams wrote: > Also, using DNS for this opens mail domains to zone walking to find > mailboxes, whereas a proper lookup service wouldn't (it would still be > an oracle, but there would be no NSEC* to facilitate discovery of all > email addresses at the domain). How can you zone walk to find mailboxes when the localpart is hashed? Or = did you propose a solution where the localpart is not hashed? jakob From nobody Fri Mar 27 00:53: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 070C61A90B5 for ; Fri, 27 Mar 2015 00:53: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_SE=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 f15vpZJCZ3dt for ; Fri, 27 Mar 2015 00:53:25 -0700 (PDT) Received: from spg.kirei.se (spg.kirei.se [91.206.174.9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 432391A90A1 for ; Fri, 27 Mar 2015 00:53:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kirei.se; s=spg20100524; h=received:content-type:mime-version:subject:from:in-reply-to:date: content-transfer-encoding:message-id:references:to:x-mailer; bh=2Hb6USKgYTB50pE/HO7oo20lsgWgW3/siUihmY8Ys6Y=; b=fCHtZzqVGtTLdjDjxBYkZlCwNd5ADNAF+W0qvoX6mQRhJXDTQ4DtTBKmr11M4GsAMn/o8nt/oU2m4 sSpMrO/vERUsVwU7v8dm3VVHh7le9L7I9Jm7FqwaIziQWU0aXWpNzO1LEajv8PIT/DO1RqzEW+8655 uS6hQqNhMvk6sCVM= Received: from mail.kirei.se (unknown [91.206.174.10]) by spg-relay.kirei.se (Halon Mail Gateway) with ESMTPS for ; Fri, 27 Mar 2015 08:37:52 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Jakob Schlyter In-Reply-To: Date: Fri, 27 Mar 2015 08:37:52 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <7FEBE9A9-8AA9-463A-A266-F4A21A59660F@kirei.se> References: <20150318001300.34285.qmail@ary.lan> <40D64A6D-B518-40F2-9556-762839A92A9E@seantek.com> To: dane WG list X-Mailer: Apple Mail (2.2070.6) Archived-At: Subject: Re: [dane] Comments on draft-ietf-dane-openpgpkey-02 (fwd) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2015 07:53:27 -0000 On 26 mar 2015, at 19:57, Doug Montgomery wrote: > I guess I am confused as to why I would want to support either key = discovery or distribution for the (500million - 1) versions of my email = address that I don't use. >=20 > My mail agent only generates one version of my from address. I only = convey one version in written, oral, and online forms of distribution. >=20 > I am perfectly happy if it is not possible to discover the = 500million-1 variants of my email address that I don't use or exercise = but that my mail provider chooses to treat as equivalent. Frankly if = it was possible, I would write mail filters to drop those variants on = receipt, because they clearly indicate some use of my email address that = I did not endorse. >=20 > For my uses, straight hashing of the form of my address you are = presented with is all I want. To be honest, I would consider it an = undesirable feature to support the versions of my address that I don't = use.=20 >=20 > Enabling the simple direct function of key retrieval for the addresses = we use, in a ubiquitous way would be very powerful. =20 >=20 > We should leave for future study the issue of key retrieval for the = addresses we don't use. I'm completely agree with Doug here. MTAs may do all kinds of magic = matching, what matters is what address the sender/receiver use and = providing a solution for that is very powerful. jakob From nobody Sun Mar 29 11:46: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 EAD3C1A86E0 for ; Sun, 29 Mar 2015 11:46: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 7521_IHriBsY for ; Sun, 29 Mar 2015 11:46: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 5024D1A854D for ; Sun, 29 Mar 2015 11:46:34 -0700 (PDT) Received: (qmail 9023 invoked from network); 29 Mar 2015 18:46:33 -0000 Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 29 Mar 2015 18:46:33 -0000 Date: 29 Mar 2015 18:46:11 -0000 Message-ID: <20150329184611.64750.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] Comments on draft-ietf-dane-openpgpkey-02 (fwd) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Mar 2015 18:46:36 -0000 In article you write: >For any set of aliases that are manually configured, publishing a key, or >CNAME for each of those is of the same order of complexity as establishing >the alias itself. For over a decade, I've been doing the common trick of inventing a new address each time I sign up for something. Correct me if I'm wrong, but you appear to be saying that now, I have to stop, go to some sort of DNS provisioning system, tell it about the name I'm about to invent, publish the new record, and wait for it to propagate before I can go back to the web page where I'm about to use the name. Also, I have no idea what all of the addresses are that I've made up over the years, many of which still get mail from whoever I gave them to. It appears I'm out of luck there. >Unless your user agent generates a fuzzy match variant of your from: >address outbound with each email, I am not sure that the scaling problem is. There are plenty of mail systems that do that. Perhaps it would be helpful to learn more about the way that modern mail systems work. R's, John From nobody Sun Mar 29 14:01: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 696A11A0363 for ; Sun, 29 Mar 2015 14:01:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.59 X-Spam-Level: * X-Spam-Status: No, score=1.59 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_ADSP_ALL=0.8, 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 dAsFgZhbb_ps for ; Sun, 29 Mar 2015 14:01: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 B24AB1A0354 for ; Sun, 29 Mar 2015 14:01:01 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3lFTpw5bWkz5PD; Sun, 29 Mar 2015 23:00:56 +0200 (CEST) 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 QmJnLcHOowlK; Sun, 29 Mar 2015 23:00:49 +0200 (CEST) Received: from ns0.nohats.ca (ns0.nohats.ca [IPv6:2a03:6000:1004:1::102]) by mx.nohats.ca (Postfix) with ESMTP; Sun, 29 Mar 2015 23:00:47 +0200 (CEST) Received: by ns0.nohats.ca (Postfix, from userid 500) id DF1C13F511; Sun, 29 Mar 2015 17:00:46 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by ns0.nohats.ca (Postfix) with ESMTP id D85873F445; Sun, 29 Mar 2015 17:00:46 -0400 (EDT) Date: Sun, 29 Mar 2015 17:00:46 -0400 (EDT) From: paul@nohats.ca To: John Levine In-Reply-To: <20150329184611.64750.qmail@ary.lan> Message-ID: References: <20150329184611.64750.qmail@ary.lan> User-Agent: Alpine 2.11 (LRH 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] Comments on draft-ietf-dane-openpgpkey-02 (fwd) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Mar 2015 21:01:03 -0000 On Sun, 29 Mar 2015, John Levine wrote: > For over a decade, I've been doing the common trick of inventing a new > address each time I sign up for something. Correct me if I'm wrong, but > you appear to be saying that now, I have to stop, go to some sort of DNS > provisioning system, tell it about the name I'm about to invent, publish > the new record, and wait for it to propagate before I can go back to the > web page where I'm about to use the name. > > Also, I have no idea what all of the addresses are that I've made up > over the years, many of which still get mail from whoever I gave them > to. It appears I'm out of luck there. For one, you can do *._openpgpkey.example.com. IN OPENPGPKEY [...] Second you should really have the email address listed as ID on you openpgp key entry anyway. Third, you can keep doing this fine and not receive encrypred email, just like you have been doing all of those years. These are not the problems you are looking for, Paul From nobody Sun Mar 29 14:12:22 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44CBD1A1A19 for ; Sun, 29 Mar 2015 14:12:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.701 X-Spam-Level: X-Spam-Status: No, score=-0.701 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 6YMaDV2kGb-I for ; Sun, 29 Mar 2015 14:12:19 -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 32AA11A1A1E for ; Sun, 29 Mar 2015 14:12:19 -0700 (PDT) Received: by oiav1 with SMTP id v1so616564oia.2 for ; Sun, 29 Mar 2015 14:12:18 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:thread-topic:thread-index :date:message-id:references:in-reply-to:accept-language :content-language:content-type:content-id:content-transfer-encoding :mime-version; bh=u8CSi1ebZ1c7WVg+hf0FBENQ16/4r7ytnk0J+UXwFgk=; b=OJviEDqumqEvPdAdGkWc5fXzDKjw/z3qyppfDbnJAxSYfWbLgraMEjuS6qZwxqaOMS 4AaGeEI54eXtty6HwpfZB15sTqcZ3peRiDskINMpCA8jTZqj6c4bj9TjE+ygi5lPzdUx 6/WQrVAET6Lemt2A8HLVPMzpl+VCBBiq5AESCGx8gOuhNZpr+TZKHi+mDAoUroa8PYGH u9go270AIbIH+nY5p5SklfMivFEMLE/7mrsZPjUB93jXKJheP0JxqW+dIWkSysgdj1iT /3nJv3JqWVGcIHXusPz1Ig2p82aFd5ucfTAaAM2MpZQm4uxuaPW1Jl57igP7D+mpEcsM XyRQ== X-Gm-Message-State: ALoCoQn63nN7Ju7dCcbblZEj/dawXZ/PjUnK52temYG0p4fBWK21sVpe37qD3K4nZzTefq5ikxNlDtbS+f8ivSrNlf7TVxJucw== X-Received: by 10.55.54.19 with SMTP id d19mr59745609qka.98.1427663538461; Sun, 29 Mar 2015 14:12:18 -0700 (PDT) Received: from brn1lxmailout01.verisign.com (brn1lxmailout01.verisign.com. [72.13.63.41]) by mx.google.com with ESMTPS id cd6sm3138608qcb.2.2015.03.29.14.12.18 (version=TLSv1 cipher=RC4-SHA bits=128/128); Sun, 29 Mar 2015 14:12:18 -0700 (PDT) X-Relaying-Domain: verisign.com Received: from brn1wnexcas01.vcorp.ad.vrsn.com (brn1wnexcas01 [10.173.152.205]) by brn1lxmailout01.verisign.com (8.13.8/8.13.8) with ESMTP id t2TLCFvs009216 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 29 Mar 2015 17:12:16 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Sun, 29 Mar 2015 17:12:15 -0400 From: "Osterweil, Eric" To: "paul@nohats.ca" Thread-Topic: [dane] Comments on draft-ietf-dane-openpgpkey-02 (fwd) Thread-Index: AQHQXfwKBM0/8GmPcUia3XoiZHQl0p0blDkAgAEHPICAAZIHAIAALmeAgAAakQCAAAJygIAABH4AgAAEs4CAAA1yAIACoY8AgAB2lACAAPReAIAABScAgAAEyQCAC954AIAA8CIAgAABXYCAAATtgIAABxeAgAADbgCABKLzgIAAJZoAgAADOwA= Date: Sun, 29 Mar 2015 21:12:14 +0000 Message-ID: <170A48A7-953D-4A67-8B8F-6B99FC98A245@verisign.com> References: <20150329184611.64750.qmail@ary.lan> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: John Levine , "dane@ietf.org" Subject: Re: [dane] Comments on draft-ietf-dane-openpgpkey-02 (fwd) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Mar 2015 21:12:21 -0000 On Mar 29, 2015, at 5:00 PM, wrote: > On Sun, 29 Mar 2015, John Levine wrote: >=20 >> For over a decade, I've been doing the common trick of inventing a new >> address each time I sign up for something. Correct me if I'm wrong, but >> you appear to be saying that now, I have to stop, go to some sort of DNS >> provisioning system, tell it about the name I'm about to invent, publish >> the new record, and wait for it to propagate before I can go back to the >> web page where I'm about to use the name. >>=20 >> Also, I have no idea what all of the addresses are that I've made up >> over the years, many of which still get mail from whoever I gave them >> to. It appears I'm out of luck there. >=20 > For one, you can do *._openpgpkey.example.com. IN OPENPGPKEY [...] >=20 > Second you should really have the email address listed as ID on you > openpgp key entry anyway. >=20 > Third, you can keep doing this fine and not receive encrypred email, > just like you have been doing all of those years. +1 Eric From nobody Sun Mar 29 14:14:17 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34BED1A1A62 for ; Sun, 29 Mar 2015 14:14:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.563 X-Spam-Level: * X-Spam-Status: No, score=1.563 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 FbPSgKF3G1Uf for ; Sun, 29 Mar 2015 14:14:15 -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 CC5571A1A52 for ; Sun, 29 Mar 2015 14:14:14 -0700 (PDT) Received: (qmail 25566 invoked from network); 29 Mar 2015 21:14:13 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=63dd.55186b25.k1503; bh=ycq3izvx5kxAsa54awerOflvp1Tun016aQNG3dxrQTM=; b=M5luvWUPXO+S/xrMWHTBNeXchSJB40/Qxr+DlswcehbQa35gxznSRVtdDiAoBA8G6m5ClswMKfECtTa5dZMeyPGamlLF0HQUcY9OFqsuqmHPwUHtreTXonqlFLuUoXVChrjixridHMapRSTW7H7PP6EIhcs23pgc/8H1aBZxq6lpNvOHOD3gE4SxzAy+fNAw538yaxd0dqU/0O1+sENqoTDsodWA4FpaWT6JsYx1viqWJsw2UInMqNkyppCnV34K 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=63dd.55186b25.k1503; bh=ycq3izvx5kxAsa54awerOflvp1Tun016aQNG3dxrQTM=; b=P1O4ub3wvCr3GAqaxW4UL7SqmFIYlL53vuRnsDjHMbWL6k5tvNRy6NDvoBTcw/lw6F9u2i9mE1MLOaopUdTAKVzwefTEKF1tl4lMKaJPSBMYOifvRaL8NKyALV9ftHaXz9YAh2S+jc+jCvu50oq1/Lm8pw3joMA2u0s4YCrBT2l6KjkXGsdl2Pa/VbZu7/TCWjIKplG1SnMgPjnf61z0kqRXeB+lmn4Pin5i/1hsykEdr81OG800krLmU4sCdOXj 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; 29 Mar 2015 21:14:13 -0000 Date: 29 Mar 2015 17:14:13 -0400 Message-ID: From: "John R Levine" To: paul@nohats.ca In-Reply-To: References: <20150329184611.64750.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] Comments on draft-ietf-dane-openpgpkey-02 (fwd) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Mar 2015 21:14:16 -0000 >> Also, I have no idea what all of the addresses are that I've made up >> over the years, many of which still get mail from whoever I gave them >> to. It appears I'm out of luck there. > > For one, you can do *._openpgpkey.example.com. IN OPENPGPKEY [...] My system has more than one user, so we have addresses like johnl-* bobf-*. How are we supposed to handle that with DNS wildcards? > Second you should really have the email address listed as ID on you > openpgp key entry anyway. I do, and thousands of subaddresses, too, and I'd like to let people send me mail just like they do now, only encrypted. > Third, you can keep doing this fine and not receive encrypred email, > just like you have been doing all of those years. I'm not very interested in a "solution" that doesn't match the way e-mail works, and has worked for decades. At the session in Dallas, it was pretty clear that the other people at the mike with extensive e-mail experience aren't either. This is starting to remind me of too many other discussions of mail security hacks that don't match the way that mail actually works, in which the propnents argue that the parts of our working mail that don't happen to match the hack was broken all along. (See, for example, endless arguments about "forgery" in SPF and DMARC lists.) Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. From nobody Sun Mar 29 14:28: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 232A71A1DE2 for ; Sun, 29 Mar 2015 14:28:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.59 X-Spam-Level: * X-Spam-Status: No, score=1.59 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_ADSP_ALL=0.8, 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 qVlXVOb_g55p for ; Sun, 29 Mar 2015 14:28: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 4366D1A1BEE for ; Sun, 29 Mar 2015 14:28:31 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3lFVQj4bLFz1x7; Sun, 29 Mar 2015 23:28:29 +0200 (CEST) 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 btnrWe8IVKN2; Sun, 29 Mar 2015 23:28:28 +0200 (CEST) Received: from ns0.nohats.ca (ns0.nohats.ca [IPv6:2a03:6000:1004:1::102]) by mx.nohats.ca (Postfix) with ESMTP; Sun, 29 Mar 2015 23:28:28 +0200 (CEST) Received: by ns0.nohats.ca (Postfix, from userid 500) id DDD423F511; Sun, 29 Mar 2015 17:28:27 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by ns0.nohats.ca (Postfix) with ESMTP id D80B33F447; Sun, 29 Mar 2015 17:28:27 -0400 (EDT) Date: Sun, 29 Mar 2015 17:28:27 -0400 (EDT) From: paul@nohats.ca To: John R Levine In-Reply-To: Message-ID: References: <20150329184611.64750.qmail@ary.lan> User-Agent: Alpine 2.11 (LRH 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] Comments on draft-ietf-dane-openpgpkey-02 (fwd) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Mar 2015 21:28:32 -0000 On Sun, 29 Mar 2015, John R Levine wrote: >> Second you should really have the email address listed as ID on you >> openpgp key entry anyway. > > I do, and thousands of subaddresses, too, and I'd like to let people send me > mail just like they do now, only encrypted. This draft is about the use of openpgp and email. It is not a swiss-army knife of email encryption. Note that I said "should have the email address", and it is explictly not a requirement in the document, exactly so you that do not need to add dozens of IDs if you do not want to. >> Third, you can keep doing this fine and not receive encrypred email, >> just like you have been doing all of those years. > > I'm not very interested in a "solution" that doesn't match the way e-mail > works, and has worked for decades. At the session in Dallas, it was pretty > clear that the other people at the mike with extensive e-mail experience > aren't either. You are confused about the document. This document is for: OpenPGP is a message format for email (and file) encryption, that lacks a standardized lookup mechanism to obtain OpenPGP public keys. This document specifies a method for securely publishing and locating OpenPGP public keys in DNS using a new OPENPGPKEY DNS Resource Record. It does not have as goal to design a method for ubiquitous email encryption for all possible uses of email and encryption technologies. I am happy to see that the openpgpkey draft reinvigorated the email people into looking at a solution for the generic email address to recipient mapping. I will keep a close eye on the progress made by the APP area and email experts. I'd be happy to write up a bis document to the openpgpkey document once the APP area has a draft document out on this issue. Paul From nobody Sun Mar 29 14:36: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 710531A1EF3 for ; Sun, 29 Mar 2015 14:36:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.238 X-Spam-Level: X-Spam-Status: No, score=-1.238 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_I_LETTER=-2, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZBAsed_jkB2h for ; Sun, 29 Mar 2015 14:36:18 -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 B34FE1A2130 for ; Sun, 29 Mar 2015 14:36:17 -0700 (PDT) Received: (qmail 27488 invoked from network); 29 Mar 2015 21:36:16 -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=6b5f.55187050.k1503; bh=t5C7QIhUbJ7AzU5aDNgxs+m80jmLPZC9mMcuFxXtKlE=; b=jNlU1yPj5L2uW+A9rcgAnX0CmrcfoGimmF7gJ5TLHoDjzLcHM9yoaAbHHaJWOf7rU4TA1noOifHOoCZlLdRWqzk/rJH2PfFqW4GcqLWw6leH0XkRXznfcxwE3hdcVTPlbRc1p2Z040xlIuqWuc0nt70iEJy/PDaDNxQ4+KEf8aslsVZTtdG9R3kJCAsai5gcsXaB85dKPm6aLwwmsvvonA52yrVGERUUFxvtEyLrB5v/L4yeSUcVuwvPDvY7hDy5 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=6b5f.55187050.k1503; bh=t5C7QIhUbJ7AzU5aDNgxs+m80jmLPZC9mMcuFxXtKlE=; b=HEj7/Shnjgdt2cAt/eCepQ+bNlSCXw2IlqmECazY8NKjlByZhLj6pWzIBiZovYjRvtWzarL6yvKYGetJeLUtgBY6RiQCQb5tLR2ItuNhftX0FpdRa3SKYPCT+bxzQJLB/jEN35vRh7Up3dKqixY8TOjZlTCPkXvEBS+7XW1pjQbJ+l6EuxVp3wpaqPZsH5U4qed1ajT6sFEXOVfaq7+agRtN5UptaXNniJUOWryOEctyJnofTpvQqGBQpGol9Hls 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; 29 Mar 2015 21:36:16 -0000 Date: 29 Mar 2015 17:36:15 -0400 Message-ID: From: "John R Levine" To: paul@nohats.ca In-Reply-To: References: <20150329184611.64750.qmail@ary.lan> User-Agent: Alpine 2.11 (OSX 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Archived-At: Cc: dane@ietf.org Subject: Re: [dane] Comments on draft-ietf-dane-openpgpkey-02 (fwd) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Mar 2015 21:36:20 -0000 > It does not have as goal to design a method for ubiquitous email > encryption for all possible uses of email and encryption technologies. Nobody's asking for that, just for something that works for the way e-mail actually works, rather than what might as well be only for adddresses that start with the letters A through F. > I am happy to see that the openpgpkey draft reinvigorated the email > people into looking at a solution for the generic email address to > recipient mapping. I'll be sending one along shortly. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. From nobody Sun Mar 29 19:37:53 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2B4B1A1A4D for ; Sun, 29 Mar 2015 19:37:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2WITqGmFA8Xt for ; Sun, 29 Mar 2015 19:37:36 -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 70C591A1A29 for ; Sun, 29 Mar 2015 19:37:36 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id A8329283011; Mon, 30 Mar 2015 02:37:34 +0000 (UTC) Date: Mon, 30 Mar 2015 02:37:34 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20150330023734.GP17637@mournblade.imrryr.org> References: <20150329184611.64750.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] Comments on draft-ietf-dane-openpgpkey-02 (fwd) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Mar 2015 02:37:45 -0000 On Sun, Mar 29, 2015 at 05:36:15PM -0400, John R Levine wrote: > >I am happy to see that the openpgpkey draft reinvigorated the email people > >into looking at a solution for the generic email address to recipient > >mapping. > > I'll be sending one along shortly. If we're reconsidering the design, perhaps a smaller thing to reconsider is the idea (IIRC my fault) to use SHA-224 in an attempt to handle long (> 63 octet) local-parts, and avoid false matches due to case folding. An alternative is to go back to the original base32 encoding, which is lossless, and thus can allow the remote DNS server (a special-purpose DNS lookup engine serving a zone with per-user information) to decode the local-part and perform whatever fuzzy matching may be appropriate. The lossless encoding can support longer names by breaking them up into multiple labels. This allows static DNS to be published where desired, and custom code to produce dynamic results when appropriate. -- Viktor. From nobody Sun Mar 29 22:39: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 01F451A907D for ; Sun, 29 Mar 2015 22:39:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.1 X-Spam-Level: X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dXLe1wvPa82H for ; Sun, 29 Mar 2015 22:39:39 -0700 (PDT) Received: from mail-ob0-x233.google.com (mail-ob0-x233.google.com [IPv6:2607:f8b0:4003:c01::233]) (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 A12461A907B for ; Sun, 29 Mar 2015 22:39:39 -0700 (PDT) Received: by obvd1 with SMTP id d1so47973728obv.0 for ; Sun, 29 Mar 2015 22:39:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=/kRu942RSL7z/k9/m8ldBeBDWsIm9BcNPd1Au4k9aSc=; b=JWLgUaHFCFoWzm6dt/CakWTU45pHL7A6dLyUrZaZ+4iJwJWtgmD0XX6sOX4qE526+L gf64vDLq9on7G54wz+tEyIf1LynkkwY2IRqWzj8JboN1sG8LC+m8CAk7KMYSztGpOws8 p21WGue/u6C+IpfGweZ9c8J9fF6Fbc62C0yOYwVaFDrrS46vTWZKShphOEfyREujmMRJ xGhT/68mwCr6SIVMjx0gmZ3Tjyfc+Tlfz0KcrlB3OHMeRuHYRmzg2tJ/E3HLEpzJZxrm ScAgskBcOOo75cOfQXyySS8ImX+uf9tWWllhxzbjXZ+FqhWBZ9qmrW87rW11W4oNRyYr nZHg== X-Received: by 10.182.252.70 with SMTP id zq6mr3911822obc.30.1427693979131; Sun, 29 Mar 2015 22:39:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.202.231.148 with HTTP; Sun, 29 Mar 2015 22:39:17 -0700 (PDT) In-Reply-To: <20150329184611.64750.qmail@ary.lan> References: <20150329184611.64750.qmail@ary.lan> From: Doug Montgomery Date: Mon, 30 Mar 2015 01:39:17 -0400 Message-ID: To: John Levine Content-Type: multipart/alternative; boundary=001a1134b39279661505127ae8fe Archived-At: Cc: dane WG list Subject: Re: [dane] Comments on draft-ietf-dane-openpgpkey-02 (fwd) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Mar 2015 05:39:42 -0000 --001a1134b39279661505127ae8fe Content-Type: text/plain; charset=UTF-8 On Sun, Mar 29, 2015 at 2:46 PM, John Levine wrote: > In article QHp9Azjiw@mail.gmail.com> you write: > >For any set of aliases that are manually configured, publishing a key, or > >CNAME for each of those is of the same order of complexity as establishing > >the alias itself. > > For over a decade, I've been doing the common trick of inventing a new > address each time I sign up for something. Correct me if I'm wrong, but > you appear to be saying that now, I have to stop, go to some sort of DNS > provisioning system, tell it about the name I'm about to invent, publish > the new record, and wait for it to propagate before I can go back to the > web page where I'm about to use the name. > Also, I have no idea what all of the addresses are that I've made up > over the years, many of which still get mail from whoever I gave them > to. It appears I'm out of luck there. > I am not sure I understand the use case of wanting to enable opportunistic inbound encryption to all of the thousands of address that you can't even remember. But OK, is your use case is that you want keying (the same keying?) for all 500M potential variants? .... or just the thousands you have used? What about the person who might want different keying for his personal email and that of his mailing lists (assuming that is what many folks do with their aliases). Actually there are strict compliance implications about managing network identities in many commercial environments, where the idea that on is creating keying material for other, non explicitly created identities, won't fly. So if you enable key discovery and retrieval the 500M variants, please provide a mechanism to explicitly disable this feature too. As for DNS provisioning, none of this is going anywhere if there isn't significant automation between identity creation and keying. The vast majority of users don't even know there is a DNS. Personally, I am interested in enterprise-class solutions. Here if the DANE keying material is not dynamically updated from our identity/credential management system, it is a complete non-starter. > > >Unless your user agent generates a fuzzy match variant of your from: > >address outbound with each email, I am not sure that the scaling problem > is. > > There are plenty of mail systems that do that. Perhaps it would be > helpful to learn more about the way that modern mail systems work. > I am aware of how mail modern systems work (many have better ways of organizing email than generating thousands of addresses :). I was speaking of the hypothetical 500M algorithmic variants. I assume your mail system is not randomly generating your thousands of aliases. I am also aware of the problem I thought we were trying to solve. What I heard at the mic was that solving the general problem of keying that matches all the various local fuzzy matching rules of modern mail systems was either intractable, or outside the scope of DANE, or both. Let alone taking on the problem of those who don't want that behavior, or might want different keys on different local aliases. What I heard after the meeting on the list was some support of solving the simple problem in a ubiquitous way in DANE. I am guessing we would provide a solution that covers the vast majority of users with a simple one key per unique LHS. I think there may be support for solving the simple problem in DANE now. As for the more complex scenarios, it might warrant revisiting the use cases to understand the requirements, design trade offs of if, where and how the issue is addressed. > > R's, > John > -- DougM at Work --001a1134b39279661505127ae8fe Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sun, Mar 29, 2015 at 2:46 PM, John Levine <johnl@taugh.com> wrote:
In article &= lt;CAMaMmn=3Dg9FA2sYFzcnLgGCEfpnWFVb3sOwyPMr_g=3DQHp9Azjiw@mail.gmail.com> you write:
>For any set of aliases that are manually configured, publishing a key, = or
>CNAME for each of those is of the same order of complexity as establish= ing
>the alias itself.

For over a decade, I've been doing the common trick of inventing= a new
address each time I sign up for something.=C2=A0 Correct me if I'm wron= g, but
you appear to be saying that now, I have to stop, go to some sort of DNS provisioning system, tell it about the name I'm about to invent, publis= h
the new record, and wait for it to propagate before I can go back to the web page where I'm about to use the name.=C2=A0

Also, I have no idea what all of the addresses are that I've made up over the years, many of which still get mail from whoever I gave them
to.=C2=A0 It appears I'm out of luck there.

I am not sure I understand the use case of wanting to enable oppor= tunistic inbound encryption to all of the thousands of address that you can= 't even remember.=C2=A0 But OK, is your use case is that you want keyin= g (the same keying?) for all 500M potential variants? .... or just the thou= sands you have used?

What about the person who mig= ht want different keying for his personal email and that of his mailing lis= ts (assuming that is what many folks do with their aliases).

=
Actually there are strict compliance implications about managing= network identities in many commercial environments, where the idea that on= is creating keying material for other, non explicitly created identities, = won't fly.=C2=A0 So if you enable key discovery and retrieval the 500M = variants, please provide a mechanism to explicitly disable this feature too= .=C2=A0

As for DNS provisioning, none of this is g= oing anywhere if there isn't significant automation between identity cr= eation and keying.=C2=A0 The vast majority of users don't even know the= re is a DNS.

Personally, I am interested in enterp= rise-class solutions.=C2=A0 Here if the DANE keying material is not dynamic= ally updated from our identity/credential management system, it is a comple= te non-starter.
=C2=A0

>Unless your user agent generates a fuzzy match variant of your from: >address outbound with each email, I am not sure that the scaling proble= m is.

There are plenty of mail systems that do that.=C2=A0 Perhaps it woul= d be
helpful to learn more about the way that modern mail systems work.

I am aware of how mail modern systems work (man= y have better ways of organizing email than generating thousands of address= es :). =C2=A0 I was speaking of the hypothetical 500M algorithmic variants.= =C2=A0 I assume your mail system is not randomly generating your thousands = of aliases.

I am also aware of the problem I thoug= ht we were trying to solve.=C2=A0 What I heard at the mic was that solving = the general problem of keying that matches all the various local fuzzy matc= hing rules of modern mail systems was either intractable, or outside the sc= ope of DANE, or both.=C2=A0 Let alone taking on the problem of those who do= n't want that behavior, or might want different keys on different local= aliases.

What I heard after the meeting on the li= st was some support of solving the simple problem in a ubiquitous way in DA= NE. =C2=A0 I am guessing we would provide a solution that covers the vast m= ajority of users with a simple one key per unique LHS.

=
I think there may be support for solving the simple problem in DANE no= w. =C2=A0=C2=A0

As for the more complex scenarios,= it might warrant revisiting the use cases to understand the requirements, = design trade offs of if, where and how the issue is addressed.
= =C2=A0

R's,
John



--
DougM at Work
--001a1134b39279661505127ae8fe-- From alexis.shaw@gmail.com Sun Mar 29 23:56:24 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DB831A90E6 for ; Sun, 29 Mar 2015 23:56:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, MIME_QP_LONG_LINE=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 ORmZ_qVV9ULv for ; Sun, 29 Mar 2015 23:56:20 -0700 (PDT) Received: from mail-pa0-x22c.google.com (mail-pa0-x22c.google.com [IPv6:2607:f8b0:400e:c03::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C92B01A90E1 for ; Sun, 29 Mar 2015 23:56:20 -0700 (PDT) Received: by pacwe9 with SMTP id we9so158304635pac.1 for ; Sun, 29 Mar 2015 23:56:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:content-transfer-encoding:from:mime-version:subject :date:message-id:references:cc:in-reply-to:to; bh=aqGAWiOCL++izxUskJ1jSytFRlrhpkPlQyvB/dufQWs=; b=lcFU+yojkgcWT9WLFmyR75hVad9JBMGTMJTQSvfaupNBBW3TmN/6S62qZTz2Td4LyK 7PejwAgLU+5YzZJfBk8UKf9E71B/loazBtpLO/sGb5Q8i0jseMl+Jir6q6lTllvs9JXx LX5uwIIgw1G78vGSKM2Sa5ZG2L88VmfYyMRkuRWyH2hNAba9plwUeUk5ylb7Aj7DumlD LBu91/RaoT1s8l6MDtoePqk69xS1KiBv1NiUyB49r/JS7rzK5rk8IIDArflZFJBQM92Q dmx+Ooa2qtlN4jX33GKW4uUz+77TMhaB98m6ZMoNv+zF68l+FrKD6v7ltibSjPXCD0fL PHDQ== X-Received: by 10.70.0.98 with SMTP id 2mr16241610pdd.55.1427698580452; Sun, 29 Mar 2015 23:56:20 -0700 (PDT) Received: from [10.249.50.249] (uniwide-pat-pool-129-94-8-249.gw.unsw.edu.au. [129.94.8.249]) by mx.google.com with ESMTPSA id sm5sm9413995pac.10.2015.03.29.23.56.17 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 29 Mar 2015 23:56:18 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-23644692-6C64-4988-B826-3B0A944A0B1A Content-Transfer-Encoding: 7bit From: Alexis shaw Mime-Version: 1.0 (1.0) Date: Mon, 30 Mar 2015 17:55:51 +1100 Message-Id: <1F3A1910-0777-46AA-BBBF-8FF25D71E94F@gmail.com> References: <20150329184611.64750.qmail@ary.lan> In-Reply-To: To: Doug Montgomery X-Mailer: iPhone Mail (12B411) Archived-At: X-Mailman-Approved-At: Mon, 30 Mar 2015 09:13:54 -0700 Cc: John Levine , dane WG list Subject: Re: [dane] Comments on draft-ietf-dane-openpgpkey-02 (fwd) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Mar 2015 06:57:18 -0000 --Apple-Mail-23644692-6C64-4988-B826-3B0A944A0B1A Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Listening in why not allow the certificates to be defined on a regex, and ha= ve the queries to the database return a regex match. Seems to solve the prob= lem. Email address grammars more complex than a regular expression seem a pa= in anyway.=20 Regards Alexis Shaw b > On 30 Mar 2015, at 4:39 pm, Doug Montgomery wrote: >=20 >=20 >=20 >> On Sun, Mar 29, 2015 at 2:46 PM, John Levine wrote: >> In article you write: >> >For any set of aliases that are manually configured, publishing a key, o= r >> >CNAME for each of those is of the same order of complexity as establishi= ng >> >the alias itself. >>=20 >> For over a decade, I've been doing the common trick of inventing a new >> address each time I sign up for something. Correct me if I'm wrong, but >> you appear to be saying that now, I have to stop, go to some sort of DNS >> provisioning system, tell it about the name I'm about to invent, publish >> the new record, and wait for it to propagate before I can go back to the >> web page where I'm about to use the name.=20 >>=20 >> Also, I have no idea what all of the addresses are that I've made up >> over the years, many of which still get mail from whoever I gave them >> to. It appears I'm out of luck there. >=20 > I am not sure I understand the use case of wanting to enable opportunistic= inbound encryption to all of the thousands of address that you can't even r= emember. But OK, is your use case is that you want keying (the same keying?= ) for all 500M potential variants? .... or just the thousands you have used?= >=20 > What about the person who might want different keying for his personal ema= il and that of his mailing lists (assuming that is what many folks do with t= heir aliases). >=20 > Actually there are strict compliance implications about managing network i= dentities in many commercial environments, where the idea that on is creatin= g keying material for other, non explicitly created identities, won't fly. S= o if you enable key discovery and retrieval the 500M variants, please provid= e a mechanism to explicitly disable this feature too.=20 >=20 > As for DNS provisioning, none of this is going anywhere if there isn't sig= nificant automation between identity creation and keying. The vast majority= of users don't even know there is a DNS. >=20 > Personally, I am interested in enterprise-class solutions. Here if the DA= NE keying material is not dynamically updated from our identity/credential m= anagement system, it is a complete non-starter. > =20 >>=20 >> >Unless your user agent generates a fuzzy match variant of your from: >> >address outbound with each email, I am not sure that the scaling problem= is. >>=20 >> There are plenty of mail systems that do that. Perhaps it would be >> helpful to learn more about the way that modern mail systems work. >=20 > I am aware of how mail modern systems work (many have better ways of organ= izing email than generating thousands of addresses :). I was speaking of t= he hypothetical 500M algorithmic variants. I assume your mail system is not= randomly generating your thousands of aliases. >=20 > I am also aware of the problem I thought we were trying to solve. What I h= eard at the mic was that solving the general problem of keying that matches a= ll the various local fuzzy matching rules of modern mail systems was either i= ntractable, or outside the scope of DANE, or both. Let alone taking on the p= roblem of those who don't want that behavior, or might want different keys o= n different local aliases. >=20 > What I heard after the meeting on the list was some support of solving the= simple problem in a ubiquitous way in DANE. I am guessing we would provid= e a solution that covers the vast majority of users with a simple one key pe= r unique LHS. >=20 > I think there may be support for solving the simple problem in DANE now. = =20 >=20 > As for the more complex scenarios, it might warrant revisiting the use cas= es to understand the requirements, design trade offs of if, where and how th= e issue is addressed. > =20 >>=20 >> R's, >> John >=20 >=20 >=20 > --=20 > DougM at Work > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane --Apple-Mail-23644692-6C64-4988-B826-3B0A944A0B1A Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Listening in why not allow the certifi= cates to be defined on a regex, and have the queries to the database return a= regex match. Seems to solve the problem. Email address grammars more comple= x than a regular expression seem a pain anyway. 

Regards
Alexis Shaw b

On 30 Mar 2015, at 4:39= pm, Doug Montgomery <dougm.work@= gmail.com> wrote:



On S= un, Mar 29, 2015 at 2:46 PM, John Levine <johnl@taugh.com> wrote= :
In article <CAMaMmn=3D= g9FA2sYFzcnLgGCEfpnWFVb3sOwyPMr_g=3DQHp9Azjiw@mail.gmail.com> you write:
>For any set of aliases that are manually configured, publishing a key, o= r
>CNAME for each of those is of the same order of complexity as establishi= ng
>the alias itself.

For over a decade, I've been doing the common trick of inventing a ne= w
address each time I sign up for something.  Correct me if I'm wrong, bu= t
you appear to be saying that now, I have to stop, go to some sort of DNS
= provisioning system, tell it about the name I'm about to invent, publish
= the new record, and wait for it to propagate before I can go back to the
= web page where I'm about to use the name. 

Also, I have no idea what all of the addresses are that I've made up
over the years, many of which still get mail from whoever I gave them
to.  It appears I'm out of luck there.

<= div>I am not sure I understand the use case of wanting to enable opportunist= ic inbound encryption to all of the thousands of address that you can't even= remember.  But OK, is your use case is that you want keying (the same k= eying?) for all 500M potential variants? .... or just the thousands you have= used?

What about the person who might want differe= nt keying for his personal email and that of his mailing lists (assuming tha= t is what many folks do with their aliases).

Actual= ly there are strict compliance implications about managing network identitie= s in many commercial environments, where the idea that on is creating keying= material for other, non explicitly created identities, won't fly.  So i= f you enable key discovery and retrieval the 500M variants, please provide a= mechanism to explicitly disable this feature too. 

As for DNS provisioning, none of this is going anywhere if there isn't= significant automation between identity creation and keying.  The vast= majority of users don't even know there is a DNS.

= Personally, I am interested in enterprise-class solutions.  Here if the= DANE keying material is not dynamically updated from our identity/credentia= l management system, it is a complete non-starter.
 

>Unless your user agent generates a fuzzy match variant of your from:
= >address outbound with each email, I am not sure that the scaling problem= is.

There are plenty of mail systems that do that.  Perhaps it would= be
helpful to learn more about the way that modern mail systems work.

I am aware of how mail modern systems work (many h= ave better ways of organizing email than generating thousands of addresses := ).   I was speaking of the hypothetical 500M algorithmic variants. = ; I assume your mail system is not randomly generating your thousands of ali= ases.

I am also aware of the problem I thought we w= ere trying to solve.  What I heard at the mic was that solving the gene= ral problem of keying that matches all the various local fuzzy matching rule= s of modern mail systems was either intractable, or outside the scope of DAN= E, or both.  Let alone taking on the problem of those who don't want th= at behavior, or might want different keys on different local aliases.
<= div>
What I heard after the meeting on the list was some suppo= rt of solving the simple problem in a ubiquitous way in DANE.   I am gu= essing we would provide a solution that covers the vast majority of users wi= th a simple one key per unique LHS.

I think there m= ay be support for solving the simple problem in DANE now.   
=

As for the more complex scenarios, it might warrant revi= siting the use cases to understand the requirements, design trade offs of if= , where and how the issue is addressed.
 

R's,
John



--
DougM at Work
____________________= ___________________________
dane mailing list
dane@ietf.org
https://www.ietf.org/mailman= /listinfo/dane
= --Apple-Mail-23644692-6C64-4988-B826-3B0A944A0B1A-- From nobody Mon Mar 30 09:57: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 2C7FC1A877C for ; Mon, 30 Mar 2015 09:57:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.944 X-Spam-Level: X-Spam-Status: No, score=-0.944 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MxpWAwFMvxIm for ; Mon, 30 Mar 2015 09:57:29 -0700 (PDT) Received: from homiemail-a66.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 654B61A86FD for ; Mon, 30 Mar 2015 09:57:29 -0700 (PDT) Received: from homiemail-a66.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a66.g.dreamhost.com (Postfix) with ESMTP id 3AFDF350058 for ; Mon, 30 Mar 2015 09:57:29 -0700 (PDT) Received: from mail-ig0-f170.google.com (mail-ig0-f170.google.com [209.85.213.170]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a66.g.dreamhost.com (Postfix) with ESMTPSA id F236935005B for ; Mon, 30 Mar 2015 09:57:28 -0700 (PDT) Received: by igbud6 with SMTP id ud6so81046151igb.1 for ; Mon, 30 Mar 2015 09:57:27 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.107.27.143 with SMTP id b137mr50049974iob.76.1427734647451; Mon, 30 Mar 2015 09:57:27 -0700 (PDT) Received: by 10.64.130.66 with HTTP; Mon, 30 Mar 2015 09:57:27 -0700 (PDT) In-Reply-To: <20150330023734.GP17637@mournblade.imrryr.org> References: <20150329184611.64750.qmail@ary.lan> <20150330023734.GP17637@mournblade.imrryr.org> Date: Mon, 30 Mar 2015 11:57:27 -0500 Message-ID: From: Nico Williams To: dane WG list Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [dane] Comments on draft-ietf-dane-openpgpkey-02 (fwd) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Mar 2015 16:57:30 -0000 On Sun, Mar 29, 2015 at 9:37 PM, Viktor Dukhovni wrote: > On Sun, Mar 29, 2015 at 05:36:15PM -0400, John R Levine wrote: > >> >I am happy to see that the openpgpkey draft reinvigorated the email people >> >into looking at a solution for the generic email address to recipient >> >mapping. >> >> I'll be sending one along shortly. > > If we're reconsidering the design, perhaps a smaller thing to > reconsider is the idea (IIRC my fault) to use SHA-224 in an attempt > to handle long (> 63 octet) local-parts, and avoid false matches > due to case folding. > > An alternative is to go back to the original base32 encoding, which > is lossless, and thus can allow the remote DNS server (a special-purpose > DNS lookup engine serving a zone with per-user information) to > decode the local-part and perform whatever fuzzy matching may be > appropriate. > > The lossless encoding can support longer names by breaking them up > into multiple labels. > > This allows static DNS to be published where desired, and custom > code to produce dynamic results when appropriate. I like this. A lookup protocol would be optional. But I think we need to specify the lookup protocol, and MUAs [that support DANE for PGP/S/MIME] will need to support it. The lookup protocol can only be optional to provide; it can't be optional on the client-side. Nico -- From nobody Mon Mar 30 10:21:38 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD69C1A8F4B for ; Mon, 30 Mar 2015 10:21:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_40=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jmZ_Na89X3WI for ; Mon, 30 Mar 2015 10:21:35 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B45D31A8F4A for ; Mon, 30 Mar 2015 10:21:35 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 8D624283032; Mon, 30 Mar 2015 17:21:34 +0000 (UTC) Date: Mon, 30 Mar 2015 17:21:34 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20150330172134.GS17637@mournblade.imrryr.org> References: <20150329184611.64750.qmail@ary.lan> <20150330023734.GP17637@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] Comments on draft-ietf-dane-openpgpkey-02 (fwd) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Mar 2015 17:21:37 -0000 On Mon, Mar 30, 2015 at 11:57:27AM -0500, Nico Williams wrote: > > An alternative is to go back to the original base32 encoding, which > > is lossless, and thus can allow the remote DNS server (a special-purpose > > DNS lookup engine serving a zone with per-user information) to > > decode the local-part and perform whatever fuzzy matching may be > > appropriate. > > > > The lossless encoding can support longer names by breaking them up > > into multiple labels. > > > > This allows static DNS to be published where desired, and custom > > code to produce dynamic results when appropriate. > > I like this. A lookup protocol would be optional. But I think we > need to specify the lookup protocol, and MUAs [that support DANE for > PGP/S/MIME] will need to support it. The lookup protocol can only be > optional to provide; it can't be optional on the client-side. My main concern with this direction is that ISP iterative resolvers act as open proxies for this protocol, and: * Add latency because caching of lookup results is unlikely to scale. * Suffer from bloated caches full of negative replies for billions of accounts. * Make it more difficult for the final servers to detect abusive clients that are doing dictionary (directory harvesting) attacks. [ Yes email addresses are not secrets, but some opacity can be useful. ] If none of the above are compelling, then going back to a lossless encoding may be a reasonable compromise. Otherwise, we can take the view that: * The multitude of addresses per user problem is not a problem, only a small specific number of addresses will support encryption (those may need to appear in the public key "certificates" anyway). * DNS is here and scales to high query volumes. Or that: * It must be possible to E2E protect all the variant addresses, by returning the same keys for variants as for the canonical address. * Email operators will not want to publish user to key mappings in their current DNS, and no DNS front-end to their LDAP or similar directories is presently available. Since new code is needed regardless, its protocol may as well be designed specifically for this problem. -- Viktor. From nobody Mon Mar 30 12:18:20 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2AF61ACC87 for ; Mon, 30 Mar 2015 12:18:18 -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 osQ2EWnlnlXG for ; Mon, 30 Mar 2015 12:18:17 -0700 (PDT) Received: from homiemail-a49.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id D7D381A702D for ; Mon, 30 Mar 2015 12:18:17 -0700 (PDT) Received: from homiemail-a49.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a49.g.dreamhost.com (Postfix) with ESMTP id 9646E200D30AE for ; Mon, 30 Mar 2015 12:18:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:subject:message-id:references:mime-version:content-type :in-reply-to; s=cryptonector.com; bh=//uKlyf4/RpYm/ReouvrUQdc7CA =; b=fQ1EYZ/6UdiuXHchsx9ZPI7xs2il5aZJEWZOyVTqVsCxCWS+07BxK5anu8U f8foZPCVt31Fh6s/c//qEenwGfyjTwXR8B6JHadisJaT+vG99saOPElLFotHiKwt StaCvnf5V6nE8lcbdv7n0QKT5qQQfICbBy5xYezF2m8XbGmM= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a49.g.dreamhost.com (Postfix) with ESMTPA id 2540F200D30A2 for ; Mon, 30 Mar 2015 12:18:16 -0700 (PDT) Date: Mon, 30 Mar 2015 14:18:16 -0500 From: Nico Williams To: dane@ietf.org Message-ID: <20150330191814.GR10960@localhost> References: <20150329184611.64750.qmail@ary.lan> <20150330023734.GP17637@mournblade.imrryr.org> <20150330172134.GS17637@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150330172134.GS17637@mournblade.imrryr.org> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [dane] Comments on draft-ietf-dane-openpgpkey-02 (fwd) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Mar 2015 19:18:18 -0000 On Mon, Mar 30, 2015 at 05:21:34PM +0000, Viktor Dukhovni wrote: > On Mon, Mar 30, 2015 at 11:57:27AM -0500, Nico Williams wrote: > > > This allows static DNS to be published where desired, and custom > > > code to produce dynamic results when appropriate. > > > > I like this. A lookup protocol would be optional. But I think we > > need to specify the lookup protocol, and MUAs [that support DANE for > > PGP/S/MIME] will need to support it. The lookup protocol can only be > > optional to provide; it can't be optional on the client-side. > > My main concern with this direction is that ISP iterative resolvers > act as open proxies for this protocol, and: > > * Add latency because caching of lookup results is unlikely to scale. Requiring client support for the lookup protocol solves this. Sites with many mailboxes can implement the lookup protocol and not publish mailbox names in the DNS. > * Suffer from bloated caches full of negative replies for billions > of accounts. Ditto. > * Make it more difficult for the final servers to detect abusive > clients that are doing dictionary (directory harvesting) attacks. > [ Yes email addresses are not secrets, but some opacity can be > useful. ] Ditto. > If none of the above are compelling, then going back to a lossless I think they are quite compelling > encoding may be a reasonable compromise. Otherwise, we can take > the view that: > > * The multitude of addresses per user problem is not a problem, > only a small specific number of addresses will support encryption > (those may need to appear in the public key "certificates" anyway). > [...] Don't we need DANE for e-mail signature signing key verification too? Nico -- From nobody Mon Mar 30 12:28: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 D3E421ACCE2 for ; Mon, 30 Mar 2015 12:28:41 -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_20=-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 uXMu348qOMDX for ; Mon, 30 Mar 2015 12:28:40 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33D9E1ACCF3 for ; Mon, 30 Mar 2015 12:28:39 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3lG3jw1tcszCGw; Mon, 30 Mar 2015 21:28:36 +0200 (CEST) Authentication-Results: mx.nohats.ca; dkim=pass (1024-bit key) header.d=nohats.ca header.i=@nohats.ca header.b=YibmRhGc 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 Qu7iYuwZHPEL; Mon, 30 Mar 2015 21:28:35 +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, 30 Mar 2015 21:28:35 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 31708803E0; Mon, 30 Mar 2015 15:28:34 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1427743714; bh=RkZwhRcgUfnVfcL/+4Nsmqfjj9flEKauJ5v5UrOVBJU=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=YibmRhGc2/Q73lfW/4Ab3TFSBie05TUwdw4oyPYCIwhZRX86JdYWcqtta7ssf2+/1 LDyFvuKhVYi59zVbsE66Bu6WD6cAC8MmFkE4/Qm/dAAIP6TVc5Z9ynrz2Fd9GXAxdi KggcD4RuK85ZykkN6Ze5yAKa5LUysO4YVgDk5tLI= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id t2UJSXHc029441; Mon, 30 Mar 2015 15:28:33 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Mon, 30 Mar 2015 15:28:33 -0400 (EDT) From: Paul Wouters To: Nico Williams In-Reply-To: <20150330191814.GR10960@localhost> Message-ID: References: <20150329184611.64750.qmail@ary.lan> <20150330023734.GP17637@mournblade.imrryr.org> <20150330172134.GS17637@mournblade.imrryr.org> <20150330191814.GR10960@localhost> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: dane@ietf.org Subject: Re: [dane] Comments on draft-ietf-dane-openpgpkey-02 (fwd) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Mar 2015 19:28:42 -0000 On Mon, 30 Mar 2015, Nico Williams wrote: >> * Suffer from bloated caches full of negative replies for billions >> of accounts. > > Ditto. Caches already need to have extensive policies for abuse queries and when legitimatelly running out of resources and figuring out what to flush. Let the DNS/cache implementors handle that - they've done a good job so far. Similarly, trust the cache implementors to deal with many _positive_ entries for large records. >> * Make it more difficult for the final servers to detect abusive >> clients that are doing dictionary (directory harvesting) attacks. >> [ Yes email addresses are not secrets, but some opacity can be >> useful. ] > > Ditto. That will just make the botnet slower and more distributed. Any sufficiently busy domain won't really be able to slow down the botnet. Think of gmail or yahoo, how much rate limiting can they afford without locking out real clients? >> If none of the above are compelling, then going back to a lossless > > I think they are quite compelling I don't think these are compelling at all. I'm not sure how the lossless helps either, unless either the DNS server does fuzzy record returning (which I cannot see work with DNSEC) or you move the lookup protocol outside DNS. Either way, this document and an implementation in DNS does not gain anything by using base32/lossless. >> encoding may be a reasonable compromise. Otherwise, we can take >> the view that: >> >> * The multitude of addresses per user problem is not a problem, >> only a small specific number of addresses will support encryption >> (those may need to appear in the public key "certificates" anyway). >> [...] > > Don't we need DANE for e-mail signature signing key verification too? Yes you can use it for that too, but I'm not sure how this relates to the current discussion. Paul From nobody Tue Mar 31 18:17: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 A7A531A1AA0 for ; Tue, 31 Mar 2015 18:17:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.862 X-Spam-Level: X-Spam-Status: No, score=0.862 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rQPhnZY_z6BU for ; Tue, 31 Mar 2015 18:17:43 -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 A24321B2BB4 for ; Tue, 31 Mar 2015 18:17:38 -0700 (PDT) Received: (qmail 19984 invoked from network); 1 Apr 2015 01:17:37 -0000 Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 1 Apr 2015 01:17:37 -0000 Date: 1 Apr 2015 01:17:15 -0000 Message-ID: <20150401011715.96906.qmail@ary.lan> From: "John Levine" To: dane@ietf.org In-Reply-To: <20150330023734.GP17637@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] encoding mail addresses in the DNS X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2015 01:17:44 -0000 >An alternative is to go back to the original base32 encoding, which >is lossless, and thus can allow the remote DNS server (a special-purpose >DNS lookup engine serving a zone with per-user information) to >decode the local-part and perform whatever fuzzy matching may be >appropriate. > >The lossless encoding can support longer names by breaking them up >into multiple labels. > >This allows static DNS to be published where desired, and custom >code to produce dynamic results when appropriate. I wrote up a draft summarizing the ways one might do mailbox name lookups in the DNS with something close to the local-part rules that MTAs have: http://datatracker.ietf.org/doc/draft-levine-dns-mailbox/ There's two reversible encodings, including a worked out version of base32 that handles full 64 character local-parts, preserves the lexical order of local-parts, and makes signed dynamic zones at least somewhat possible, an implementation of regular expression matching that I think is cool, but probably doesn't scale adequately for large mail systems, and a straightforward way to securely identify a web lookup service. As far as I can tell, the base32 approach handles everything that hashing does, is no harder to use if you want to publish a static set of names, but still offers the possibility for large mail systems to serve stuff on the fly. Take a look. I can send you a tiny python script that turns local-parts into the base32 names if you want. R's, John