From nobody Thu Jan 1 04:08: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 A2B431A1B49 for ; Thu, 1 Jan 2015 04:08:44 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, 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 r0hUU7KzWYWa for ; Thu, 1 Jan 2015 04:08:42 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C0341A1B2F for ; Thu, 1 Jan 2015 04:08:42 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id CAE2DBF15 for ; Thu, 1 Jan 2015 12:08:40 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CmOpIhApdFU1 for ; Thu, 1 Jan 2015 12:08:38 +0000 (GMT) Received: from [10.87.48.73] (unknown [86.42.21.122]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id CE852BF11 for ; Thu, 1 Jan 2015 12:08:38 +0000 (GMT) Message-ID: <54A538C7.8060701@cs.tcd.ie> Date: Thu, 01 Jan 2015 12:08:39 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: dane References: <1968865.8edv0lVl2c@home> In-Reply-To: <1968865.8edv0lVl2c@home> X-Forwarded-Message-Id: <1968865.8edv0lVl2c@home> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/dane/t8JujsDwHqnfT4vmEURt_i_UESo Subject: [dane] Fwd: Comments about draft-ietf-httpbis-http2-16 : Connection reuse X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 01 Jan 2015 12:08:44 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 FYI. If you're interested in this, the discussion needs to be on the httpbis WG list and/or on ietf@ietf.org as HTTP/2.0 is in IETF LC now, until Jan 14th. Cheers, S. - -------- Forwarded Message -------- Subject: Comments about draft-ietf-httpbis-http2-16 : Connection reuse Resent-Date: Thu, 01 Jan 2015 00:04:36 +0000 Resent-From: ietf-http-wg@w3.org Date: Thu, 01 Jan 2015 01:04 +0100 From: Aeris To: ietf-http-wg@w3.org Sorry to speak about this only now, but I notice the following problem only few days ago when I activate SPDY on a TLSA protected domain. §9.1.1 about connection reusage on HTTP/2 say Connections that are made to an origin servers MAY be reused for requests with multiple different URI authority components. A connection can be reused as long as the origin server is authoritative (Section 10.1). For "https" resources, connection reuse additionally depends on having a certificate that is valid for the host in the URI. In my opinion, this behaviour leads to 2 huge problems in term of security and 1 in term of usability/maintenability of HTTP/2. 1- X.509 certificate is not trustable by itself and need real content for validation There are some extensions completing the certificate validation, as DANE/TLSA (RFC6698) or websec-key-pinning (currently IETF draft). For both, guessing A certificate validity for B domain can’t be done just with the A certificate fetched from the A domain. In case of TLSA, you need the real B certificate to check if this is the one declared in the DNS. For PKP, you need the real B content to check the HTTP header. So current specification of HTTP/2 can break TLSA and PKP, by badly guessing that A certificate can be reuse on B domain, instead of using the real B certificate. This is actually the case with current SPDY implementation (Firefox or Chrome). Having a A content including B content on the same IP with a A certificate valid for B domain but not for B TLSA, SPDY reuse the A channel for B content, and Firefox/Chrome display warning or block the content because TLSA error. 2- TLS is not only X.509 certificate. It’s also a lot of other things. The current HTTP/2 specification restrict TLS to only the certificate it use. If A domain use RSA 1024 bits key but B domain use ECC 571 bits key, reusing the A channel for B content reduce a lot the security compared to the case with 2 differents channels. Same problem if you enable different ciphers (saying NULL cipher for static content and AES256-GCM for critical content), or perfect forward secrecy ciphers for one and not for the other. Can be the case if you use weak but fast config for your static content and strong but slow one for the critical content. Same trouble in case of some downgrade attack on static content. If HTTP/2 use the weakest channel for both, there is a big security problem. 421 error code is not usable in this case to reject a channel reusage, because the required checks can’t be done application-side (TLS client context and server config not available) and even server-side, is extremly complicated (if even doable)… 3- Channel reuse leads to « systemd-for-the-web » if done cleanly. Given the 2 points above, doing channel reuse cleanly require for HTTP/2 to become a systemd-like monster. « cleanly » means « no difference compare to 2 channels usage », so take into account real B TLS context : certificat, key type and size, TLSA entry and corresponding DNSSec validation, TLS version, selected cipher, PKP HTTP header, key pinning (hardcoded in browser, pinned by user, pinned by plugin (HTTPS Everywhere / Certificate Patrol)) and virtually any others things a overall TLS ecosystem can have to manage, including not built-in or custom/non-standard. TLSA is a good example for this point because not browser built-in but available through plugin, PKP because not currently a standard, and HTTPSEverywhere/CertificatePatrol because interfering with browser built-in config. To choose if you can reuse or not a A channel for a B domain, HTTP/2 must be aware of many things, perhaps neither built-in nor even standardized. Changing or adding a new step of verification on TLS will require rebuild of HTTP/2 client, hooks on plugins for not-built-in features, plugins need to be notified if HTTP/2 is in use or not… Everything will be aware of HTTP/2 and HTTP/2 will be aware of everything. New SystemD on the road… And even if done cleanly, channel reusing choice will be more expensive than just open a new channel (and worse, require a new channel in all cases for protocol/cipher/key/certificate/PKP/TLSA verification…). So, HTTP/2 must reject connection reusage, and respect real wills of system administrator if they declare 2 differents TLS contexts for 2 domains, but behind the same IP. This kind of config decision must no be done or worse changed client-side. On a post-Snowden era, don’t sacrifice security for speed… :'( Regards (and happy new year :)), - -- Aeris Protect your privacy, encrypt your communications GPG : EFB74277 ECE4E222 OTR : 5769616D 2D3DAC72 https://café-vie-privée.fr/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJUpTjDAAoJEC88hzaAX42irDgH/0KGVmkfujatx9YGehagzk+K GBrc9jH2wrd3kxbkKjsorh0yC4W66U2gHy4921IlQ1PSdBgvkiRP8V/z13d4ML39 ydnUvs/rVdaq1bstvbiTo5foj4ISK5K9qkzS/xWKrSez4vDtIINpnoBPe/eIVzYY Y439nQn1wlmDxLqXZv8GcvD3SrxOQ2pjNLnK9U5JsYdbhR8JIqBok+iwQEZ79AYZ KrSKbUjILn/pZieAysSj4vMSp7ksaF6pblh0n/tvPnVBtiwqbjDwwEgYBFMIZteG gEJ1awKeenol1lXFAZuXvGPRsVtkiksS2qpMHcjiKqZ5ypBb28izzItOu7tLvRA= =35mj -----END PGP SIGNATURE----- From nobody Fri Jan 2 10:26: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 48E2B1A1B92; Fri, 2 Jan 2015 10:26:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.186 X-Spam-Level: X-Spam-Status: No, score=0.186 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FAKE_REPLY_C=1.486, J_CHICKENPOX_31=0.6] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OtbxPAWfvwGR; Fri, 2 Jan 2015 10:26:49 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE25F1A1B63; Fri, 2 Jan 2015 10:26:48 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id A5485284AF7; Fri, 2 Jan 2015 18:26:47 +0000 (UTC) Date: Fri, 2 Jan 2015 18:26:47 +0000 From: Viktor Dukhovni To: ietf , dane Message-ID: <20150102182647.GI24649@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54A538C7.8060701@cs.tcd.ie> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/7tOr633Xmsm1YH3j_LtgnD_oYOQ Subject: Re: [dane] Comments about draft-ietf-httpbis-http2-16 : Connection reuse X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: ietf@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jan 2015 18:26:51 -0000 > From: Aeris > To: ietf-http-wg@w3.org > Date: Thu, 01 Jan 2015 01:04 +0100 > > Sorry to speak about this only now, but I notice the following problem > only few days ago when I activate SPDY on a TLSA protected domain. [ Inserting verbatim text from draft ] > 9.1.1. Connection Reuse > > Connections that are made to an origin servers, either directly or > through a tunnel created using the CONNECT method (Section 8.3) > MAY be reused for requests with multiple different URI authority > components. A connection can be reused as long as the origin server > is authoritative (Section 10.1). For "http" resources, this depends > on the host having resolved to the same IP address. > > For "https" resources, connection reuse additionally depends on > having a certificate that is valid for the host in the URI. An > origin server might offer a certificate with multiple > "subjectAltName" attributes, or names with wildcards, one of which > is valid for the authority in the URI. For example, a certificate > with a "subjectAltName" of "*.example.com" might permit the use of > the same connection for requests to URIs starting with > "https://a.example.com/" and "https://b.example.com/". The key words to consider are: ... a certificate that is valid for the host in the URI. ... Were browsers to actually implement DANE TLSA as a built-in alternative to the Web PKI, then the words above would need to be understood in the context of DANE TLSA. With the Web PKI, verification of server identity is split into two parts: * Verify the certificate trust chain: is the content of the certificate trustworthy? * Verify the server identity: does the certificate bind the subject public key to the desired subject (alternative) name? Notably, the first part is independent of the second, and once the certificate is deemed trusted, it can be "queried" multiple times to determine whether any of a plurality of names are associated with the same subject public key. With DANE TLSA, the validity of a certificate chain is not independent of the desired subject name (essentially a transport endpoint: port, protocol, hostname). This is because the chain's X.509 trust anchors are not absolute, they are potentially different for each "authority". Therefore, a correct implementation of connection reuse per 9.1.1 in the context of DANE would involve the client obtaining the TLSA records for the desired (new) authority, and determining whether the existing connection's certificate chain is valid with respect to the TLSA records for the new authority. So in my view 9.1.1 is fine, provided one understands the term "valid" in the appropriate context. For a non-HTTP example, in the Postfix MTA, the lookup key for TLS session resumption includes a digest of the peer's (sorted) TLSA records. When a peer's TLSA records change, sessions validated via the previous TLSA records are not resumed because they may no longer be valid. > In my opinion, this behaviour leads to 2 huge problems in term of security > and 1 in term of usability/maintenability of HTTP/2. > > 1- X.509 certificate is not trustable by itself and need real content for > validation > > There are some extensions completing the certificate validation, as > DANE/TLSA (RFC6698) or websec-key-pinning (currently IETF draft). For > both, guessing A certificate validity for B domain can?t be done just with > the A certificate fetched from the A domain. In case of TLSA, you need > the real B certificate to check if this is the one declared in the DNS. > For PKP, you need the real B content to check the > HTTP header. > > So current specification of HTTP/2 can break TLSA and PKP, by badly guessing > that A certificate can be reuse on B domain, instead of using the real B > certificate. > > This is actually the case with current SPDY implementation (Firefox or > Chrome). Having a A content including B content on the same IP with a A > certificate valid for B domain but not for B TLSA, SPDY reuse the A channel > for B content, and Firefox/Chrome display warning or block the content > because TLSA error. The real problem here is the fact that TLSA support is an add-on feature in browsers, that piggy-backs on the browser's connection management, rather than an integral feature than is taken into account as part of connection management. So I think that the problem is less with the text of 9.1.1 and more with the approach of doing DANE via plugins. If DANE is to be used with browsers, it needs to be an integral part of the implementation, not an afterthought. -- Viktor. From nobody Tue Jan 6 08:31: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 978991A005D for ; Tue, 6 Jan 2015 08:31:10 -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 0xMr_uz05u3D for ; Tue, 6 Jan 2015 08:31:08 -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 29EEF1A86E6 for ; Tue, 6 Jan 2015 08:29:31 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3kGzgY3bgLz1c7 for ; Tue, 6 Jan 2015 17:29:29 +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=Fg5SWKk5; 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 5nxXl90a6TDu for ; Tue, 6 Jan 2015 17:29:28 +0100 (CET) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) by mx.nohats.ca (Postfix) with ESMTPS for ; Tue, 6 Jan 2015 17:29:28 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 5DCE5803E0 for ; Tue, 6 Jan 2015 11:29:27 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1420561767; bh=GVdMrNASe8FiJUOMzJWIw2Db6ENnycKEf5WJjiLOqvs=; h=Date:From:To:Subject; b=Fg5SWKk5ZZhFI/pkIOn0yYMXb1W67jK092NljOvNFp5fsFilFGp0BzVtb/aIEoIOF +OepPP37VtU5DKEIs4GbIoKBz0SQMJAGHt+38Rde8T19k47OqyEBAYOKUBB8N542T9 99Q1+W3ydJDov/LX7qL4rtMwQobkzVE+Glcy0Fi8= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id t06GTQsX019908 for ; Tue, 6 Jan 2015 11:29:27 -0500 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Tue, 6 Jan 2015 11:29:26 -0500 (EST) From: Paul Wouters To: dane WG list Message-ID: User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/dane/qAFpawpmVqtB8KA3dHcCgKzzqKE Subject: [dane] updated hash-slinger package X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 06 Jan 2015 16:31:10 -0000 http://people.redhat.com/pwouters/hash-slinger (in fedora/epel updates-testing repository) I just pushed an update to hash-slinger, so now you can do: $ openpgpkey --fetch paul@nohats.ca -----BEGIN PGP PUBLIC KEY BLOCK----- Comment: paul@nohats.ca key obtained from DNS Comment: key transfer was protected by DNSSEC Version: GnuPG v1 mQENAz97DD0AAAEH/2hrtp4YrNMcOAAF8YbM8ryWl8uH/dTFzV2plMt+CVh7V5EG N7icm8n+aXUJeY+pvftjiXj0kvEJmcOllfbvG+4Bus4cn2NtM7Yy0kZLSE050bkn OE+WX9/ffbnXQcnk/E6DBnosIaxPCxnmL2SV6UtGNkbeC3tDcUWfrMtQaqkUhhqN gfD1p47HIrbPGnr4EX+Ck52HPe7/neo9WZ6XR4pWNQ50clJXJfBpwZVpedx9f0ys [...] pOfy75us2QcD8vVTXB/pItRy+2eJP1uhiP85Xko8QhVn6Hi0spJeGHt5Wk63Mrvm gZ3ro3/uz7/w0P56Q1bX5+bfGq8JB1UFOA0gwxZCdg== =T8tU -----END PGP PUBLIC KEY BLOCK----- $ openpgpkey --fetch paul@nohats.ca | gpg --import --dry-run gpg: WARNING: digest algorithm MD5 is deprecated gpg: please see http://www.gnupg.org/faq/weak-digest-algos.html for more information gpg: key B5CC27E1: "Paul Wouters (migration only, use new key) " not changed gpg: Total number processed: 1 gpg: unchanged: 1 It also fixes the --create option to deal with all the weird character set anomalies in people's keys. Requires python-gnupg 0.3.7. So all people with non-english entries in they gpg keyring should be able to finally use openpgpkey to create OPENPGPKEY records: openpgpkey --create your@email.com --output generic (generic record format) openpgpkey --create your@email.com --output rfc (OPENPGPKEY presentation format) (openpgpkey --verify will fetch and compare with local keyring) It also fixes sshfp for debian and adds ECDSA key support. And finally I added ipseckey (only with libreswan and possibly openswan) Paul From nobody Tue Jan 6 21:21: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 44A8C1A1A33 for ; Tue, 6 Jan 2015 21:21:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.702 X-Spam-Level: X-Spam-Status: No, score=-0.702 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, 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 OKrl9vPQlxYR for ; Tue, 6 Jan 2015 21:21:34 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (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 C82F71A1A16 for ; Tue, 6 Jan 2015 21:21:34 -0800 (PST) Received: from [192.168.123.7] (unknown [23.241.1.22]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 8EACF22E261 for ; Wed, 7 Jan 2015 00:21:33 -0500 (EST) Message-ID: <54ACC218.8070507@seantek.com> Date: Tue, 06 Jan 2015 21:20:24 -0800 From: Sean Leonard User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: dane@ietf.org Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dane/V6pcVC2lI2E__8d8sO4U6CvG2QE Subject: [dane] (draft-ietf-dane-smime) SHA-224 not in CryptoAPI X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 07 Jan 2015 05:21:37 -0000 Hello: I would like to point out that SHA-224 is not a good choice for a fixed hash algorithm. SHA-224 is not implemented in Microsoft CryptoAPI / Cryptography Next Generation, which means that Windows apps (clients and servers) will have a more difficult time implementing this thing. Reference: . I suggest sticking with SHA-256. Looking back at the archives, it appears that a motivator for SHA-224 is that it is "short" and therefore fits in a DNS label with hex encoding. I do not buy this argument. Base32 encoding works great for SHA-256. Since DNS labels are octets anyway, if you want "short" I do not see a big deal with putting 32 octets in the label. Pushback on the grounds that "it's not a hostname" and "watch out for case folding" are moot because "_smimecert" is not a valid hostname either: that's why "_" was chosen for SRV records and their kin. It's not a vanity contest. Maybe there are other considerations; I am not a DNS ops expert. Suffice to say, base32 would work just fine. (As an implementer, I have other various opinions about this work but don't feel like bringing them up at this time.) Sean From nobody Tue Jan 6 21:42: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 780071A1A33 for ; Tue, 6 Jan 2015 21:42:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lPwhuQdYu5mK for ; Tue, 6 Jan 2015 21:42:18 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F13E71A1A27 for ; Tue, 6 Jan 2015 21:42:17 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 02D9E282CC6; Wed, 7 Jan 2015 05:42:16 +0000 (UTC) Date: Wed, 7 Jan 2015 05:42:16 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20150107054216.GV7322@mournblade.imrryr.org> References: <54ACC218.8070507@seantek.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54ACC218.8070507@seantek.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/urSjITfBoFhkOanKhzDlEWmtepE Subject: Re: [dane] (draft-ietf-dane-smime) SHA-224 not in CryptoAPI 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, 07 Jan 2015 05:42:20 -0000 On Tue, Jan 06, 2015 at 09:20:24PM -0800, Sean Leonard wrote: > I would like to point out that SHA-224 is not a good choice for a fixed hash > algorithm. SHA-224 is not implemented in Microsoft CryptoAPI / Cryptography > Next Generation, which means that Windows apps (clients and servers) will > have a more difficult time implementing this thing. Reference: > . I suggest sticking with > SHA-256. A base32 encoding of SHA2-224 requires 45 octets, while SHA2-256 requires 52 octets. Every little bit of space saved helps, DNS names have a limited length. One could of course truncate SHA2-256, if availability of SHA2-224 is a major problem. IIRC SHA2-224 is essentially that, but is "salted" a bit differently to distinguish it from truncated SHA2-256 output. The larger question is whether putting per-user keys in DNS is the right approach, or whether DNS should instead provide key material to authenticate a dedicated lookup service that is not bound by DNS encoding restrictions at all, which can in turn query alternative sources (LDAP, ...)? Are user keys a good fit for DNS? There was some discussion of this a while back, but it just died down with no conclusions. Using something other than DNS would allow the lookup service to handle key canonicalization (case folding, handling of address extensions, ...), which are otherwise difficult. -- Viktor. From nobody Tue Jan 6 23:15: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 1B2C51A8966 for ; Tue, 6 Jan 2015 23:15:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_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 83NsyfxPs_wB for ; Tue, 6 Jan 2015 23:15:36 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (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 899C81A8960 for ; Tue, 6 Jan 2015 23:15:36 -0800 (PST) Received: from [192.168.123.7] (unknown [23.241.1.22]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 6326722E269 for ; Wed, 7 Jan 2015 02:15:35 -0500 (EST) Message-ID: <54ACDCD2.9070008@seantek.com> Date: Tue, 06 Jan 2015 23:14:26 -0800 From: Sean Leonard User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: dane@ietf.org References: <54ACC218.8070507@seantek.com> <20150107054216.GV7322@mournblade.imrryr.org> In-Reply-To: <20150107054216.GV7322@mournblade.imrryr.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/dane/CVJrkiECa0PgbR8pzng5rddKSm0 Subject: Re: [dane] (draft-ietf-dane-smime) SHA-224 not in CryptoAPI X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 07 Jan 2015 07:15:39 -0000 On 1/6/2015 9:42 PM, Viktor Dukhovni wrote: > The larger question is whether putting per-user keys in DNS is the > right approach, or whether DNS should instead provide key material > to authenticate a dedicated lookup service that is not bound by > DNS encoding restrictions at all, which can in turn query alternative > sources (LDAP, ...)? Are user keys a good fit for DNS? There was > some discussion of this a while back, but it just died down with > no conclusions. Using something other than DNS would allow the > lookup service to handle key canonicalization (case folding, handling > of address extensions, ...), which are otherwise difficult. Right...all the questions that I am intentionally avoiding in this=20 thread (see original post) . > On Tue, Jan 06, 2015 at 09:20:24PM -0800, Sean Leonard wrote: > >> I would like to point out that SHA-224 is not a good choice for a fixe= d hash >> algorithm. SHA-224 is not implemented in Microsoft CryptoAPI / Cryptog= raphy >> Next Generation, which means that Windows apps (clients and servers) w= ill >> have a more difficult time implementing this thing. Reference: >> . I suggest sticking with >> SHA-256. > A base32 encoding of SHA2-224 requires 45 octets, while SHA2-256 > requires 52 octets. Every little bit of space saved helps, DNS > names have a limited length. One could of course truncate SHA2-256, > if availability of SHA2-224 is a major problem. IIRC SHA2-224 is > essentially that, but is "salted" a bit differently to distinguish > it from truncated SHA2-256 output. If we are quibbling about 7 octets, I think we really have lost=20 perspective on this. For 99.99999999% of all e-mail addresses, just encoding the local-part=20 as-is in a single DNS label would be the shortest. That is the approach=20 somewhat-but-not-quite taken by CERT RRs [RFC4398]. Various justifications of hashing have been given on this list. Some=20 advocate for HMAC-ing with some per-domain key. There is a lot of=20 literature on the attacks thwarted and attacks let through with these=20 approaches. Mostly, I don't think applying any transform buys you=20 meaningful security; it just lets you map long local-parts to a single=20 DNS label. The difference between 32, 45, and 52 octets is negligible. In all=20 seriousness: the domain-part is not going to be greater than 201=20 octets/characters for an e-mail address, even with IDNA. The RR payload=20 is going to be significantly larger than the name anyway. Sean From nobody Wed Jan 7 09:25: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 CD5EA1A004B for ; Wed, 7 Jan 2015 09:25:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.567 X-Spam-Level: X-Spam-Status: No, score=-1.567 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, 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 VRqdpZhSj-UX for ; Wed, 7 Jan 2015 09:25:09 -0800 (PST) Received: from gateway04.websitewelcome.com (gateway04.websitewelcome.com [67.18.44.19]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4FDE11A0055 for ; Wed, 7 Jan 2015 09:25:09 -0800 (PST) Received: by gateway04.websitewelcome.com (Postfix, from userid 5007) id 93DA0C3ED378E; Wed, 7 Jan 2015 11:25:08 -0600 (CST) Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway04.websitewelcome.com (Postfix) with ESMTP id 82CDDC3ED3745 for ; Wed, 7 Jan 2015 11:25:08 -0600 (CST) Received: from [96.231.226.60] (port=55205 helo=[192.168.1.2]) by gator3286.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1Y8uLz-0002Qm-SZ; Wed, 07 Jan 2015 11:25:07 -0600 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Sean Turner In-Reply-To: <0DAFC2A8-A1E2-46F4-BA52-E8261CB09159@ogud.com> Date: Wed, 7 Jan 2015 12:25:05 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <113FC996-99E2-4203-BA55-AA901F9C0893@ieca.com> References: <0DAFC2A8-A1E2-46F4-BA52-E8261CB09159@ogud.com> To: Olafur Gudmundsson X-Mailer: Apple Mail (2.1878.6) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator3286.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source-IP: 96.231.226.60 X-Exim-ID: 1Y8uLz-0002Qm-SZ X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([192.168.1.2]) [96.231.226.60]:55205 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 1 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20= Archived-At: http://mailarchive.ietf.org/arch/msg/dane/a6dsVTNewlju4Ks_0KWcTe0nZ7A Cc: "" Subject: Re: [dane] WGLC: DANE-SRV & DANE-SMTP X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jan 2015 17:25:11 -0000 Apologies for this being a bit late =85 I read the DANE-SRV record, had some nits (Victor also caught =91em), = and support progressing the draft. Still working on the SMTP draft it=92s a big denser. spt On Nov 12, 2014, at 23:09, Olafur Gudmundsson wrote: > Dear wg members >=20 > This email message starts a three week WGLC ending on December 4=92th = at 23:59 UTC.=20 >=20 > http://tools.ietf.org/wg/dane/draft-ietf-dane-srv > and=20 > https://tools.ietf.org/html/draft-ietf-dane-smtp-with-dane-13 >=20 > These two document are specifying related uses of DANE.=20 > Please review the documents carefully, in particular we want to make = sure the documents have no=20 > contradictions.=20 >=20 > We need at least 5 members of the working group to state in public = that they have read the documents and=20 > state what is needed to fixed before the documents are advanced.=20 >=20 > I will act as document shepherd for these two documents.=20 >=20 > Olafur & Warren > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane From nobody Wed Jan 7 10:46: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 9FD971A014C for ; Wed, 7 Jan 2015 10:46:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.778 X-Spam-Level: X-Spam-Status: No, score=-0.778 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URI_HEX=1.122] 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 yrKIUPT8NTNB for ; Wed, 7 Jan 2015 10:45:59 -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 1C6151A0242 for ; Wed, 7 Jan 2015 10:45:56 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3kHffR0dQdz31J for ; Wed, 7 Jan 2015 19:45:51 +0100 (CET) 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 AdDN8X3pY3YK for ; Wed, 7 Jan 2015 19:45:49 +0100 (CET) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) by mx.nohats.ca (Postfix) with ESMTPS for ; Wed, 7 Jan 2015 19:45:48 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 8B66B809FE for ; Wed, 7 Jan 2015 13:45:47 -0500 (EST) Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id t07Ijk89031173 for ; Wed, 7 Jan 2015 13:45:47 -0500 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Wed, 7 Jan 2015 13:45:46 -0500 (EST) From: Paul Wouters X-X-Sender: paul@bofh.nohats.ca To: dane WG list In-Reply-To: <20150107054216.GV7322@mournblade.imrryr.org> Message-ID: References: <54ACC218.8070507@seantek.com> <20150107054216.GV7322@mournblade.imrryr.org> 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: http://mailarchive.ietf.org/arch/msg/dane/0p8FQJDDfDszSQd97eJOHmsJ4_8 Subject: Re: [dane] (draft-ietf-dane-smime) SHA-224 not in CryptoAPI X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 07 Jan 2015 18:46:01 -0000 On Wed, 7 Jan 2015, Viktor Dukhovni wrote: > On Tue, Jan 06, 2015 at 09:20:24PM -0800, Sean Leonard wrote: > >> I would like to point out that SHA-224 is not a good choice for a fixed hash >> algorithm. SHA-224 is not implemented in Microsoft CryptoAPI / Cryptography >> Next Generation, which means that Windows apps (clients and servers) will >> have a more difficult time implementing this thing. Reference: >> . I suggest sticking with >> SHA-256. Wish we had known that sooner :( > A base32 encoding of SHA2-224 requires 45 octets, while SHA2-256 > requires 52 octets. Every little bit of space saved helps, DNS > names have a limited length. One could of course truncate SHA2-256, > if availability of SHA2-224 is a major problem. IIRC SHA2-224 is > essentially that, but is "salted" a bit differently to distinguish > it from truncated SHA2-256 output. I have no problem with this for OPENPGPKEY. > The larger question is whether putting per-user keys in DNS is the > right approach, or whether DNS should instead provide key material > to authenticate a dedicated lookup service Actually, this has nothing to do with the problem of the hash of the username which is needed to _find_ the DNS record. You are talking about adding another level of indirection for the return _data_ and you'll be adding another choke/failure/filter point people can attack to prevent you from publishing your key Plus, a mechanism already exists to solve what you (not I) deem to be a problem: danm._pka.prime.gushi.org. TXT "v=pka1;fpr=C2063054549295F3349037FFFBBE5A30624BB249;uri=http://prime.gushi.org/danm.pubkey.txt" Perhaps someone wants to run a fetch on the RIPE ATLAS network for: ab16de0656382d91838914109ab89a0a4e04321550a1a20ace7a8b66._openpgpkey.nohats.ca and see how many sites cannot get the data back? > Using something other than DNS would allow the > lookup service to handle key canonicalization (case folding, handling > of address extensions, ...), which are otherwise difficult. We've been waiting for 20 years. Pervasive monitoring etc... ExecSum: If we use a truncated sha2_256 in smime, we should use it in openpgpkey too. We should try to keep these two in sync. Not storing key data in DNS is off-topic. Paul From nobody Wed Jan 7 17:15: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 EE10B1A8846 for ; Wed, 7 Jan 2015 17:15:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_62=0.6] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OKMs3n5hjJ1z for ; Wed, 7 Jan 2015 17:15:30 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD3671A87D5 for ; Wed, 7 Jan 2015 17:15:30 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 8E17A282CC6; Thu, 8 Jan 2015 01:15:29 +0000 (UTC) Date: Thu, 8 Jan 2015 01:15:29 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20150108011529.GU7322@mournblade.imrryr.org> References: <0DAFC2A8-A1E2-46F4-BA52-E8261CB09159@ogud.com> <113FC996-99E2-4203-BA55-AA901F9C0893@ieca.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <113FC996-99E2-4203-BA55-AA901F9C0893@ieca.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/krui534XW6khBnaSgvz6Ba_uOWY Subject: Re: [dane] WGLC: DANE-SRV & DANE-SMTP X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2015 01:15:33 -0000 On Wed, Jan 07, 2015 at 12:25:05PM -0500, Sean Turner wrote: > I read the DANE-SRV record, had some nits (Victor also caught > 'em), and support progressing the draft. I think you're saying that the associated revisions can be made as part of moving into IETF LC, and don't need further WG review? Is that right? But being new around here, I am not quite sure. > Still working on the SMTP draft it's a big denser. Yeah, sorry about that. The SMTP draft is a lot more detailed, because it is applies DANE to a concrete protocol, and so can and I think should be more specific in its prescriptions. With RFC 7435 out the door, at least part of the basic premise need no longer be debated. We'll need to remember to update the references from draft-dukhovni-opportunistic-security to RFC7435 at some convenient point in time. I did ask a question during LC: http://www.ietf.org/mail-archive/web/dane/current/msg07159.html ... One deployment pitfall discovered in recent interoperability tests is that some domains have cleartext-only anti-spam proxies in front of their MTA, with the proxies only allowing connections to the real MTA once the SMTP client passes a grey-listing check (this was observed with "spamd" as the proxy, but any "selective access" to TLS can be similarly problematic). If the receiving domain publishes TLSA records, this creates a catch-22 with DANE-aware client MTAs. The DANE client never begins the first mail transaction, because the proxy does not offer STARTTLS, (the proxy is a receiving system deployed downgrade to cleartext MiTM in front of the real MTA). The short-term solution for such domains is to NOT publish TLSA RRs for port 25. Longer-term the anti-spam proxy should be upgraded to support STARTTLS. For example, the Postfix "postscreen" service, which has functionality similar to "spamd", supports STARTTLS so that grey-listing does not amount to a similar downgrade attack. I'd like to add some language about avoiding this problem in the operational considerations section of the smtp-with-dane draft. Any objections? Additional operational considerations might include not forgetting to update TLSA RRs for *all* the names under which a server might be known when doing key rotation. This is a problem particularly when a single wild-card certificate is deployed on all the MX hosts, and replaced concurrently on them all, creating an immediate outage for any domains that use variant MX host names (for flexibility of later hosting some domains separately). With DANE one should strongly consider per-server certificates to avoid synchronized multi-MTA outages. And lastly, by far the most common problems are with DNSSEC. A mixture of failure to perform timely re-signing and at present lots of domains with nameservers that have non-working Denial of Existence. I don't have a comprehensive list of software that is deficient in this manner, but it seems that some older versions of PowerDNS botch DoE in at least some configurations. Similar issues reportedly with djbdns DNSSEC patches. A few domains have firewalls that block TLSA queries, one blocked these only for IPv4 clients, with IPv6 clients not filtered, that can create difficult to diagnose problems. So I am looking for guidance on how much *current* operational experience to include in the draft that may ultimately become irrelevant as the infrastructure improves, but may be very useful to get us past the initial deployment hurdles. If we don't get early adopters past the initial problems, the long-term obsolescence of the issues might remain forever in the future. Any feedback on that would be appreciated, plus guidance on *when* to make any such changes. -- Viktor. P.S. As for deployment stats, my curated list now has 794 domains, but not all of that is recent growth, some is due to an additional data source that contributed 241 domains. The domain count for my original sources grew from 463 to 553 over the last month. The count of domains for which TLSA lookups break stands at 2561, with 2352 of them attributable to 3 .nl and 1 .cz hosted DNS providers: 910 transip.nl 852 forpsi.cz 453 hostnet.nl 137 ns0.nl I'm told that the above registrars, which account for the bulk of the deployment barriers, are working on it, and I am still optimistic that this will be addressed over the next few months. Anyone reading this who is operating PowerDNS older than 3.3.1, should upgrade, as older versions generally exhibit interoperability issues (incorrect denial of existence). From nobody Thu Jan 8 14:23: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 78D4D1A1B1E for ; Thu, 8 Jan 2015 14:23:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_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 54jz09EfOus1 for ; Thu, 8 Jan 2015 14:23:37 -0800 (PST) Received: from gateway31.websitewelcome.com (gateway31.websitewelcome.com [192.185.144.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 F2C621A1B1B for ; Thu, 8 Jan 2015 14:23:33 -0800 (PST) Received: by gateway31.websitewelcome.com (Postfix, from userid 500) id 64CA587F9E726; Thu, 8 Jan 2015 16:23:33 -0600 (CST) Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway31.websitewelcome.com (Postfix) with ESMTP id 4F68487F9E6BF for ; Thu, 8 Jan 2015 16:23:33 -0600 (CST) Received: from [96.231.226.60] (port=55779 helo=[192.168.1.2]) by gator3286.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1Y9LUK-00016m-L0 for dane@ietf.org; Thu, 08 Jan 2015 16:23:32 -0600 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Sean Turner In-Reply-To: <20150108011529.GU7322@mournblade.imrryr.org> Date: Thu, 8 Jan 2015 17:23:30 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <0DAFC2A8-A1E2-46F4-BA52-E8261CB09159@ogud.com> <113FC996-99E2-4203-BA55-AA901F9C0893@ieca.com> <20150108011529.GU7322@mournblade.imrryr.org> To: dane@ietf.org X-Mailer: Apple Mail (2.1878.6) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator3286.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source-IP: 96.231.226.60 X-Exim-ID: 1Y9LUK-00016m-L0 X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([192.168.1.2]) [96.231.226.60]:55779 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 1 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20= Archived-At: Subject: Re: [dane] WGLC: DANE-SRV & DANE-SMTP X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2015 22:23:38 -0000 On Jan 07, 2015, at 20:15, Viktor Dukhovni = wrote: >> I read the DANE-SRV record, had some nits (Victor also caught >> 'em), and support progressing the draft. >=20 > I think you're saying that the associated revisions can be made as > part of moving into IETF LC, and don't need further WG review? Is > that right? But being new around here, I am not quite sure. Yes - let=92s get this one out the door. spt= From nobody Thu Jan 8 14:26: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 B22D71A1B1E for ; Thu, 8 Jan 2015 14:26:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w45CbhJxHfXE for ; Thu, 8 Jan 2015 14:26:09 -0800 (PST) Received: from mail-ig0-f171.google.com (mail-ig0-f171.google.com [209.85.213.171]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 529A41A1B21 for ; Thu, 8 Jan 2015 14:26:09 -0800 (PST) Received: by mail-ig0-f171.google.com with SMTP id z20so5205804igj.4 for ; Thu, 08 Jan 2015 14:26:07 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=vwnfsMjSX1CYx5t5lIaKxN4JKdmcQFIlewChLqTiUqA=; b=ZKhf3zkz+MOPR5mOI+YVO9C0oIO+SEmWGaIWEKYH5xRQzNuwxmTaxOZSvsNIjUyAHk saqwullxp6WdE4QpI03Rno7q2F5YZgPlfQTZcwfFCVlf5CDyxFsM3eU2tGCHRwQPG0Mb sC726+5/EaKtlPqo/sLsIzPTjTCwFrto0Cdb2+9FHrajJORvtW000C3NglXoNZr8NES5 eabwibRHG69BKWpzvSy+0PW6P8poxUrywYdqIxUbxNIXjTeuChzihZJGOR5l/AtC+MPY 9lB3RCzb+gxtEsN4+2rixTwV4LttswrcuG6CvvQwEosw1DNSkumpsTLsGRVOi8/vfofQ 5vYg== X-Gm-Message-State: ALoCoQnhMH1sXN5/632XeUa9rRFe+iB6KpcmZVSq9p99qgq4KmZsCSDgeIoepi/3ogzcULl6AH+5 X-Received: by 10.107.170.98 with SMTP id t95mr11579869ioe.7.1420755967823; Thu, 08 Jan 2015 14:26:07 -0800 (PST) Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id p198sm2928809iop.36.2015.01.08.14.26.05 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 08 Jan 2015 14:26:06 -0800 (PST) Message-ID: <54AF03FC.2020603@andyet.net> Date: Thu, 08 Jan 2015 15:26:04 -0700 From: Peter Saint-Andre - &yet User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Sean Turner , dane@ietf.org References: <0DAFC2A8-A1E2-46F4-BA52-E8261CB09159@ogud.com> <113FC996-99E2-4203-BA55-AA901F9C0893@ieca.com> <20150108011529.GU7322@mournblade.imrryr.org> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [dane] WGLC: DANE-SRV & DANE-SMTP X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2015 22:26:11 -0000 On 1/8/15 3:23 PM, Sean Turner wrote: > On Jan 07, 2015, at 20:15, Viktor Dukhovni wrote: > >>> I read the DANE-SRV record, had some nits (Victor also caught >>> 'em), and support progressing the draft. >> >> I think you're saying that the associated revisions can be made as >> part of moving into IETF LC, and don't need further WG review? Is >> that right? But being new around here, I am not quite sure. > > Yes - let’s get this one out the door. Truth be told I haven't had time to review Viktor's proposed edits yet and I thought he was going to be posting more feedback, but if he's done then the authors can have a chat about how to address his input. Peter -- Peter Saint-Andre https://andyet.com/ From nobody Thu Jan 8 14:31: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 3F58C1A1B57 for ; Thu, 8 Jan 2015 14:31:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UNc3Vu6BVXyJ for ; Thu, 8 Jan 2015 14:31:30 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2ACC21A0095 for ; Thu, 8 Jan 2015 14:31:29 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 8B0BE282CC8; Thu, 8 Jan 2015 22:31:10 +0000 (UTC) Date: Thu, 8 Jan 2015 22:31:10 +0000 From: Viktor Dukhovni To: Peter Saint-Andre - &yet Message-ID: <20150108223110.GP7322@mournblade.imrryr.org> References: <0DAFC2A8-A1E2-46F4-BA52-E8261CB09159@ogud.com> <113FC996-99E2-4203-BA55-AA901F9C0893@ieca.com> <20150108011529.GU7322@mournblade.imrryr.org> <54AF03FC.2020603@andyet.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54AF03FC.2020603@andyet.net> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: dane@ietf.org Subject: Re: [dane] WGLC: DANE-SRV & DANE-SMTP X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2015 22:31:31 -0000 On Thu, Jan 08, 2015 at 03:26:04PM -0700, Peter Saint-Andre - &yet wrote: > Truth be told I haven't had time to review Viktor's proposed edits yet and I > thought he was going to be posting more feedback, but if he's done then the > authors can have a chat about how to address his input. My last review message said I was done. Sorry if it was not sufficiently obvious. -- Viktor. From nobody Thu Jan 8 14:37: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 821A41A1B62 for ; Thu, 8 Jan 2015 14:37:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NUUEm-9asRKB for ; Thu, 8 Jan 2015 14:37:05 -0800 (PST) Received: from mail-ie0-f180.google.com (mail-ie0-f180.google.com [209.85.223.180]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CCBE41A0177 for ; Thu, 8 Jan 2015 14:36:46 -0800 (PST) Received: by mail-ie0-f180.google.com with SMTP id rp18so12098646iec.11 for ; Thu, 08 Jan 2015 14:36:46 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=41fS9+w+16T6pzUn16KBdROhyxSW6b/asf8p+Mgh84k=; b=WjsgfqZfKDYNla8oCpu6RUQLRM3Qe3N0cSUwa2sNahXmJQ5YhDd+u59QTlwTkzP5Qu nwxQ7budbCErbzQa0xSCF5rgFn5GK5cp+RSXobggDqTt1H0+xDaxq9kM5G+k9KY3OkYp ONW/jzyPTTGoyUuzENKip4gGAZlxLAWv9WuoTLP4V8St2gwvtGmWTa8dhO0ZmEXWFI9d LjcBF5DqThuGQN8U5jzeybmpX8fWuOtKvaVTe2vwKz+c3/cvK0FuKjTxNAhB/5Y/L/05 4WYW+oNTnUY1AdvxRSx1ddUaB3WgeIbVwyuuUhiUvCpasNhYgXyX5leVYHi6Sp1EUWx+ U8Bw== X-Gm-Message-State: ALoCoQl+43BufsgdPRdbsHVUka6SaydEea3tuaFVeOtEpPQ4xDi3V/zvAnXC7i8D7u77PQuMOEsq X-Received: by 10.107.18.32 with SMTP id a32mr11669747ioj.77.1420756606313; Thu, 08 Jan 2015 14:36:46 -0800 (PST) Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id lr3sm3209598igb.22.2015.01.08.14.36.45 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 08 Jan 2015 14:36:45 -0800 (PST) Message-ID: <54AF067C.5070003@andyet.net> Date: Thu, 08 Jan 2015 15:36:44 -0700 From: Peter Saint-Andre - &yet User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Viktor Dukhovni References: <0DAFC2A8-A1E2-46F4-BA52-E8261CB09159@ogud.com> <113FC996-99E2-4203-BA55-AA901F9C0893@ieca.com> <20150108011529.GU7322@mournblade.imrryr.org> <54AF03FC.2020603@andyet.net> <20150108223110.GP7322@mournblade.imrryr.org> In-Reply-To: <20150108223110.GP7322@mournblade.imrryr.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: dane@ietf.org Subject: Re: [dane] WGLC: DANE-SRV & DANE-SMTP X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2015 22:37:06 -0000 On 1/8/15 3:31 PM, Viktor Dukhovni wrote: > On Thu, Jan 08, 2015 at 03:26:04PM -0700, Peter Saint-Andre - &yet wrote: > >> Truth be told I haven't had time to review Viktor's proposed edits yet and I >> thought he was going to be posting more feedback, but if he's done then the >> authors can have a chat about how to address his input. > > My last review message said I was done. Sorry if it was not > sufficiently obvious. I've been so busy with day-job responsibilities that I haven't read any of your messages. :( But Matt and I plan to meet in person late next week so we'll have a little authors' meeting and figure out next steps. Peter -- Peter Saint-Andre https://andyet.com/ From nobody Mon Jan 12 05:52: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 64CDB1A90F1 for ; Mon, 12 Jan 2015 05:52:32 -0800 (PST) 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 fsL3KA2qf7fY for ; Mon, 12 Jan 2015 05:52:26 -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 9BDFB1A90FE for ; Mon, 12 Jan 2015 05:52:26 -0800 (PST) Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t0CDqPBL002803 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Mon, 12 Jan 2015 08:52:25 -0500 Received: from pspacek.brq.redhat.com (pspacek.brq.redhat.com [10.34.128.7]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t0CDqNUT031680 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Mon, 12 Jan 2015 08:52:25 -0500 Message-ID: <54B3D197.7040808@redhat.com> Date: Mon, 12 Jan 2015 14:52:23 +0100 From: Petr Spacek Organization: Red Hat User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: dane@ietf.org References: <20141027233636.24734.41333.idtracker@ietfa.amsl.com> In-Reply-To: <20141027233636.24734.41333.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 Archived-At: Subject: Re: [dane] I-D Action: draft-ietf-dane-openpgpkey-01.txt: keyring format definition X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 12 Jan 2015 13:52:32 -0000 On 28.10.2014 00:36, internet-drafts@ietf.org wrote: > Title : Using DANE to Associate OpenPGP public keys with email addresses > Author : Paul Wouters > Filename : draft-ietf-dane-openpgpkey-01.txt I would like to see a clarification for section: 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. I'm struggling with definition of "formatted OpenPGP public keyring". After a quick glance I have found only this: 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. I did not read whole RFC 4880 so it is possible that I have missed some related definitions but IMHO this reference deserves clarification. Where is the actual keyring format defined? -- Petr Spacek @ Red Hat From nobody Mon Jan 12 06:55:46 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5319C1AC399 for ; Mon, 12 Jan 2015 06:55:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.062 X-Spam-Level: X-Spam-Status: No, score=-2.062 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, 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 VSFQ2zwAVHFv for ; Mon, 12 Jan 2015 06:55:42 -0800 (PST) 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 175FD1A924B for ; Mon, 12 Jan 2015 06:55:41 -0800 (PST) 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=1421074537; x=1422888938; bh=ktIwL0e bM3YgrNUD3SGii6Kva1d7iQ0Yk4bJmE9NbeQ=; b=zaMdT6ppBFjVwhQ13qxy66B 9tA/b+Txgf7opWRNX9gAMZ7taaDPVxSduyrL/CKMSh3A2PBLlrUxZeWpVyytwNuC hUaJCOSEiy0aGG/kUs7ULpaDgxIClyS1DNoRklly7xvZGO0oKKViTUr/I6SD9Xak C9MgHOzkVo1fZIsSHFpNxCrV3Xe3a/WSTaBhSju2CjzSIwY8qaNuAnFWrWFj5pX/ 4VIsLdSAzhZPDcYwj0xYu6SchmvL8544tgywy7YGv/p026I8N9WpgV4wGBEqCeEm YoLFmP544jx0P7GC9ZozzsXvqVTy8m9h7+eTighWEzlxih0wzH2xjPmULYS2dWw= = X-Virus-Scanned: Debian amavisd-new at mail.sys4.de Received: from sys4.de (ppp-188-174-169-108.dynamic.mnet-online.de [188.174.169.108]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.sys4.de (Postfix) with ESMTPSA id 3kLdJT261wz2M for ; Mon, 12 Jan 2015 15:55:37 +0100 (CET) Date: Mon, 12 Jan 2015 15:55:36 +0100 From: Patrick Ben Koetter To: dane@ietf.org Message-ID: <20150112145536.GG15038@sys4.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit Archived-At: Subject: [dane] ANN: dane-users@sys4.de mailing list and https://dane.sys4.de DANE SMTP test site X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 12 Jan 2015 14:55:44 -0000 Today, amost 3% of DANE SMTP enabled domains either fail to validate or publish unsupported TLSA records[1]. This fraction would have been even higher without an effort to notify problem sites most of which have fixed the reported issues. This error rate is too high. The DANE Validator is intended to identify configuration errors and to help administrators create working DANE SMTP configurations. Today's release marks the first public beta. We plan to release version 1 soon. Coinciding with the release of the Validator we have also created a "DANE users" mailing list at dane-users@sys4.de. This list will provide a forum to discuss practical issues of DANE configuration and deployment. In order to subscribe to this list visit https://mail.sys4.de/cgi-bin/mailman/listinfo/dane-users. Regards Patrick Koetter [1] Based on DANE adoption surveys by Viktor Dukhovni. -- [*] 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 Jan 12 07:06: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 C509D1AC3B6 for ; Mon, 12 Jan 2015 07:06:27 -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 BS2NYnJPpn7H for ; Mon, 12 Jan 2015 07:06:20 -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 1F50B1AC3B3 for ; Mon, 12 Jan 2015 07:06:14 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3kLdXd5xlvzCHf; Mon, 12 Jan 2015 16:06:09 +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=UeaxMSoo; 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 7bnkuZcwCQ6D; Mon, 12 Jan 2015 16: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, 12 Jan 2015 16:06:08 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 1B22E8004F; Mon, 12 Jan 2015 10:06:08 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1421075168; bh=sfyA4LKIj97Y5nlotJZvF5skB9IhhaXbP3aRJbm9CkI=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=UeaxMSooN5Vz4z+xqqKPSpAWosm2fOxyKp7TkSZRBIQF71h3ftVcIa0P2WffjrPKD BDI9WIHTZcKHRFz8iwjE1YMgDngH0f7BOLwyabL0qX+XIYAs6DAX6OdnKDtMF1XGSJ 288q0WPVsWYdXIMVGurhYw/z02Vw/QlbZTR5JVf4= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id t0CF67no032687; Mon, 12 Jan 2015 10:06:07 -0500 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Mon, 12 Jan 2015 10:06:07 -0500 (EST) From: Paul Wouters To: Petr Spacek In-Reply-To: <54B3D197.7040808@redhat.com> Message-ID: References: <20141027233636.24734.41333.idtracker@ietfa.amsl.com> <54B3D197.7040808@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] I-D Action: draft-ietf-dane-openpgpkey-01.txt: keyring format definition X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 12 Jan 2015 15:06:28 -0000 On Mon, 12 Jan 2015, Petr Spacek wrote: > I would like to see a clarification for section: > > 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. > > > I'm struggling with definition of "formatted OpenPGP public keyring". After a > quick glance I have found only this: > > 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. > > I did not read whole RFC 4880 so it is possible that I have missed some > related definitions but IMHO this reference deserves clarification. > > Where is the actual keyring format defined? That's it. You're looking at it. There is not a better reference that I'm aware of. I have been looking for it myself as well. Paul From nobody Mon Jan 12 07:38: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 6772B1ABD3B for ; Mon, 12 Jan 2015 07:38:19 -0800 (PST) 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 LaCnyP2FjLsx for ; Mon, 12 Jan 2015 07:38:17 -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 B02C71AC3E2 for ; Mon, 12 Jan 2015 07:38:02 -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 t0CFc0Yq007705 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Mon, 12 Jan 2015 10:38:01 -0500 Received: from pspacek.brq.redhat.com ([10.34.249.150]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t0CFbwDP016056 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Mon, 12 Jan 2015 10:38:00 -0500 Message-ID: <54B3EA56.3020006@redhat.com> Date: Mon, 12 Jan 2015 16:37:58 +0100 From: Petr Spacek Organization: Red Hat User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Paul Wouters References: <20141027233636.24734.41333.idtracker@ietfa.amsl.com> <54B3D197.7040808@redhat.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27 Archived-At: Cc: dane@ietf.org Subject: Re: [dane] I-D Action: draft-ietf-dane-openpgpkey-01.txt: keyring format definition X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 12 Jan 2015 15:38:19 -0000 On 12.1.2015 16:06, Paul Wouters wrote: > On Mon, 12 Jan 2015, Petr Spacek wrote: > >> I would like to see a clarification for section: >> >> 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. >> >> >> I'm struggling with definition of "formatted OpenPGP public keyring". After a >> quick glance I have found only this: >> >> 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. >> >> I did not read whole RFC 4880 so it is possible that I have missed some >> related definitions but IMHO this reference deserves clarification. >> >> Where is the actual keyring format defined? > > That's it. You're looking at it. There is not a better reference that > I'm aware of. I have been looking for it myself as well. Ooooh, that is bad. I would say too bad for any implementation which wants to be interoperable. So, what do we do next? I can see three ways: 1) Write a new RFC to standardize keyring format. Is it worth the effort? I'm not sure. 2) We could move forward with some simplified single-purpose definition of keyring based on - Key Material Packet http://tools.ietf.org/html/rfc4880#section-5.5 - User ID Packet http://tools.ietf.org/html/rfc4880#section-5.11 3) Do something in between first two approaches: It seems that it should be relatively simple to define totally simple universal keyring simply as sequence of OpenPGP packets defined on: http://tools.ietf.org/html/rfc4880#section-5.5 That definition would allow us to add revocation data in future or possibly add other extensions. I assume that RFC written today would say: A application MUST ignore all packet types except A,B,C,D. Later, when a new packet format is standardized and new tag assigned to it, we can add this new tag to list of non-ignored tags (and define meaning of it) in separate RFC. -- Petr^2 Spacek From nobody Mon Jan 12 07:46: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 D60E11AC3E1 for ; Mon, 12 Jan 2015 07:46:37 -0800 (PST) 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 zgJYMZJXdICw for ; Mon, 12 Jan 2015 07:46:36 -0800 (PST) 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 AA1D11AC3EE for ; Mon, 12 Jan 2015 07:46:36 -0800 (PST) Received: from [10.20.30.90] (50-1-98-91.dsl.dynamic.fusionbroadband.com [50.1.98.91]) (authenticated bits=0) by proper.com (8.15.1/8.14.7) with ESMTPSA id t0CFkXqI091256 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 12 Jan 2015 08:46:35 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: proper.com: Host 50-1-98-91.dsl.dynamic.fusionbroadband.com [50.1.98.91] claimed to be [10.20.30.90] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Paul Hoffman In-Reply-To: <54B3EA56.3020006@redhat.com> Date: Mon, 12 Jan 2015 07:46:33 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <0EC4E535-A63A-49C3-A9F6-38B64F04D3F8@vpnc.org> References: <20141027233636.24734.41333.idtracker@ietfa.amsl.com> <54B3D197.7040808@redhat.com> <54B3EA56.3020006@redhat.com> To: Petr Spacek X-Mailer: Apple Mail (2.1993) Archived-At: Cc: Paul Wouters , dane@ietf.org Subject: Re: [dane] I-D Action: draft-ietf-dane-openpgpkey-01.txt: keyring format definition X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 12 Jan 2015 15:46:38 -0000 On Jan 12, 2015, at 7:37 AM, Petr Spacek wrote: > So, what do we do next? Discuss this on the closed but still active OpenPGP WG mailing list: = https://www.ietf.org/mailman/listinfo/openpgp --Paul Hoffman= From nobody Thu Jan 15 11:42:00 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6B2A1B320B for ; Thu, 15 Jan 2015 11:41:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.886 X-Spam-Level: ** X-Spam-Status: No, score=2.886 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FAKE_REPLY_C=1.486, J_CHICKENPOX_31=0.6] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z-qq6cbEGPJ4 for ; Thu, 15 Jan 2015 11:41:53 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 63DD21B31F8 for ; Thu, 15 Jan 2015 11:41:01 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 2E9BE284B0A; Thu, 15 Jan 2015 19:40:54 +0000 (UTC) Date: Thu, 15 Jan 2015 19:40:54 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20150115194053.GZ29286@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0DAFC2A8-A1E2-46F4-BA52-E8261CB09159@ogud.com> <54AF03FC.2020603@andyet.net> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [dane] WGLC: DANE-SRV & DANE-SMTP X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jan 2015 19:41:55 -0000 On Wed, Nov 12, 2014 at 06:09:41PM -1000, Olafur Gudmundsson wrote: > This email message starts a three week WGLC ending on December 4th at 23:59 UTC. > > http://tools.ietf.org/wg/dane/draft-ietf-dane-srv > and > https://tools.ietf.org/html/draft-ietf-dane-smtp-with-dane-13 On Thu, Jan 08, 2015 at 05:23:30PM -0500, Sean Turner wrote: > > I think you're saying that the associated revisions can be made as > > part of moving into IETF LC, and don't need further WG review? Is > > that right? But being new around here, I am not quite sure. > > Yes - let?s get this one out the door. On Thu, Jan 08, 2015 at 03:26:04PM -0700, Peter Saint-Andre - &yet wrote: > Truth be told I haven't had time to review Viktor's proposed edits yet and I > thought he was going to be posting more feedback, but if he's done then the > authors can have a chat about how to address his input. So where are we with the LC? Are we waiting for Sean to finish reading the SMTP draft? For the SRV draft authors to mull over my comments? Or just stalled for lack of momentum? -- Viktor. From nobody Thu Jan 15 14:24:58 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7EF11A904F for ; Thu, 15 Jan 2015 14:24:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.239 X-Spam-Level: ** X-Spam-Status: No, score=2.239 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_BRBL_LASTEXT=1.449, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EELyCjd_QKo3 for ; Thu, 15 Jan 2015 14:24:54 -0800 (PST) Received: from new.toad.com (new.toad.com [209.237.225.253]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (112/168 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24C251A906B for ; Thu, 15 Jan 2015 14:24:54 -0800 (PST) Received: from new.toad.com (localhost.localdomain [127.0.0.1]) by new.toad.com (8.12.9/8.12.9) with ESMTP id t0FMOoCl025516; Thu, 15 Jan 2015 14:24:50 -0800 Message-Id: <201501152224.t0FMOoCl025516@new.toad.com> To: dane@ietf.org, gnu@toad.com Date: Thu, 15 Jan 2015 14:24:50 -0800 From: John Gilmore Archived-At: Subject: [dane] Extending TLSA RFC to operate with TLS's new raw public keys X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 15 Jan 2015 22:24:56 -0000 It has been seven months since the DANE WG "adopted" my very short draft that repealed the CA-motivated anti-interoperability prohibitions in RFC 6698 and simply specified how DANE authenticates or publishes raw public keys. Therefore, the draft has expired. In the meantime, as far as I can tell, nothing has been done. All the urgency to actually solve this problem evaporated as soon as I allowed RFC 7250 to issue despite containing no text that addressed this problem. I was assured by my friend Olafur and my colleagues Warren and Stephen, the people in authority over this working group and this whole security area, that they would address the issue "ASAP" if I would just follow their recommended procedures. Yet it did not happen. I did it the way you-all recommended, and nothing got done. So the self-serving CA lobby won (delay is a win), and the NSA won (delay is a win for them too), and the public lost. Where do we go from here? John From nobody Thu Jan 15 14:49: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 1AC931A90A1 for ; Thu, 15 Jan 2015 14:49:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_20=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CtLCd-ZI9533 for ; Thu, 15 Jan 2015 14:48:58 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2EC331A9090 for ; Thu, 15 Jan 2015 14:48:58 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 1F27E284B0A; Thu, 15 Jan 2015 22:48:57 +0000 (UTC) Date: Thu, 15 Jan 2015 22:48:57 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20150115224856.GG29286@mournblade.imrryr.org> References: <201501152224.t0FMOoCl025516@new.toad.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201501152224.t0FMOoCl025516@new.toad.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [dane] Extending TLSA RFC to operate with TLS's new raw public keys 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, 15 Jan 2015 22:49:01 -0000 On Thu, Jan 15, 2015 at 02:24:50PM -0800, John Gilmore wrote: > It has been seven months since the DANE WG "adopted" my very short > draft that repealed the CA-motivated anti-interoperability > prohibitions in RFC 6698 and simply specified how DANE authenticates > or publishes raw public keys. Therefore, the draft has expired. In > the meantime, as far as I can tell, nothing has been done. The dane-ops draft in section 5.1 specifically extends the semantics of "3 1 X" to cover RPK. (The reference to the RPK draft needs to be updated to reference the published RFC). http://tools.ietf.org/html/draft-ietf-dane-ops-07#section-12 * In Section 5.1 we update [RFC6698] to specify peer identity matching and certificate validity interval based solely on the basis of the TLSA RRset. We also specify DANE authentication of raw public keys [I-D.ietf-tls-oob-pubkey] via TLSA records with Certificate Usage DANE-EE(3) and selector SPKI(1). If the text in section 5.1 of that document needs to say more, or to be phrased differently, patches (to the XML please) welcome. This group moves slowly. I wish it were otherwise, but it seems that working on DANE is nobody's day-job. > All the urgency to actually solve this problem evaporated as soon as I > allowed RFC 7250 to issue despite containing no text that addressed > this problem. I was assured by my friend Olafur and my colleagues > Warren and Stephen, the people in authority over this working group > and this whole security area, that they would address the issue "ASAP" > if I would just follow their recommended procedures. Yet it did not > happen. > > I did it the way you-all recommended, and nothing got done. So the > self-serving CA lobby won (delay is a win), and the NSA won (delay is > a win for them too), and the public lost. > > Where do we go from here? Perhaps it is time to move the OPS draft into LC, now that the SMTP and SRV drafts have had their turn. (And perhaps time to move those into IETF last call). -- Viktor. From nobody Fri Jan 16 07:27: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 542671ACDF7 for ; Fri, 16 Jan 2015 07:27:37 -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 Z_ATFUE-ZQJ4 for ; Fri, 16 Jan 2015 07:27:33 -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 57A561ACDED for ; Fri, 16 Jan 2015 07:27:33 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3kP5qQ1xDqzDQf; Fri, 16 Jan 2015 16:27:30 +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=a9ZuijKC; 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 UtjZevmfOfOu; Fri, 16 Jan 2015 16:27: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; Fri, 16 Jan 2015 16:27:28 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id E8AA78078B; Fri, 16 Jan 2015 10:27:25 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1421422046; bh=TNkNNsGw0VG+hIFbPwkxG9syLlt6bzrzwfIumSShkew=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=a9ZuijKC2tvxa/VNejjnzAQcU5RM9HTY21aqOgDeYJxo7hEL4jUYyJ4pB/7ad6PyI TwzZ2AILzREmup5hkCa+m+EWxFIjIhvlRKFkrK1PDr1+z3wmrqNd/THXUnnV2KwwNc kR/N6/bRxpZUmiMhwEFfZD9ZsRsuvSTCtomFjW6k= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id t0GFRO1n031957; Fri, 16 Jan 2015 10:27:24 -0500 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Fri, 16 Jan 2015 10:27:24 -0500 (EST) From: Paul Wouters To: dane@ietf.org In-Reply-To: <20150115224856.GG29286@mournblade.imrryr.org> Message-ID: References: <201501152224.t0FMOoCl025516@new.toad.com> <20150115224856.GG29286@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] Extending TLSA RFC to operate with TLS's new raw public keys X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 16 Jan 2015 15:27:37 -0000 On Thu, 15 Jan 2015, Viktor Dukhovni wrote: > The dane-ops draft in section 5.1 specifically extends the semantics > of "3 1 X" to cover RPK. (The reference to the RPK draft needs to > be updated to reference the published RFC). > > http://tools.ietf.org/html/draft-ietf-dane-ops-07#section-12 > > * In Section 5.1 we update [RFC6698] to specify peer identity > matching and certificate validity interval based solely on the > basis of the TLSA RRset. We also specify DANE authentication of > raw public keys [I-D.ietf-tls-oob-pubkey] via TLSA records with > Certificate Usage DANE-EE(3) and selector SPKI(1). > > If the text in section 5.1 of that document needs to say more, or > to be phrased differently, patches (to the XML please) welcome. Before I send patches, we will need a discussion, because I know you will reject the proposals I would write. The whole point of DANE-EE(3) with selector SPKI(1) was to demote _any_ X.509 material apart from the public key as legacy garbage. But people couldn't say that out loud so the wording in 6698 was done in a way to make both sides of the argument happy. As John showed, and the WG agreed to, we needed to make that more explicit. After I presented John's draft at the meeting, the consensus was these changes should be folded into this document as it already updates 6698. So instead of text stating "ignore the expiry date of the certificate", the next needed is that for DANE-EE(3) and selector SPKI(1) everything but the SPKI of the certificate should be completely ignored. In fact, RFC 7250 allows for certificates that contain nothing more than SPKI. Then, to attempt to avoid a problem with the text as it is currently in the draft, this band-aid is specified: Clients that employ DANE to authenticate the peer server SHOULD NOT negotiate the use of raw public keys unless the server's TLSA RRset includes compatible TLSA records. The only reason for this is because enough of the certificate wasn't already ignored by clients not supporting raw public keys! Also, the DANE document is not the place to specify how TLS clients with raw key support should do TLS negotiations with extensions. The only thing this document needs to state is "DANE-EE(3) and selector SPKI(1) means only look at the public key, ignore everything else" and than magically both clients that don't support raw keys but implement this document and clients that do support raw keys and implement this document, will work fine. If you agree with these points, I'm happy to submit xml updates. > Perhaps it is time to move the OPS draft into LC No. I think we need to resolve this issue first. It has been evaded for years, from the start of the work on 6698 up to this latest draft. Paul From nobody Fri Jan 16 08:47: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 A2C301ACF02 for ; Fri, 16 Jan 2015 08:47:23 -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 ExYsctOcX-04 for ; Fri, 16 Jan 2015 08:47:21 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C7431ACF54 for ; Fri, 16 Jan 2015 08:47:14 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 7D7CE284B3B; Fri, 16 Jan 2015 16:47:13 +0000 (UTC) Date: Fri, 16 Jan 2015 16:47:13 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20150116164713.GT29286@mournblade.imrryr.org> References: <201501152224.t0FMOoCl025516@new.toad.com> <20150115224856.GG29286@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] Extending TLSA RFC to operate with TLS's new raw public keys 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, 16 Jan 2015 16:47:23 -0000 On Fri, Jan 16, 2015 at 10:27:24AM -0500, Paul Wouters wrote: > >The dane-ops draft in section 5.1 specifically extends the semantics > >of "3 1 X" to cover RPK. (The reference to the RPK draft needs to > >be updated to reference the published RFC). > > > > http://tools.ietf.org/html/draft-ietf-dane-ops-07#section-12 > > > > * In Section 5.1 we update [RFC6698] to specify peer identity > > matching and certificate validity interval based solely on the > > basis of the TLSA RRset. We also specify DANE authentication of > > raw public keys [I-D.ietf-tls-oob-pubkey] via TLSA records with > > Certificate Usage DANE-EE(3) and selector SPKI(1). > > > >If the text in section 5.1 of that document needs to say more, or > >to be phrased differently, patches (to the XML please) welcome. > > Before I send patches, we will need a discussion, because I know you > will reject the proposals I would write. I'd like to think we're not likely to disagree. > The whole point of DANE-EE(3) > with selector SPKI(1) was to demote _any_ X.509 material apart from > the public key as legacy garbage. And indeed this is essentially accomplished with the SMTP and ops draft already, by requiring the validator to ignore any hostnames and expiration data in any enclosing certificate even with selector Cert(0). In Postfix, in fact everything in the certificate other than the public key is already ignored with DANE-EE(3). > But people couldn't say that out loud so the wording in 6698 was done in > a way to make both sides of the argument happy. As John showed, and the > WG agreed to, we needed to make that more explicit. After I presented > John's draft at the meeting, the consensus was these changes should be > folded into this document as it already updates 6698. I agree. > So instead of text stating "ignore the expiry date of the certificate", > the next needed is that for DANE-EE(3) and selector SPKI(1) everything > but the SPKI of the certificate should be completely ignored. In fact, > RFC 7250 allows for certificates that contain nothing more than SPKI. I agree, and I thought that the current text says essentially that, since by allowing RPK we're effectively saying that nothing else matters. A leaf certificate matched via "3 1 X" is simply a less space efficient format for RPK. I paved the way for this with the SMTP and OPS drafts, getting the initial consensus on the hostname and expiration bits, but my argument to ignore *everything* else (though it was also for Cert(0)), ran into some opposition, so I settled for what's essential to the operational success of DANE with SMTP. > Then, to attempt to avoid a problem with the text as it is currently > in the draft, this band-aid is specified: > > Clients that employ DANE to > authenticate the peer server SHOULD NOT negotiate the use of raw > public keys unless the server's TLSA RRset includes compatible TLSA > records. Naturally enough, if the server's TLSA RRs is, e.g., "IN 2 0 1 " it would be rather unwise to propose RPK in the TLSA handshake, since that'll lead to DANE verification failure. However, if the server publishes at least some "IN TLSA 3 1 X" record, then one can offer to negotiate RPK. > The only reason for this is because enough of the certificate wasn't > already ignored by clients not supporting raw public keys! No. The reason is to avoid negotiating non-interoperable parameters. > Also, the DANE document is not the place to specify how TLS clients > with raw key support should do TLS negotiations with extensions. The DANE document is the place where one can specify how RPK interacts with DANE. We're talking about extending 6698 to cover use of "3 1 X" records with RPK. Paul, I really am going to agree with you on the technical points. I sense only a conflict where you seem to believe that I'll be opposed to RPK, but I'm not. I fully support extending DANE-EE(3) with SPKI(1) to interoperate with RPK. > The only thing this document needs to state is "DANE-EE(3) and selector > SPKI(1) means only look at the public key, ignore everything else" and > than magically both clients that don't support raw keys but implement > this document and clients that do support raw keys and implement this > document, will work fine. It is also I think appropriate to say (and the document attempts to do so) that when authentication is going to be DANE-based, faced with a TLSA RRset that does not include any "3 1 X" records, RPK would be unwise, but when "3 1 X" RRs are published, one can safely offer to negotiate RPK. There are then considerations for key rotation, as servers moving from "3 1 X" to "2 0 1" should ensure that their "3 1 X" records still match reality during the transition. See https://tools.ietf.org/html/draft-ietf-dane-ops-07#section-8.2 > If you agree with these points, I'm happy to submit xml updates. I see little substantive disagreement. Unless you are adamant that the document should be silent on when a DANE client should avoid RPK for lack of compatible TLSA records. > >Perhaps it is time to move the OPS draft into LC > > No. I think we need to resolve this issue first. It has been evaded for > years, from the start of the work on 6698 up to this latest draft. Sometimes LC is the only way to get meaninglful discussion, but I am quite open to such discussion before, during or after WG LC. And I think we are in violent agreement, and the only thing between us is just some residual heat from the embers of "Opportunistic Security" fire. A few beers might solve that, but sadly I am not planning to be at IETF Dallas. If you're ever in NYC, look me up. -- Viktor. From nobody Fri Jan 16 21:56: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 5BB7A1A9163 for ; Fri, 16 Jan 2015 21:56:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s4mH4TMrqZqu for ; Fri, 16 Jan 2015 21:56:44 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0BF141A9145 for ; Fri, 16 Jan 2015 21:56:43 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 3A9B2284B0A; Sat, 17 Jan 2015 05:56:42 +0000 (UTC) Date: Sat, 17 Jan 2015 05:56:42 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20150117055642.GP29286@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: [dane] icann.org DANE SMTP? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Jan 2015 05:56:46 -0000 Anyone have appropriate contacts at icann.org to encourage them to dogfood DANE TLSA RRs for their SMTP servers? A quick scan of the DNS and MX hosts shows that icann.org and all its MX hosts (A/AAAA records) are DNSSEC validated, but none of the MX hosts offer STARTTLS: icann.org. IN MX 10 pechora1.icann.org. ; NOERROR AD=1 pechora1.icann.org. IN A 192.0.33.71 ; smtperr: STARTTLS not offered pechora1.icann.org. IN AAAA 2620:0:2d0:201:0:0:1:71 ; smtperr: STARTTLS not offered icann.org. IN MX 10 pechora3.icann.org. ; NOERROR AD=1 pechora3.icann.org. IN A 192.0.33.73 ; smtperr: STARTTLS not offered pechora3.icann.org. IN AAAA 2620:0:2d0:201:0:0:1:73 ; smtperr: STARTTLS not offered icann.org. IN MX 10 pechora4.icann.org. ; NOERROR AD=1 pechora4.icann.org. IN A 192.0.33.74 ; smtperr: STARTTLS not offered pechora4.icann.org. IN AAAA 2620:0:2d0:201:0:0:1:74 ; smtperr: STARTTLS not offered icann.org. IN MX 10 pechora5.icann.org. ; NOERROR AD=1 pechora5.icann.org. IN A 192.0.46.71 ; smtperr: STARTTLS not offered pechora5.icann.org. IN AAAA 2620:0:2830:201:0:0:1:71 ; smtperr: STARTTLS not offered icann.org. IN MX 10 pechora7.icann.org. ; NOERROR AD=1 pechora7.icann.org. IN A 192.0.46.73 ; smtperr: STARTTLS not offered pechora7.icann.org. IN AAAA 2620:0:2830:201:0:0:1:73 ; smtperr: STARTTLS not offered icann.org. IN MX 10 pechora8.icann.org. ; NOERROR AD=1 pechora8.icann.org. IN A 192.0.46.74 ; smtperr: STARTTLS not offered pechora8.icann.org. IN AAAA 2620:0:2830:201:0:0:1:74 ; smtperr: STARTTLS not offered Sure looks like Sendmail with STARTTLS not enabled: posttls-finger: Connected to pechora1.icann.org[192.0.33.71]:25 posttls-finger: < 220 pechora1.lax.icann.org ESMTP Sendmail 8.13.8/8.13.8; Sat, 17 Jan 2015 05:48:31 GMT posttls-finger: > EHLO amnesiac.local posttls-finger: < 250-pechora1.lax.icann.org Hello amnesiac.local [192.0.2.1], pleased to meet you posttls-finger: < 250-ENHANCEDSTATUSCODES posttls-finger: < 250-PIPELINING posttls-finger: < 250-8BITMIME posttls-finger: < 250-SIZE posttls-finger: < 250-DSN posttls-finger: < 250-ETRN posttls-finger: < 250-DELIVERBY posttls-finger: < 250 HELP posttls-finger: > QUIT posttls-finger: < 221 2.0.0 pechora1.lax.icann.org closing connection all they have to do is enable STARTTLS and publish TLSA RRs. Either some suitable DANE-TA(2) trust-anchor with CNAMEs for each host's TLSA RRset to a shared location where the trust-anchor IN TLSA DANE-TA(2) Cert(0) SHA2-256(1) TLSA RRset is defined, or a different self-signed certificate for each MX host with per-host IN TLSA DANE-EE(3) SPKI(1) SHA2-256(1) records. We got there for ietf.org, and I think icann.org should set a similar example. People reasonably seem to expect them to, based on frequent tests for icann.org at https://dane.sys4.de/ Do what you say and all that... -- Viktor. From nobody Sun Jan 18 19:20: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 8DF681AD06C for ; Sun, 18 Jan 2015 19:20:42 -0800 (PST) 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 06KUjnc36kN0 for ; Sun, 18 Jan 2015 19:20:40 -0800 (PST) Received: from out.west.pexch112.icann.org (pfe112-ca-1.pexch112.icann.org [64.78.40.7]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 351011AD06B for ; Sun, 18 Jan 2015 19:20:40 -0800 (PST) Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) with Microsoft SMTP Server (TLS) id 15.0.847.32; Sun, 18 Jan 2015 19:20:37 -0800 Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.0847.030; Sun, 18 Jan 2015 19:20:37 -0800 From: Terry Manderson To: "dane@ietf.org" Thread-Topic: [dane] icann.org DANE SMTP? Thread-Index: AQHQMhpvpu+7Kgeoi0CIe5U62rhhNpzH91GA Date: Mon, 19 Jan 2015 03:20:37 +0000 Message-ID: References: <20150117055642.GP29286@mournblade.imrryr.org> In-Reply-To: <20150117055642.GP29286@mournblade.imrryr.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.7.141117 x-originating-ip: [192.0.32.234] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3504518435_90160612" MIME-Version: 1.0 Archived-At: Subject: Re: [dane] icann.org DANE SMTP? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jan 2015 03:20:42 -0000 --B_3504518435_90160612 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Hi Viktor, Thanks for the nudge. There are certainly ICANN people on this mailing list, including myself. I (while wearing the ICANN org hat) have responsibility for the engineering department that is tasked with the domain portfolio in ICANN and the infrastructure which DNSSEC signs and serves it. We have had this discussion internally to ICANN, in fact we had it last year, and we have every intention to do this. (The SMTP part is another team, but they have also concurred and are willing to also 'walk the walk') Our path to get there is currently dependent on an upgrade of our DNSSEC signing infrastructure (that also entails a move of datacenters). So please hang in there while we reconstruct some secure cages, ship some rather heavy safes, and commission new HSMs.. Please watch this space, and if you like I will post back here when we have both the RRs in and STARTTLS enabled. Cheers Terry On 17/01/2015 3:56 pm, "Viktor Dukhovni" wrote: >Anyone have appropriate contacts at icann.org to encourage them >to dogfood DANE TLSA RRs for their SMTP servers? > >A quick scan of the DNS and MX hosts shows that icann.org and all >its MX hosts (A/AAAA records) are DNSSEC validated, but none of >the MX hosts offer STARTTLS: > > icann.org. IN MX 10 pechora1.icann.org. ; NOERROR AD=1 > pechora1.icann.org. IN A 192.0.33.71 ; smtperr: STARTTLS not offered > pechora1.icann.org. IN AAAA 2620:0:2d0:201:0:0:1:71 ; smtperr: >STARTTLS not offered > icann.org. IN MX 10 pechora3.icann.org. ; NOERROR AD=1 > pechora3.icann.org. IN A 192.0.33.73 ; smtperr: STARTTLS not offered > pechora3.icann.org. IN AAAA 2620:0:2d0:201:0:0:1:73 ; smtperr: >STARTTLS not offered > icann.org. IN MX 10 pechora4.icann.org. ; NOERROR AD=1 > pechora4.icann.org. IN A 192.0.33.74 ; smtperr: STARTTLS not offered > pechora4.icann.org. IN AAAA 2620:0:2d0:201:0:0:1:74 ; smtperr: >STARTTLS not offered > icann.org. IN MX 10 pechora5.icann.org. ; NOERROR AD=1 > pechora5.icann.org. IN A 192.0.46.71 ; smtperr: STARTTLS not offered > pechora5.icann.org. IN AAAA 2620:0:2830:201:0:0:1:71 ; smtperr: >STARTTLS not offered > icann.org. IN MX 10 pechora7.icann.org. ; NOERROR AD=1 > pechora7.icann.org. IN A 192.0.46.73 ; smtperr: STARTTLS not offered > pechora7.icann.org. IN AAAA 2620:0:2830:201:0:0:1:73 ; smtperr: >STARTTLS not offered > icann.org. IN MX 10 pechora8.icann.org. ; NOERROR AD=1 > pechora8.icann.org. IN A 192.0.46.74 ; smtperr: STARTTLS not offered > pechora8.icann.org. IN AAAA 2620:0:2830:201:0:0:1:74 ; smtperr: >STARTTLS not offered > >Sure looks like Sendmail with STARTTLS not enabled: > > posttls-finger: Connected to pechora1.icann.org[192.0.33.71]:25 > posttls-finger: < 220 pechora1.lax.icann.org ESMTP Sendmail >8.13.8/8.13.8; Sat, 17 Jan 2015 05:48:31 GMT > posttls-finger: > EHLO amnesiac.local > posttls-finger: < 250-pechora1.lax.icann.org Hello amnesiac.local >[192.0.2.1], pleased to meet you > posttls-finger: < 250-ENHANCEDSTATUSCODES > posttls-finger: < 250-PIPELINING > posttls-finger: < 250-8BITMIME > posttls-finger: < 250-SIZE > posttls-finger: < 250-DSN > posttls-finger: < 250-ETRN > posttls-finger: < 250-DELIVERBY > posttls-finger: < 250 HELP > posttls-finger: > QUIT > posttls-finger: < 221 2.0.0 pechora1.lax.icann.org closing connection > >all they have to do is enable STARTTLS and publish TLSA RRs. Either >some suitable DANE-TA(2) trust-anchor with CNAMEs for each host's >TLSA RRset to a shared location where the trust-anchor > > IN TLSA DANE-TA(2) Cert(0) SHA2-256(1) > >TLSA RRset is defined, or a different self-signed certificate for >each MX host with per-host > > IN TLSA DANE-EE(3) SPKI(1) SHA2-256(1) > >records. We got there for ietf.org, and I think icann.org should >set a similar example. People reasonably seem to expect them to, >based on frequent tests for icann.org at https://dane.sys4.de/ > >Do what you say and all that... > >-- > Viktor. > >_______________________________________________ >dane mailing list >dane@ietf.org >https://www.ietf.org/mailman/listinfo/dane --B_3504518435_90160612 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIITvAYJKoZIhvcNAQcCoIITrTCCE6kCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC EYgwggcDMIIF66ADAgECAhAPz2lJUZsAlD35l4oJxf0FMA0GCSqGSIb3DQEBBQUAMGIxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2Vy dC5jb20xITAfBgNVBAMTGERpZ2lDZXJ0IEFzc3VyZWQgSUQgQ0EtMTAeFw0xMjAzMjcwMDAw MDBaFw0xNTAzMjcxMjAwMDBaMIGsMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5p YTEXMBUGA1UEBxMOTWFyaW5hIGRlbCBSZXkxPDA6BgNVBAoTM0ludGVybmV0IENvcnBvcmF0 aW9uIGZvciBBc3NpZ25lZCBOYW1lcyBhbmQgTnVtYmVyczEXMBUGA1UECxMORE5TIE9wZXJh dGlvbnMxGDAWBgNVBAMTD1RlcnJ5IE1hbmRlcnNvbjCCASIwDQYJKoZIhvcNAQEBBQADggEP ADCCAQoCggEBAKRhZ4W3U6MnfS2woYEFCIyN+g1MNILokbUKk+PTl5mmK3QtWQxTSOu2sdzN xHMy6p2RoT9BMGOamttFq2WswSru6/7JT1TflytGaPHfK5kMP/pI47hmcwUEm9Z169I5ar7z BTiEAQA06cGKtgJ8XiiLFUIHLVuRq3WGxjnFTHlAHXY6mdgDT/ntAnoEvvPVm4XqUnjJiZTS ojzyr1q2RqFvyXs2blOARumDqvLI33yLGcUuaEL+A+hgodzM/fL4kdoy964mXvmEerpm4d4f Y/JfbRUWxc0Eomu9nwGFNk6ijO41qk+OIboct2qeA+5PPclXJNNHYVfzT2dyWfGgxaMCAwEA AaOCA2gwggNkMB8GA1UdIwQYMBaAFBUAEisTmLKZB+0e36K+Vw0rZwLNMB0GA1UdDgQWBBSz wvR2YXpP9XjS9cknMX5g3LM2jTAkBgNVHREEHTAbgRl0ZXJyeS5tYW5kZXJzb25AaWNhbm4u b3JnMA4GA1UdDwEB/wQEAwIFoDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwfQYD VR0fBHYwdDA4oDagNIYyaHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0QXNzdXJl ZElEQ0EtMS5jcmwwOKA2oDSGMmh0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFz c3VyZWRJRENBLTEuY3JsMIIBxQYDVR0gBIIBvDCCAbgwggG0BgpghkgBhv1sBAECMIIBpDA6 BggrBgEFBQcCARYuaHR0cDovL3d3dy5kaWdpY2VydC5jb20vc3NsLWNwcy1yZXBvc2l0b3J5 Lmh0bTCCAWQGCCsGAQUFBwICMIIBVh6CAVIAQQBuAHkAIAB1AHMAZQAgAG8AZgAgAHQAaABp AHMAIABDAGUAcgB0AGkAZgBpAGMAYQB0AGUAIABjAG8AbgBzAHQAaQB0AHUAdABlAHMAIABh AGMAYwBlAHAAdABhAG4AYwBlACAAbwBmACAAdABoAGUAIABEAGkAZwBpAEMAZQByAHQAIABD AFAALwBDAFAAUwAgAGEAbgBkACAAdABoAGUAIABSAGUAbAB5AGkAbgBnACAAUABhAHIAdAB5 ACAAQQBnAHIAZQBlAG0AZQBuAHQAIAB3AGgAaQBjAGgAIABsAGkAbQBpAHQAIABsAGkAYQBi AGkAbABpAHQAeQAgAGEAbgBkACAAYQByAGUAIABpAG4AYwBvAHIAcABvAHIAYQB0AGUAZAAg AGgAZQByAGUAaQBuACAAYgB5ACAAcgBlAGYAZQByAGUAbgBjAGUALjB3BggrBgEFBQcBAQRr MGkwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0LmNvbTBBBggrBgEFBQcwAoY1 aHR0cDovL2NhY2VydHMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0QXNzdXJlZElEQ0EtMS5jcnQw DAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOCAQEAYpwxK/KvdhbyQqrKp2ylMQpNzqVH ofo4hPILTnp/o+UyYVn6daWSilaV+XNBzE5Rm/f7ms2iA1zBzOvGv55pLH0n6lgIRTeuAGzf KIsPCwPvYQkkMAPXHzh9A44m19hvigTgOPNyjzcOTiHqwwCJSDTEZx17CEkrzQPq1vfG1Lvk +AWjEtxCsGmsuCHHaZjwQ8SsGI7W5cA1Y4RTcQf6S9eIpSsOwXIYdDgWq9Uhi/amW7ryW06Y GH7BHaitqgmm32MZuid3UzJUU6+Ljx7uGA9Fe6k1uPEHhaXTAoobPSpPdOgGmnxUCRQu2OI7 +I8vHiSe7DC/LmxEDC5kB+lUTjCCBsIwggWqoAMCAQICEAoE3yF0XU0rjOozcgUAUOkwDQYJ KoZIhvcNAQEFBQAwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcG A1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBS b290IENBMB4XDTA2MTExMDAwMDAwMFoXDTIxMTExMDAwMDAwMFowYjELMAkGA1UEBhMCVVMx FTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEhMB8G A1UEAxMYRGlnaUNlcnQgQXNzdXJlZCBJRCBDQS0xMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEA6IItmfnKwkKVpYBzQHDSnlZUXKnE0kEGj8kz/E1FkVyBn+0snPgWWd+etSQV wpi5tHdJ3InECtqvy15r7a2wcTHrzzpADEZNk+yLejYIA6sMNP4YSYL+x8cxSIB8HqIPkg5Q ycaH6zY/2DDD/6b3+6LNb3Mj/qxWBZDwMiEWicZwiPkFl32jx0PdAug7Pe2xQaPtP77blUjE 7h6z8rwMK5nQxl0SQoHhg26Ccz8mSxSQrllmCsSNvtLOBq6thG9IhJtPQLnxTPKvmPv2zkBd XPao8S+v7Iki8msYZbHBc63X8djPHgp0XEK4aH631XcKJ1Z8D2KkPzIUYJX9BwSiCQIDAQAB o4IDbzCCA2swDgYDVR0PAQH/BAQDAgGGMDsGA1UdJQQ0MDIGCCsGAQUFBwMBBggrBgEFBQcD AgYIKwYBBQUHAwMGCCsGAQUFBwMEBggrBgEFBQcDCDCCAcYGA1UdIASCAb0wggG5MIIBtQYL YIZIAYb9bAEDAAQwggGkMDoGCCsGAQUFBwIBFi5odHRwOi8vd3d3LmRpZ2ljZXJ0LmNvbS9z c2wtY3BzLXJlcG9zaXRvcnkuaHRtMIIBZAYIKwYBBQUHAgIwggFWHoIBUgBBAG4AeQAgAHUA cwBlACAAbwBmACAAdABoAGkAcwAgAEMAZQByAHQAaQBmAGkAYwBhAHQAZQAgAGMAbwBuAHMA dABpAHQAdQB0AGUAcwAgAGEAYwBjAGUAcAB0AGEAbgBjAGUAIABvAGYAIAB0AGgAZQAgAEQA aQBnAGkAQwBlAHIAdAAgAEMAUAAvAEMAUABTACAAYQBuAGQAIAB0AGgAZQAgAFIAZQBsAHkA aQBuAGcAIABQAGEAcgB0AHkAIABBAGcAcgBlAGUAbQBlAG4AdAAgAHcAaABpAGMAaAAgAGwA aQBtAGkAdAAgAGwAaQBhAGIAaQBsAGkAdAB5ACAAYQBuAGQAIABhAHIAZQAgAGkAbgBjAG8A cgBwAG8AcgBhAHQAZQBkACAAaABlAHIAZQBpAG4AIABiAHkAIAByAGUAZgBlAHIAZQBuAGMA ZQAuMA8GA1UdEwEB/wQFMAMBAf8wfQYIKwYBBQUHAQEEcTBvMCQGCCsGAQUFBzABhhhodHRw Oi8vb2NzcC5kaWdpY2VydC5jb20wRwYIKwYBBQUHMAKGO2h0dHA6Ly93d3cuZGlnaWNlcnQu Y29tL0NBQ2VydHMvRGlnaUNlcnRBc3N1cmVkSURSb290Q0EuY3J0MIGBBgNVHR8EejB4MDqg OKA2hjRodHRwOi8vY3JsMy5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURSb290Q0Eu Y3JsMDqgOKA2hjRodHRwOi8vY3JsNC5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURS b290Q0EuY3JsMB0GA1UdDgQWBBQVABIrE5iymQftHt+ivlcNK2cCzTAfBgNVHSMEGDAWgBRF 66Kv9JLLgjEtUYunpyGd823IDzANBgkqhkiG9w0BAQUFAAOCAQEAhGFOQR64dgQqtbbvj/JV hbldVv4KmObkvWWKfUAp0/yxXUX9OrgqWzNLJFzNubTkc61hXXatdDOKZtUjr0wfcm5F2XVA u6I7z41JL8BBsOIpo1E4Q1CZFKwzBjViiX13qVIH5WwgV7aBum+8s8KU7XYCgNl8zoWoHOzH Q0pLsVfPcs7f9SU8yyJP/Z9S0TfLCLs4PuDVPm95Ca1bfDGzdzXD5GP5aAqYB+dGOHeE0j6X vAqgqKwlT0RukeHSWq9r7zAcjaNEQrMQiyP61+Y1dDesz+urWB/JiCP/NtQH6jRqR+qdlWye KU9T7eMrlSBOKs+WYHr4LIDwlVLOKZaBYjCCA7cwggKfoAMCAQICEAzn4OUX2Eb+j+Vg/Bvw MDkwDQYJKoZIhvcNAQEFBQAwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IElu YzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJl ZCBJRCBSb290IENBMB4XDTA2MTExMDAwMDAwMFoXDTMxMTExMDAwMDAwMFowZTELMAkGA1UE BhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNv bTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEArQ4VzuRDgFyxh/O3YPlxEqWu3CaUiKr0zvUgOShYYAz4gNqp FZUyYTy1sSiEiorcnwoMgxd6j5Csiud5U1wxhCr2D5gyNnbM3t08qKLvavsh8lJh358g1x/i sdn+GGTSEltf+VgYNbxHzaE2+Wt/1LA4PsEbw4wz2dgvGP4oD7Ong9bDbkTAYTWWFv5ZnIt2 bdfxoksNK/8LctqeYNCOkDXGeFWHIKHP5W0KyEl8MZgzbCLph9AyWqK6E4IR7TkXnZk6cqHm +qTZ1Rcxda6FfSKuPwFGhvYoecix2uRXF8R+HA6wtJKmVrO9spftqqfwt8WoP5UW0P+hlusI Xxh3TwIDAQABo2MwYTAOBgNVHQ8BAf8EBAMCAYYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4E FgQUReuir/SSy4IxLVGLp6chnfNtyA8wHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNt yA8wDQYJKoZIhvcNAQEFBQADggEBAKIOvN/i7fDjcnN6ZJS/93Jm2DLkQnVirofr8tXZ3laz n8zOFCi5DZdgXBJMWOTTPYNJRViXNWkaqEfqVsZ5qxLYZ4GE338JPJTmuCYsIL09syiJ91// IuKXhB/pZe+H4N/BZ0mzXeuyCSrrJu14vn0/K/O3JjVtX4kBtklbnwEFm6s9JcHMtn/C8W+G xvpkaOuBLZTrQrf6jB7dYvG+UGe3bL3z8R9rDDYHFn83fKlbbXrxEkZgg9cnBL5Lzpe+w2cq aBHfgOcMM2a/Ew0UbvN/H2MQHvqNGyVtbI+lt2EBsdKjJqEQcZ2t4sP5w5lRtysHCM4u5lCy p/oKRS+i8PIxggH8MIIB+AIBATB2MGIxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2Vy dCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xITAfBgNVBAMTGERpZ2lDZXJ0IEFz c3VyZWQgSUQgQ0EtMQIQD89pSVGbAJQ9+ZeKCcX9BTAJBgUrDgMCGgUAoF0wIwYJKoZIhvcN AQkEMRYEFMNsQVtrqpvJRUus63LuHM9WW6rzMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTE1MDExOTAzMjAzNVowDQYJKoZIhvcNAQEBBQAEggEAejBH8nS7 KYlAv6jhjweKlUzmTvyXrE1VhpFowTfXP97eu8Cx2PZRLlc95EhAPrJ5CKSTrcrvayfE7lwT zCOr86XooPtkZlJ8VQxn/DdxHMC0LXziU8StEQMT1PBiC56zIKQOkpvXbs61GYmh28E1iYCo jh7PRuhvGP4nh3b6gaE+y2M6xZ1dx9AQhag7DgPYsV7Z4MBRsuj/CnpBRiiAKmulWBXoTT2U sP04tGT7b7uKG2z0PYwoFu52W3pIUpgqqzrhPFDd1G3sbK96f7eDr4c234eKsE5Kqh8goD47 hBOszDPPhjd6swgGjCE0Md51DA4NhAYKAa8VkgdyNiVVfQ== --B_3504518435_90160612-- From nobody Thu Jan 22 13:23:46 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F0481B2A4E for ; Thu, 22 Jan 2015 13:23:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.567 X-Spam-Level: X-Spam-Status: No, score=-0.567 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FSL_HELO_BARE_IP_2=1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, 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 2P8uo34gykQw for ; Thu, 22 Jan 2015 13:23:39 -0800 (PST) Received: from gateway11.websitewelcome.com (gateway11.websitewelcome.com [67.18.94.11]) (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 EEB2A1B2A4B for ; Thu, 22 Jan 2015 13:23:38 -0800 (PST) Received: by gateway11.websitewelcome.com (Postfix, from userid 500) id 663128B6BF165; Thu, 22 Jan 2015 15:23:38 -0600 (CST) Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway11.websitewelcome.com (Postfix) with ESMTP id 520D58B6BF142 for ; Thu, 22 Jan 2015 15:23:38 -0600 (CST) Received: from [96.231.226.60] (port=51273 helo=192.168.1.2) by gator3286.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1YEPE1-0004wb-Op for dane@ietf.org; Thu, 22 Jan 2015 15:23:37 -0600 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Sean Turner In-Reply-To: <0DAFC2A8-A1E2-46F4-BA52-E8261CB09159@ogud.com> Date: Thu, 22 Jan 2015 16:23:36 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <9DEDC923-8B03-4AF7-82FF-60C96C614641@ieca.com> References: <0DAFC2A8-A1E2-46F4-BA52-E8261CB09159@ogud.com> To: "" X-Mailer: Apple Mail (2.1878.6) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator3286.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source-IP: 96.231.226.60 X-Exim-ID: 1YEPE1-0004wb-Op X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (192.168.1.2) [96.231.226.60]:51273 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 1 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20= Archived-At: Subject: Re: [dane] WGLC: DANE-SRV & DANE-SMTP X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jan 2015 21:23:42 -0000 On Nov 12, 2014, at 23:09, Olafur Gudmundsson wrote: > Dear wg members >=20 > This email message starts a three week WGLC ending on December 4=92th = at 23:59 UTC.=20 > https://tools.ietf.org/html/draft-ietf-dane-smtp-with-dane-13 >=20 > These two document are specifying related uses of DANE.=20 > Please review the documents carefully, in particular we want to make = sure the documents have no=20 > contradictions.=20 >=20 Apologies again for being late. Here are my comments on the DANE SMTP = draft. Though pretty dense, I think this is a well written document = that does a good job explaining why you might want to deploy this as = well as how to deploy it. Got one major (procedural thing) but the rest = are editorial: This is procedural but I guess it=92s major: Am I right that this draft is using the new definition for DANE-EE that = is documented in draft-ietf-dane-ops? Don=92t we have to wait for it to = update RFC 6698 or does this specification have to indicate that it = updates RFC 6698? Nits: 0) s1.1, delayed delivery: r/When an MTA is unable forward/When an MTA = is to unable forward 1) s1.1, delayed delivery: Might be good to have a forward reference to = =93mandatory DANE TLS=94 in the later section or add it as a definition = in s1.1. 2) s1.1: Couldn=92t hurt to have informative references to DNS RR and = RRSet. 3) s1.2: r/Certificate Authority/Certification Authority 4) s1.3.2: r/and requiring/and require 5) s1.3.3: What I think you=92re trying to say here: Sending systems are in some cases explicitly configured to use TLS for mail sent to selected peer domains. This requires sending MTAs to be configured with appropriate subject names or certificate content digests to expect in the presented server certificates. is this: Sending systems are in some cases explicitly configured to use TLS for mail sent to selected peer domains, but this requires configuring sending MTAs with appropriate subject names or certificate content digests from their peer domains. 6) s2.1.3: I think if we=92re going to have a =93MUST NOT=94 for = something it=92s probably worth a pointer to the definition in RFC 4033 = for "Security-Oblivious stub-resolvers=94 or add it to s1.1 and point to = RFC 4033. 7) s2.2.1: The text about MAT delivery logs made me wonder where the = rest of the normative behavior is for MTA delivery logs and whether this = text is updating that text. 8) s3.1: Should this be "RECOMMEND": In summary, we recommend the use of either "DANE-EE(3) SPKI(1) SHA2-256(1)" or "DANE-TA(2) Cert(0) SHA2-256(1)" TLSA records depending on site needs. 9) s3.1: Maybe reword: The mandatory to support digest algorithm in [RFC6698] is SHA2-256(1) to:=20 As specified in [RFC6698], the mandatory to implement digest algorithm is SHA2-256(1). 10) s3.2.3: r/must be entire/must be the entire=20= From nobody Thu Jan 22 14:09: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 B20341A87A5 for ; Thu, 22 Jan 2015 14:09:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_61=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 yjTZ2bS1DYRV for ; Thu, 22 Jan 2015 14:09:03 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 821CE1A87F1 for ; Thu, 22 Jan 2015 14:09:03 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 55039284B3D; Thu, 22 Jan 2015 22:08:56 +0000 (UTC) Date: Thu, 22 Jan 2015 22:08:56 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20150122220856.GJ8034@mournblade.imrryr.org> References: <0DAFC2A8-A1E2-46F4-BA52-E8261CB09159@ogud.com> <9DEDC923-8B03-4AF7-82FF-60C96C614641@ieca.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9DEDC923-8B03-4AF7-82FF-60C96C614641@ieca.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [dane] WGLC: DANE-SRV & DANE-SMTP X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jan 2015 22:09:07 -0000 On Thu, Jan 22, 2015 at 04:23:36PM -0500, Sean Turner wrote: > This is procedural but I guess it's major: > > Am I right that this draft is using the new definition for DANE-EE > that is documented in draft-ietf-dane-ops? Don't we have to wait > for it to update RFC 6698 or does this specification have to indicate > that it updates RFC 6698? Indeed the semantics of DANE-EE(3) are the same in both the ops and smtp-with-dane drafts. The ops draft ammends the semantics for all use-cases of the TLSA record by updating 6698. The smtp-with-dane draft makes the same change only for opportunistic DANE TLS used in MTA to MTA SMTP. The history is that the decision to turn the ops draft into a 6698 update happened rather late, and until that time, only the smtp draft had the requisite normative language. I don't know to best deal with this procedurally. One might say that both drafts update 6698, or that only the ops draft does that, and the smtp draft applies just narrowly to the protocol at hand. I don't have any views on the logistics. > 0) s1.1, delayed delivery: r/When an MTA is unable forward/When an MTA is to unable forward Muphry bites, but I know what you mean thanks. > 1) s1.1, delayed delivery: Might be good to have a forward > reference to "mandatory DANE TLS" in the later section or add it > as a definition in s1.1. I'll add a forward reference, unless there is good reason to extend the terminology. > 2) s1.1: Couldn?t hurt to have informative references to DNS RR and RRSet. Sure. > 3) s1.2: r/Certificate Authority/Certification Authority Indeed, I thought I fixed all of those... > 4) s1.3.2: r/and requiring/and require This is a rather long sentence, but its high level structure is: One might try to ... by using ... and requiring ... So I think that "requiring" agrees better with the preceding parts. It might be clearer with an extra "by": One might try to ... by using ... and by requiring ... Or a rewrite of the whole sentence. > 5) s1.3.3: What I think you're trying to say here: > > Sending systems are in some cases explicitly configured to use TLS > for mail sent to selected peer domains. This requires sending MTAs > to be configured with appropriate subject names or certificate > content digests to expect in the presented server certificates. > > is this: > > Sending systems are in some cases explicitly configured to use TLS > for mail sent to selected peer domains, but this requires configuring > sending MTAs with appropriate subject names or certificate > content digests from their peer domains. These looks largely the same to me, your version is fine too. > 6) s2.1.3: I think if we're going to have a "MUST NOT" for > something it's probably worth a pointer to the definition in RFC > 4033 for "Security-Oblivious stub-resolvers? or add it to s1.1 and > point to RFC 4033. Makese sense. The larger question is whether this is really the right place for a MUST NOT. If the client gets this wrong it is insecure (never sees any "secure" domains and never uses DANE), but it is still interoperable. What's the right way to tell clients that they don't get any security if their recursor is oblivious? > 7) s2.2.1: The text about MTA delivery logs made me wonder where > the rest of the normative behavior is for MTA delivery logs and > whether this text is updating that text. I don't think there is any such text anywhere else. The closest you'll find is "no misrepresentation of security" in RFC 7435 (opportunistic security) of which this is an instance. > 8) s3.1: Should this be "RECOMMEND": > > In summary, we recommend the use of either "DANE-EE(3) SPKI(1) > SHA2-256(1)" or "DANE-TA(2) Cert(0) SHA2-256(1)" TLSA records > depending on site needs. Sure, if there are no objections. > 9) s3.1: Maybe reword: > > The mandatory to support digest algorithm in [RFC6698] is > SHA2-256(1) > > to: > > As specified in [RFC6698], the mandatory to implement digest > algorithm is SHA2-256(1). Yes. > 10) s3.2.3: r/must be entire/must be the entire Yes. When should the suggested changes be made? -- Viktor. From nobody Thu Jan 22 20:19: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 D42B81A0143 for ; Thu, 22 Jan 2015 20:19:35 -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 7IW8b40ZrJDW for ; Thu, 22 Jan 2015 20:19:34 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E86511A0141 for ; Thu, 22 Jan 2015 20:19:33 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 23A8F282CC8; Fri, 23 Jan 2015 04:19:31 +0000 (UTC) Date: Fri, 23 Jan 2015 04:19:31 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20150123041930.GN8034@mournblade.imrryr.org> References: <0DAFC2A8-A1E2-46F4-BA52-E8261CB09159@ogud.com> <9DEDC923-8B03-4AF7-82FF-60C96C614641@ieca.com> <20150122220856.GJ8034@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150122220856.GJ8034@mournblade.imrryr.org> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [dane] WGLC: DANE-SRV & DANE-SMTP X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jan 2015 04:19:36 -0000 On Thu, Jan 22, 2015 at 10:08:56PM +0000, Viktor Dukhovni wrote: > When should the suggested changes be made? Whether the requested changes need a -14 version as part of WG LC or will be reviewed as part of IETF LC, they are available for review at: https://github.com/vdukhovni/ietf/commit/287ca65902e0085648f126bb6d8f59124dcf463d Nothing has been changed in relation to the DANE-EE(3) redefinition procedural question. -- Viktor. From nobody Sat Jan 24 13:24: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 C852A1A007B for ; Sat, 24 Jan 2015 13:24:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.799 X-Spam-Level: X-Spam-Status: No, score=0.799 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KkTVeydEveUn for ; Sat, 24 Jan 2015 13:24:21 -0800 (PST) Received: from smtp76.ord1c.emailsrvr.com (smtp76.ord1c.emailsrvr.com [108.166.43.76]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B78BF1A007A for ; Sat, 24 Jan 2015 13:24:21 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp2.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id 27810180205 for ; Sat, 24 Jan 2015 16:24:21 -0500 (EST) X-Virus-Scanned: OK Received: by smtp2.relay.ord1c.emailsrvr.com (Authenticated sender: ogud-AT-ogud.com) with ESMTPSA id E8C40180115 for ; Sat, 24 Jan 2015 16:24:20 -0500 (EST) X-Sender-Id: ogud@ogud.com Received: from [10.20.30.43] (pool-74-96-189-180.washdc.fios.verizon.net [74.96.189.180]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:587 (trex/5.4.2); Sat, 24 Jan 2015 21:24:21 GMT From: Olafur Gudmundsson Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <2772BE49-FDEC-4C33-AFE8-33E66B6ABBCF@ogud.com> Date: Sat, 24 Jan 2015 16:24:20 -0500 To: "" Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) X-Mailer: Apple Mail (2.1993) Archived-At: Subject: [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: Sat, 24 Jan 2015 21:24:23 -0000 The chairs have requested a one hour slot please send us any requests for agenda slots Olafur & Warren From nobody Sat Jan 24 21:54: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 DA3181A3BA0 for ; Sat, 24 Jan 2015 21:54:02 -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 jr5gTJwPHx8Q for ; Sat, 24 Jan 2015 21:54:01 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3AD6A1A212A for ; Sat, 24 Jan 2015 21:54:01 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 3DD20282EC3; Sun, 25 Jan 2015 05:54:00 +0000 (UTC) Date: Sun, 25 Jan 2015 05:54:00 +0000 From: Viktor Dukhovni To: DANE WG Message-ID: <20150125055400.GJ8034@mournblade.imrryr.org> References: <2772BE49-FDEC-4C33-AFE8-33E66B6ABBCF@ogud.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2772BE49-FDEC-4C33-AFE8-33E66B6ABBCF@ogud.com> 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 List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Jan 2015 05:54:03 -0000 On Sat, Jan 24, 2015 at 04:24:20PM -0500, Olafur Gudmundsson wrote: > The chairs have requested a one hour slot > please send us any requests for agenda slots Though I won't be there, I hope there will be some discussion of any outstanding issues on the ops/6698-update draft. In particular if the proposal to extend "3 1 X" to apply to raw public keys is not clear or is miguided, let's get that settled, and let's *finally* get a LC timeframe for the document. 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've not yet done anything on the DANE client authentication front, because I wanted to see the ops and SMTP drafts come to some closure first. This does not mean that DANE client auth is forgotten, I think it is still a reasonable thing to specify. 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. Exim 4.85 includes DANE support for SMTP, so there are now two implementations of the SMTP draft. In the mean-time Transip have fixed their DNS servers, and the number of DNSSEC domains that return bogus denial of existence for TLSA queries has dropped by ~40%. There is distant rumbling of progress on the forpsi front. The S/MIME discussion seems to have stalled, perhaps someone will have fresh ideas on how to move that forward. Finally, it would be nice to see (correct!) DANE TLSA support in TLS toolkits: OpenSSL, GnuTLS, PolarSSL, ... while I'll likely help out on the OpenSSL front, what can be done to get DANE support in the rest? To get around last-mile problems, perhaps a revived effort to define a TLS extension with "stapled TLSA records" (including the full chain of DS/DNSKEY and RRSIG records necessary to validate them). With stapled TLSA RRs, clients in DNSSEC-hostile environments can elicit the relevant DNSSEC in-band data from servers. -- Viktor. From nobody Thu Jan 29 07:43: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 7EACB1A1AA9 for ; Thu, 29 Jan 2015 07:43:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.433 X-Spam-Level: * X-Spam-Status: No, score=1.433 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, FSL_HELO_BARE_IP_2=1, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_61=0.6, RCVD_IN_DNSWL_NONE=-0.0001, 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 0uQ-dV4Fj6UK for ; Thu, 29 Jan 2015 07:43:45 -0800 (PST) Received: from gateway05.websitewelcome.com (gateway05.websitewelcome.com [67.18.124.3]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 696931A1A87 for ; Thu, 29 Jan 2015 07:43:45 -0800 (PST) Received: by gateway05.websitewelcome.com (Postfix, from userid 5007) id 95D6B257AEF66; Thu, 29 Jan 2015 09:43:44 -0600 (CST) Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway05.websitewelcome.com (Postfix) with ESMTP id 76774257AEE6A for ; Thu, 29 Jan 2015 09:43:44 -0600 (CST) Received: from [96.231.226.60] (port=62180 helo=192.168.1.2) by gator3286.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1YGrFv-0005xH-RC for dane@ietf.org; Thu, 29 Jan 2015 09:43:44 -0600 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Sean Turner In-Reply-To: <20150122220856.GJ8034@mournblade.imrryr.org> Date: Thu, 29 Jan 2015 10:43:42 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <383563B8-2F31-48F2-9B09-C7195313DB15@ieca.com> References: <0DAFC2A8-A1E2-46F4-BA52-E8261CB09159@ogud.com> <9DEDC923-8B03-4AF7-82FF-60C96C614641@ieca.com> <20150122220856.GJ8034@mournblade.imrryr.org> To: dane@ietf.org X-Mailer: Apple Mail (2.1878.6) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator3286.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source-IP: 96.231.226.60 X-Exim-ID: 1YGrFv-0005xH-RC X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (192.168.1.2) [96.231.226.60]:62180 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 4 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20= Archived-At: Subject: Re: [dane] WGLC: DANE-SRV & DANE-SMTP X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jan 2015 15:43:47 -0000 On Jan 22, 2015, at 17:08, Viktor Dukhovni = wrote: > On Thu, Jan 22, 2015 at 04:23:36PM -0500, Sean Turner wrote: >=20 >> This is procedural but I guess it's major: >>=20 >> Am I right that this draft is using the new definition for DANE-EE >> that is documented in draft-ietf-dane-ops? Don't we have to wait >> for it to update RFC 6698 or does this specification have to indicate >> that it updates RFC 6698? >=20 > Indeed the semantics of DANE-EE(3) are the same in both the ops > and smtp-with-dane drafts. >=20 > The ops draft ammends the semantics for all use-cases of the TLSA > record by updating 6698. The smtp-with-dane draft makes the same > change only for opportunistic DANE TLS used in MTA to MTA SMTP. >=20 > The history is that the decision to turn the ops draft into a 6698 > update happened rather late, and until that time, only the smtp > draft had the requisite normative language. >=20 > I don't know to best deal with this procedurally. One might say > that both drafts update 6698, or that only the ops draft does that, > and the smtp draft applies just narrowly to the protocol at hand. >=20 > I don't have any views on the logistics. Multiple drafts can update one draft so if you want to save time you can = just add "Updates: 6698 (once approved)" to the header of both drafts and you=92d = be procedurally covered. Well I guess technically, you need to also say = =93This draft updates RFC 6698=94 or something like that in the abstract = of the nits checker will complain. >> 0) s1.1, delayed delivery: r/When an MTA is unable forward/When an = MTA is to unable forward >=20 > Muphry bites, but I know what you mean thanks. >=20 >> 1) s1.1, delayed delivery: Might be good to have a forward >> reference to "mandatory DANE TLS" in the later section or add it >> as a definition in s1.1. >=20 > I'll add a forward reference, unless there is good reason to extend > the terminology. Nope that=92ll work. >> 2) s1.1: Couldn?t hurt to have informative references to DNS RR and = RRSet. >=20 > Sure. >=20 >> 3) s1.2: r/Certificate Authority/Certification Authority >=20 > Indeed, I thought I fixed all of those=85 >> 4) s1.3.2: r/and requiring/and require >=20 > This is a rather long sentence, but its high level > structure is: >=20 > One might try to ... by using ... and requiring ... >=20 > So I think that "requiring" agrees better with the > preceding parts. It might be clearer with an > extra "by": >=20 > One might try to ... by using ... and by requiring ... >=20 > Or a rewrite of the whole sentence. I re-read it leave it as is. >> 5) s1.3.3: What I think you're trying to say here: >>=20 >> Sending systems are in some cases explicitly configured to use TLS >> for mail sent to selected peer domains. This requires sending MTAs >> to be configured with appropriate subject names or certificate >> content digests to expect in the presented server certificates. >>=20 >> is this: >>=20 >> Sending systems are in some cases explicitly configured to use TLS >> for mail sent to selected peer domains, but this requires configuring >> sending MTAs with appropriate subject names or certificate >> content digests from their peer domains. >=20 > These looks largely the same to me, your version is fine too. Yeah just moving some words. >> 6) s2.1.3: I think if we're going to have a "MUST NOT" for >> something it's probably worth a pointer to the definition in RFC >> 4033 for "Security-Oblivious stub-resolvers? or add it to s1.1 and >> point to RFC 4033. >=20 > Makese sense. The larger question is whether this is really the > right place for a MUST NOT. If the client gets this wrong it is > insecure (never sees any "secure" domains and never uses DANE), > but it is still interoperable. What's the right way to tell clients > that they don't get any security if their recursor is oblivious? I think doing it here is fine. There might be other places we=92d also = do it, but here I think is a fine place to start. >> 7) s2.2.1: The text about MTA delivery logs made me wonder where >> the rest of the normative behavior is for MTA delivery logs and >> whether this text is updating that text. >=20 > I don't think there is any such text anywhere else. The closest > you'll find is "no misrepresentation of security" in RFC 7435 > (opportunistic security) of which this is an instance. This is good to know and personally I=92m fine with it. I wonder if the = mail folks won=92t come unglued about this though because it=92s = imposing some kind of requirements on the MTA. But, let=92s see what = they say before we try to second guess what might make it through. >> 8) s3.1: Should this be "RECOMMEND": >>=20 >> In summary, we recommend the use of either "DANE-EE(3) SPKI(1) >> SHA2-256(1)" or "DANE-TA(2) Cert(0) SHA2-256(1)" TLSA records >> depending on site needs. >=20 > Sure, if there are no objections. I guess we=92ll see ;) >> 9) s3.1: Maybe reword: >>=20 >> The mandatory to support digest algorithm in [RFC6698] is >> SHA2-256(1) >>=20 >> to:=20 >>=20 >> As specified in [RFC6698], the mandatory to implement digest >> algorithm is SHA2-256(1). >=20 > Yes. >=20 >> 10) s3.2.3: r/must be entire/must be the entire=20 >=20 > Yes. >=20 > When should the suggested changes be made? Since we=92re changing at least one 2119 keyword, I guess I=92d go ahead = and spin a new version before IETF LC - but that=92s really up to the = chairs. spt > --=20 > Viktor. >=20 > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane From nobody Thu Jan 29 09:06: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 E9B9F1A00F9 for ; Thu, 29 Jan 2015 09:06:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_61=0.6, RCVD_IN_DNSWL_LOW=-0.7] 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 oPpsJZ0_wRyM for ; Thu, 29 Jan 2015 09:06:44 -0800 (PST) Received: from mail-wi0-f173.google.com (mail-wi0-f173.google.com [209.85.212.173]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A10861A1BE0 for ; Thu, 29 Jan 2015 09:06:43 -0800 (PST) Received: by mail-wi0-f173.google.com with SMTP id r20so29173931wiv.0 for ; Thu, 29 Jan 2015 09:06:42 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=mtJqm2Nh2OW11Qm/TgMKQXzmx2hyeywD/4CORdKmcU4=; b=aAGLiVAPkE0OHx/FtfEy7wO4UZ610YzUtFA3rFUFA3aotKHE5IXAsfxLJh1ujZ00Yt eHbCwsEVwmWMbMho/3KBkP098ihmDqZPPMqGcOt42w3AF1G/SUqdXJuXrzOQ3EjTk19C lCLw6Mx8DYnoheBaM2q/2Vl36v9Xwf4rxZOcifgYXGFUfJTQppgu3LhEbKD6/EZXp1Cu t3vE+JHiFsjVfv3U2o69ESfwlPKq9viH3pD71CsWLll2mQsLGf0H373++/rG08WKl0we 4PeJ+3ACKrFKABgwR2PVC3pgBid7BcC/grsgm/1bM2TlcOoienX+7NPwJJnghYZcFB+F W+kw== X-Gm-Message-State: ALoCoQmWkeRxBu3MS6QaUp9/FZed87AkNXZ78uUNN21r+xldD4Y6MZBsgajqjwbSE+vX1lg/eC9n MIME-Version: 1.0 X-Received: by 10.180.73.178 with SMTP id m18mr1748006wiv.65.1422551201840; Thu, 29 Jan 2015 09:06:41 -0800 (PST) Received: by 10.194.158.231 with HTTP; Thu, 29 Jan 2015 09:06:41 -0800 (PST) In-Reply-To: <383563B8-2F31-48F2-9B09-C7195313DB15@ieca.com> References: <0DAFC2A8-A1E2-46F4-BA52-E8261CB09159@ogud.com> <9DEDC923-8B03-4AF7-82FF-60C96C614641@ieca.com> <20150122220856.GJ8034@mournblade.imrryr.org> <383563B8-2F31-48F2-9B09-C7195313DB15@ieca.com> Date: Thu, 29 Jan 2015 12:06:41 -0500 Message-ID: From: Warren Kumari To: Sean Turner Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "" Subject: Re: [dane] WGLC: DANE-SRV & DANE-SMTP X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jan 2015 17:06:50 -0000 On Thu, Jan 29, 2015 at 10:43 AM, Sean Turner wrote: > On Jan 22, 2015, at 17:08, Viktor Dukhovni wrote= : > >> On Thu, Jan 22, 2015 at 04:23:36PM -0500, Sean Turner wrote: >> >>> This is procedural but I guess it's major: >>> >>> Am I right that this draft is using the new definition for DANE-EE >>> that is documented in draft-ietf-dane-ops? Don't we have to wait >>> for it to update RFC 6698 or does this specification have to indicate >>> that it updates RFC 6698? >> >> Indeed the semantics of DANE-EE(3) are the same in both the ops >> and smtp-with-dane drafts. >> >> The ops draft ammends the semantics for all use-cases of the TLSA >> record by updating 6698. The smtp-with-dane draft makes the same >> change only for opportunistic DANE TLS used in MTA to MTA SMTP. >> >> The history is that the decision to turn the ops draft into a 6698 >> update happened rather late, and until that time, only the smtp >> draft had the requisite normative language. >> >> I don't know to best deal with this procedurally. One might say >> that both drafts update 6698, or that only the ops draft does that, >> and the smtp draft applies just narrowly to the protocol at hand. >> >> I don't have any views on the logistics. > > Multiple drafts can update one draft so if you want to save time you can = just add > "Updates: 6698 (once approved)" to the header of both drafts and you=E2= =80=99d be procedurally covered. Well I guess technically, you need to als= o say =E2=80=9CThis draft updates RFC 6698=E2=80=9D or something like that = in the abstract of the nits checker will complain. > >>> 0) s1.1, delayed delivery: r/When an MTA is unable forward/When an MTA = is to unable forward >> >> Muphry bites, but I know what you mean thanks. >> >>> 1) s1.1, delayed delivery: Might be good to have a forward >>> reference to "mandatory DANE TLS" in the later section or add it >>> as a definition in s1.1. >> >> I'll add a forward reference, unless there is good reason to extend >> the terminology. > > Nope that=E2=80=99ll work. > >>> 2) s1.1: Couldn?t hurt to have informative references to DNS RR and RRS= et. >> >> Sure. >> >>> 3) s1.2: r/Certificate Authority/Certification Authority >> >> Indeed, I thought I fixed all of those=E2=80=A6 > >>> 4) s1.3.2: r/and requiring/and require >> >> This is a rather long sentence, but its high level >> structure is: >> >> One might try to ... by using ... and requiring ... >> >> So I think that "requiring" agrees better with the >> preceding parts. It might be clearer with an >> extra "by": >> >> One might try to ... by using ... and by requiring ... >> >> Or a rewrite of the whole sentence. > > I re-read it leave it as is. > >>> 5) s1.3.3: What I think you're trying to say here: >>> >>> Sending systems are in some cases explicitly configured to use TLS >>> for mail sent to selected peer domains. This requires sending MTAs >>> to be configured with appropriate subject names or certificate >>> content digests to expect in the presented server certificates. >>> >>> is this: >>> >>> Sending systems are in some cases explicitly configured to use TLS >>> for mail sent to selected peer domains, but this requires configuring >>> sending MTAs with appropriate subject names or certificate >>> content digests from their peer domains. >> >> These looks largely the same to me, your version is fine too. > > Yeah just moving some words. > >>> 6) s2.1.3: I think if we're going to have a "MUST NOT" for >>> something it's probably worth a pointer to the definition in RFC >>> 4033 for "Security-Oblivious stub-resolvers? or add it to s1.1 and >>> point to RFC 4033. >> >> Makese sense. The larger question is whether this is really the >> right place for a MUST NOT. If the client gets this wrong it is >> insecure (never sees any "secure" domains and never uses DANE), >> but it is still interoperable. What's the right way to tell clients >> that they don't get any security if their recursor is oblivious? > > I think doing it here is fine. There might be other places we=E2=80=99d = also do it, but here I think is a fine place to start. > >>> 7) s2.2.1: The text about MTA delivery logs made me wonder where >>> the rest of the normative behavior is for MTA delivery logs and >>> whether this text is updating that text. >> >> I don't think there is any such text anywhere else. The closest >> you'll find is "no misrepresentation of security" in RFC 7435 >> (opportunistic security) of which this is an instance. > > This is good to know and personally I=E2=80=99m fine with it. I wonder i= f the mail folks won=E2=80=99t come unglued about this though because it=E2= =80=99s imposing some kind of requirements on the MTA. But, let=E2=80=99s = see what they say before we try to second guess what might make it through. > >>> 8) s3.1: Should this be "RECOMMEND": >>> >>> In summary, we recommend the use of either "DANE-EE(3) SPKI(1) >>> SHA2-256(1)" or "DANE-TA(2) Cert(0) SHA2-256(1)" TLSA records >>> depending on site needs. >> >> Sure, if there are no objections. > > I guess we=E2=80=99ll see ;) > >>> 9) s3.1: Maybe reword: >>> >>> The mandatory to support digest algorithm in [RFC6698] is >>> SHA2-256(1) >>> >>> to: >>> >>> As specified in [RFC6698], the mandatory to implement digest >>> algorithm is SHA2-256(1). >> >> Yes. >> >>> 10) s3.2.3: r/must be entire/must be the entire >> >> Yes. >> >> When should the suggested changes be made? > > Since we=E2=80=99re changing at least one 2119 keyword, I guess I=E2=80= =99d go ahead and spin a new version before IETF LC - but that=E2=80=99s re= ally up to the chairs. ... and I'd like to apologize for us not having actually called this / answered any of the requests for guidance / actually done anything. We have been stupidly busy recently (in related news: https://blog.cloudflare.com/help-us-test-our-dnssec-implementation/) , and I've been owing Olafur a call back for a few weeks now. We (the chairs and our AD) are planning a call in the next few days to discuss how to make sure we keep things moving... Y'all (DANE) deserve better and we are working on making that happen... W > > spt > >> -- >> Viktor. >> >> _______________________________________________ >> dane mailing list >> dane@ietf.org >> https://www.ietf.org/mailman/listinfo/dane > > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane --=20 I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf From nobody Thu Jan 29 10:48: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 AA8C01A1DBC for ; Thu, 29 Jan 2015 10:48:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5ctywqhxiT9c for ; Thu, 29 Jan 2015 10:48:48 -0800 (PST) Received: from mail-ie0-f173.google.com (mail-ie0-f173.google.com [209.85.223.173]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A8E21A1C00 for ; Thu, 29 Jan 2015 10:48:48 -0800 (PST) Received: by mail-ie0-f173.google.com with SMTP id tr6so37411820ieb.4 for ; Thu, 29 Jan 2015 10:48:46 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=IgZfurzfnm1TL0VN2oy9lm8Ve7RbRPbEMwRRNzw26IU=; b=idYOHxUs+q9kem6aGg6NDvo49TUfbHgp0nkvculP+R8s7JyyFffioa0cf4EFPzdCKa YvafPo6ehYHN0ZPfrJAoEAzuh0I0K/sgueydHokO2hbPxlIH2KJ8T5umDZCoWTI1DLMD e5V7ROyZbfq5KRgKpEpHCEZ35abqXVNMvP2f73tVTjDLK+/bZZup4+i8GOuco9kWEsgF IznMU+rVpWbDsJtmI8QPtj5lLqynjR1/vOisbH1/MyTJbdwRWFNyIrT/fjyy4Fvy8br3 eUVhXY9NP9KyAUcwWA9SRdO75dYfnXRtjiC5tHk1xkrMP2Qi2AfCKzJz6AZkmI58Sulv vNJg== X-Gm-Message-State: ALoCoQmVnFjnjxZzl4ccQfLkW0vfso2wFHD40FWnEAhtBW2EgPpHJZq2733RbMTQ9OTufO22NEAs X-Received: by 10.107.151.80 with SMTP id z77mr2457320iod.51.1422557326312; Thu, 29 Jan 2015 10:48:46 -0800 (PST) Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id v64sm4529438ioi.18.2015.01.29.10.48.45 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 29 Jan 2015 10:48:45 -0800 (PST) Message-ID: <54CA808C.8080507@andyet.net> Date: Thu, 29 Jan 2015 11:48:44 -0700 From: Peter Saint-Andre - &yet User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Warren Kumari , Sean Turner References: <0DAFC2A8-A1E2-46F4-BA52-E8261CB09159@ogud.com> <9DEDC923-8B03-4AF7-82FF-60C96C614641@ieca.com> <20150122220856.GJ8034@mournblade.imrryr.org> <383563B8-2F31-48F2-9B09-C7195313DB15@ieca.com> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "" Subject: Re: [dane] WGLC: DANE-SRV & DANE-SMTP X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jan 2015 18:48:54 -0000 On 1/29/15 10:06 AM, Warren Kumari wrote: > We (the > chairs and our AD) are planning a call in the next few days to discuss > how to make sure we keep things moving... > > Y'all (DANE) deserve better and we are working on making that happen... BTW, Matt Miller and I plan to meet in person next week to work through Viktor's feedback on DANE-SRV, too. Peter -- Peter Saint-Andre https://andyet.com/ From nobody Thu Jan 29 16:07:54 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8ADD01A6F0E for ; Thu, 29 Jan 2015 16:07:51 -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 mTgPl1HgreCl for ; Thu, 29 Jan 2015 16:07:49 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 815D01A066B for ; Thu, 29 Jan 2015 16:07:49 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 11694282EC3; Fri, 30 Jan 2015 00:07:48 +0000 (UTC) Date: Fri, 30 Jan 2015 00:07:48 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20150130000747.GF8034@mournblade.imrryr.org> References: <0DAFC2A8-A1E2-46F4-BA52-E8261CB09159@ogud.com> <9DEDC923-8B03-4AF7-82FF-60C96C614641@ieca.com> <20150122220856.GJ8034@mournblade.imrryr.org> <383563B8-2F31-48F2-9B09-C7195313DB15@ieca.com> <54CA808C.8080507@andyet.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54CA808C.8080507@andyet.net> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [dane] WGLC: DANE-SRV & DANE-SMTP X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jan 2015 00:07:51 -0000 On Thu, Jan 29, 2015 at 11:48:44AM -0700, Peter Saint-Andre - &yet wrote: > BTW, Matt Miller and I plan to meet in person next week to work through > Viktor's feedback on DANE-SRV, too. Thanks. Once concern beyond the SRV draft itself, is that in UTA I see an XMPP draft, that delegates all the DANE bits to the SRV draft, but the SRV draft is not XMPP-specific, and in particular does not fully lay out requirements for opportunistic clients (as in server-to-server XMPP where even if TLS may be required, authentication is IIRC optional and opportunistic). So there seems to be a specification gap between the generic SRV document and the actual requirements of XMPP. It seems to me that DANE for XMPP is under-specified. Many of the detailed issues addressed by the SMTP draft might reasonably apply also to (server to server) XMPP if the spec were more complete. Who's doing the XMPP server DANE implementation? Perhaps the problem is that either the implementations are not mature and have tackled all the issues yet, or the implementors have not raised them to the spec writers... Or perhaps I my SMTP draft is unnecessarily detailed, and people should be able to figure all the messy bits out for themselves? This is again about XMPP, not the SRV draft, but if the SRV draft is to serve as a complete spec for XMPP with DANE there may be more than needs to be said (opportunistic authentication use-case, DANE vs. PKIX usages, ...). Perhaps the UTA XMPP draft is the place to fill any residual gaps. -- Viktor.