From nobody Sat Aug 1 00:39: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 6BADB1B2B2D for ; Sat, 1 Aug 2015 00:39:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.51 X-Spam-Level: X-Spam-Status: No, score=-0.51 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 TU0_5LIb7TxO for ; Sat, 1 Aug 2015 00:39:51 -0700 (PDT) Received: from mail.rozanak.com (mail.rozanak.com [IPv6:2a01:238:42ad:1500:aa19:4238:e48f:61cf]) (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 64B731B2B23 for ; Sat, 1 Aug 2015 00:39:51 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by mail.rozanak.com (Postfix) with ESMTP id EE8D125CA2B4 for ; Sat, 1 Aug 2015 07:39:48 +0000 (UTC) X-Virus-Scanned: amavisd-new at rozanak.com Received: from mail.rozanak.com ([127.0.0.1]) by localhost (mail.iknowlaws.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kr97fcCLxIlu for ; Sat, 1 Aug 2015 09:39:47 +0200 (CEST) Received: from kopoli (p200300864F13D1C9E9DF3F71090AA52D.dip0.t-ipconnect.de [IPv6:2003:86:4f13:d1c9:e9df:3f71:90a:a52d]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.rozanak.com (Postfix) with ESMTPSA id BEE5225CA256 for ; Sat, 1 Aug 2015 09:39:47 +0200 (CEST) From: "Hosnieh Rafiee" To: References: <1437580854.052529954@apps.rackspace.com> <814D0BFB77D95844A01CA29B44CBF8A7015D2DD4@lhreml504-mbs> <4FEE7B8C-F482-4FB8-824E-26B26D30BAD7@powerdns.com> <20150731182209.GB18811@sys4.de> In-Reply-To: <20150731182209.GB18811@sys4.de> Date: Sat, 1 Aug 2015 09:39:44 +0200 Message-ID: <000601d0cc2d$3c8c80e0$b5a582a0$@rozanak.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQLtkmYZyVhjVlpDkzyaAiTQ5qXZwAHWrSYZA1g+ezsBIUOju5uKqlAQ Content-Language: en-us Archived-At: Subject: Re: [dane] OPENPGP --- Privacy considerations X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 01 Aug 2015 07:39:53 -0000 Hi, > From: dane [mailto:dane-bounces@ietf.org] On Behalf Of Florian Kirstein > Hi, > > And indeed, there are various things to consider. In the result I am currently > in strong favour of SHA instead of base, and I know of people who think > base32 will make the standard much less attractive at least here in germany > where privacy is a big topic - and for PGP users in general, as I expect they use > PGP for a reason... +1 > But first my answer to: > > > >I would see the use of base32 (without extra improvement > > >techniques) as a security risk. This is because, it decreases the > > >entropy of SHA256 hash function > > The planned/suggested use of base32 is *instead of* SHA256. Thus, > > entropy is not a topic - as there is no hashing. > > I think Hosnieh was referring to the SHA256 done in the NSEC3 records, > and/or the danger of harvesting the emails from the DNS. This is one of my major concern. But there is other privacy problem that is during transmission since before, these keys are not queried from a DNS server and they were something between MTAs and users. So, imagine you're in a public place and using WiFi and you want to check your email and send an important email. It is enough that someone sniff all queries to DNS server and just gather these values. If it is base32 without any hashing, then this adversary can easily gather information as only convert it back to utf or other encoding is enough. If it is hashed then do dictionary attack offline and gather all these email addresses. (doesn't need to be online too). So this means that if before, the adversary had hard time to gather these information by checking all websites or mailinglists. Now it is not true and by only sitting back while sniffing public wifi he can fetch a lot of such information and do reverse step to return to return it back to the victims' emails. Of course, if it is hashed, we complicated his life and he need one more step. > The current draft in 6.2 notes, that Email addresses "are not secret" and The > hashing is not a security feature. I don't fully agree on the first sentence, but > the rest is true. Disagree with your second sentence. If the purpose of hashing before was to reduce the size of input values or provide collision free values, this is not the only use case for that anymore. One example, Passwords are hashed and kept in databases. If it is not for security reason and it is not to mitigate plain text attack on the database or storages, then it appears that I am not understanding the reason!? Another example is that hashing public key in some mechanism to increase the strengthen of public key that is not only related to the strengthen of public cryptography algorithm and key size but also involve the strengthen of SHA function. You can find plenty of mechanisms, even at IETF, that uses this method. > > Adding some paragraph about handling UTF8 (normalize, don't touch > otherwise) and it's good to go. I had some discussion about this with some of my colleagues. It makes sense to do that step because each implementation might use different encoding for email addresses. In other word, the value for Java might be different than .net. So I am not disagree with that step and I think it is a right step to do. Furthermore, you have to consider in future the internationalized email addresses if and if the DNS registrar accepts to have internationalized domain (e.g. a domain name in German) . So, in that case it makes sense again to do this step. Best, Hosnieh From nobody Sat Aug 1 06:16:12 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85FD51A1A7C for ; Sat, 1 Aug 2015 06:16:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.661 X-Spam-Level: X-Spam-Status: No, score=-1.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_DE=0.35, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aX55M_7QjA8b for ; Sat, 1 Aug 2015 06:16:09 -0700 (PDT) Received: from mail.sys4.de (mail.sys4.de [IPv6:2001:1578:400:111::7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A3681A1A7F for ; Sat, 1 Aug 2015 06:16:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sys4.de; h= in-reply-to:content-disposition:content-type:content-type :mime-version:references:message-id:subject:subject:from:from :date:date; s=mail201310; t=1438434965; x=1440249366; bh=VIPdiwk D27QsM9ZyA9AbFH/BfM9MQocHtFR7J1Sbp24=; b=ah9gfT50HhyynZiXOdkn4bF uxTcBPd0/omITBzdeUvOGHjwxemkxj+A/o3vmwZ7+fAuILv7kalSR6lcR/pOmgrt 2IFwVpGnzCb9k/PorviGXYSI9Z4Tqf611yV/6xQiV5ME/GFj94E/fwC3fmNauNhd De3lRFopMoGNe2gpIOGf/CW7YfRIF63ozBUy9FdFSi5LUp69qcp+4e6fPVPqRX3E 9Vkhyn1Q5/Aba3854ekfYbUvyPWCepzcOfmv6Q2g0YO3KI7gh0Z4ErUd+QpedNBq glpaawK/XsQ3apKlHgShkZqCj7Z49zH0KrW/h+/pNSvqNKxFOfQuYLJhKPuSXaA= = X-Virus-Scanned: Debian amavisd-new at mail.sys4.de Received: from sys4.de (mail.sys4.de [194.126.158.139]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.sys4.de (Postfix) with ESMTPSA id 3mk5Zs5G0FzgN for ; Sat, 1 Aug 2015 15:16:05 +0200 (CEST) Date: Sat, 1 Aug 2015 15:16:04 +0200 From: Florian Kirstein To: dane@ietf.org Message-ID: <20150801131604.GC18811@sys4.de> References: <1437580854.052529954@apps.rackspace.com> <814D0BFB77D95844A01CA29B44CBF8A7015D2DD4@lhreml504-mbs> <4FEE7B8C-F482-4FB8-824E-26B26D30BAD7@powerdns.com> <20150731182209.GB18811@sys4.de> <000601d0cc2d$3c8c80e0$b5a582a0$@rozanak.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <000601d0cc2d$3c8c80e0$b5a582a0$@rozanak.com> Archived-At: Subject: Re: [dane] OPENPGP --- Privacy considerations X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 01 Aug 2015 13:16:11 -0000 Hi, > server and they were something between MTAs and users. So, imagine you're in > a public place and using WiFi and you want to check your email Did you read my full email? Thats EXACTLY what I wrote in a later paragraph. And it's the reason I wrote I vote for sha. And even would prefer iterations there %) And see the risk of rainbow tables used to reverse those. > Disagree with your second sentence. If the purpose of hashing before was to > reduce the size of input values or provide collision free values Thats all the draft states. That the hashing was not intended as security feature. And that is true. If it would have been intended to secure the transmission, it would include iterations and possibly some anti-rainbow measures. I don't agree with this intention obviously, I was just stating that (only) for the purpose of harvesting addresses from the zone the hash of the localpart is not the thing to consider and it's also not helping much. And that was the main thing the authors were talking about there, stating that it's the job of the DNSSEC operator to secure the zone, not the OPENPGPKEY standard. Which is OK for me. I also don't say hashes are not useable for security functions - but a simple sha hash today also isn't the strongest one. One could even go as far and suggest scrypt or similar instead of chopped sha. So my main points are: - hash is better than base32 because it makes sniffing recipients from the network much harder - if we agree that it is a real problem, we should add iterations AND a SALT somewhere to the zone, or even switch to scrypt. It's also widely available in libraries today like for python or perl. But I have no idea how the others here see that and if it's worth delaying the draft even more. It would not be too complicated though and even doesn't have the DoS problems iterations have in NSEC3. I think the base32 transmition will actually prevent people from using for example a thunderbird plugin that looks up keys - for privacy reasons. I expect a normal hash would be OK for most of those though, after all the metadata is not uber-secret, it's still in all the mail server logs on the way and so on. Real paranoid people will wait another 20 years for encrypted DNS to be widely deployed %) But sending all your recipients in clear text really is not what you want today... > Furthermore, you have to consider in future the internationalized email > addresses That's where the proposal of normalizing the unicode comes from. And as far as I remember there were no objections to this so far, it's just not in the draft yet. Greetings, Florian -- [*] sys4 AG http://sys4.de, +49 (89) 30 90 46 64 Franziskanerstrasse 15, 81669 Muenchen Sitz der Gesellschaft: Muenchen, Amtsgericht Muenchen: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein From nobody Sat Aug 1 09:37: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 C31A21A0025 for ; Sat, 1 Aug 2015 09:37:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NHonx7b48raa for ; Sat, 1 Aug 2015 09:37:20 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA8D51A0011 for ; Sat, 1 Aug 2015 09:37:19 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 8FE3A284D64; Sat, 1 Aug 2015 16:37:18 +0000 (UTC) Date: Sat, 1 Aug 2015 16:37:18 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20150801163718.GC4347@mournblade.imrryr.org> References: <1437580854.052529954@apps.rackspace.com> <814D0BFB77D95844A01CA29B44CBF8A7015D2DD4@lhreml504-mbs> <4FEE7B8C-F482-4FB8-824E-26B26D30BAD7@powerdns.com> <20150731182209.GB18811@sys4.de> <000601d0cc2d$3c8c80e0$b5a582a0$@rozanak.com> <20150801131604.GC18811@sys4.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150801131604.GC18811@sys4.de> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [dane] OPENPGP --- Privacy considerations 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, 01 Aug 2015 16:37:21 -0000 On Sat, Aug 01, 2015 at 03:16:04PM +0200, Florian Kirstein wrote: > Did you read my full email? Thats EXACTLY what I wrote in a later > paragraph. And it's the reason I wrote I vote for sha. And even would > prefer iterations there %) And see the risk of rainbow tables used > to reverse those. My original proposal that introduced hashes for the local part suggested hashing the full email address to help thwart rainbow tables. That was not accepted, because it does not support domain equivalence via DNAME aliases. And we've failed to reach consensus on even a single layer of hashing just the local part. There is, however reluctant, some consensus around base32. No matter what storage encoding of the localpart is used, a passive wiretap will reveal the domain of each correspondent's key lookup, and whether that correspondent is new or one that was looked up previously. This is inherent in using a cleartext DNS query protocol. How important is support for such equivalent domains, relative to potential privacy gains? There is no privacy for lookups of DNS data, until the transmission channel is somehow encrypted, but even then, unless your local resolver avoids forwarding all queries to the ISP, the ISP resolver has the plaintext of all DNS queries. There was some recent discussion of https://tools.ietf.org/html/draft-moore-email-addrquery-01 on the IETF UTA list. As written in that draft the MSA learns the plaintext of all key lookups, but this is not a data leak, because in short order the MSA will see the envelope of the final outbound message. With STARTTLS on increasingly more SMTP hops, localpart data is modestly well protected (passive wiretaps may be able to distinguish between long and short envelope recipient addresses based on the sizes of TLS packets unless random padding is used to extend such packets to hide the plaintext length). Protection from traffic analysis requires Tor (or better). So trade-offs are inevitable, and evidently make reaching consensus difficult. In the UTA discussion, I am running into irrational fear of DNSSEC, and I think an unreasonable goal of eliminating the MSA as a trusted party. Always using the MSA as a proxy would I believe significantly improve the scalability and abuse resistane of the protocol. Without the complexity of end-to-end payload signing, the MSA would need to be trusted. It may be possible to add end-to-end signing, but not clear how without DANE publishing the signing keys, and stapled DANE responses between MUA and MSA. Given the clear DNSSEC animus of at least some of the parties, I don't see a way forward that avoids compromising at least one of the objectives. Time will tell... These are not easy to solve problems. If someone thinks they have a simple solution that does not compromise on any of the design goals, they're probably not thinking hard enough. -- Viktor. From patrik.loehr@posteo.de Sat Aug 1 11:05:57 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DA7A1A02F1 for ; Sat, 1 Aug 2015 11:05:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.062 X-Spam-Level: X-Spam-Status: No, score=-0.062 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, 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 QqVSCEi47MRw for ; Sat, 1 Aug 2015 11:05:54 -0700 (PDT) Received: from mx02.posteo.de (mx02.posteo.de [89.146.194.165]) (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 5D6001A0276 for ; Sat, 1 Aug 2015 11:05:54 -0700 (PDT) Received: from dovecot04.posteo.de (unknown [185.67.36.27]) by mx02.posteo.de (Postfix) with ESMTPS id 884AD25ACC33; Sat, 1 Aug 2015 20:05:49 +0200 (CEST) Received: from mail.posteo.de (localhost [127.0.0.1]) by dovecot04.posteo.de (Postfix) with ESMTPSA id 3mkD1847d5zFpVh; Sat, 1 Aug 2015 20:05:47 +0200 (CEST) Message-ID: <55BD0A6A.2090802@posteo.de> Date: Sat, 01 Aug 2015 20:05:30 +0200 From: =?ISO-8859-15?Q?Patrik_L=F6hr?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: dane@ietf.org, Olafur Gudmundsson References: <20150801174602.043B625ACC26@mx02.posteo.de> In-Reply-To: <20150801174602.043B625ACC26@mx02.posteo.de> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms070206060705010004030300" Archived-At: Subject: Re: [dane] OPENPGP and SMIME local part question X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 01 Aug 2015 18:08:29 -0000 This is a cryptographically signed message in MIME format. --------------ms070206060705010004030300 Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: quoted-printable Hello everyone, At Posteo, we've implemented OPENPGPKEY and SMIMEA. We are a provider of email accounts (exclusively on a paid basis) with a strong focus on privacy and security. We think it would be better for the local parts to use hashing. Our two points: - The discussion obviously came up because of trying to determine a way to find entries when users use upper and lower case characters. From our perspective, this is not a problem that these drafts can solve. - Base encoding equates to plaintext transfer and for a security feature, privacy should not be disregarded. In detail: For us it is not a question for these drafts, whether local parts should be normalised or not. The drafts complement email, and they should therefore not introduce their own interpretation of email. This runs contrary to the sense of the RFC system and would in that form presumably delay or prevent adoption of the drafts. For us it is perfectly clear that the local parts are either written the same and match, or not. If the email community thinks that there is a problem with the local parts, then that is, in my opinion, a matter for another draft. OPENPGPKEY and SMIMEA should not be used for work on a different project. Hashing of local parts is definitely a great advance over plaintext transfer in terms of security. Even if hashing was not initially intended as a security feature, it is one. In any case, it distinctly hinders the possibility of simply reading the data in DNS requests - data that could convey a lot about the communication behaviour of users. Hashing is from our perspective a necessary first step, especially when DNS requests do not occur encrypted. Of course, hashing does not protect against "decryption" - but it makes a distinct difference whether I need to make a targeted attack on a hash, or can arbitrarily search through the plaintext in a stream of data. We would strongly welcome it if the drafts were to move forward with hashing, in terms of acceptance as a genuine security feature at the service of internet users. We need as much security as possible; the Snowden revelations demonstrated this. Best regards, Patrik Am 22.07.2015 um 12:00 schrieb "Olafur Gudmundsson" : Dear Colleagues The sense of the room in the IETF-93 meeting was to do do a BASE32 encoding of local part with 60 character labels, shortest label is the left most label. If you can NOT live with this path forward now is your last chance to say so. By August 1'st the chairs will instruct editors how to proceed. Warren & Olafur --=20 Patrik L=F6hr Posteo e.K. Methfesselstr. 38 10965 Berlin web Handelsregister: Berlin-Charlottenburg =B7 HRA 47592 B --------------ms070206060705010004030300 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMbDCC BjAwggUYoAMCAQICAw2zGTANBgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRl IFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlh dGUgQ2xpZW50IENBMB4XDTE1MDQxNDEzNDUzNFoXDTE2MDQxNDEzMjcwNVowSDEfMB0GA1UE AwwWcGF0cmlrLmxvZWhyQHBvc3Rlby5kZTElMCMGCSqGSIb3DQEJARYWcGF0cmlrLmxvZWhy QHBvc3Rlby5kZTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL4AsH4F/E5sb3xc 7+8rPfCcBHjuZk5LHc3JBJ48t2wgdIRliSkiK1VtIp5SHTMDBGKy7O6z1JQiB9mmJkQ2F6/T 62SsisSHctrCybHSufP8c4Vlr2vJScJIqzLVdg/WHo+UosmCwaZ8XCeLFr8g/lhNlZ5BKcb+ OUFYSeEfcb0AZc/gIhrQ6nnDARQVWpj3S2SXeGutkrrifjU1niqViMUxbE8TNitg2R3XoFJc a4e8rLACP0m6UoJ1JelHiaKdCYOCk+w8GGRrDTXecF1RzCU/9CIvdMzpurxSN6zfSvUg58dE xGv+4hFxydbR0+GN8+KWshFFumTa0xCIVfYzKskCAwEAAaOCAtwwggLYMAkGA1UdEwQCMAAw CwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQU TvYppnwFOAQKigRZCBsApLfBzTAwHwYDVR0jBBgwFoAUU3Ltkpzg2ssBXHx+ljVO8tS4UYIw IQYDVR0RBBowGIEWcGF0cmlrLmxvZWhyQHBvc3Rlby5kZTCCAUwGA1UdIASCAUMwggE/MIIB OwYLKwYBBAGBtTcBAgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNv bS9wb2xpY3kucGRmMIH3BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9u IEF1dGhvcml0eTADAgEBGoG+VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGlu ZyB0byB0aGUgQ2xhc3MgMSBWYWxpZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRD b20gQ0EgcG9saWN5LCByZWxpYW5jZSBvbmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBp biBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5nIHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8E LzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1MS1jcmwuY3JsMIGOBggr BgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5zdGFydHNzbC5jb20vc3Vi L2NsYXNzMS9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly9haWEuc3RhcnRzc2wuY29t L2NlcnRzL3N1Yi5jbGFzczEuY2xpZW50LmNhLmNydDAjBgNVHRIEHDAahhhodHRwOi8vd3d3 LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBAJnKy35YtxD0cETG0zygXYrCFQTX zjOgEPPunCIJw9O3BAgYS4z7NGdpJv2U1hru38QTdV8gtTv/BVwkyfnWQbCgopkVYvQ4hE94 3G9QIDtEffB9FhXj93BECa7Avqz+jvt1BAHG4IobsBfpJyOKtLFFQfJx7zM5QRWxnudIZVbj mKGlB6UfOOcglcfQyF28/JI4SY8qafWVxqGoL17rzuoqWq89dxWxljaCeUpLL9jp7txUMyJ1 9f8LTU+N27vAw1DShxljz4pIiH9wKzAEisZcFA5ocWvZVXxCKTKXAu7Vgyv07OtcUrhJaAmn 0feBFoyoDofwq7JKx2XDCkgjEPEwggY0MIIEHKADAgECAgEeMA0GCSqGSIb3DQEBBQUAMH0x CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUg RGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAxNTVaFw0xNzEwMjQyMTAxNTVaMIGMMQsw CQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERp Z2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQ cmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDHCYPMzi3YGrEppC4Tq5a+ijKDjKaIQZZVR63UbxIP6uq/I0fhCu+cQhoUfE6E RKKnu8zPf1Jwuk0tsvVCk6U9b+0UjM0dLep3ZdE1gblK/1FwYT5Pipsu2yOMluLqwvsuz9/9 f1+1PKHG/FaR/wpbfuIqu54qzHDYeqiUfsYzoVflR80DAC7hmJ+SmZnNTWyUGHJbBpA8Q89l GxahNvuryGaC/o2/ceD2uYDX9U8Eg5DpIpGQdcbQeGarV04WgAUjjXX5r/2dabmtxWMZwhZn a//jdiSyrrSMTGKkDiXm6/3/4ebfeZuCYKzN2P8O2F/Xe2AC/Y7zeEsnR7FOp+uXAgMBAAGj ggGtMIIBqTAPBgNVHRMBAf8EBTADAQH/MA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUU3Lt kpzg2ssBXHx+ljVO8tS4UYIwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwZgYI KwYBBQUHAQEEWjBYMCcGCCsGAQUFBzABhhtodHRwOi8vb2NzcC5zdGFydHNzbC5jb20vY2Ew LQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNydDBbBgNVHR8E VDBSMCegJaAjhiFodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwJ6AloCOGIWh0 dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDCBgAYDVR0gBHkwdzB1BgsrBgEEAYG1 NwECATBmMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRm MDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRm MA0GCSqGSIb3DQEBBQUAA4ICAQAKgwh9eKssBly4Y4xerhy5I3dNoXHYfYa8PlVLL/qtXnkF gdtY1o95CfegFJTwqBBmf8pyTUnFsukDFUI22zF5bVHzuJ+GxhnSqN2sD1qetbYwBYK2iyYA 5Pg7Er1A+hKMIzEzcduRkIMmCeUTyMyikfbUFvIBivtvkR8ZFAk22BZy+pJfAoedO61HTz4q SfQoCRcLN5A0t4DkuVhTMXIzuQ8CnykhExD6x4e6ebIbrjZLb7L+ocR0y4YjCl/Pd4MXU91y 0vTipgr/O75CDUHDRHCCKBVmz/Rzkc/b970MEeHt5LC3NiWTgBSvrLEuVzBKM586YoRD9Dy3 OHQgWI270g+5MYA8GfgI/EPT5G7xPbCDz+zjdH89PeR3U4So4lSXur6H6vp+m9TQXPF3a0Lw Zrp8MQ+Z77U1uL7TelWO5lApsbAonrqASfTpaprFVkL4nyGH+NHST2ZJPWIBk81i6Vw0ny0q ZW2Niy/QvVNKbb43A43ny076khXO7cNbBIRdJ/6qQNq9Bqb5C0Q5nEsFcj75oxQRqlKf6Tcv GbjxkJh8BYtv9ePsXklAxtm8J7GCUBthHSQgepbkOexhJ0wP8imUkyiPHQ0GvEnd83129fZj oEhdGwXV27ioRKbj/cIq7JRXun0NbeY+UdMYu9jGfIpDLtUUGSgsg2zMGs5R4jGCA90wggPZ AgEBMIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD b20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAw2zGTAJBgUrDgMC GgUAoIICHTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNTA4 MDExODA1MzBaMCMGCSqGSIb3DQEJBDEWBBQemlJXUgfNcJWyD57wCKJ4AQpGyzBsBgkqhkiG 9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZI hvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGlBgkr BgEEAYI3EAQxgZcwgZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQu MSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQD Ey9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDDbMZ MIGnBgsqhkiG9w0BCRACCzGBl6CBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBAgMNsxkwDQYJKoZIhvcNAQEBBQAEggEAA9vsyx8cXh1q4rCx8w72cCYys4sPBzf/JF1O pgBXgJuA+i+i1vjI+9BncQiDz1d93+FVrd124bv9eRzs5z807f48BufEBMIFi3RjGZLA7nQf ZOzHZ5isphuSN8esTWBt+mk0FS5a0fW3wiNGL3fXLuQjt99/ratbg34rPmqD5B4/bMuMbKql 2hWZ4J9RAGWvpasJUnXAKxnkZgvKsVBU1wR9A6ib59R+XTCd38RhLaS8Df3SL34WBHSSQII6 gzVWOyH97MKG0x2RyPeJUwuCMWZFUFHigthDzi+WjbYkhAORFgw4JW2Jg6KFwatwDNr8nODw GrCBbz0j8AroyFkyMwAAAAAAAA== --------------ms070206060705010004030300-- From nobody Sat Aug 1 11:47: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 4D3781A03FF for ; Sat, 1 Aug 2015 11:47:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.961 X-Spam-Level: X-Spam-Status: No, score=-3.961 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04rAjJmNRDOH for ; Sat, 1 Aug 2015 11:47:06 -0700 (PDT) Received: from mail.sys4.de (mail.sys4.de [194.126.158.139]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A0251A03C7 for ; Sat, 1 Aug 2015 11:47:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sys4.de; h= in-reply-to:content-disposition:content-type:content-type :mime-version:references:message-id:subject:subject:from:from :date:date; s=mail201310; t=1438454824; x=1440269225; bh=601F7b/ /TfTsC3Q7sckp817v8WpoOIQEi4aLhbXgnJc=; b=RvTDeNRCX4lstJYrPzTBlhZ Bf6cNW1Dj6EsumZAusAQXbqScYrOh6JlOPa+LnG/voZJVjI2KOMsx4I/ZitPqwfM RpdjQI40NDDWUG8favP8xFMAPlOwE04PMw3HCW+wPlU/J0pnnJw1yh6krPVZHfnG +iZyvRmv87FNLHFn3HsYh+u6PCV+mluUB8sC59BbDc+z0/DJ025ei606Qwq4Jm1M 7xhdhC1y5BYLGaTxiVFdEn7GvatgF2Y5GlUCRUirIp67Wp+vDdHbe/E3h9orKCE4 ycWPU93grNTAhpyzKYPODrsjyscYJhvY/qfm/QVcsBFMexnQFxlQgL6HnNkzImw= = X-Virus-Scanned: Debian amavisd-new at mail.sys4.de Received: from sys4.de (mail.sys4.de [194.126.158.139]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.sys4.de (Postfix) with ESMTPSA id 3mkDwm1vZBzX4; Sat, 1 Aug 2015 20:47:04 +0200 (CEST) Date: Sat, 1 Aug 2015 20:47:03 +0200 From: Florian Kirstein To: Olafur Gudmundsson Message-ID: <20150801184703.GD18811@sys4.de> References: <1437580854.052529954@apps.rackspace.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <1437580854.052529954@apps.rackspace.com> Archived-At: Cc: dane@ietf.org Subject: Re: [dane] OPENPGP and SMIME local part question X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 01 Aug 2015 18:47:08 -0000 Hi, > The sense of the room in the IETF-93 meeting was to do do a BASE32 encoding of local part with 60 character labels, shortest label is the left most label. If you can NOT live with this path forward now is your last chance to say so. Probably Hosnieh's and my mails also would have better fit here, but for the record: we both also see big privacy issued with the base32 encoding, not worth the theoretical benefits. As I already wrote: I'd rather drop the lowercasing (which caused much of the discussion leading to base32) then go without some "scrambling" of the localpart. Even tough I still believe lowercasing before lookup would not collide with current RFCs (as it's a key lookup, not mail routing). But if it has to be - let's try without that and see what real life experience shows us. Greetings, Florian -- [*] sys4 AG http://sys4.de, +49 (89) 30 90 46 64 Franziskanerstrasse 15, 81669 Muenchen Sitz der Gesellschaft: Muenchen, Amtsgericht Muenchen: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein From nobody Sat Aug 1 20:15: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 C78751A8A43; Sat, 1 Aug 2015 20:14:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PAo62uW8ifW8; Sat, 1 Aug 2015 20:14:57 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7131B1A8A27; Sat, 1 Aug 2015 20:14:57 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Joel Jaeggli" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.2.0.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150802031457.26126.79480.idtracker@ietfa.amsl.com> Date: Sat, 01 Aug 2015 20:14:57 -0700 Archived-At: Cc: dane-chairs@ietf.org, dane@ietf.org, draft-ietf-dane-ops.ad@ietf.org, draft-ietf-dane-ops.shepherd@ietf.org, draft-ietf-dane-ops@ietf.org Subject: [dane] Joel Jaeggli's No Objection on draft-ietf-dane-ops-14: (with COMMENT) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Aug 2015 03:14:59 -0000 Joel Jaeggli has entered the following ballot position for draft-ietf-dane-ops-14: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dane-ops/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- from fred baker's opsdir review, I would like to see a commnet on these from the authors. thanks joel I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review. Document editors and WG chairs should treat these comments just like any other last call comments. Document reviewed: draft-ietf-dane-ops-12 Summary: Ready to go, two comments that might be considered last call or IESG comments if the AD agrees. I think the opening paragraph of the introduction needs some tweaking. The DANE TLSA specification ([RFC6698]) introduces the DNS "TLSA" resource record type. TLSA records associate a certificate or a public key of an end-entity or a trusted issuing authority with the corresponding TLS transport endpoint. DNSSEC validated DANE TLSA records can be used to augment or replace the use of trusted public Certification Authorities (CAs). I'm not an expert on this, but I think it would be more accurate to say that it replaces a PKI, not a CA. A CA probably deploys and operates a PKI. However, it does so in the context of a business - it vets entities that it will sell certificates to, and then sells them certificates, which it stores somewhere such as a PKI. I would expect that the CA, in this model, would have the same business (and hence is not replaced), but store its certificates in TLSA records instead of or in addition to in a PKI. In section 1.1, a number of terms are defined, including "public key". If "public key" needs definition (which it does, as the term is used to specifically refer to a field within a certificate, as opposed to a more general cryptographic usage), I think "Certificate Authority (CA)" and "Public Key Infrastructure (PKI)", which are also used throughout the document, require definition. You note that neither of these comments is substantive with respect to the protocol, the record, or the operational recommendations that the draft makes. Operationally, the document poses no requirements on operators as a general class. It does require that a DNS operator implement DNSSEC (else I'm not sure how one trusts a TLSA), and it has a number specific directions to the CA about the TLSA records it asks the DNS operator to store. However, an operator that simply offers transit service, for example, is not affected. From nobody Sun Aug 2 07:43:56 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDFDE1A8A07 for ; Sun, 2 Aug 2015 07:43:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.19 X-Spam-Level: X-Spam-Status: No, score=0.19 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sjoads5uBcg7 for ; Sun, 2 Aug 2015 07:43:53 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D81F1A8A06 for ; Sun, 2 Aug 2015 07:43:53 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3mklTg1cVbz3Ll; Sun, 2 Aug 2015 16:43:51 +0200 (CEST) Authentication-Results: mx.nohats.ca; dkim=pass (1024-bit key) header.d=nohats.ca header.i=@nohats.ca header.b=HJ7VISMN X-OPENPGPKEY: Message passed unmodified X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id HGV6nq5B1UlQ; Sun, 2 Aug 2015 16:43:49 +0200 (CEST) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Sun, 2 Aug 2015 16:43:49 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 7AFB580042; Sun, 2 Aug 2015 10:43:48 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1438526628; bh=oGFZW9ZtLs9ylNxvlhaio/hOk8TG5HnS7G3yvPt08vk=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=HJ7VISMNhJCRGUtZF2giWNiKDXZafa5w66x6PlMoAgLA0ggYscBDCxpdTlikVr0Vq vWd6SSVldKsVYRQ5Zx/Hvm0OhLBSE7g9t+NYn8W5+nZ7kB7oA6p1XfT4jNNiUXg1xG HGU5YsZmbQ98WlVazjZ5qHxgv5aI4gyzKtZZpDd8= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.15.1/8.15.1/Submit) with ESMTP id t72Ehkdh016711; Sun, 2 Aug 2015 10:43:47 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Sun, 2 Aug 2015 10:43:46 -0400 (EDT) From: Paul Wouters To: =?ISO-8859-15?Q?Patrik_L=F6hr?= In-Reply-To: <55BD0A6A.2090802@posteo.de> Message-ID: References: <20150801174602.043B625ACC26@mx02.posteo.de> <55BD0A6A.2090802@posteo.de> User-Agent: Alpine 2.11 (LFD 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=iso-8859-15; format=flowed Content-Transfer-Encoding: 8BIT Archived-At: Cc: dane@ietf.org Subject: Re: [dane] OPENPGP and SMIME local part question X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 02 Aug 2015 14:43:54 -0000 On Sat, 1 Aug 2015, Patrik Löhr wrote: > We think it would be better for the local parts to use hashing. > > Our two points: > - The discussion obviously came up because of trying to determine a way > to find entries when users use upper and lower case characters. From our > perspective, this is not a problem that these drafts can solve. But the choice to solve this point is "allow two lookups" or "lowercase". > - Base encoding equates to plaintext transfer and for a security > feature, privacy should not be disregarded. > Hashing of local parts is definitely a great advance over plaintext > transfer in terms of security. Even if hashing was not initially > intended as a security feature, it is one. In any case, it distinctly > hinders the possibility of simply reading the data in DNS requests - > data that could convey a lot about the communication behaviour of users. But you would only be obfuscating the query, not the answer. The answer is actually even more interesting because it contains the entire key, possibly more email addresses as ID's and signatures. Assuming the key id the user asked for is present on the key obtained, it's trivial to hash the keyids and find the original query data. So you would gain security by hashing only for those you are willing to send plaintext email to? DNS privacy would help but then you should also be unwilling to use any random wifi network's DNS server, and build a VPN to a trusted DNS server farm. I would say let DPRIVE solve the DNS privacy for all DNS RRtypes. Paul From nobody Sun Aug 2 08:01:56 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18CB11A7001 for ; Sun, 2 Aug 2015 08:01:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.239 X-Spam-Level: X-Spam-Status: No, score=0.239 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_DE=0.35, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kgWu84XARpDF for ; Sun, 2 Aug 2015 08:01:53 -0700 (PDT) Received: from mail.sys4.de (mail.sys4.de [IPv6:2001:1578:400:111::7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 698161A6F2A for ; Sun, 2 Aug 2015 08:01:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sys4.de; h= in-reply-to:content-disposition:content-type:content-type :mime-version:references:message-id:subject:subject:from:from :date:date; s=mail201310; t=1438527710; x=1440342111; bh=SD9FC9j mB2UGf9Y+Y0ph7mcU7+kHMV/mXBMsIsVAno8=; b=GZeAkwQSKEMCVdrlyX/651d PspuBvGvmV/sHHvOTJ2QBv5zX3WtMFaoAfODS/m4qGrg+ybt9h0LtLkmRfpdSY/0 Im2+wCmy+Zy/X1YcFuRfcCZgIlVT2JMl92XPW5Hv/rzPac1610M847XRvKy9GukY 4gcg/Qq12002x5uThv/XUkIB8x68VkQHP7XM0FUU5oH8F8Ru5tvbaFh4Gs5X0UfX x8wd6/ffMnvGGot/fGM8wfn1J9H/oM9Z9tSr/VbZa0Q7VfjFBe0oU0CMR6mlpTBU LlZGd3Ntzm458PztiCyi2pSsxD0fcGx3vZkaNhB1+9QAs58yjAOMySUE31/Z7wA= = X-Virus-Scanned: Debian amavisd-new at mail.sys4.de Received: from sys4.de (mail.sys4.de [194.126.158.139]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.sys4.de (Postfix) with ESMTPSA id 3mkltQ5xNszFN for ; Sun, 2 Aug 2015 17:01:50 +0200 (CEST) Date: Sun, 2 Aug 2015 17:01:49 +0200 From: Florian Kirstein To: dane@ietf.org Message-ID: <20150802150149.GE18811@sys4.de> References: <20150801174602.043B625ACC26@mx02.posteo.de> <55BD0A6A.2090802@posteo.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: Archived-At: Subject: Re: [dane] OPENPGP and SMIME local part question X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 02 Aug 2015 15:01:55 -0000 Hi, > But the choice to solve this point is "allow two lookups" or "lowercase". If people see big issues with lowercase, I could live with "allow two lookups" (one lowercase) to handle people entering addresses manually. An UI could optionally (independant of the lookup) warn if the keys User-ID differs from what he entered. A milter of course can't do that. But as a milter's only other option is to send unencrypted, I would not see a problem there even in the theoretical case of a case collission. So I really don't see the benefits of base32 worth the privacy breach. > But you would only be obfuscating the query, not the answer. The answer > is actually even more interesting because it contains the entire key, Not really "more interesting" - someone who knows the email address can query the key himself... But of course, for successfull queries the answer would be visible. But for those at least the mail will most likeley be encrypted then :) The problem I (and I expect also Patrik) sees is all the "useless" queries. If a mail server operator wants to implement a milter, or a user wants to install a MUA plugin looking for keys, this will look up every address passing through. And we all know: for now that will in most cases NOT give a result for a forseeable future. So he will consider: is the few cases I get a key back worth the privacy leak for ALL THE OTHER addresses? And I see a big risk that this will slow or completely hinder deployment of such client side implementations, which will lead to not many people offering the recrods, which in the end will lead to suffering... I mean failure of OPENPGPKEY. And of course I totally agree that the real answer is DNS privacy, but if we wait for that to be widely deployed we can really delay our draft for another few years... So in my opinion it should be designed in a way that it at least offers the easy possible privacy by hashing, making it impossible to simply snoop all the addresses. I think it makes a big difference for the people on the client side. Greetings, Florian -- [*] sys4 AG http://sys4.de, +49 (89) 30 90 46 64 Franziskanerstrasse 15, 81669 Muenchen Sitz der Gesellschaft: Muenchen, Amtsgericht Muenchen: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein From nobody Sun Aug 2 12:30:48 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E3791ACE06 for ; Sun, 2 Aug 2015 12:30:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.1 X-Spam-Level: * X-Spam-Status: No, score=1.1 tagged_above=-999 required=5 tests=[BAYES_50=0.8, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u_f4bpgcpuHf for ; Sun, 2 Aug 2015 12:30:46 -0700 (PDT) Received: from xsmtp03.mail2web.com (xsmtp03.mail2web.com [168.144.250.223]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E6771ACE05 for ; Sun, 2 Aug 2015 12:30:46 -0700 (PDT) Received: from [10.5.2.49] (helo=xmail11.myhosting.com) by xsmtp03.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1ZLyy4-0006Yz-Fj for dane@ietf.org; Sun, 02 Aug 2015 15:30:45 -0400 Received: (qmail 26734 invoked from network); 2 Aug 2015 19:30:43 -0000 Received: from unknown (HELO huitema1) (Authenticated-user:_huitema@huitema.net@[24.16.156.113]) (envelope-sender ) by xmail11.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 2 Aug 2015 19:30:43 -0000 From: "Christian Huitema" To: "'Paul Wouters'" , =?ISO-8859-15?Q?'Patrik_L=F6hr'?= References: <20150801174602.043B625ACC26@mx02.posteo.de> <55BD0A6A.2090802@posteo.de> In-Reply-To: Date: Sun, 2 Aug 2015 12:30:40 -0700 Message-ID: <00e901d0cd59$b984dca0$2c8e95e0$@huitema.net> MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQFsoaNIRY4PBAbmcQi3c34CpxmNswHWiZmZAYLOAxmepqNF4A== Content-Language: en-us Archived-At: Cc: dane@ietf.org Subject: Re: [dane] OPENPGP and SMIME local part question X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 02 Aug 2015 19:30:47 -0000 On Sunday, August 2, 2015 7:44 AM, Paul Wouters wrote: > ... > DNS privacy would help but then you should also be unwilling to use any > random wifi network's DNS server, and build a VPN to a trusted DNS > server farm. > > I would say let DPRIVE solve the DNS privacy for all DNS RRtypes. Uh, No. DPRIVE is chartered to solve a different problem: prevent observers from gleaning meta-data by looking at the DNS requests originating from a client. I am concerned that we cannot keep email addresses and PGP keys private if we publish them in the DNS. Data published in the DNS is there to be read by everybody, there is no access control whatsoever. If we are concerned with the privacy of email addresses, then we should not publish them in the DNS. In that case, we would need a specialized service, probably incorporating some form of control based on a "social graph." -- Christian Huitema From nobody Sun Aug 2 18:54:11 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06B651B2AEA; Sun, 2 Aug 2015 18:54:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.2 X-Spam-Level: X-Spam-Status: No, score=-1.2 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tcNRLFKeiYla; Sun, 2 Aug 2015 18:54:05 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 98A1D1B2AD9; Sun, 2 Aug 2015 18:54:05 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 74435284D68; Mon, 3 Aug 2015 01:54:04 +0000 (UTC) Date: Mon, 3 Aug 2015 01:54:04 +0000 From: Viktor Dukhovni To: Elwyn Davies Message-ID: <20150803015404.GG19228@mournblade.imrryr.org> References: <55BDD0E9.7000805@dial.pipex.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <55BDD0E9.7000805@dial.pipex.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: General area reviewing team , iesg@ietf.org, dane@ietf.org Subject: Re: [dane] Gen-art telechat review of draft-ietf-dane-ops-14 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 03 Aug 2015 01:54:08 -0000 On Sun, Aug 02, 2015 at 06:12:25PM +1000, Elwyn Davies wrote: > Minor issues: > I am not totally convinced about the remaining usage of RFC 2118 keywords, > but I'll leave that for the ADs to consider. Thanks for the feedback. Rereading to see what SHOULDs/MUSTs/... might warrant adjustment. > Nits/editorial comments: > > There are a couple of nits introduced by the edits (or left over from the > previous version): > > s3, para 2: s/ When a servers does/When a server does/, > s/SHOULD respond/the server SHOULD respond/ > > s8, para 3, last sentence: s/the only other/The only other/ > > s10.1, next to last para: s/as when significantly/as the full certificates > are significantly/ > > s12, bullet 4: s/to processes extended/to process extended/ > > s14, last para: s/PKIX-TA(0(/PKIX-TA(0)/ Queued for the next revision. Thanks. -- Viktor. https://github.com/vdukhovni/ietf/commits/master commit dbce022a4dc2e813aa5bd0a0ab9d667a1af655eb Author: Viktor Dukhovni Date: Sun Aug 2 21:50:50 2015 -0400 IESG and GEN-ART Review feedback diff --git a/draft-ietf-dane-ops b/draft-ietf-dane-ops index 5f6befd..4705de9 100644 --- a/draft-ietf-dane-ops +++ b/draft-ietf-dane-ops @@ -91,17 +91,18 @@ a certificate or a public key of an end-entity or a trusted issuing authority with the corresponding TLS transport endpoint. DANE relies on the DNS Security Extensions (DNSSEC, ). DNSSEC validated DANE TLSA records can be - used to augment or replace the use of trusted public Certification - Authorities (CAs). + target="RFC4033"/>). DANE TLSA records validated by DNSSEC can + be used to augment or replace the use of trusted public + Certification Authorities (CAs). - defines three TLSA record fields with - respectively 4, 2 and 3 currently specified values. These yield - 24 distinct combinations of TLSA record types. This document - recommends a smaller set of best-practice combinations of these - fields to simplify protocol design, implementation and deployment. + defines three TLSA record fields, the + first with 4 possible values, the second with 2, and the third + with 3. These yield 24 distinct combinations of TLSA record + types. This document recommends a smaller set of best-practice + combinations of these fields to simplify protocol design, + implementation and deployment. @@ -303,12 +304,12 @@ _25._tcp.mail.example.com. IN TLSA 2 0 1 ( (SNI) extension of TLS (). Servers MAY support SNI and respond with a matching certificate chain, but MAY also ignore SNI and respond with a default certificate - chain. When a servers does support SNI, but is not configured - with a certificate chain that exactly matches the client's SNI - extension, SHOULD respond with some other (default or closest - match) certificate chain, since clients may support more than - one server name, but can only put a single name in the SNI - extension. + chain. When a server supports SNI but is not configured with + a certificate chain that exactly matches the client's SNI + extension, the server SHOULD respond with another certificate + chain (a default or closest match). This is because clients + might support more than one server name, but can only put a + single name in the SNI extension. @@ -1060,7 +1061,7 @@ _25._tcp.mx2.example.net. IN TLSA 3 1 1 ( PKIX Certificate Usages. Some clients may prefer to negotiate raw public keys, which are only compatible with TLSA records whose Certificate Usage is DANE-EE(3) - with selector SPKI(1). the only other TLSA record type that + with selector SPKI(1). The only other TLSA record type that is potentially compatible with raw public keys is DANE-EE(3) Cert(0) Full(0), but support for raw public keys with that TLSA record type is not expected to be broadly implemented. @@ -1390,7 +1391,7 @@ _25._tcp.mail.example.com. IN TLSA 3 1 0 ( While TLSA records using a TLSA Selector of SPKI(1) and a TLSA Matching Type of Full(0) (which publish the bare public keys without the overhead of a containing X.509 certificate) - are generally more compact, these are also best avoided as + are generally more compact, these are also best avoided when significantly larger than their digests. Rather, servers SHOULD publish digest-based TLSA Matching Types in their TLSA records. Instead, the complete corresponding @@ -1598,7 +1599,7 @@ _25._tcp.mail.example.com. IN TLSA 2 0 1 ( and explain that PKIX-EE(1) and PKIX-TA(0) are generally NOT RECOMMENDED. This document notes that with usage PKIX-TA(0) clients may need - to processes extended trust chains beyond the first trusted + to process extended trust chains beyond the first trusted issuer, when that issuer is not self-signed. recommends that DANE application @@ -1663,7 +1664,7 @@ _25._tcp.mail.example.com. IN TLSA 2 0 1 ( Thus, when TLSA records are used with opportunistic protocols - where the PKIX-TA(0( and PKIX-EE(1) do not apply, the recommended + where the PKIX-TA(0) and PKIX-EE(1) do not apply, the recommended protocol design is for servers to not publish such TLSA records, and for opportunistic TLS clients to use them to only enforce the use of (albeit unauthenticated) TLS, but otherwise treat From nobody Sun Aug 2 19:27:33 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2B601B2B39; Sun, 2 Aug 2015 19:27:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.114 X-Spam-Level: X-Spam-Status: No, score=-1.114 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FAKE_REPLY_C=1.486, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oFRrI0gS_HxV; Sun, 2 Aug 2015 19:27:28 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07C811B2B38; Sun, 2 Aug 2015 19:27:28 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 41CF9284D68; Mon, 3 Aug 2015 02:27:27 +0000 (UTC) Date: Mon, 3 Aug 2015 02:27:27 +0000 From: Viktor Dukhovni To: Joel Jaeggli , "Fred Baker (fred)" Message-ID: <20150803022726.GI19228@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <38816F37-D9A9-44C6-B7B0-071A6364EE5D@cisco.com> <20150802031457.26126.79480.idtracker@ietfa.amsl.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: "ops-dir@ietf.org" , The IESG , dane@ietf.org Subject: Re: [dane] Joel Jaeggli's No Objection on draft-ietf-dane-ops-14: (with COMMENT) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2015 02:27:30 -0000 On Sat, Aug 01, 2015 at 08:14:57PM -0700, Joel Jaeggli wrote: > COMMENT: > > From fred baker's opsdir review, I would like to see a commnet on these > from the authors. Sure. On Tue, Jun 23, 2015 at 07:32:56PM +0000, Fred Baker (fred) wrote: > Summary: Ready to go, two comments that might be considered last call or IESG comments if the AD agrees. > > I think the opening paragraph of the introduction needs some tweaking. > > The DANE TLSA specification ([RFC6698]) introduces the DNS "TLSA" > resource record type. TLSA records associate a certificate or a > public key of an end-entity or a trusted issuing authority with the > corresponding TLS transport endpoint. DNSSEC validated DANE TLSA > records can be used to augment or replace the use of trusted public > Certification Authorities (CAs). The latest version is: The DNS-Based Authentication of Named Entities (DANE) specification ([RFC6698]) introduces the DNS "TLSA" resource record type ("TLSA" is not an acronym). TLSA records associate a certificate or a public key of an end-entity or a trusted issuing authority with the corresponding TLS transport endpoint. DANE relies on the DNS Security Extensions (DNSSEC, [RFC4033]). DNSSEC validated DANE TLSA records can be used to augment or replace the use of trusted public Certification Authorities (CAs). > I'm not an expert on this, but I think it would be more accurate to say > that it replaces a PKI, not a CA. A CA probably deploys and operates a > PKI. However, it does so in the context of a business - it vets entities > that it will sell certificates to, and then sells them certificates, which > it stores somewhere such as a PKI. I would expect that the CA, in this > model, would have the same business (and hence is not replaced), but store > its certificates in TLSA records instead of or in addition to in a PKI. To me the paragraph looks fine as-is, it refers to augmenting or replacing "the use of trusted public CAs", not the CAs themselves. If we speak instead of replacing or augmenting the Web PKI, we'd need to explain what the Web PKI is (a bunch of trusted public CAs). So it is I think simpler to just say what is meant. If the text does not look sufficiently clear to others, I'm open to suggestions. > In section 1.1, a number of terms are defined, including "public key". If > "public key" needs definition (which it does, as the term is used to > specifically refer to a field within a certificate, as opposed to a more > general cryptographic usage), I think "Certificate Authority (CA)" and > "Public Key Infrastructure (PKI)", which are also used throughout the > document, require definition. A definition of "public key" has already been added to the terminology section. The term PKI is listed as "well-known" at: https://www.rfc-editor.org/rfc-style-guide/abbrev.expansion.txt The remaining proposed addition to the terminology section is "CA", which is expanded on first use, but not specifically defined in the terminology section. I might note that the terminology section of RFC 6698 consists entirely of a reference to other RFCs: This document also makes use of standard PKIX, DNSSEC, TLS, and DNS terminology. See [RFC5280], [RFC4033], [RFC5246], and STD 13 [RFC1034] [RFC1035], respectively, for these terms. In addition, terms related to TLS-protected application services and DNS names are taken from [RFC6125]. Would anything like that be appropriate for this draft (which now that I think of it still needs to add 6698 to the "updates" list)? -- Viktor. From nobody Mon Aug 3 19:10:16 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E2941B3330 for ; Mon, 3 Aug 2015 19:10:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.83 X-Spam-Level: * X-Spam-Status: No, score=1.83 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.741, RCVD_IN_DNSWL_LOW=-0.7, 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 FdLkDtA48FU5 for ; Mon, 3 Aug 2015 19:10:14 -0700 (PDT) Received: from cnnic.cn (smtp13.cnnic.cn [218.241.118.13]) by ietfa.amsl.com (Postfix) with ESMTP id 4635B1B3329 for ; Mon, 3 Aug 2015 19:10:09 -0700 (PDT) Received: from healthyao-THINK (unknown [218.241.103.72]) by ocmail02.zx.nicx.cn (Coremail) with SMTP id AQAAf0C5wJT_HsBV6davBw--.7243S2; Tue, 04 Aug 2015 10:10:07 +0800 (CST) Date: Tue, 4 Aug 2015 10:10:06 +0800 From: "Jiankang Yao" To: dane X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7.0.1.92[cn] Mime-Version: 1.0 Message-ID: <2015080410094450139169@cnnic.cn> Content-Type: multipart/alternative; boundary="----=_001_NextPart055623813510_=----" X-CM-TRANSID: AQAAf0C5wJT_HsBV6davBw--.7243S2 X-Coremail-Antispam: 1UD129KBjvdXoW7Gr18Zw1fJrWfXr13ArWrXwb_yoW3urc_ur yaqrZ3Ka1agws3Jan3Aws5WFZru3yxAr1UA34YqFnxt3yay347Aa98W3yDWF1UGa12vwsx KFnxWr1I9343ZjkaLaAFLSUrUUUUUb8apTn2vfkv8UJUUUU8Yxn0WfASr-VFAUDa7-sFnT 9fnUUIcSsGvfJTRUUUbfkYjsxI4VWkCwAYFVCjjxCrM7AC8VAFwI0_Jr0_Gr1l1xkIjI8I 6I8E6xAIw20EY4v20xvaj40_Wr0E3s1l1IIY67AEw4v_Jr0_Jr4l8cAvFVAK0II2c7xJM2 8CjxkF64kEwVA0rcxSw2x7M28EF7xvwVC0I7IYx2IY67AKxVW7JVWDJwA2z4x0Y4vE2Ix0 cI8IcVCY1x0267AKxVWxJVW8Jr1l84ACjcxK6I8E87Iv67AKxVW8Jr0_Cr1UM28EF7xvwV C2z280aVCY1x0267AKxVWxJr0_GcWle2I262IYc4CY6c8Ij28IcVAaY2xG8wAqx4xG6xAI xVCFxsxG0wAv7VC0I7IYx2IY67AKxVWUJVWUGwAv7VC2z280aVAFwI0_Jr0_Gr1lOx8S6x CaFVCjc4AY6r1j6r4UM4x0Y48IcxkI7VAKI48JM4xvF2IEb7IF0Fy264kE64k0F24lFcxC 0VAYjxAxZF0Ex2IqxwCY02Avz4vE14v_Gr1l42xK82IYc2Ij64vIr41l4I8I3I0E4IkC6x 0Yz7v_Jr0_Gr1lx2IqxVAqx4xG67AKxVWUGVWUWwC20s026x8GjcxK67AKxVWUGVWUWwC2 zVAF1VAY17CE14v26r1j6r15MIIYrxkI7VAKI48JMIIF0xvE2Ix0cI8IcVAFwI0_Jr0_JF 4lIxAIcVC0I7IYx2IY6xkF7I0E14v26r1j6r4UMIIF0xvE42xK8VAvwI8IcIk0rVWrZr1j 6s0DMIIF0xvEx4A2jsIE14v26r1j6r4UMIIF0xvEx4A2jsIEc7CjxVAFwI0_Jr0_Gr1l6V ACY4xI67k04243AbIYCTnIWIevJa73UjIFyTuYvjxU2H7KDUUUU X-CM-SenderInfo: x1dryyw6fq0xffof0/ Archived-At: Subject: [dane] hash truncated to 28 octets X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: yaojk List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Aug 2015 02:10:15 -0000 This is a multi-part message in MIME format. ------=_001_NextPart055623813510_=---- Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: base64 SGVsbG8sDQoNCg0KSSBqdXN0IHJlYWQgdGhpcyBkcmFmdC4NCg0KaW4gc2VjdGlvbiAzLCBvZiBk cmFmdC1pZXRmLWRhbmUtb3BlbnBncGtleS0wMy50eHQgDQoNCiINCg0KSWYgaXQoImxvY2FsLXBh cnQiIGluIHRoZSBtYWlsIG1lc3NhZ2UgKSBpcyB3cml0dGVuIGluIGFub3RoZXIgZW5jb2Rpbmcg aXQgc2hvdWxkIGJlDQogICAgICBjb252ZXJ0ZWQgdG8gVVRGLTguICBOZXh0LCBpdCBpcyB0dXJu ZWQgaW50byBsb3dlcmNhc2UgYW5kIGhhc2hlZA0KICAgICAgdXNpbmcgdGhlIFNIQTItMjU2IFtS RkM1NzU0XSBhbGdvcml0aG0sIHdpdGggdGhlIGhhc2ggdHJ1bmNhdGVkIHRvDQogICAgICAyOCBv Y3RldHMgYW5kIHJlcHJlc2VudGVkIGluIGl0cyBoZXhhZGVjaW1hbCByZXByZXNlbnRhdGlvbiwg dG8NCiAgICAgIGJlY29tZSB0aGUgbGVmdC1tb3N0IGxhYmVsIGluIHRoZSBwcmVwYXJlZCBkb21h aW4gbmFtZS4NCiAgICAgIFRydW5jYXRpb24gY29tZXMgZnJvbSB0aGUgcmlnaHQtbW9zdCBvY3Rl dHMuICBUaGlzIGRvZXMgbm90DQogICAgICBpbmNsdWRlIHRoZSBhdCBzeW1ib2wgKCJAIikgdGhh dCBzZXBhcmF0ZXMgdGhlIGxlZnQgYW5kIHJpZ2h0DQogICAgICBzaWRlcyBvZiB0aGUgZW1haWwg YWRkcmVzcy4NCiINCg0KUXVlc3Rpb246DQoxLCB3aHkgc2hvdWxkIGl0IGJlICBoYXNoIHRydW5j YXRlZCB0byAyOCBvY3RldHMgPyB3aHkgY2hvb3NlIDI4IG5vdCBvdGhlciBudW1iZXJzPw0KMixz aW5jZSBzb21lIGxvY2FsLXBhcnRzIGFyZSBsb25nZXIgdGhhbiAyOCBvY3RldHMsIGFyZSB0aGVy ZSBzb21lIGNvbGxpc2lvbnMgYWZ0ZXIgaGFzaCB0cnVuY2F0ZWQgdG8gMjggb2N0ZXRzID8NCg0K DQoNCkJlc3QgUmVnYXJkDQoNCg0KDQpKaWFua2FuZyBZYW8= ------=_001_NextPart055623813510_=---- Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hello,
 
 
I just read this draft.
 
in section 3, of draft-ietf-dane-openpgpkey-03.txt
 
"
 
If it("local-part" in the mail message ) is written in another encodi= ng it=20 should be
      converted to UTF-8.  Next= , it=20 is turned into lowercase and hashed
      usin= g the=20 SHA2-256 [RFC5754] algorithm, with the hash truncated=20 to
      28 octets and represented in its=20 hexadecimal representation, to
      become th= e=20 left-most label in the prepared domain name.
    &n= bsp;=20 Truncation comes from the right-most octets.  This does=20 not
      include the at symbol ("@") that sep= arates=20 the left and right
      sides of the email=20 address.
"
 
Question:
1, why should it=20 be  hash truncated to 28 octets ? why c= hoose=20 28 not other numbers?
2,since some local-parts are longer than 28 octets, are there some=20 collisions after hash truncated to 28 octets ?
 
 

Best Regard
Jiankang Yao
------=_001_NextPart055623813510_=------ From nobody Mon Aug 3 21:06:59 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C1AD1B3447; Mon, 3 Aug 2015 21:06:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=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 pmIvPZNWCgHg; Mon, 3 Aug 2015 21:06:56 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FA641B3440; Mon, 3 Aug 2015 21:06:56 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Spencer Dawkins" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.3.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150804040656.19706.87231.idtracker@ietfa.amsl.com> Date: Mon, 03 Aug 2015 21:06:56 -0700 Archived-At: Cc: dane-chairs@ietf.org, dane@ietf.org, draft-ietf-dane-ops.ad@ietf.org, draft-ietf-dane-ops.shepherd@ietf.org, draft-ietf-dane-ops@ietf.org Subject: [dane] Spencer Dawkins' No Objection on draft-ietf-dane-ops-14: (with COMMENT) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Aug 2015 04:06:58 -0000 Spencer Dawkins has entered the following ballot position for draft-ietf-dane-ops-14: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dane-ops/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for producing this document. I wish the IETF could produce more like it. I had a bunch of editorial comments and questions. I see how nuanced the recommendations are, so I might just lack the background to understand some of the material, but I wanted to pass them along. I was sort of surprised that the first two paragraphs of the introduction were about TLS and DTLS, and DANE wasn't mentioned until the third paragraph. Maybe move the third paragraph to the top of the section? In section 1.1, in this text: TLSA parameters: In [RFC6698] the TLSA record is defined to consist of four fields. The first three of these are numeric parameters that specify the meaning of the data in the fourth and final field. This document refers to the first three fields as "TLSA parameters", or sometimes just "parameters" when obvious from context. I was pretty lost until I got to section 2, where at least the first three fields were named - the fourth wasn't named until the last line of Section 2.1. Any chance all four fields could be named here? In section 4, in this text: Protocol designers need to carefully consider which set of DANE certificate usages to support. Simultaneous support for all four usages is NOT RECOMMENDED for DANE clients. Protocol designers are encouraged to specify use of either the PKIX-TA(0) and PKIX-EE(1) ^^^^^^ ^^^ certificate usages, or the use of the DANE-TA(2) and DANE-EE(3) ^^ ^^^ usages. When all four usages are supported, an attacker capable of compromising the integrity of DNSSEC needs only to replace server's TLSA RRset with one that lists suitable DANE-EE(3) or DANE-TA(2) records, effectively bypassing an added verification via public CAs. In other words, when all four usages are supported, PKIX-TA(2) and PKIX-EE(1) offer only illusory incremental security over DANE-TA(2) and DANE-EE(3). I'm sure the third sentence is accurate, but it took me a while to parse the logical operators and figure out that the point was XOR ((A and B), (C and D)) (I think). I think the paragraph would actually be clearer with that sentence completely removed. About six paragraphs down into section 5.1, I see TLSA records published for DANE servers should, as a best practice, be "DANE-EE(3) SPKI(1) SHA2-256(1)" records. Is this an unqualified "do this in all cases"? If so, it's buried really deeply. If not, it wasn't obvious to me what the qualifications might be. Just as a nit, in section 5.2.2, I see With DANE-TA(2), a complication arises when the TA certificate is omitted from the server's certificate chain, perhaps on the basis of Section 7.4.2 of [RFC5246]: The sender's certificate MUST come first in the list. Each following certificate MUST directly certify the one preceding it. Because certificate validation requires that root keys be distributed independently, the self-signed certificate that specifies the root certification authority MAY be omitted from the chain, under the assumption that the remote end must already possess it in order to validate it in any case. Is that where the quote stops? I didn't check, but indenting the quote would help. Thanks for including section 10.1.1, UDP and TCP Considerations. In section 10.1.2, While TLSA records using a TLSA Selector of SPKI(1) and a TLSA Matching Type of Full(0) (which publish the bare public keys without the overhead of a containing X.509 certificate) are generally more compact, these are also best avoided as when significantly larger ^^^^^^^ than their digests. The ^^^^ text wasn't parsing for me. "because they are/can be significantly larger"? But I'm guessing. In section 10.3, If, on the other hand, the use of TLS is "opportunistic", then the client SHOULD generally use the server via an unauthenticated TLS connection, but if TLS encryption cannot be established, the client MUST NOT use the server. Standards for DANE specific to the particular application protocol may modify the above requirements, as appropriate. I found myself wondering how you'd know modifying those requirements is appropriate. Is there any guidance you could give, or an example? In section 11, When the registrar is also the DNS operator for the domain, one needs to consider whether the registrar will allow orderly migration of the domain to another registrar or DNS operator in a way that will maintain DNSSEC integrity. TLSA Publishers SHOULD ensure their registrar publishes a suitable domain transfer policy. I'm thinking that's not an RFC 2119 SHOULD, but if it is, I wonder why it's not a MUST ... I have the same thoughts about this text in section 11, DNS Operators SHOULD use a registrar lock of their domains to offer some protection against this possibility. and this text, in the following paragraph. TLSA Publishers SHOULD ensure their registrar publishes a suitable domain transfer policy. From nobody Mon Aug 3 22:00:01 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D34E61B2D87; Mon, 3 Aug 2015 21:59:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EWwaBC8s_X3c; Mon, 3 Aug 2015 21:59:57 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21C111B2BDD; Mon, 3 Aug 2015 21:59:53 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 95FA0284D64; Tue, 4 Aug 2015 04:59:52 +0000 (UTC) Date: Tue, 4 Aug 2015 04:59:52 +0000 From: Viktor Dukhovni To: Spencer Dawkins Message-ID: <20150804045952.GH19228@mournblade.imrryr.org> References: <20150804040656.19706.87231.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150804040656.19706.87231.idtracker@ietfa.amsl.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: draft-ietf-dane-ops.shepherd@ietf.org, draft-ietf-dane-ops.ad@ietf.org, dane-chairs@ietf.org, The IESG , dane@ietf.org Subject: Re: [dane] Spencer Dawkins' No Objection on draft-ietf-dane-ops-14: (with COMMENT) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Aug 2015 05:00:00 -0000 On Mon, Aug 03, 2015 at 09:06:56PM -0700, Spencer Dawkins wrote: > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Thanks for producing this document. I wish the IETF could produce more > like it. Wow, thanks! > I was sort of surprised that the first two paragraphs of the introduction > were about TLS and DTLS, and DANE wasn't mentioned until the third > paragraph. Maybe move the third paragraph to the top of the section? In the latest version, the first two paragraphs of the introduction are: The Transport Layer Security (TLS) [RFC5246] and Datagram Transport Layer Security (DTLS) [RFC6347] protocols provide secured TCP and UDP communication, respectively, over IP. In the context of this document, channel security is assumed to be provided by TLS or DTLS. By convention, "TLS" will be used throughout this document and, unless otherwise specified, the text applies equally well to DTLS over UDP. Used without authentication, TLS provides protection only against eavesdropping through its use of encryption. With authentication, TLS also provides integrity protection and authentication, which protects the transport against man-in-the-middle (MiTM) attacks. The DNS-Based Authentication of Named Entities (DANE) specification ([RFC6698]) introduces the DNS "TLSA" resource record type ("TLSA" is not an acronym). TLSA records associate a certificate or a public key of an end-entity or a trusted issuing authority with the corresponding TLS transport endpoint. DANE relies on the DNS Security Extensions (DNSSEC, [RFC4033]). DANE TLSA records validated by DNSSEC can be used to augment or replace the use of trusted public Certification Authorities (CAs). I think it is simple enough to switch these while keeping TLS expanded on first use. Will do, thanks for the suggestion. > In section 1.1, in this text: > > TLSA parameters: In [RFC6698] the TLSA record is defined to consist > of four fields. The first three of these are numeric parameters > that specify the meaning of the data in the fourth and final > field. This document refers to the first three fields as "TLSA > parameters", or sometimes just "parameters" when obvious from > context. > > I was pretty lost until I got to section 2, where at least the first > three fields were named - the fourth wasn't named until the last line of > Section 2.1. Any chance all four fields could be named here? Yeah, we should avoid the needless suspense . > In section 4, in this text: > > Protocol designers need to carefully consider which set of DANE > certificate usages to support. Simultaneous support for all four > usages is NOT RECOMMENDED for DANE clients. Protocol designers are > encouraged to specify use of either the PKIX-TA(0) and PKIX-EE(1) > ^^^^^^ ^^^ > certificate usages, or the use of the DANE-TA(2) and DANE-EE(3) > ^^ ^^^ > usages. When all four usages are supported, an attacker capable of > compromising the integrity of DNSSEC needs only to replace server's > TLSA RRset with one that lists suitable DANE-EE(3) or DANE-TA(2) > records, effectively bypassing an added verification via public CAs. > In other words, when all four usages are supported, PKIX-TA(2) and > PKIX-EE(1) offer only illusory incremental security over DANE-TA(2) > and DANE-EE(3). This paragraph is being rewritten as we speak to address earlier comments about ensuring clarity of who these "protocol designers" are, and being more clear about what we want them to do. > I'm sure the third sentence is accurate, but it took me a while to parse > the logical operators and figure out that the point was XOR ((A and B), > (C and D)) (I think). I think the paragraph would actually be clearer > with that sentence completely removed. I am always of fixing bugs by deleting code. Thanks. I think that works. > About six paragraphs down into section 5.1, I see > > TLSA records published for DANE servers should, as a best practice, > be "DANE-EE(3) SPKI(1) SHA2-256(1)" records. > > Is this an unqualified "do this in all cases"? If so, it's buried really > deeply. If not, it wasn't obvious to me what the qualifications might > be. This is a best-practice, not a mandate. At some sites, it makes sense to use "DANE-TA(2) Cert(0) SHA2-256(1)", when many services have certificates from a common CA (trust-anchor), and the domain operator prefers to decouple ceritificate rotation from DNS updates. In the "2 0 1" variant (also described), the server TLSA RRsets are CNAMEs to the shared RRset that lists the digests of trusted CA certificates. The "3 1 1" case will be by far more numerous, but the "2 0 1" case is also an equally valid alternative, for sites with lots of DANE services (the downside is that virtual hosting becomes more complex). Perhaps there's a better way to describe a situation where there's a best-practice for 95% of users and a second best practice for the remainin 5% (numbers made up, but the idea is right)? > Just as a nit, in section 5.2.2, I see > > With DANE-TA(2), a complication arises when the TA certificate is > omitted from the server's certificate chain, perhaps on the basis of > Section 7.4.2 of [RFC5246]: > > The sender's certificate MUST come first in the list. Each > following certificate MUST directly certify the one preceding > it. Because certificate validation requires that root keys be > distributed independently, the self-signed certificate that > specifies the root certification authority MAY be omitted from > the chain, under the assumption that the remote end must > already possess it in order to validate it in any case. > > Is that where the quote stops? I didn't check, but indenting the quote > would help. It was indented in the .html version produced by xml2rfc, but not in the .txt. Fixed. Thanks. > Thanks for including section 10.1.1, UDP and TCP Considerations. > > In section 10.1.2, > > While TLSA records using a TLSA Selector of SPKI(1) and a TLSA > Matching Type of Full(0) (which publish the bare public keys without > the overhead of a containing X.509 certificate) are generally more > compact, these are also best avoided as when significantly larger > ^^^^^^^ > than their digests. > > The ^^^^ text wasn't parsing for me. "because they are/can be > significantly larger"? But I'm guessing. Thanks, the problem was already queued to be fixed in the final version. It now reads: While TLSA records using a TLSA Selector of SPKI(1) and a TLSA Matching Type of Full(0) (which publish the bare public keys without the overhead of a containing X.509 certificate) are generally more compact, these are also best avoided when significantly larger than their digests. (For 256-bit EC keys, it is likely that the key size and the digest size are close in size, and the full key is fine in that case). > In section 10.3, > > If, on the other hand, the use of TLS is "opportunistic", then the > client SHOULD generally use the server via an unauthenticated TLS > connection, but if TLS encryption cannot be established, the client > MUST NOT use the server. Standards for DANE specific to the > particular application protocol may modify the above requirements, as > appropriate. > > I found myself wondering how you'd know modifying those requirements is > appropriate. Is there any guidance you could give, or an example? Hard to say what makes the most sense in some hypothetical opportunistic application. For opportunistic applications a key consideration is whether we're asking for more security than we can realistically expect (see RFC7435). If not, then the design is fine, if yes, then even in the absense of active attacks clients run into problems with various peers that do not interoperate "securely enough". That's a problem, because there are then strong incentives to just disable "OS" and stick with cleartext. So the bar needs to be set at a realistic level. I'd expect that requiring at least some form of (unauthenticated) TLS from sites that publish TLSA RRs (even if unusable) is likely safe, but perhaps that's too much to expect in some cases, or not worth the small security gains. Should some version of the above elaboration go in the text? > In section 11, > > When the registrar is also the DNS operator for the domain, one needs > to consider whether the registrar will allow orderly migration of the > domain to another registrar or DNS operator in a way that will > maintain DNSSEC integrity. TLSA Publishers SHOULD ensure their > registrar publishes a suitable domain transfer policy. > > I'm thinking that's not an RFC 2119 SHOULD, but if it is, I wonder why > it's not a MUST ... Excellent observation. Perhaps 2119 is indeed too strong here. Failure to do that may make it difficult for the domain owner to ever move the domain to another registrar without breakage. But there's no interoperability issue while the domain stays put. If we want to ensure that domains can be moved without downtime (or downgrades to unsigned during the move) then this is a MUST (on operational, rather than interoperability grounds). So not sure where to go with this. > I have the same thoughts about this text in section 11, > > DNS Operators SHOULD use a registrar lock of their domains > to offer some protection against this possibility. > > and this text, in the following paragraph. > > TLSA Publishers SHOULD ensure their > registrar publishes a suitable domain transfer policy. These address a security issue, without a lock, another registrar might claim the domain without authorization, and then replace the DS RRset, and publish rogue keys. This is again operational advice with a security impact. Whether 2119 is the right way to state that advice, I am not sure. Guidance from the IESG would be great. -- Viktor. From nobody Mon Aug 3 22:50: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 0DAA11B35F1; Mon, 3 Aug 2015 22:50:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XTr5VdQHg34Y; Mon, 3 Aug 2015 22:50:14 -0700 (PDT) Received: from mail-vk0-x22d.google.com (mail-vk0-x22d.google.com [IPv6:2607:f8b0:400c:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86A4B1B35EE; Mon, 3 Aug 2015 22:50:14 -0700 (PDT) Received: by vkhg129 with SMTP id g129so50564269vkh.2; Mon, 03 Aug 2015 22:50:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=NBizW79ro3xG9Ygoh13GB2yxGehM10DNIDFGuUci3AQ=; b=IoVyQ8h+6WqMKc26TEJ/Ghou+82cBvdFIKvzkDhpt4woKFKRUgjfe7eNaX0Uy3we1V yTJgQP/b6zWyxroP45eBmwEXsO9U8icmHzbTgOMWh3b9Dv37oDNp5CYWawM+CAA1hpNh TzUKcdwFO9MwiBRWVkjmD7ZHyvMJrTO1dzbJ5aEq81XDLuWkvI3EuvEA/rCYsMH8wQt/ FFIBOZ4IPaN2d9x0h5YhdIxQhXmq9uELSe/G7uCh3Pki35cB505OQPQK1fE2MSHBcc0U ZbuEYhsa/cYLqBWzkE/aIilLYOMU4LkR+oO1sclS8B1a/WuxGVV4wqtsmsGlmPPnDGHe eP0g== MIME-Version: 1.0 X-Received: by 10.52.116.67 with SMTP id ju3mr2782979vdb.66.1438667413749; Mon, 03 Aug 2015 22:50:13 -0700 (PDT) Received: by 10.31.63.1 with HTTP; Mon, 3 Aug 2015 22:50:13 -0700 (PDT) In-Reply-To: <20150804045952.GH19228@mournblade.imrryr.org> References: <20150804040656.19706.87231.idtracker@ietfa.amsl.com> <20150804045952.GH19228@mournblade.imrryr.org> Date: Tue, 4 Aug 2015 00:50:13 -0500 Message-ID: From: Spencer Dawkins at IETF To: Viktor Dukhovni Content-Type: multipart/alternative; boundary=bcaec548aa59258633051c75dc25 Archived-At: Cc: draft-ietf-dane-ops.shepherd@ietf.org, draft-ietf-dane-ops.ad@ietf.org, dane-chairs@ietf.org, The IESG , dane@ietf.org Subject: Re: [dane] Spencer Dawkins' No Objection on draft-ietf-dane-ops-14: (with COMMENT) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Aug 2015 05:50:19 -0000 --bcaec548aa59258633051c75dc25 Content-Type: text/plain; charset=UTF-8 Hi, Viktor, Thanks for the speedy response! Just a couple of things ... everything else you said, is fine with me. On Mon, Aug 3, 2015 at 11:59 PM, Viktor Dukhovni wrote: > On Mon, Aug 03, 2015 at 09:06:56PM -0700, Spencer Dawkins wrote: > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > Thanks for producing this document. I wish the IETF could produce more > > like it. > > Wow, thanks! > > > I was sort of surprised that the first two paragraphs of the introduction > > were about TLS and DTLS, and DANE wasn't mentioned until the third > > paragraph. Maybe move the third paragraph to the top of the section? > > In the latest version, the first two paragraphs of the introduction are: > > The Transport Layer Security (TLS) [RFC5246] and Datagram > Transport Layer Security (DTLS) [RFC6347] protocols provide > secured TCP and UDP communication, respectively, over IP. In > the context of this document, channel security is assumed to > be provided by TLS or DTLS. By convention, "TLS" will be used > throughout this document and, unless otherwise specified, the > text applies equally well to DTLS over UDP. Used without > authentication, TLS provides protection only against eavesdropping > through its use of encryption. With authentication, TLS also > provides integrity protection and authentication, which protects > the transport against man-in-the-middle (MiTM) attacks. > > The DNS-Based Authentication of Named Entities (DANE) specification > ([RFC6698]) introduces the DNS "TLSA" resource record type > ("TLSA" is not an acronym). TLSA records associate a certificate > or a public key of an end-entity or a trusted issuing authority > with the corresponding TLS transport endpoint. DANE relies on > the DNS Security Extensions (DNSSEC, [RFC4033]). DANE TLSA > records validated by DNSSEC can be used to augment or replace > the use of trusted public Certification Authorities (CAs). > > I think it is simple enough to switch these while keeping TLS > expanded on first use. Will do, thanks for the suggestion. > > > In section 1.1, in this text: > > > > TLSA parameters: In [RFC6698] the TLSA record is defined to consist > > of four fields. The first three of these are numeric parameters > > that specify the meaning of the data in the fourth and final > > field. This document refers to the first three fields as "TLSA > > parameters", or sometimes just "parameters" when obvious from > > context. > > > > I was pretty lost until I got to section 2, where at least the first > > three fields were named - the fourth wasn't named until the last line of > > Section 2.1. Any chance all four fields could be named here? > > Yeah, we should avoid the needless suspense . > > > In section 4, in this text: > > > > Protocol designers need to carefully consider which set of DANE > > certificate usages to support. Simultaneous support for all four > > usages is NOT RECOMMENDED for DANE clients. Protocol designers are > > encouraged to specify use of either the PKIX-TA(0) and PKIX-EE(1) > > ^^^^^^ ^^^ > > certificate usages, or the use of the DANE-TA(2) and DANE-EE(3) > > ^^ ^^^ > > usages. When all four usages are supported, an attacker capable of > > compromising the integrity of DNSSEC needs only to replace server's > > TLSA RRset with one that lists suitable DANE-EE(3) or DANE-TA(2) > > records, effectively bypassing an added verification via public CAs. > > In other words, when all four usages are supported, PKIX-TA(2) and > > PKIX-EE(1) offer only illusory incremental security over DANE-TA(2) > > and DANE-EE(3). > > This paragraph is being rewritten as we speak to address earlier > comments about ensuring clarity of who these "protocol designers" > are, and being more clear about what we want them to do. > > > I'm sure the third sentence is accurate, but it took me a while to parse > > the logical operators and figure out that the point was XOR ((A and B), > > (C and D)) (I think). I think the paragraph would actually be clearer > > with that sentence completely removed. > > I am always of fixing bugs by deleting code. Thanks. I think that works. > > > About six paragraphs down into section 5.1, I see > > > > TLSA records published for DANE servers should, as a best practice, > > be "DANE-EE(3) SPKI(1) SHA2-256(1)" records. > > > > Is this an unqualified "do this in all cases"? If so, it's buried really > > deeply. If not, it wasn't obvious to me what the qualifications might > > be. > > This is a best-practice, not a mandate. Ack. I'm trying to understand if it's always a best practice. > At some sites, it makes sense to use "DANE-TA(2) Cert(0) SHA2-256(1)", > when many services have certificates from a common CA (trust-anchor), > and the domain operator prefers to decouple ceritificate rotation > from DNS updates. In the "2 0 1" variant (also described), the > server TLSA RRsets are CNAMEs to the shared RRset that lists the > digests of trusted CA certificates. > > The "3 1 1" case will be by far more numerous, but the "2 0 1" case > is also an equally valid alternative, for sites with lots of DANE > services (the downside is that virtual hosting becomes more complex). > > Perhaps there's a better way to describe a situation where there's > a best-practice for 95% of users and a second best practice for > the remainin 5% (numbers made up, but the idea is right)? Something like this (especially explaining the tradeoff, as you did) seems helpful. > > Just as a nit, in section 5.2.2, I see > > > > With DANE-TA(2), a complication arises when the TA certificate is > > omitted from the server's certificate chain, perhaps on the basis of > > Section 7.4.2 of [RFC5246]: > > > > The sender's certificate MUST come first in the list. Each > > following certificate MUST directly certify the one preceding > > it. Because certificate validation requires that root keys be > > distributed independently, the self-signed certificate that > > specifies the root certification authority MAY be omitted from > > the chain, under the assumption that the remote end must > > already possess it in order to validate it in any case. > > > > Is that where the quote stops? I didn't check, but indenting the quote > > would help. > > It was indented in the .html version produced by xml2rfc, but not > in the .txt. Fixed. Thanks. > > > Thanks for including section 10.1.1, UDP and TCP Considerations. > > > > In section 10.1.2, > > > > While TLSA records using a TLSA Selector of SPKI(1) and a TLSA > > Matching Type of Full(0) (which publish the bare public keys without > > the overhead of a containing X.509 certificate) are generally more > > compact, these are also best avoided as when significantly larger > > ^^^^^^^ > > than their digests. > > > > The ^^^^ text wasn't parsing for me. "because they are/can be > > significantly larger"? But I'm guessing. > > Thanks, the problem was already queued to be fixed in the final > version. It now reads: > > While TLSA records using a TLSA Selector of SPKI(1) and a TLSA > Matching Type of Full(0) (which publish the bare public keys > without the overhead of a containing X.509 certificate) are > generally more compact, these are also best avoided when > significantly larger than their digests. > > (For 256-bit EC keys, it is likely that the key size and the digest > size are close in size, and the full key is fine in that case). > > > In section 10.3, > > > > If, on the other hand, the use of TLS is "opportunistic", then the > > client SHOULD generally use the server via an unauthenticated TLS > > connection, but if TLS encryption cannot be established, the client > > MUST NOT use the server. Standards for DANE specific to the > > particular application protocol may modify the above requirements, as > > appropriate. > > > > I found myself wondering how you'd know modifying those requirements is > > appropriate. Is there any guidance you could give, or an example? > You could reasonably have asked if I was overreacting to the word "appropriate", but since you didn't ... :-) > Hard to say what makes the most sense in some hypothetical > opportunistic application. > > For opportunistic applications a key consideration is whether we're > asking for more security than we can realistically expect (see > RFC7435). If not, then the design is fine, if yes, then even in > the absense of active attacks clients run into problems with various > peers that do not interoperate "securely enough". That's a problem, > because there are then strong incentives to just disable "OS" and > stick with cleartext. > > So the bar needs to be set at a realistic level. I'd expect that > requiring at least some form of (unauthenticated) TLS from sites > that publish TLSA RRs (even if unusable) is likely safe, but perhaps > that's too much to expect in some cases, or not worth the small > security gains. > > Should some version of the above elaboration go in the text? It was really helpful for me. Maybe just saying "may modify the above requirements, if (a sentence or two that points toward your elaboration)"? > > > In section 11, > > > > When the registrar is also the DNS operator for the domain, one needs > > to consider whether the registrar will allow orderly migration of the > > domain to another registrar or DNS operator in a way that will > > maintain DNSSEC integrity. TLSA Publishers SHOULD ensure their > > registrar publishes a suitable domain transfer policy. > > > > I'm thinking that's not an RFC 2119 SHOULD, but if it is, I wonder why > > it's not a MUST ... > > Excellent observation. > > Perhaps 2119 is indeed too strong here. Failure to do that may > make it difficult for the domain owner to ever move the domain to > another registrar without breakage. But there's no interoperability > issue while the domain stays put. If we want to ensure that domains > can be moved without downtime (or downgrades to unsigned during > the move) then this is a MUST (on operational, rather than > interoperability grounds). So not sure where to go with this. I've seen RFC 2119 language used in even stranger ways in published RFCs. I'm not sure that's a good thing. > > I have the same thoughts about this text in section 11, > > > > DNS Operators SHOULD use a registrar lock of their domains > > to offer some protection against this possibility. > > > > and this text, in the following paragraph. > > > > TLSA Publishers SHOULD ensure their > > registrar publishes a suitable domain transfer policy. > > These address a security issue, without a lock, another registrar > might claim the domain without authorization, and then replace the > DS RRset, and publish rogue keys. This is again operational advice > with a security impact. Whether 2119 is the right way to state > that advice, I am not sure. Guidance from the IESG would be great. If you're not convinced that using RFC 2119 language in this way is the right thing to do, you might say "need to X, because if they don't Y happens". That might be more helpful than a SHOULD. Does that help? Spencer --bcaec548aa59258633051c75dc25 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi, Viktor,

Thanks for the speedy respo= nse! Just a couple of things ... everything else you said, is fine with me.=

On Mon, Aug= 3, 2015 at 11:59 PM, Viktor Dukhovni <ietf-dane@dukhovni.org>= wrote:
On Mon, A= ug 03, 2015 at 09:06:56PM -0700, Spencer Dawkins wrote:

> ----------------------------------------------------------------------=
> COMMENT:
> ----------------------------------------------------------------------=
>
> Thanks for producing this document. I wish the IETF could produce more=
> like it.

Wow, thanks!

> I was sort of surprised that the first two paragraphs of the introduct= ion
> were about TLS and DTLS, and DANE wasn't mentioned until the third=
> paragraph. Maybe move the third paragraph to the top of the section?
In the latest version, the first two paragraphs of the introduction = are:

=C2=A0 =C2=A0 The Transport Layer Security (TLS) [RFC5246] and Datagram
=C2=A0 =C2=A0 Transport Layer Security (DTLS) [RFC6347] protocols provide =C2=A0 =C2=A0 secured TCP and UDP communication, respectively, over IP. In<= br> =C2=A0 =C2=A0 the context of this document, channel security is assumed to<= br> =C2=A0 =C2=A0 be provided by TLS or DTLS. By convention, "TLS" wi= ll be used
=C2=A0 =C2=A0 throughout this document and, unless otherwise specified, the=
=C2=A0 =C2=A0 text applies equally well to DTLS over UDP.=C2=A0 Used withou= t
=C2=A0 =C2=A0 authentication, TLS provides protection only against eavesdro= pping
=C2=A0 =C2=A0 through its use of encryption. With authentication, TLS also<= br> =C2=A0 =C2=A0 provides integrity protection and authentication, which prote= cts
=C2=A0 =C2=A0 the transport against man-in-the-middle (MiTM) attacks.

=C2=A0 =C2=A0 The DNS-Based Authentication of Named Entities (DANE) specifi= cation
=C2=A0 =C2=A0 ([RFC6698]) introduces the DNS "TLSA" resource reco= rd type
=C2=A0 =C2=A0 ("TLSA" is not an acronym). TLSA records associate = a certificate
=C2=A0 =C2=A0 or a public key of an end-entity or a trusted issuing authori= ty
=C2=A0 =C2=A0 with the corresponding TLS transport endpoint. DANE relies on=
=C2=A0 =C2=A0 the DNS Security Extensions (DNSSEC, [RFC4033]). DANE TLSA =C2=A0 =C2=A0 records validated by DNSSEC can be used to augment or replace=
=C2=A0 =C2=A0 the use of trusted public Certification Authorities (CAs).
I think it is simple enough to switch these while keeping TLS
expanded on first use.=C2=A0 Will do, thanks for the suggestion.

> In section 1.1, in this text:
>
>=C2=A0 =C2=A0 TLSA parameters:=C2=A0 In [RFC6698] the TLSA record is de= fined to consist
>=C2=A0 =C2=A0 =C2=A0 =C2=A0of four fields.=C2=A0 The first three of the= se are numeric parameters
>=C2=A0 =C2=A0 =C2=A0 =C2=A0that specify the meaning of the data in the = fourth and final
>=C2=A0 =C2=A0 =C2=A0 =C2=A0field.=C2=A0 This document refers to the fir= st three fields as "TLSA
>=C2=A0 =C2=A0 =C2=A0 =C2=A0parameters", or sometimes just "pa= rameters" when obvious from
>=C2=A0 =C2=A0 =C2=A0 =C2=A0context.
>
> I was pretty lost until I got to section 2, where at least the first > three fields were named - the fourth wasn't named until the last l= ine of
> Section 2.1. Any chance all four fields could be named here?

Yeah, we should avoid the needless suspense .

> In section 4, in this text:
>
>=C2=A0 =C2=A0 Protocol designers need to carefully consider which set o= f DANE
>=C2=A0 =C2=A0 certificate usages to support.=C2=A0 Simultaneous support= for all four
>=C2=A0 =C2=A0 usages is NOT RECOMMENDED for DANE clients.=C2=A0 Protoco= l designers are
>=C2=A0 =C2=A0 encouraged to specify use of either the PKIX-TA(0) and PK= IX-EE(1)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0^^^^^^=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ^^^
>=C2=A0 =C2=A0 certificate usages, or the use of the DANE-TA(2) and DANE= -EE(3)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 ^^=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0^^^
>=C2=A0 =C2=A0 usages.=C2=A0 When all four usages are supported, an atta= cker capable of
>=C2=A0 =C2=A0 compromising the integrity of DNSSEC needs only to replac= e server's
>=C2=A0 =C2=A0 TLSA RRset with one that lists suitable DANE-EE(3) or DAN= E-TA(2)
>=C2=A0 =C2=A0 records, effectively bypassing an added verification via = public CAs.
>=C2=A0 =C2=A0 In other words, when all four usages are supported, PKIX-= TA(2) and
>=C2=A0 =C2=A0 PKIX-EE(1) offer only illusory incremental security over = DANE-TA(2)
>=C2=A0 =C2=A0 and DANE-EE(3).

This paragraph is being rewritten as we speak to address earlier
comments about ensuring clarity of who these "protocol designers"=
are, and being more clear about what we want them to do.

> I'm sure the third sentence is accurate, but it took me a while to= parse
> the logical operators and figure out that the point was XOR ((A and B)= ,
> (C and D)) (I think). I think the paragraph would actually be clearer<= br> > with that sentence completely removed.

I am always of fixing bugs by deleting code.=C2=A0 Thanks.=C2=A0 I t= hink that works.

> About six paragraphs down into section 5.1, I see
>
>=C2=A0 =C2=A0 TLSA records published for DANE servers should, as a best= practice,
>=C2=A0 =C2=A0 be "DANE-EE(3) SPKI(1) SHA2-256(1)" records. >
> Is this an unqualified "do this in all cases"? If so, it'= ;s buried really
> deeply. If not, it wasn't obvious to me what the qualifications mi= ght
> be.

This is a best-practice, not a mandate.

<= div>Ack. I'm trying to understand if it's always a best practice.
=C2=A0
At some sites, it makes= sense to use "DANE-TA(2) Cert(0) SHA2-256(1)",
when many services have certificates from a common CA (trust-anchor),
and the domain operator prefers to decouple ceritificate rotation
from DNS updates.=C2=A0 In the "2 0 1" variant (also described), = the
server TLSA RRsets are CNAMEs to the shared RRset that lists the
digests of trusted CA certificates.

The "3 1 1" case will be by far more numerous, but the "2 0 = 1" case
is also an equally valid alternative, for sites with lots of DANE
services (the downside is that virtual hosting becomes more complex).

Perhaps there's a better way to describe a situation where there's<= br> a best-practice for 95% of users and a second best practice for
the remainin 5% (numbers made up, but the idea is right)?
=
Something like this (especially explaining the tradeoff, as = you did) seems helpful.
=C2=A0
> Just as a nit, in section 5.2.2, I see
>
>=C2=A0 =C2=A0 With DANE-TA(2), a complication arises when the TA certif= icate is
>=C2=A0 =C2=A0 omitted from the server's certificate chain, perhaps = on the basis of
>=C2=A0 =C2=A0 Section 7.4.2 of [RFC5246]:
>
>=C2=A0 =C2=A0 The sender's certificate MUST come first in the list.= =C2=A0 Each
>=C2=A0 =C2=A0 following certificate MUST directly certify the one prece= ding
>=C2=A0 =C2=A0 it.=C2=A0 Because certificate validation requires that ro= ot keys be
>=C2=A0 =C2=A0 distributed independently, the self-signed certificate th= at
>=C2=A0 =C2=A0 specifies the root certification authority MAY be omitted= from
>=C2=A0 =C2=A0 the chain, under the assumption that the remote end must<= br> >=C2=A0 =C2=A0 already possess it in order to validate it in any case. >
> Is that where the quote stops? I didn't check, but indenting the q= uote
> would help.

It was indented in the .html version produced by xml2rfc, but not in the .txt.=C2=A0 Fixed.=C2=A0 Thanks.

> Thanks for including section 10.1.1, UDP and TCP Considerations.
>
> In section 10.1.2,
>
>=C2=A0 =C2=A0 While TLSA records using a TLSA Selector of SPKI(1) and a= TLSA
>=C2=A0 =C2=A0 Matching Type of Full(0) (which publish the bare public k= eys without
>=C2=A0 =C2=A0 the overhead of a containing X.509 certificate) are gener= ally more
>=C2=A0 =C2=A0 compact, these are also best avoided as when significantl= y larger
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0^^^^^^^
>=C2=A0 =C2=A0 than their digests.
>
> The ^^^^ text wasn't parsing for me. "because they are/can be=
> significantly larger"? But I'm guessing.

Thanks, the problem was already queued to be fixed in the final
version.=C2=A0 It now reads:

=C2=A0 =C2=A0 While TLSA records using a TLSA Selector of SPKI(1) and a TLS= A
=C2=A0 =C2=A0 Matching Type of Full(0) (which publish the bare public keys<= br> =C2=A0 =C2=A0 without the overhead of a containing X.509 certificate) are =C2=A0 =C2=A0 generally more compact, these are also best avoided wh= en
=C2=A0 =C2=A0 significantly larger than their digests.

(For 256-bit EC keys, it is likely that the key size and the digest
size are close in size, and the full key is fine in that case).

> In section 10.3,
>
>=C2=A0 =C2=A0 If, on the other hand, the use of TLS is "opportunis= tic", then the
>=C2=A0 =C2=A0 client SHOULD generally use the server via an unauthentic= ated TLS
>=C2=A0 =C2=A0 connection, but if TLS encryption cannot be established, = the client
>=C2=A0 =C2=A0 MUST NOT use the server.=C2=A0 Standards for DANE specifi= c to the
>=C2=A0 =C2=A0 particular application protocol may modify the above requ= irements, as
>=C2=A0 =C2=A0 appropriate.
>
> I found myself wondering how you'd know modifying those requiremen= ts is
> appropriate. Is there any guidance you could give, or an example?

You could reasonably have asked if = I was overreacting to the word "appropriate", but since you didn&= #39;t ... :-)
=C2=A0
Hard to = say what makes the most sense in some hypothetical
opportunistic application.

For opportunistic applications a key consideration is whether we're
asking for more security than we can realistically expect (see
RFC7435).=C2=A0 If not, then the design is fine, if yes, then even in
the absense of active attacks clients run into problems with various
peers that do not interoperate "securely enough".=C2=A0 That'= s a problem,
because there are then strong incentives to just disable "OS" and=
stick with cleartext.

So the bar needs to be set at a realistic level.=C2=A0 I'd expect that<= br> requiring at least some form of (unauthenticated) TLS from sites
that publish TLSA RRs (even if unusable) is likely safe, but perhaps
that's too much to expect in some cases, or not worth the small
security gains.

Should some version of the above elaboration go in the text?

It was really helpful for me.=C2=A0

<= div>Maybe just saying "may modify the above requirements, if (a senten= ce or two that points toward your elaboration)"?
=C2=A0

> In section 11,
>
>=C2=A0 =C2=A0 When the registrar is also the DNS operator for the domai= n, one needs
>=C2=A0 =C2=A0 to consider whether the registrar will allow orderly migr= ation of the
>=C2=A0 =C2=A0 domain to another registrar or DNS operator in a way that= will
>=C2=A0 =C2=A0 maintain DNSSEC integrity.=C2=A0 TLSA Publishers SHOULD e= nsure their
>=C2=A0 =C2=A0 registrar publishes a suitable domain transfer policy. >
> I'm thinking that's not an RFC 2119 SHOULD, but if it is, I wo= nder why
> it's not a MUST ...

Excellent observation.

Perhaps 2119 is indeed too strong here.=C2=A0 Failure to do that may
make it difficult for the domain owner to ever move the domain to
another registrar without breakage.=C2=A0 But there's no interoperabili= ty
issue while the domain stays put.=C2=A0 If we want to ensure that domains can be moved without downtime (or downgrades to unsigned during
the move) then this is a MUST (on operational, rather than
interoperability grounds).=C2=A0 So not sure where to go with this.

I've seen RFC 2119 language used in even stran= ger ways in published RFCs. I'm not sure that's a good thing.
=
=C2=A0
> I hav= e the same thoughts about this text in section 11,
>
>=C2=A0 =C2=A0 DNS Operators SHOULD use a registrar lock of their domain= s
>=C2=A0 =C2=A0 to offer some protection against this possibility.
>
> and this text, in the following paragraph.
>
>=C2=A0 =C2=A0 TLSA Publishers SHOULD ensure their
>=C2=A0 =C2=A0 registrar publishes a suitable domain transfer policy.
These address a security issue, without a lock, another registrar might claim the domain without authorization, and then replace the
DS RRset, and publish rogue keys.=C2=A0 This is again operational advice with a security impact.=C2=A0 Whether 2119 is the right way to state
that advice, I am not sure.=C2=A0 Guidance from the IESG would be great.

If you're not convinced that using RFC 21= 19 language in this way is the right thing to do, you might say "need = to X, because if they don't Y happens". That might be more helpful= than a SHOULD.

Does that help?

Spencer
--bcaec548aa59258633051c75dc25-- From nobody Tue Aug 4 00:50:45 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BE2A1A8911 for ; Tue, 4 Aug 2015 00:50:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yIvTtEmpuF07 for ; Tue, 4 Aug 2015 00:50:42 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E83F1A0276 for ; Tue, 4 Aug 2015 00:50:42 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3mlpCy104vz3Mt; Tue, 4 Aug 2015 09:50:38 +0200 (CEST) Authentication-Results: mx.nohats.ca; dkim=pass (1024-bit key) header.d=nohats.ca header.i=@nohats.ca header.b=XnW4qMeb X-OPENPGPKEY: Message passed unmodified X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id lD7w-9IxkzZc; Tue, 4 Aug 2015 09:50:37 +0200 (CEST) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Tue, 4 Aug 2015 09:50:37 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 6C58380042; Tue, 4 Aug 2015 03:50:36 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1438674636; bh=g4/ReULYuq6vjB/ikf7NojMx9JJo5nnWNATJ5R6ngTo=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=XnW4qMebeB3MY2gXnCLMmkASCc7OxVVsFW95Q2xJAVlMsxpKb5WJSO/RBRlECh9q6 0sLmgs03Fqulv8MYPt+i2CFMEls4DXRLGtPhxzsMPidauqvVJelX09FvDS4Cvwj4BX ew2jrQvfLKS0xMOpnuJ0j+YdBYqLRTVwJUZAb6ZA= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.15.1/8.15.1/Submit) with ESMTP id t747oWpe010910; Tue, 4 Aug 2015 03:50:36 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Tue, 4 Aug 2015 03:50:32 -0400 (EDT) From: Paul Wouters To: Jiankang Yao In-Reply-To: <2015080410094450139169@cnnic.cn> Message-ID: References: <2015080410094450139169@cnnic.cn> User-Agent: Alpine 2.11 (LFD 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 8BIT Archived-At: Cc: dane Subject: Re: [dane] hash truncated to 28 octets X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 04 Aug 2015 07:50:44 -0000 On Tue, 4 Aug 2015, Jiankang Yao wrote: > I just read this draft. Note we are changing that part of the draft to use another mechanism instead of hashing. > Question: > 1, why should it be  hash truncated to 28 octets ? why choose 28 not other numbers? It was to match the length of the previous draft's sha224 version. That algorithm wasn't available on all platforms (eg Microsoft) so it was changed to sha256 but truncated. Truncation was to make the labels smaller and more managable. > 2,since some local-parts are longer than 28 octets, are there some collisions after hash truncated to 28 octets ? I think if you have 100.000 email addresses in one domain, the chance of collision would be pretty small. but non-zero. anyway, we will use base32 split encoding in the next version of the draft. Paul From nobody Tue Aug 4 01:19:54 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EB221B3710 for ; Tue, 4 Aug 2015 01:19:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ku8F8XhoNk43 for ; Tue, 4 Aug 2015 01:19:51 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D2911B36FF for ; Tue, 4 Aug 2015 01:19:47 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BVV34635; Tue, 04 Aug 2015 08:13:37 +0000 (GMT) Received: from LHREML504-MBS.china.huawei.com ([10.125.30.107]) by lhreml405-hub.china.huawei.com ([10.201.5.242]) with mapi id 14.03.0235.001; Tue, 4 Aug 2015 09:13:27 +0100 From: Hosnieh Rafiee To: Paul Wouters Thread-Topic: [dane] hash truncated to 28 octets Thread-Index: AQHQzlrMhdSAGdPWTkezS9Y3k/SzVp37ZwEAgAASuDA= Date: Tue, 4 Aug 2015 08:13:27 +0000 Message-ID: <814D0BFB77D95844A01CA29B44CBF8A7015D3B80@lhreml504-mbs> References: <2015080410094450139169@cnnic.cn> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.221.82.162] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: dane Subject: Re: [dane] hash truncated to 28 octets X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 04 Aug 2015 08:19:53 -0000 > I think if you have 100.000 email addresses in one domain, the chance > of collision would be pretty small. but non-zero. >=20 > anyway, we will use base32 split encoding in the next version of the > draft. What about the privacy? Leave it alone without thinking at all about privac= y and say that other WGs are taking care of this so why we should bother ou= tselves? Is it a right way to do this!? We all know that, if we are so optimistic an= d say that Dprive can come up with a good solution very quickly, it takes t= ime that all systems implement and support it (if we say there will be no p= roblem at all or any new attacks), We have seen how fast a security system = is deployed and supported , let's not go so far and back to the history of = DNSSEC... . To be realistic, this will result in either no implementation of this appr= oach in mail system until the privacy is clear or not enabling this approac= h, although, it is there because it has even no weak privacy protection. Th= erefore, the old way of key exchange is preferable over this one. Best, Hosnieh =20 From nobody Tue Aug 4 05:12: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 60EC21A1BD1 for ; Tue, 4 Aug 2015 05:12:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.2 X-Spam-Level: X-Spam-Status: No, score=-1.2 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wGmYGelBhGWi for ; Tue, 4 Aug 2015 05:12:47 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 073721A1BB0 for ; Tue, 4 Aug 2015 05:12:46 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id BE6E7284D71; Tue, 4 Aug 2015 12:12:45 +0000 (UTC) Date: Tue, 4 Aug 2015 12:12:45 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20150804121245.GI19228@mournblade.imrryr.org> References: <2015080410094450139169@cnnic.cn> 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] hash truncated to 28 octets X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Aug 2015 12:12:48 -0000 On Tue, Aug 04, 2015 at 03:50:32AM -0400, Paul Wouters wrote: > >2,since some local-parts are longer than 28 octets, are there some collisions after hash?truncated?to?28?octets?? > > I think if you have 100.000 email addresses in one domain, the chance of > collision would be pretty small. but non-zero. You'd need 2^112 email addresses for an appreciable chance of collision. If every person on the planet (say 10^{10} people some day) each had 100 email addresses in the same domain, that'd be 10^{12} or ~2^{40} addresses. The collision probability would be around 2^{80}/2^{112} = 2^{-32} ~ 10^{-6}. With "just" 10^{10} addresses, it drops by a factor of 10^4 to 10^{-10}. So we'd need around 10^10 Gmail sized domains before seeing a collision in one of them. -- Viktor. From nobody Tue Aug 4 10:05:16 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAAEE1A88FA; Tue, 4 Aug 2015 10:05:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.1 X-Spam-Level: X-Spam-Status: No, score=-1.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8] 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 I8YBWXV8x3Zf; Tue, 4 Aug 2015 10:05:13 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 912601A8923; Tue, 4 Aug 2015 10:05:12 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Alissa Cooper" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.3.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150804170512.1526.92423.idtracker@ietfa.amsl.com> Date: Tue, 04 Aug 2015 10:05:12 -0700 Archived-At: Cc: dane-chairs@ietf.org, dane@ietf.org, draft-ietf-dane-ops.ad@ietf.org, draft-ietf-dane-ops.shepherd@ietf.org, draft-ietf-dane-ops@ietf.org Subject: [dane] Alissa Cooper's No Objection on draft-ietf-dane-ops-14: (with COMMENT) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Aug 2015 17:05:14 -0000 Alissa Cooper has entered the following ballot position for draft-ietf-dane-ops-14: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dane-ops/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for working on this. I agree generally with the editorial comments others have already made and I have a few more. Section 4: s/generally RECOMMENDED./RECOMMENDED./ s/a mixture of clients; some supporting/a mixture of clients, some supporting/ Section 4.2: I note that this section is silent about the interaction between CT and the PKIX-TA(0) and PKIX-EE(1) usages. I'm assuming the implication is "go ahead and use CT if you want to in those cases," but whatever it is, might it be worth making it explicit here? Section 10.3: "A service with DNSSEC-validated TLSA records implicitly promises TLS support. When all the TLSA records for a service are found "unusable", due to unsupported parameter combinations or malformed associated data, DANE clients cannot authenticate the service certificate chain. When authenticated TLS is mandatory, the client SHOULD NOT connect to the associated server." Seems like that last requirement should be a MUST NOT. Section 14: "When TLS is opportunistic, the client MAY proceed to use the server with mandatory unauthenticated TLS." I find the use of the word "mandatory" here confusing -- what is mandatory in the opportunistic case? Seems like this would make more sense without the word "mandatory." From nobody Tue Aug 4 10:34: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 6D50E1A88F2; Tue, 4 Aug 2015 10:34:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 58kWDbFCqv8F; Tue, 4 Aug 2015 10:34:50 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C6FD1A8923; Tue, 4 Aug 2015 10:34:50 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 18B7A284D85; Tue, 4 Aug 2015 17:34:49 +0000 (UTC) Date: Tue, 4 Aug 2015 17:34:49 +0000 From: Viktor Dukhovni To: The IESG , dane@ietf.org, draft-ietf-dane-ops.ad@ietf.org, draft-ietf-dane-ops.shepherd@ietf.org Message-ID: <20150804173448.GL19228@mournblade.imrryr.org> References: <20150804170512.1526.92423.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150804170512.1526.92423.idtracker@ietfa.amsl.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [dane] Alissa Cooper's No Objection on draft-ietf-dane-ops-14: (with COMMENT) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Aug 2015 17:34:52 -0000 On Tue, Aug 04, 2015 at 10:05:12AM -0700, Alissa Cooper wrote: > Section 4: > s/generally RECOMMENDED./RECOMMENDED./ > s/a mixture of clients; some supporting/a mixture of clients, some > supporting/ Sure. > Section 4.2: > I note that this section is silent about the interaction between CT and > the PKIX-TA(0) and PKIX-EE(1) usages. I'm assuming the implication is "go > ahead and use CT if you want to in those cases," but whatever it is, > might it be worth making it explicit here? Yes, full steam ahead with PKIX-TA/PKIX-EE. I'll add something suitably concise to that effect. > > Section 10.3: > "A service with DNSSEC-validated TLSA records implicitly promises TLS > support. When all the TLSA records for a service are found > "unusable", due to unsupported parameter combinations or malformed > associated data, DANE clients cannot authenticate the service > certificate chain. When authenticated TLS is mandatory, the client > SHOULD NOT connect to the associated server." > > Seems like that last requirement should be a MUST NOT. Yes, MUST NOT will do. > > Section 14: > "When TLS is opportunistic, the client MAY proceed to use > the server with mandatory unauthenticated TLS." > > I find the use of the word "mandatory" here confusing -- what is > mandatory in the opportunistic case? Seems like this would make more > sense without the word "mandatory." Good catch, this is unclear. When the client is using TLS and DANE opportunistically, and finds TLSA records all which happen to be "unusable", to avoid downgrade attacks to cleartext, it MUST still use TLS, but without (DANE) authentication (which is not possible). This is already specified in the SRV and SMTP drafts. In this draft it is stated more generally. Will fix. -- Viktor. From nobody Tue Aug 4 20:45:45 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 012381B2BA6; Tue, 4 Aug 2015 20:45:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rTQc6zOPn7_9; Tue, 4 Aug 2015 20:45:42 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 507501B2BA3; Tue, 4 Aug 2015 20:45:40 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Ben Campbell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.3.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150805034540.27866.98360.idtracker@ietfa.amsl.com> Date: Tue, 04 Aug 2015 20:45:40 -0700 Archived-At: Cc: dane-chairs@ietf.org, dane@ietf.org, draft-ietf-dane-ops.ad@ietf.org, draft-ietf-dane-ops.shepherd@ietf.org, draft-ietf-dane-ops@ietf.org Subject: [dane] Ben Campbell's Yes on draft-ietf-dane-ops-14: (with COMMENT) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2015 03:45:44 -0000 Ben Campbell has entered the following ballot position for draft-ietf-dane-ops-14: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dane-ops/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for this. I only have some editorial comments, and others have beaten me to the punch on all save the following: -- Section 8, first paragraph: This section updates [RFC6698] by specifying a requirement on the TLSA Publisher to ensure that each combination of Certificate Usage, selector and matching type in the server's TLSA RRset MUST include at least one record that matches the server's current certificate chain. "Requirement on the ... publisher to ensure...that each combination... MUST include..." is sort of an odd construction for a 2119 MUST. Does the following capture the intent? NEW: This section updates [RFC6698] by specifying that the TLSA Publisher MUST ensure that each combination of Certificate Usage, selector and matching type in the server's TLSA RRset includes at least one record that matches the server's current certificate chain. END From nobody Tue Aug 4 20:57:52 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BD091B2BD2; Tue, 4 Aug 2015 20:57:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ko9_59TpBSmO; Tue, 4 Aug 2015 20:57:47 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE6891B2BCE; Tue, 4 Aug 2015 20:57:47 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id D59B4284D68; Wed, 5 Aug 2015 03:57:46 +0000 (UTC) Date: Wed, 5 Aug 2015 03:57:46 +0000 From: Viktor Dukhovni To: The IESG , draft-ietf-dane-ops.shepherd@ietf.org, draft-ietf-dane-ops.ad@ietf.org, dane@ietf.org Message-ID: <20150805035746.GO19228@mournblade.imrryr.org> References: <20150805034540.27866.98360.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150805034540.27866.98360.idtracker@ietfa.amsl.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [dane] Ben Campbell's Yes on draft-ietf-dane-ops-14: (with COMMENT) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2015 03:57:49 -0000 On Tue, Aug 04, 2015 at 08:45:40PM -0700, Ben Campbell wrote: > Thanks for this. I only have some editorial comments, and others have > beaten me to the punch on all save the following: > > -- Section 8, first paragraph: > > This section updates [RFC6698] by specifying a requirement on the > TLSA Publisher to ensure that each combination of Certificate Usage, > selector and matching type in the server's TLSA RRset MUST include at > least one record that matches the server's current certificate chain. > > "Requirement on the ... publisher to ensure...that each combination... > MUST include..." is sort of an odd construction for a 2119 MUST. Does > the following capture the intent? > > NEW: > This section updates [RFC6698] by specifying that the > TLSA Publisher MUST ensure that each combination of Certificate > Usage, selector and matching type in the server's TLSA RRset includes at > least one record that matches the server's current certificate chain. > END Yes. Thanks. -- Viktor. From nobody Wed Aug 5 01:14:55 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BF6B1B2D95; Wed, 5 Aug 2015 01:14:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.01 X-Spam-Level: X-Spam-Status: No, score=-4.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_I_LETTER=-2, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xGhZlwIuicfg; Wed, 5 Aug 2015 01:14:50 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A8EB1B2D9B; Wed, 5 Aug 2015 01:14:48 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3mmQjL0kxWz3Mr; Wed, 5 Aug 2015 10:14:46 +0200 (CEST) Authentication-Results: mx.nohats.ca; dkim=pass (1024-bit key) header.d=nohats.ca header.i=@nohats.ca header.b=bazC9b8G X-OPENPGPKEY: Message passed unmodified X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id 1TNEIJsti9mc; Wed, 5 Aug 2015 10:14:44 +0200 (CEST) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Wed, 5 Aug 2015 10:14:44 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id EE90180042; Wed, 5 Aug 2015 04:14:42 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1438762483; bh=p2hL40NnUX14BDCxI9RAEDgsbJNomDvMu3AdFnp1psI=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=bazC9b8GQe6XIJp/PqAqgX27v/pAtPAAn0buXkIwBjSC677Pe14UZYw9WH7tOjpU+ vUssRt23heMA89wwRb7m1gEAk3X1zPJcjFZkC7bezZvbex4Hs6YUqYOE5OWIy8On8L dUnfSRCGIZ965rMWlg5lGqplGzk+g5T/FHZ8Ysro= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.15.1/8.15.1/Submit) with ESMTP id t758EgMi008903; Wed, 5 Aug 2015 04:14:42 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Wed, 5 Aug 2015 04:14:42 -0400 (EDT) From: Paul Wouters To: Daniel Kahn Gillmor In-Reply-To: <87bnem2xjq.fsf@alice.fifthhorseman.net> Message-ID: References: <87bnf1hair.fsf@alice.fifthhorseman.net> <87bnem2xjq.fsf@alice.fifthhorseman.net> User-Agent: Alpine 2.11 (LFD 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=utf-8; format=flowed Content-Transfer-Encoding: 8BIT Archived-At: Cc: IETF OpenPGP , dane WG list Subject: Re: [dane] [openpgp] The DANE draft X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2015 08:14:53 -0000 On Wed, 5 Aug 2015, Daniel Kahn Gillmor wrote: > i'm not subscribed to dane@ietf.org, feel free to forward if you think > this would be useful. [ I added dane back to the CC: as I think it will be useful to keep the openpgp discussion there too, as some people there also wanted a different specification of the RDATA ] > key discovery vs key validation > ------------------------------- > > As an optional key discovery mechanism for OpenPGP, i think this > proposal has merit. I share Watson's concerns about "smuggling in a > different trust model", but i have no complaints about DNSSEC validation > being used as a corroborative validation mechanism, should clients > choose to accept it for validation purposes. For clients that *don't* > choose to accept it for validation purposes, they should validate the > keys via their usual mechanisms, and rely on OPENPGPKEY records solely > for discovery purposes. The text does make it clear that you have that choice: The proposed new DNS Resource Record type is secured using DNSSEC. This trust model is not meant to replace the Trust Signature model. However, it can be used to encrypt a message that would otherwise have to be sent out unencrypted, where it could be monitored by a third party in transit or located in plaintext on a storage or email server. This method can also be used to obtain the OpenPGP public key which can then be used for manual verification. So there is no "smuggling".... DNSSEC is used to protect the transport, and as a poor man's better-than-nothing web-of-trust alternative. > metadata leakage > ---------------- > > I'm a little concerned about the potential for metadata leakage -- i > don't want my MUAs to do DNS lookups every time i try to send mail to > someone whose keys i dont have. The MUA can present you with information to manually verify or put a trust level to the key. The MUA should also cache negative attempts to get a key and limit these so avoid fingerprinting email send times by looking at DNS queries. That part is not in the current RRtype specification, but should go into the openpgpkey-usage document (co-authors wanted!) > localpart mangling > ------------------ > > I have no strong preference for base32 vs. digested localpart for the > hostname. Digested localparts require a little bit more work to invert > than base32, but given the low entropy of typical normalized localparts, > they don't provide a lot of protection against a determined attacker. And as clearly stated, were never meant to provide security. > I'm slightly more concerned with e-mail address length limits on base32 > than on digested localparts -- a long localpart plus a long domain name > could make for a very large DNS label, whereas a fixed digest should > give us a fixed bound on size. Do you forsee email addresses > 256/2 to be common use? > In either case, some canonicalization will be required (before base32 or > digest, whichever is chosen). fwiw, i believe that case normalization > of the localpart is pragmatic for today's networks, despite not being > within the letter of the RFC. I would advise clients to downcase before > doing a lookup. Thanks. I share that belief. > The main advantage for base32 over digested localpart seems to be for > synthesized OPENPGPKEY records in an online-signing DNSSEC-capable > server. I don't believe this is a significant advantage for a key > discovery mechanism for OpenPGP, because i believe some people will want > to verify the OpenPGP certificate itself, regardless of its DNSSEC > status, and the OpenPGP certificate won't have wildcards in it. Other people believe there is some use. If the only downside is not supporting insanely long email addresses, which I think are a more rare event, I think that it is okay. > RDATA content/structure > ----------------------- > > The -03 spec §2.1 currently suggests that the RDATA should be an > "RFC4880 OpenPGP public keyring", but RFC 4880 doesn't define a "public > keyring" in any reusable way (see > https://tools.ietf.org/html/rfc4880#section-3.6). > > > § 2.2 says: > > The RDATA Wire Format consists of a single OpenPGP public key as > defined in Section 5.5.1.1 of [RFC4880]. Note that this format is > without ASCII armor or base64 encoding. > > But 5.5.1.1 is *just* a public key packet. This is not a useful record > to store. > > Instead what you want is probably exactly one "Transferable Public Key" > (https://tools.ietf.org/html/rfc4880#section-11.1), which is the > standard for the composable OpenPGP certificate format. But see the > "Filtered Certificates" section below for more detail. I will update the reference to refer to that section. Thanks. That does look better. > Key Transitions > --------------- > > While i say "exactly one" Transferable Public Key, i'm assuming that the > DNS is OK with serving multiple OPENPGPKEY records at a single label. What is the advantage of multiple DNS records with 1 key over one DNS record with multiple keys? While I'm all four specifying one method to increase chances of interop, I'm not particularly set on one or the other solution. > Filtered Certificates > --------------------- > > Given that some users have aggregated OpenPGP certificates that are > quite large (my own is currently ~475KB), we don't want to require > people to publish their entire certificate in the DNS. Because OpenPGP > certificates ("transferable public keys) are composable (they consist of > a series of packets, many of which can be dropped), a reasonable policy > for filtering the certificate for size purposes should be suggested. We mention this in Section 5: https://tools.ietf.org/html/draft-ietf-dane-openpgpkey-03#section-5 > At a minimum, the OPENPGPKEY record for alice@example.com MUST contain: > > * primary key X > - one User ID Y, SHOULD match 'alice@example.com' > - self-signature from X, binding X to Y. > > > [ note: I do not believe we need to require that the User ID MUST match > the looked-up record, though it's obviously preferable to a validator > if it does. ] > > This extremely minimal record might not provide an encryption-capable > subkey, though, and the primary key may not be encryption-capable > itself. > > So a more sensible transferable public key would also include all > relevant subkeys: > > * primary key X > - one User ID Y, SHOULD match 'alice@example.com' > - self-signature from X, binding Y to X. > - encryption-capable subkey Z > - self-signature from X, binding Z to X. > - [ other subkeys if relevant ...] > > > Owners of the record may also want to include some up-to-date > third-party certifications which they think would be helpful for > validation, which would result in: > > * primary key X > - one User ID Y, SHOULD match 'alice@example.com' > - self-signature from X, binding Y to X. > - third-party certification from V, binding Y to X > - [ other third-party certifications if relevant ...] > - encryption-capable subkey Z > - self-signature from X, binding Z to X. > - [ other subkeys if relevant ...] [...] > With GnuPG, you can achieve a rough minimization with: > > gpg --export-options export-minimal,no-export-attributes $PGPFPR > opengpgpkey.pgp The idea was not to specify these policies in the DNS RRtype. Just tell people to keep to small keys. It did include an example gpg command in appendix A, but your command seems even better so I will update it. I would prefer not to mention specific key elements as those might change and are not really relevent for the DNS specification. Or perhaps these recommendations could go in the openpgpkey-usage document. Paul From nobody Wed Aug 5 01:17:25 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7332D1B2DB1 for ; Wed, 5 Aug 2015 01:17:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zJ0ApcLngxos for ; Wed, 5 Aug 2015 01:17:13 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 227731B2DA4 for ; Wed, 5 Aug 2015 01:17:12 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3mmQm64VxDz3NG for ; Wed, 5 Aug 2015 10:17:10 +0200 (CEST) Authentication-Results: mx.nohats.ca; dkim=pass (1024-bit key) header.d=nohats.ca header.i=@nohats.ca header.b=SyMuALF2 X-OPENPGPKEY: Message passed unmodified X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id DLkgwrZY8bj9 for ; Wed, 5 Aug 2015 10:17:09 +0200 (CEST) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS for ; Wed, 5 Aug 2015 10:17:09 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id D15AD80042 for ; Wed, 5 Aug 2015 04:17:08 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1438762628; bh=f/ntqZ/AktrH7sshqim4KpmHnFhrHzbLC97js6DvuuU=; h=Date:From:To:Subject; b=SyMuALF26WVAm1hImGq2xLK5Z0IkiJReEqS2HQNl4mzc0MLYn9uriaiW8tO8Jah10 ecO1IDu+0YilStggzy1QBvjTr/vAO0/Pbc//+V9hIyWB/5rej7JLZCFMzbttAMcsFy HON8q2bMWu5RfDR/8uMxwm7pAnEREWAyOUMULozk= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.15.1/8.15.1/Submit) with ESMTP id t758H8od009042 for ; Wed, 5 Aug 2015 04:17:08 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Wed, 5 Aug 2015 04:17:08 -0400 (EDT) From: Paul Wouters To: dane WG list Message-ID: User-Agent: Alpine 2.11 (LFD 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Archived-At: Subject: [dane] regarding my previous draft-ietf-dane-ops-14 comments X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 05 Aug 2015 08:17:14 -0000 Hi, After a phone conversation with Viktor, he convinced me the current text is actually good and my previous objections were my misinterpretations. So I'm in favour of the document in its current form. Paul From nobody Wed Aug 5 04:28: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 DF9C01B2FA1; Wed, 5 Aug 2015 04:28:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 FY5ibOyLKQV7; Wed, 5 Aug 2015 04:28:28 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3E6D1B2FA3; Wed, 5 Aug 2015 04:28:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id E8AC9BE73; Wed, 5 Aug 2015 12:28:26 +0100 (IST) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QMiwOz39IQy6; Wed, 5 Aug 2015 12:28:26 +0100 (IST) Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id B4CA1BDD0; Wed, 5 Aug 2015 12:28:26 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1438774106; bh=Xr60cxx6GWZyuc1D793Tr80WOOIzJEzexBI3lvr7FUU=; h=Date:From:To:CC:Subject:References:In-Reply-To:From; b=syFXThxV1vkibLpNwr1hBAPyuxFbM9POcAiQ3UohV4mGCZn8j+kPavH+ildXigDcv icO1nYQC1orJSf6O71Q3Rb1h6UnejkF7FwfTpStBm9flo7NdqYItgLvkIXoNPKxLZS 7YcL2lfAdUgNa14Sggd6ojUFZKhQ+d3F8uOxy//w= Message-ID: <55C1F35A.5070904@cs.tcd.ie> Date: Wed, 05 Aug 2015 12:28:26 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.8.0 MIME-Version: 1.0 To: Paul Wouters , Daniel Kahn Gillmor References: <87bnf1hair.fsf@alice.fifthhorseman.net> <87bnem2xjq.fsf@alice.fifthhorseman.net> In-Reply-To: OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: IETF OpenPGP , dane WG list Subject: Re: [dane] [openpgp] The DANE draft X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2015 11:28:31 -0000 On 05/08/15 09:14, Paul Wouters wrote: >> >> >> I have no strong preference for base32 vs. digested localpart for the >> hostname. Digested localparts require a little bit more work to invert >> than base32, but given the low entropy of typical normalized localparts, >> they don't provide a lot of protection against a determined attacker. > > And as clearly stated, were never meant to provide security. Hmm. With no hats, I gotta say I prefer the harder to invert local part (i.e. hashed) to the reversible one (b32). If this experiment ends up successful, then I think we'll be setting a precedent for other per-user identifiers to be used as part of a DNS name so I do not believe that arguments about this aspect ought be decided solely based on PGP or SMIME or DANE. We should also consider that some other protocol is highly likely to follow what seems to have worked (just as _blah.example.com has been mimicked) and where we don't now know the privacy consequences of copying the pattern we're setting here. For that reason, I really would prefer that we stick to the hash and not go for the reversible per-user identifier. (Separately, I also don't buy that there will be much use for actually reversing the b32 encoding and if there were then the relevant work could just as easily be done in advance by a server that is willing to answer for a few known alternatives.) So sorry to continue an argument but shouldn't this experiment be a more conservative about privacy just in case it ends up wildly successful? Ta, S. From nobody Wed Aug 5 06:11:29 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFB9D1A0377 for ; Wed, 5 Aug 2015 06:11:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.661 X-Spam-Level: X-Spam-Status: No, score=-1.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_DE=0.35, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QGGytcSPhA8L for ; Wed, 5 Aug 2015 06:11:26 -0700 (PDT) Received: from mail.sys4.de (mail.sys4.de [IPv6:2001:1578:400:111::7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2ABDD1A0276 for ; Wed, 5 Aug 2015 06:11:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sys4.de; h= in-reply-to:content-transfer-encoding:content-disposition :content-type:content-type:mime-version:references:message-id :subject:subject:from:from:date:date; s=mail201310; t= 1438780282; x=1440594683; bh=21GF47jiNk/1wCiAZ7EKZOlCOGuhU3xt+/j 4yXk1hbM=; b=NHJmnXU7bZWqdhSB02OWk5Pqs/Btqk3s2qDY01HcoFrJv7FYV0H A5m9GLqMXz1eeJEj3LMJPkQ6tMIr8P5SrrQ3g7dtLwp6PhBTgwj1CB4Dqofq6hDm v7gTw9sLiuVjSQOoBSKJWOf6CsIEM389uazqe1r2yAZwGYZXHovfgzngv7JZXF+S kIDzategDKyEqFXBA7LlCaZA8wsVoQT/B3p/61mcpIGI2qs8AMKQCB0mGsSqXT4n xqyXE4RV24qHbT3yW0KQOy9797NQiXnJxJcQgb8oZeabY89q9lx1NtbUBGtdkfon WRLwSBnMhNdrrndopZu5btzJ4pKK5KTypZA== X-Virus-Scanned: Debian amavisd-new at mail.sys4.de Received: from sys4.de (ppp-88-217-18-155.dynamic.mnet-online.de [88.217.18.155]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.sys4.de (Postfix) with ESMTPSA id 3mmYHZ5FbZzDS for ; Wed, 5 Aug 2015 15:11:22 +0200 (CEST) Date: Wed, 5 Aug 2015 15:11:21 +0200 From: Patrick Ben Koetter To: dane@ietf.org Message-ID: <20150805131120.GA12058@sys4.de> References: <87bnf1hair.fsf@alice.fifthhorseman.net> <87bnem2xjq.fsf@alice.fifthhorseman.net> <55C1F35A.5070904@cs.tcd.ie> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <55C1F35A.5070904@cs.tcd.ie> Archived-At: Subject: Re: [dane] [openpgp] The DANE draft X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2015 13:11:28 -0000 * Stephen Farrell : > > > On 05/08/15 09:14, Paul Wouters wrote: > >> > >> > >> I have no strong preference for base32 vs. digested localpart for the > >> hostname. Digested localparts require a little bit more work to invert > >> than base32, but given the low entropy of typical normalized localparts, > >> they don't provide a lot of protection against a determined attacker. > > > > And as clearly stated, were never meant to provide security. > > Hmm. > > With no hats, I gotta say I prefer the harder to invert local part > (i.e. hashed) to the reversible one (b32). > > If this experiment ends up successful, then I think we'll be setting > a precedent for other per-user identifiers to be used as part of a > DNS name so I do not believe that arguments about this aspect ought > be decided solely based on PGP or SMIME or DANE. We should also > consider that some other protocol is highly likely to follow what > seems to have worked (just as _blah.example.com has been mimicked) > and where we don't now know the privacy consequences of copying > the pattern we're setting here. > > For that reason, I really would prefer that we stick to the hash and > not go for the reversible per-user identifier. ACK p@rick -- [*] sys4 AG https://sys4.de, +49 (89) 30 90 46 64 Franziskanerstraße 15, 81669 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein From nobody Wed Aug 5 08:12:19 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFDF11B2F8E; Wed, 5 Aug 2015 08:12:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.347 X-Spam-Level: X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IivP_sGwdvcO; Wed, 5 Aug 2015 08:12:17 -0700 (PDT) Received: from hoffman.proper.com (Opus1.Proper.COM [207.182.41.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 342F41B2D82; Wed, 5 Aug 2015 08:12:17 -0700 (PDT) Received: from [10.32.60.120] (142-254-17-100.dsl.dynamic.fusionbroadband.com [142.254.17.100]) (authenticated bits=0) by hoffman.proper.com (8.15.1/8.14.9) with ESMTPSA id t75FC6Jf071674 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 5 Aug 2015 08:12:07 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 142-254-17-100.dsl.dynamic.fusionbroadband.com [142.254.17.100] claimed to be [10.32.60.120] From: "Paul Hoffman" To: "Stephen Farrell" Date: Wed, 05 Aug 2015 08:12:06 -0700 Message-ID: In-Reply-To: <55C1F35A.5070904@cs.tcd.ie> References: <87bnf1hair.fsf@alice.fifthhorseman.net> <87bnem2xjq.fsf@alice.fifthhorseman.net> <55C1F35A.5070904@cs.tcd.ie> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.1r5084) Archived-At: Cc: Paul Wouters , dane WG list , Daniel Kahn Gillmor , IETF OpenPGP Subject: Re: [dane] [openpgp] The DANE draft X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2015 15:12:18 -0000 Wearing my author hat: I don't care between b32 and hashing. Both are equally easy to document. However: On 5 Aug 2015, at 4:28, Stephen Farrell wrote: > So sorry to continue an argument but shouldn't this experiment be > a more conservative about privacy just in case it ends up wildly > successful? How is using the hash more conservative about privacy, except in zones that are signed with NSEC instead of the more common NSEC3? If you assume zones signed with NSEC3, both options are equally susceptible to dictionary-based guessing attacks, given that the effort to create search dictionaries for the billion of common LHS names is pretty low even for hashes. --Paul Hoffman From nobody Wed Aug 5 08:25:22 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62B481A00E0; Wed, 5 Aug 2015 08:25:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 OVo4AgLdUA11; Wed, 5 Aug 2015 08:25:13 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 974BD1B2A28; Wed, 5 Aug 2015 08:25:10 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id CADE9BE88; Wed, 5 Aug 2015 16:25:08 +0100 (IST) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vh6GFjukIvpH; Wed, 5 Aug 2015 16:25:08 +0100 (IST) Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 9FFDCBE55; Wed, 5 Aug 2015 16:25:08 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1438788308; bh=G52SpfXnuuM9Qv9Myg5CU3LY2Y63olLshp+tGLF7oTY=; h=Date:From:To:CC:Subject:References:In-Reply-To:From; b=MH4SaHgyeU3S4VXoCgxCUSZSZRB4D5ryFGcAabaHoV0qB5msPXjElCzp5llZxikDA iNwVe+U8/nOVyP6zWE9JeO5Vdb8K72FQ2KUeaWmPRhIULMXKg8nYgwtOG0Qv8AP6oM S5i7AyxrtyaAVMTmU4AnAFwzQm2Zb9UvDo7/lXkE= Message-ID: <55C22AD4.5010709@cs.tcd.ie> Date: Wed, 05 Aug 2015 16:25:08 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.8.0 MIME-Version: 1.0 To: Paul Hoffman References: <87bnf1hair.fsf@alice.fifthhorseman.net> <87bnem2xjq.fsf@alice.fifthhorseman.net> <55C1F35A.5070904@cs.tcd.ie> In-Reply-To: OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: Paul Wouters , dane WG list , Daniel Kahn Gillmor , IETF OpenPGP Subject: Re: [dane] [openpgp] The DANE draft X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2015 15:25:18 -0000 On 05/08/15 16:12, Paul Hoffman wrote: > Wearing my author hat: I don't care between b32 and hashing. Both are > equally easy to document. However: > > On 5 Aug 2015, at 4:28, Stephen Farrell wrote: > >> So sorry to continue an argument but shouldn't this experiment be >> a more conservative about privacy just in case it ends up wildly >> successful? > > How is using the hash more conservative about privacy, except in zones > that are signed with NSEC instead of the more common NSEC3? If you > assume zones signed with NSEC3, both options are equally susceptible to > dictionary-based guessing attacks, given that the effort to create > search dictionaries for the billion of common LHS names is pretty low > even for hashes. Tempora. That on-path attacker has a far easier time reversing the b32 than anything based on the hash. Even with DPRIVE, we don't know how to handle the recursive to authoritative part. So a "putative other protocol that copies this" could well do a great job on hiding identifiers only to be caught out by following this b32 convention. I do accept that hashing doesn't make much difference for PGP or SMIME since the DNS answer in the success case almost certainly gives the game away, but I don't think that has to be true in general. The failure case may also be of interest though, with hashing, that DNS answer doesn't immediately tell the attacker to whom I'd like to send email. And I guess if some MUA adopts this there'll be quite a few negative answers for quite some time, so there's a privacy difference there I think. (Not sure if that was raised before - apologies if so.) S. > > --Paul Hoffman > > From nobody Wed Aug 5 08:36:47 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57ABB1A0122; Wed, 5 Aug 2015 08:36:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.56 X-Spam-Level: X-Spam-Status: No, score=-1.56 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id COsRkHRi1tm6; Wed, 5 Aug 2015 08:36:44 -0700 (PDT) Received: from smtp3.strotmann.de (smtp3.strotmann.de [IPv6:2a03:4000:2:33f::5353]) (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 0B2111A013B; Wed, 5 Aug 2015 08:36:43 -0700 (PDT) Received: from debian01.home.strotmann.de (unknown [IPv6:2a01:198:2b6:1000:240:caff:fea0:83b3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp3.strotmann.de (Postfix) with ESMTPS id 02DE97FF8B; Wed, 5 Aug 2015 17:36:09 +0200 (CEST) Received: from Carstens-MacBook-Pro.local (unknown [IPv6:2a03:4000:6:2115::2]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by debian01.home.strotmann.de (Postfix) with ESMTPSA id 8CB4820005C; Wed, 5 Aug 2015 17:36:08 +0200 (CEST) Message-ID: <55C22D64.9080507@strotmann.de> Date: Wed, 05 Aug 2015 17:36:04 +0200 From: Carsten Strotmann User-Agent: Postbox 4.0.1 (Macintosh/20150514) MIME-Version: 1.0 To: Paul Hoffman References: <87bnf1hair.fsf@alice.fifthhorseman.net> <87bnem2xjq.fsf@alice.fifthhorseman.net> <55C1F35A.5070904@cs.tcd.ie> In-Reply-To: X-Enigmail-Version: 1.2.3 OpenPGP: id=F7465F6A; url=keys.gnupg.net Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070201010808000703080608" Archived-At: Cc: IETF OpenPGP , dane WG list Subject: Re: [dane] [openpgp] The DANE draft X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2015 15:36:46 -0000 This is a cryptographically signed message in MIME format. --------------ms070201010808000703080608 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hello Paul, Paul Hoffman wrote: > Wearing my author hat: I don't care between b32 and hashing. Both are > equally easy to document. However: > > On 5 Aug 2015, at 4:28, Stephen Farrell wrote: > >> So sorry to continue an argument but shouldn't this experiment be >> a more conservative about privacy just in case it ends up wildly >> successful? > > How is using the hash more conservative about privacy, except in zones > that are signed with NSEC instead of the more common NSEC3? If you > assume zones signed with NSEC3, both options are equally susceptible to > dictionary-based guessing attacks, given that the effort to create > search dictionaries for the billion of common LHS names is pretty low > even for hashes. > for OPENPGPKEY/SMIMECERT zones, operators could (maybe SHOULD) use NSEC/NSEC3 "narrow" signing to prevent "zone-walking". The issue is more in the DNS query logs. My experience from working with many DNS-admins over the last decade tells me: DNS-Admins that could/would snoop into DNS-query logs by creating a small Perl script to decode the email addresses seen in the logs. Less DNS-Resovler Admins would go all the way of breaking hashes either using dictionary-based guessing attacks or a rainbow table. Breaking hashes requires much more "willful intent" than decoding BASE32. The hashing communicates a "don't go here" message, even though it is technically not a strong protection. It is like having a closed door vs. no door at all. No door communicates "come in, no secrets, we're open" while the closed door (even if it can be opened by minor force) communicates "private space". Best regards Carsten --------------ms070201010808000703080608 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGfzCC BnswggRjoAMCAQICAxBwIDANBgkqhkiG9w0BAQsFADB5MRAwDgYDVQQKEwdSb290IENBMR4w HAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmlu ZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xNTAz MjcxMDA2MDJaFw0xNTA5MjMxMDA2MDJaMD8xGDAWBgNVBAMTD0NBY2VydCBXb1QgVXNlcjEj MCEGCSqGSIb3DQEJARYUY2Fyc3RlbkBzdHJvdG1hbm4uZGUwggIiMA0GCSqGSIb3DQEBAQUA A4ICDwAwggIKAoICAQClk0pULQ8GSo1lOVvTDSMpw6yNdknHBZF9H//Ex2HBdldmy1OdY22r xIAYdz5KBzDg3r1v3bVuQvDDxowFvYugWgYav7yrJ0T/y8ftJlm7PnZHt7l/kLbLEmxxXdsl fkUzQkPFeUSKXQt6ZHpCFsIw7twvrD7It1SLccEOKinWD9hfnBO19mg3cTdAsQdIGT3Cq5yI tskXH75I+GxpMQxoGiwbfs5P1m1+ujgBjwlRSXgnDjDSYLkqkPI6nnjMfv/cpJpm4gqf1Gcj V3Gdd9aQED0w60DGZ1ZBD46jxtIRJl2ozVdd/CYfBNVDNwBo57Ag3oPzlqvGbpGlBiTiciLH gaw7cKMk72FdsGX3AnzFh9I16ZcmzD3a6cwsHYLDW+lKewTyu6LgyNceAUd7JiB8UA2wF8j7 HoupLfSxFu3toq+OdpR6eSanI05suMrZpNPQGDpALRpCpcSPK3rFVg/SXBj1uvOCepFNYBSu IRsG/6zrUXG0Jmcz05TMF9GCqtDuVmkICwbnMniri7OKB+rbuj0hrh8oo3WdY3sxYli21ch7 hbP8dQiYwAXysGN1AEUmZk7dDGuRn/RW99vecgCBd4hk3jXytAvUm2c+Ua3NYrfkPHx4RO+f k13gzfFRBNTSJg8CjVK3CXk+NgutYoZNZ3TWcHcqL+byLH1jIsgyzwIDAQABo4IBRDCCAUAw DAYDVR0TAQH/BAIwADBWBglghkgBhvhCAQ0ESRZHVG8gZ2V0IHlvdXIgb3duIGNlcnRpZmlj YXRlIGZvciBGUkVFIGhlYWQgb3ZlciB0byBodHRwOi8vd3d3LkNBY2VydC5vcmcwDgYDVR0P AQH/BAQDAgOoMEAGA1UdJQQ5MDcGCCsGAQUFBwMEBggrBgEFBQcDAgYKKwYBBAGCNwoDBAYK KwYBBAGCNwoDAwYJYIZIAYb4QgQBMDIGCCsGAQUFBwEBBCYwJDAiBggrBgEFBQcwAYYWaHR0 cDovL29jc3AuY2FjZXJ0Lm9yZzAxBgNVHR8EKjAoMCagJKAihiBodHRwOi8vY3JsLmNhY2Vy dC5vcmcvcmV2b2tlLmNybDAfBgNVHREEGDAWgRRjYXJzdGVuQHN0cm90bWFubi5kZTANBgkq hkiG9w0BAQsFAAOCAgEAVMv5QTFt4uaS0pBXnRseGLMvtCCzfQj1oFflMw+mw9sGeZyhN0bM UmU4u7x3x1Uw3pj3lVb3MCmFPY+JjBNfOJ5glmMUcpr7aYjpRJoSlxrN66+4cC1/Wi7gx26S LHb/cqhr/XDv32N4zeFo17NTechNHIix7RnMjcIh970jYT2gW9I0USB5l23Gh+kg0Dwn+J98 DcRH4uwKGh32HSmPvnlKV3LghXuYRCSLYonPIoeDbUNkv0sL1rI+qK0YLwijxyqG2i4Pgvhp /U10fHXFDD2UX+9TiJTSABWd5BeFBR2imuXbO8yMXBIG/D7fPNqOCTWozH9PvZpNZj42I3CR QWOnshVT4XIp/gveGu+Dedme3VaIYXwT4Vx3hzEyF2/DaLy1LU9bYIKa/8XRVG4CSQiD91Gq HwtthENlIMKdOHiTrp9K1dD+9PvwsxY//2XRkhJKaeC/31idtF51OBM9MNgQVMth8btxnlSI Zz1l8wCBgfdOiwLsCq42++/87hgb6/GPLGnV+PLFB/IVM+rX41DQAQZyAeBEsqXwR6ODhOEZ KhawJHZl1ajjrKkaoM5u5cA0D7b1/WwxoCe9oe9FL+M3eTSLOa4jH6AenxvygQNh+tMhiB59 oSSPLeWxQdKXCu2ngbCvX4KUcLbw5F3KQ8xm45g1uatSHov19pwzexMxggSUMIIEkAIBATCB gDB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcx IjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1 cHBvcnRAY2FjZXJ0Lm9yZwIDEHAgMAkGBSsOAwIaBQCgggHoMBgGCSqGSIb3DQEJAzELBgkq hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1MDgwNTE1MzYwNFowIwYJKoZIhvcNAQkEMRYE FF4l9VpMgKiVACm3xfmcM7byr81DMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoG CCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggq hkiG9w0DAgIBKDCBkQYJKwYBBAGCNxAEMYGDMIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAc BgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5n IEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMQcCAwgZMG CyqGSIb3DQEJEAILMYGDoIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6 Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEh MB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMQcCAwDQYJKoZIhvcNAQEBBQAE ggIADW5GqXW07UBA/lXFf1ZdGBd6BxfrR4y1WsfTVnaeBnOePQRCvC4XpRCrEtrbNMjJ3mW9 ULHcdFq1QYdTWsaMrjRE7Qi26O9sq7WUaUumckyL2L+dDzHcVLEWlZYRFMLhkActjQN0Z1Kw FJP9WgMSvEpnMtRjadLuB7M/g6NkCqVr8OP5/Vy5Vcl4GBbYbUxBCmRZTaQYnELbt3Lebdil TNezmLdR04+MGfxIoLxyEnTU4qjp4BA3isM18mDWcGOrLDuc5ogW/LSQCrvzagDm1ncwzPHT 9eoiOHBnvYr/EoWPveGmc2PAMKZfrPsy8d9QaYllKir1n+mqJN4wvA5PfipPtMEy4swB5MQL OZXXyGX1rmaRvjiWK1/Z0MFODItqBszulUcsegW3Skl3RRPzCxl7a8BCTgIfnSeXnbS9Kb4s mU4Cf87ZnYDk4r7hoW8OqGB6jBvljUMH3BN7cOdDbLrSKc++kSSqS+3MblMjgY5/3q3RH5UX 5nfVWZhNuLNn4UwymU6J814PC1t7GdxoJeT9i5xPB9/jSNIfNKBjw7unigHk8aVKXKlvOZze 2WPPg7NKMTxQfny/sRAB4KSzP2Oztwu1SauX0UNYKSn2LSxfw69fu5WeSqZP7C4vhFSOVkTg DPy6EIuF2r5+A/O60eDfqm/NHqQOZaEC4OSFmXgAAAAAAAA= --------------ms070201010808000703080608-- From nobody Wed Aug 5 08:56:16 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D39D1A07BD; Wed, 5 Aug 2015 08:56:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.347 X-Spam-Level: X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vewqDLmK45ga; Wed, 5 Aug 2015 08:56:14 -0700 (PDT) Received: from hoffman.proper.com (Opus1.Proper.COM [207.182.41.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C6E11B30CA; Wed, 5 Aug 2015 08:56:09 -0700 (PDT) Received: from [10.32.60.120] (142-254-17-100.dsl.dynamic.fusionbroadband.com [142.254.17.100]) (authenticated bits=0) by hoffman.proper.com (8.15.1/8.14.9) with ESMTPSA id t75Fu0KI073394 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 5 Aug 2015 08:56:03 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 142-254-17-100.dsl.dynamic.fusionbroadband.com [142.254.17.100] claimed to be [10.32.60.120] From: "Paul Hoffman" To: "Stephen Farrell" Date: Wed, 05 Aug 2015 08:55:58 -0700 Message-ID: In-Reply-To: <55C22AD4.5010709@cs.tcd.ie> References: <87bnf1hair.fsf@alice.fifthhorseman.net> <87bnem2xjq.fsf@alice.fifthhorseman.net> <55C1F35A.5070904@cs.tcd.ie> <55C22AD4.5010709@cs.tcd.ie> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.1r5084) Archived-At: Cc: Paul Wouters , dane WG list , Daniel Kahn Gillmor , IETF OpenPGP Subject: Re: [dane] [openpgp] The DANE draft X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2015 15:56:15 -0000 On 5 Aug 2015, at 8:25, Stephen Farrell wrote: > On 05/08/15 16:12, Paul Hoffman wrote: >> Wearing my author hat: I don't care between b32 and hashing. Both are >> equally easy to document. However: >> >> On 5 Aug 2015, at 4:28, Stephen Farrell wrote: >> >>> So sorry to continue an argument but shouldn't this experiment be >>> a more conservative about privacy just in case it ends up wildly >>> successful? >> >> How is using the hash more conservative about privacy, except in >> zones >> that are signed with NSEC instead of the more common NSEC3? If you >> assume zones signed with NSEC3, both options are equally susceptible >> to >> dictionary-based guessing attacks, given that the effort to create >> search dictionaries for the billion of common LHS names is pretty low >> even for hashes. > > Tempora. That on-path attacker has a far easier time reversing the > b32 than anything based on the hash. Even with DPRIVE, we don't know > how to handle the recursive to authoritative part. Thanks, I was only thinking of off-path attackers. I agree that, if we are concerned with on-path watchers, hashes would preserve much more privacy than Base32 encodings. --Paul Hoffman From nobody Wed Aug 5 09:35:35 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32F8E1A1BEF for ; Wed, 5 Aug 2015 09:35:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.961 X-Spam-Level: X-Spam-Status: No, score=-1.961 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, 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 ZHHe3T12SUjI for ; Wed, 5 Aug 2015 09:35:22 -0700 (PDT) Received: from mx02.posteo.de (mx02.posteo.de [89.146.194.165]) (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 E2B1D1A1E0B for ; Wed, 5 Aug 2015 09:35:21 -0700 (PDT) Received: from dovecot04.posteo.de (unknown [185.67.36.27]) by mx02.posteo.de (Postfix) with ESMTPS id BE88D25B8E75; Wed, 5 Aug 2015 18:35:16 +0200 (CEST) Received: from mail.posteo.de (localhost [127.0.0.1]) by dovecot04.posteo.de (Postfix) with ESMTPSA id 3mmdpq4Qc4zFpVk; Wed, 5 Aug 2015 18:35:15 +0200 (CEST) Message-ID: <55C23B3D.1030502@posteo.de> Date: Wed, 05 Aug 2015 18:35:09 +0200 From: =?windows-1252?Q?Patrik_L=F6hr?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: dane@ietf.org, paul.hoffman@vpnc.org, paul@nohats.ca, stephen.farrell@cs.tcd.ie References: <87bnf1hair.fsf@alice.fifthhorseman.net> <87bnem2xjq.fsf@alice.fifthhorseman.net> <55C1F35A.5070904@cs.tcd.ie> <55C22AD4.5010709@cs.tcd.ie> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [dane] [openpgp] The DANE draft X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2015 16:35:34 -0000 Hi Paul, that's the point - we are concerned with on-path watchers. That is why we are in strong favour of hashing like i already stated: Hashing does not protect against "decryption" - but it makes a distinct difference whether I need to make a targeted attack on a hash, or can arbitrarily search through the plaintext in a stream of data. Best Patrik Am 05.08.2015 um 17:55 schrieb Paul Hoffman: > On 5 Aug 2015, at 8:25, Stephen Farrell wrote: > >> On 05/08/15 16:12, Paul Hoffman wrote: >>> Wearing my author hat: I don't care between b32 and hashing. Both are >>> equally easy to document. However: >>> >>> On 5 Aug 2015, at 4:28, Stephen Farrell wrote: >>> >>>> So sorry to continue an argument but shouldn't this experiment be >>>> a more conservative about privacy just in case it ends up wildly >>>> successful? >>> >>> How is using the hash more conservative about privacy, except in zones >>> that are signed with NSEC instead of the more common NSEC3? If you >>> assume zones signed with NSEC3, both options are equally susceptible to >>> dictionary-based guessing attacks, given that the effort to create >>> search dictionaries for the billion of common LHS names is pretty low >>> even for hashes. >> >> Tempora. That on-path attacker has a far easier time reversing the >> b32 than anything based on the hash. Even with DPRIVE, we don't know >> how to handle the recursive to authoritative part. > > Thanks, I was only thinking of off-path attackers. > > I agree that, if we are concerned with on-path watchers, hashes would > preserve much more privacy than Base32 encodings. > > --Paul Hoffman > > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane -- Patrik Löhr Posteo e.K. Methfesselstr. 38 10965 Berlin tel. +49 30 85074618 mail web USt-IdNr.: DE186713958 Handelsregister: Berlin-Charlottenburg · HRA 47592 B From nobody Wed Aug 5 11:33:29 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1D2E1B3446 for ; Wed, 5 Aug 2015 11:33:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DNa-AIXuyOhx for ; Wed, 5 Aug 2015 11:33:25 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 121D11B3458 for ; Wed, 5 Aug 2015 11:32:48 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 07218284D68; Wed, 5 Aug 2015 18:32:47 +0000 (UTC) Date: Wed, 5 Aug 2015 18:32:46 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20150805183246.GQ19228@mournblade.imrryr.org> References: <87bnf1hair.fsf@alice.fifthhorseman.net> <87bnem2xjq.fsf@alice.fifthhorseman.net> <55C1F35A.5070904@cs.tcd.ie> <55C22AD4.5010709@cs.tcd.ie> <55C23B3D.1030502@posteo.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <55C23B3D.1030502@posteo.de> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [dane] [openpgp] The DANE draft 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, 05 Aug 2015 18:33:26 -0000 On Wed, Aug 05, 2015 at 06:35:09PM +0200, Patrik L?hr wrote: > That's the point - we are concerned with on-path watchers. > That is why we are in strong favour of hashing like I already stated: > Hashing does not protect against "decryption" - but it makes a distinct > difference whether I need to make a targeted attack on a hash, or can > arbitrarily search through the plaintext in a stream of data. I don't think hashing (without salt) provides sufficient obfuscation to deter on-path attacks. If you're serious about mitigating on-path passive monitoring of DNS lookups, you MUST not only hash the localparts, but the hash MUST include a salt. Building a table of the top few billion localpart names is just too cheap. Even with salting, very large domains like gmail.com, ... are still substantially vulnerable to attack without a reasonably high iteration count. However, a high iteration count makes the construction of the zone data rather expensive. I don't think it is possible to construct any reasonable mechanism that avoids metadata leakage with DNS queries sent in the clear. If avoiding metadata leakage is important, the lookups need to happen over TLS or IPsec. Half-measures that attempt to obfuscate DNS queries are not IMHO a useful direction to pursue. The reason I proposed hashing (long ago) was to deal with long localparts, not enhance privacy. I did propose including the domain name in the hash ("breaking" DNAME support, really requiring per address not per localpart data) to frustrate data recovery by zone walkers, but that was not about mitigation of on-path metadata collection. -- Viktor. From nobody Wed Aug 5 11:49:18 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF3AB1A8AD4 for ; Wed, 5 Aug 2015 11:49:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pr9V3xa367v8 for ; Wed, 5 Aug 2015 11:49:16 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D52E1A8A56 for ; Wed, 5 Aug 2015 11:49:16 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 82E8C284D68; Wed, 5 Aug 2015 18:49:15 +0000 (UTC) Date: Wed, 5 Aug 2015 18:49:15 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20150805184915.GR19228@mournblade.imrryr.org> References: <2015080410094450139169@cnnic.cn> <20150804121245.GI19228@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150804121245.GI19228@mournblade.imrryr.org> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [dane] hash truncated to 28 octets 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, 05 Aug 2015 18:49:17 -0000 On Tue, Aug 04, 2015 at 12:12:45PM +0000, Viktor Dukhovni wrote: > On Tue, Aug 04, 2015 at 03:50:32AM -0400, Paul Wouters wrote: > > > >2,since some local-parts are longer than 28 octets, are there some collisions after hash?truncated?to?28?octets?? > > > > I think if you have 100.000 email addresses in one domain, the chance of > > collision would be pretty small. but non-zero. > > You'd need 2^112 email addresses for an appreciable chance of > collision. If every person on the planet (say 10^{10} people some > day) each had 100 email addresses in the same domain, that'd be > 10^{12} or ~2^{40} addresses. The collision probability would be > around 2^{80}/2^{112} = 2^{-32} ~ 10^{-6}. With "just" 10^{10} > addresses, it drops by a factor of 10^4 to 10^{-10}. For the record, the above vastly overestimates the collision probability. I accidentally computed the probability for a 112-bit hash, not a 224-bit hash. For a 224-bit hash, the collision probability with 10^{12} addresses is around 2^{80}/2^{224} or 2^{-144}. No collisions are likely before Earth is incinerated by a red-giant Sun around 2^{85} nanoseconds from now. -- Viktor. From nobody Wed Aug 5 12:04:59 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D977C1A7012 for ; Wed, 5 Aug 2015 12:04:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 sEEFxL849vvH for ; Wed, 5 Aug 2015 12:04:49 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C05A1A21AD for ; Wed, 5 Aug 2015 12:04:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 62C64BE8A for ; Wed, 5 Aug 2015 20:04:47 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZWk9PEhLCDlI for ; Wed, 5 Aug 2015 20:04:46 +0100 (IST) Received: from [10.87.48.73] (unknown [86.42.29.233]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 589E7BE4C for ; Wed, 5 Aug 2015 20:04:46 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1438801486; bh=Bygvxf2VBstloHsICwYJBtf8Pyi3upD9aYL2fWa1jQE=; h=Date:From:To:Subject:References:In-Reply-To:From; b=xYHa7V0EBVV+HTSJjaa7/BZd1kdn/iPw91oPgAYwlcmpKXfr8CnxXMzrnDcpAs1cl K0X3yuoCW70MIXMcJRpVWx5nzxoPMp4C555cDBhFOWOp9z/JpOZgFKFtr61bnmPGnj cKmZAXE9xm5RsBFeLWeHzWtpnFS2zhIFZV6oe6+Q= Message-ID: <55C25E4E.7000302@cs.tcd.ie> Date: Wed, 05 Aug 2015 20:04:46 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.8.0 MIME-Version: 1.0 To: dane@ietf.org References: <87bnf1hair.fsf@alice.fifthhorseman.net> <87bnem2xjq.fsf@alice.fifthhorseman.net> <55C1F35A.5070904@cs.tcd.ie> <55C22AD4.5010709@cs.tcd.ie> <55C23B3D.1030502@posteo.de> <20150805183246.GQ19228@mournblade.imrryr.org> In-Reply-To: <20150805183246.GQ19228@mournblade.imrryr.org> OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dane] [openpgp] The DANE draft X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2015 19:04:56 -0000 Hiya, On 05/08/15 19:32, Viktor Dukhovni wrote: > I don't think hashing (without salt) provides sufficient obfuscation > to deter on-path attacks. Compared to b32 hashing is clearly less bad, if we're putting user-specific identifiers in the DNS. The requirement to have a large table and to pre-calculate that does increase the effort for attachers. I don't think anyone has claimed that that would deter all attackers. And even for the most capable attacker, it would I think make it a little harder to do some kinds of pattern matching. And btw, I would assume use of a salt is impractical as would any mechanism that means that DNS queries for the same thing will differ each time. That seems more like a DNS-next-gen thing, but maybe I'm wrong about that. Be nice if so, but I suspect not. S. From nobody Wed Aug 5 12:06: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 B20541A905B; Wed, 5 Aug 2015 12:06:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id URwTaDkK6wtY; Wed, 5 Aug 2015 12:06:41 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id C1E9C1A905E; Wed, 5 Aug 2015 12:06:40 -0700 (PDT) Received: from fifthhorseman.net (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id 28429F984; Wed, 5 Aug 2015 15:06:38 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id CB56320053; Wed, 5 Aug 2015 21:06:28 +0200 (CEST) From: Daniel Kahn Gillmor To: Paul Wouters In-Reply-To: References: <87bnf1hair.fsf@alice.fifthhorseman.net> <87bnem2xjq.fsf@alice.fifthhorseman.net> User-Agent: Notmuch/0.20.2 (http://notmuchmail.org) Emacs/24.5.1 (x86_64-pc-linux-gnu) Date: Wed, 05 Aug 2015 15:06:28 -0400 Message-ID: <877fp91rnv.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: IETF OpenPGP , dane WG list Subject: Re: [dane] [openpgp] The DANE draft X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2015 19:06:43 -0000 On Wed 2015-08-05 04:14:42 -0400, Paul Wouters wrote: > The text does make it clear that you have that choice: > > The proposed new DNS Resource Record type is secured using DNSSEC. > This trust model is not meant to replace the Trust Signature model. > However, it can be used to encrypt a message that would otherwise > have to be sent out unencrypted, where it could be monitored by a > third party in transit or located in plaintext on a storage or email > server. This method can also be used to obtain the OpenPGP public > key which can then be used for manual verification. > > So there is no "smuggling".... DNSSEC is used to protect the transport, > and as a poor man's better-than-nothing web-of-trust alternative. ah, right. Please don't use the term "Trust Signature model" here. While RFC 4880 does specify "trust signatures", they're not commonly used, and they don't represent the most common implementations of how people interact with OpenPGP's network of identity assertions (aka "web of trust") -- we don't want to conflate "Trust Signature" with "web of trust". >> metadata leakage >> ---------------- >> >> I'm a little concerned about the potential for metadata leakage -- i >> don't want my MUAs to do DNS lookups every time i try to send mail to >> someone whose keys i dont have. > > The MUA can present you with information to manually verify or put a > trust level to the key. i think you are referring to the validity of a key for a given e-mail address here. in OpenPGP-land, "trust" usually means something different (e.g., how much you're willing to rely on identity assertions made by the key itself, analogous to "is this X.509 cert a trust anchor?") > The MUA should also cache negative attempts to get a key and limit > these so avoid fingerprinting email send times by looking at DNS > queries. That part is not in the current RRtype specification, but > should go into the openpgpkey-usage document (co-authors wanted!) Sounds far more reasonable than query-on-every-message, though i'm not just worried about fingerprinting e-mail send times -- i'm also worried about tracking user associations directly by lookup. >> localpart mangling >> ------------------ >> >> I have no strong preference for base32 vs. digested localpart for the >> hostname. Digested localparts require a little bit more work to invert >> than base32, but given the low entropy of typical normalized localparts, >> they don't provide a lot of protection against a determined attacker. > > And as clearly stated, were never meant to provide security. Digested local parts provide a little more privacy, not security. But i agree it's only a little bit, given the low entropy of most localparts. Is it conceivable that someone wants to use a high-entropy localpart to avoid address leakage via key lookup? In that case, it seems like you'd do just as well to have your high-entropy localpart uniquely identify your key in the first place, with something like 0EE5BE979282D80B9F7540F1CCD2ED94D21739E9@fifthhorseman.net. >> I'm slightly more concerned with e-mail address length limits on base32 >> than on digested localparts -- a long localpart plus a long domain name >> could make for a very large DNS label, whereas a fixed digest should >> give us a fixed bound on size. > > Do you forsee email addresses > 256/2 to be common use? you've dropped the units here -- 256/2 what? are we talking about characters or octets? if octets, under what encoding? I agree that e-mail addresses are rarely this long today, but we should be cautious and explicit about any additional constraints when we're proposing to mapp a limit from one domain (DNS) onto another domain (e-mail localparts). > Other people believe there is some use. If the only downside is not > supporting insanely long email addresses, which I think are a more > rare event, I think that it is okay. Steven's point about raising the cost slightly for passive attackers (e.g. TEMPORA) seems at least as relevant to me as the feasibility of online-signed zones serving up end-user OpenPGP certificates that can't possibly match the requested address exactly. That said, there's a separate scenario, where as a domain administrator i want to mint and sign an OpenPGP certificate on each query (even ones where i have no user), to avoid the possibility of someone enumerating all my actual users by walking the localpart space. minting a matching certificate would be creatable with the base32 approach (how would this work? something like the following: the DNS server responsible for these records would keep a domain-wide long-term secret. upon a query that it finds it has no legitimate record for, it would hash the query name and the long-term secret into a seed for a PRNG. from the PRNG output, it would deterministically derive secret key material and any other variable metadata (like creation date) needed to derive a new certificate. it could cache or discard these certificates as requested, because it could always re-generate them exactly from a new query. when a user opens a matching account, the user's personal key would replace the domain-generated one. i'm not saying this is a great system, just outlining how it might be done for a system that wants to keep its userbase hidden) I'm still on the fence here, as you can tell :P >> Key Transitions >> --------------- >> >> While i say "exactly one" Transferable Public Key, i'm assuming that the >> DNS is OK with serving multiple OPENPGPKEY records at a single label. > > What is the advantage of multiple DNS records with 1 key over one DNS > record with multiple keys? While I'm all four specifying one method to > increase chances of interop, I'm not particularly set on one or the > other solution. Hm, the more i think about it i find i prefer it aesthetically, but i'm not sure i have a good engineering argument. I don't see a great way to effectively prevent people from doing either one -- are there any DNS record types explicitly prohibit multiple records in response to a given query? OpenPGP composable certificates are just a series of OpenPGP packets concatenated; two certs concatenated together are themselves also just a series of OpenPGP packets by induction. We could say that the RDATA "MUST start with a Public Key Packet and MUST NOT contain more than one Public Key Packet". >> Filtered Certificates >> --------------------- >> >> Given that some users have aggregated OpenPGP certificates that are >> quite large (my own is currently ~475KB), we don't want to require >> people to publish their entire certificate in the DNS. Because OpenPGP >> certificates ("transferable public keys) are composable (they consist of >> a series of packets, many of which can be dropped), a reasonable policy >> for filtering the certificate for size purposes should be suggested. > > We mention this in Section 5: > > https://tools.ietf.org/html/draft-ietf-dane-openpgpkey-03#section-5 looks sensible, though i think some of the terminology is slightly off there. i could try to provide patches for that section if you like. how is the draft developed -- how do you prefer edits sent to you? > The idea was not to specify these policies in the DNS RRtype. Just tell > people to keep to small keys. It did include an example gpg command > in appendix A, but your command seems even better so I will update it. > > I would prefer not to mention specific key elements as those might > change and are not really relevent for the DNS specification. Or perhaps > these recommendations could go in the openpgpkey-usage document. That seems OK to me as well. --dkg From nobody Wed Aug 5 12:32: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 7260C1A0196; Wed, 5 Aug 2015 12:32:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_46=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 Oi4ZSiwMj0XP; Wed, 5 Aug 2015 12:32:35 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 222341A01E7; Wed, 5 Aug 2015 12:32:26 -0700 (PDT) Received: from fifthhorseman.net (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id B6665F984; Wed, 5 Aug 2015 15:32:24 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id 2EEAE2010F; Wed, 5 Aug 2015 21:32:14 +0200 (CEST) From: Daniel Kahn Gillmor To: Stephen Farrell , Paul Hoffman In-Reply-To: <55C22AD4.5010709@cs.tcd.ie> References: <87bnf1hair.fsf@alice.fifthhorseman.net> <87bnem2xjq.fsf@alice.fifthhorseman.net> <55C1F35A.5070904@cs.tcd.ie> <55C22AD4.5010709@cs.tcd.ie> User-Agent: Notmuch/0.20.2 (http://notmuchmail.org) Emacs/24.5.1 (x86_64-pc-linux-gnu) Date: Wed, 05 Aug 2015 15:32:14 -0400 Message-ID: <874mkd1qgx.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: Paul Wouters , dane WG list , IETF OpenPGP Subject: Re: [dane] [openpgp] The DANE draft X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2015 19:32:36 -0000 On Wed 2015-08-05 11:25:08 -0400, Stephen Farrell wrote: > Tempora. That on-path attacker has a far easier time reversing the > b32 than anything based on the hash. Even with DPRIVE, we don't know > how to handle the recursive to authoritative part. > > So a "putative other protocol that copies this" could well do a great > job on hiding identifiers only to be caught out by following this b32 > convention. > > I do accept that hashing doesn't make much difference for PGP or SMIME > since the DNS answer in the success case almost certainly gives the > game away, but I don't think that has to be true in general. > > The failure case may also be of interest though, with hashing, that DNS > answer doesn't immediately tell the attacker to whom I'd like to send > email. And I guess if some MUA adopts this there'll be quite a few > negative answers for quite some time, so there's a privacy difference > there I think. (Not sure if that was raised before - apologies if so.) yep, i raised that concern too, thanks for reinforcing it :) the cost of inverting a digest is definitely more than the cost of inverting b32, but it's unlikely to be difficult for an interested attacker to invert otherwise low-entropy domain names or localparts of e-mail addresses. see djb's writeup on nsec3walker for a related example of how low the bar is for doing large-scale hashing with the kind of low-entropy input spaces found in DNS: http://dnscurve.org/nsec3walker.html It's not exactly the same problem, but a good example of how small the protection is against a motivated adversary in this context. --dkg From nobody Wed Aug 5 19:27:55 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23CED1B2AD6 for ; Wed, 5 Aug 2015 19:27:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.83 X-Spam-Level: * X-Spam-Status: No, score=1.83 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.741, RCVD_IN_DNSWL_LOW=-0.7, 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 bVEriqO7BKxZ for ; Wed, 5 Aug 2015 19:27:52 -0700 (PDT) Received: from cnnic.cn (smtp13.cnnic.cn [218.241.118.13]) by ietfa.amsl.com (Postfix) with ESMTP id 6BF591B2AD4 for ; Wed, 5 Aug 2015 19:27:50 -0700 (PDT) Received: from healthyao-THINK (unknown [218.241.103.53]) by ocmail02.zx.nicx.cn (Coremail) with SMTP id AQAAf0ApMIQhxsJVqGWyBw--.15908S2; Thu, 06 Aug 2015 10:27:46 +0800 (CST) Date: Thu, 6 Aug 2015 10:27:44 +0800 From: "Jiankang Yao" To: dane X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7.0.1.92[cn] Mime-Version: 1.0 Message-ID: <20150806102642986441123@cnnic.cn> Content-Type: multipart/alternative; boundary="----=_001_NextPart606130563311_=----" X-CM-TRANSID: AQAAf0ApMIQhxsJVqGWyBw--.15908S2 X-Coremail-Antispam: 1UD129KBjDUn29KB7ZKAUJUUUUU529EdanIXcx71UUUUU7v73 VFW2AGmfu7bjvjm3AaLaJ3UjIYCTnIWjp_UUUYW7k0a2IF6FyUM7kC6x804xWl14x267AK xVWUJVW8JwAFc2x0x2IEx4CE42xK8VAvwI8IcIk0rVWrJVCq3wAFIxvE14AKwVWUJVWUGw A2ocxC64kIII0Yj41l84x0c7CEw4AK67xGY2AK021l84ACjcxK6xIIjxv20xvE14v26F1j 6w1UM28EF7xvwVC0I7IYx2IY6xkF7I0E14v26r4UJVWxJr1l84ACjcxK6I8E87Iv67AKxV W8Jr0_Cr1UM28EF7xvwVC2z280aVCY1x0267AKxVWxJr0_GcWle2I262IYc4CY6c8Ij28I cVAaY2xG8wAqx4xG6xAIxVCFxsxG0wAv7VC0I7IYx2IY67AKxVWUJVWUGwAv7VC2z280aV AFwI0_Jr0_Gr1lOx8S6xCaFVCjc4AY6r1j6r4UM4x0Y48IcxkI7VAKI48JM4xvF2IEb7IF 0Fy264kE64k0F24lFcxC0VAYjxAxZF0Ex2IqxwCY02Avz4vE14v_Gr1l42xK82IYc2Ij64 vIr41l4I8I3I0E4IkC6x0Yz7v_Jr0_Gr1lx2IqxVAqx4xG67AKxVWUGVWUWwC20s026x8G jcxK67AKxVWUGVWUWwC2zVAF1VAY17CE14v26r1j6r15MIIYrxkI7VAKI48JMIIF0xvE2I x0cI8IcVAFwI0_Jr0_JF4lIxAIcVC0I7IYx2IY6xkF7I0E14v26r1j6r4UMIIF0xvE42xK 8VAvwI8IcIk0rVWrZr1j6s0DMIIF0xvEx4A2jsIE14v26r1j6r4UMIIF0xvEx4A2jsIEc7 CjxVAFwI0_Jr0_Gr1l6VACY4xI67k04243AbIYCTnIWIevJa73UjIFyTuYvjxUceOJDUUU U X-CM-SenderInfo: x1dryyw6fq0xffof0/ Archived-At: Subject: [dane] right-to-left characters in local part X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: yaojk List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2015 02:27:54 -0000 This is a multi-part message in MIME format. ------=_001_NextPart606130563311_=---- Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: base64 aGVsbG8sDQoNCiAgIGluIHNlY3Rpb24gMyBvZiBkcmFmdC1pZXRmLWRhbmUtb3BlbnBncGtleSwN CiBkbyB3ZSBuZWVkIHNvbWUgZGlzY3Vzc3Rpb24gYWJvdXQgdGhlIGlzc3VlcyByZWxhdGVkIHRv IGxvY2FsIHBhcnQgb2YgdGhlIGVtYWlsIGFkZHJlc3Mgd2hpY2ggaW5jbHVkZXMgdGhlICByaWdo dC10by1sZWZ0IGNoYXJhY3RlcnMgc3VjaCBhcyBBcmFiaWMgY2hhcmFjdGVyPw0KDQoNCg0KDQoN CkppYW5rYW5nIFlhbw== ------=_001_NextPart606130563311_=---- Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
hello,
 
   in section 3 of draft-ietf-dane-openpgpkey,
 do we need some discusstion about the issues related=20 to local part of the email address which includes the=20  right-to-left characters such as Arabic character?
 
 
Jiankang Yao
------=_001_NextPart606130563311_=------ From nobody Wed Aug 5 20:09: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 22BE51B2B66 for ; Wed, 5 Aug 2015 20:09:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.347 X-Spam-Level: X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KzBC7rUz4ZBa for ; Wed, 5 Aug 2015 20:09:42 -0700 (PDT) Received: from hoffman.proper.com (Opus1.Proper.COM [207.182.41.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C2381ACD91 for ; Wed, 5 Aug 2015 20:09:42 -0700 (PDT) Received: from [192.168.114.1] (142-254-17-100.dsl.dynamic.fusionbroadband.com [142.254.17.100]) (authenticated bits=0) by hoffman.proper.com (8.15.1/8.14.9) with ESMTPSA id t7639XaL009761 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 5 Aug 2015 20:09:34 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 142-254-17-100.dsl.dynamic.fusionbroadband.com [142.254.17.100] claimed to be [192.168.114.1] From: "Paul Hoffman" To: yaojk Date: Wed, 05 Aug 2015 20:09:33 -0700 Message-ID: <80F9E64C-A1E8-4665-BCEF-DB20306BBF69@vpnc.org> In-Reply-To: <20150806102642986441123@cnnic.cn> References: <20150806102642986441123@cnnic.cn> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.1r5084) Archived-At: Cc: dane Subject: Re: [dane] right-to-left characters in local part X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 06 Aug 2015 03:09:43 -0000 On 5 Aug 2015, at 19:27, Jiankang Yao wrote: > in section 3 of draft-ietf-dane-openpgpkey, > do we need some discusstion about the issues related to local part of > the email address which includes the right-to-left characters such as > Arabic character? Why would we? Those characters are just as legitimate as other characters. --Paul Hoffman From nobody Wed Aug 5 22:23:59 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44C9C1B3983; Wed, 5 Aug 2015 22:23:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QF6lm-Br99ve; Wed, 5 Aug 2015 22:23:53 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBD441B3982; Wed, 5 Aug 2015 22:23:53 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 5D783284D71; Thu, 6 Aug 2015 05:23:52 +0000 (UTC) Date: Thu, 6 Aug 2015 05:23:52 +0000 From: Viktor Dukhovni To: The IESG , draft-ietf-dane-ops.shepherd@ietf.org, draft-ietf-dane-ops.ad@ietf.org, dane@ietf.org Message-ID: <20150806052352.GG24415@mournblade.imrryr.org> References: <20150805034540.27866.98360.idtracker@ietfa.amsl.com> <20150805035746.GO19228@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150805035746.GO19228@mournblade.imrryr.org> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [dane] Ben Campbell's Yes on draft-ietf-dane-ops-14: (with COMMENT) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2015 05:23:55 -0000 On Wed, Aug 05, 2015 at 03:57:46AM +0000, Viktor Dukhovni wrote: > > NEW: > > This section updates [RFC6698] by specifying that the > > TLSA Publisher MUST ensure that each combination of Certificate > > Usage, selector and matching type in the server's TLSA RRset includes at > > least one record that matches the server's current certificate chain. > > END > > Yes. Thanks. All suggestions received so far are I believe merged. Preview of -15 changes at: https://github.com/vdukhovni/ietf/compare/master~2...master?diff=unified&name=master I'm ready to push -15 when advised to proceed. -- Viktor. From nobody Thu Aug 6 01:24: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 4C91C1B29C4; Thu, 6 Aug 2015 01:24:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.81 X-Spam-Level: X-Spam-Status: No, score=-0.81 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_44=0.6, J_CHICKENPOX_46=0.6, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DgJiP6RYSnMN; Thu, 6 Aug 2015 01:23:59 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 806791B29C2; Thu, 6 Aug 2015 01:23:59 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3mn2sS3hmMz3Nf; Thu, 6 Aug 2015 10:23:56 +0200 (CEST) Authentication-Results: mx.nohats.ca; dkim=pass (1024-bit key) header.d=nohats.ca header.i=@nohats.ca header.b=sRWcBBIT X-OPENPGPKEY: Message passed unmodified X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id Sr8nV4o6jK5Z; Thu, 6 Aug 2015 10:23:55 +0200 (CEST) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Thu, 6 Aug 2015 10:23:55 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id C0290800B3; Thu, 6 Aug 2015 04:23:54 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1438849434; bh=5cSel0yMtjakFg6uAzVu2zcUnUhD52zez2/QjOql84Q=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=sRWcBBITR93cm0hBxJy8MWIRD5unHh7g1C7ghCw1rWOvrvdefhKc5pQsbHOH/Kibs ac9DgKKznXdUeC8rFONlJHMZImY0S34VQfivqn2FL1Zhdcy6tbbh5tEinwGbsGHXCZ rC6+FNN05T50mZIGKBb0HjwVliImmqek7BaJKt/k= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.15.1/8.15.1/Submit) with ESMTP id t768NsEC019554; Thu, 6 Aug 2015 04:23:54 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Thu, 6 Aug 2015 04:23:54 -0400 (EDT) From: Paul Wouters To: dane WG list In-Reply-To: <55C22D64.9080507@strotmann.de> Message-ID: References: <87bnf1hair.fsf@alice.fifthhorseman.net> <87bnem2xjq.fsf@alice.fifthhorseman.net> <55C1F35A.5070904@cs.tcd.ie> <55C22D64.9080507@strotmann.de> User-Agent: Alpine 2.11 (LFD 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: IETF OpenPGP Subject: Re: [dane] [openpgp] The DANE draft X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2015 08:24:01 -0000 On Wed, 5 Aug 2015, Carsten Strotmann wrote: > for OPENPGPKEY/SMIMECERT zones, operators could (maybe SHOULD) use > NSEC/NSEC3 "narrow" signing to prevent "zone-walking". email addresses are not secret. That is not the privacy you can protect at all. Anyone can either do a internet search or just attempt to deliver an email to figure out if the email address is valid. The only realy privacy concern is learning who is querying, meaning who is interested in mailing a particular user - assuming everything else on the email path is secureb by TLS, and the domain is large enough to actually hide the userbase (that is, nohats.ca is already a lost cause, because everyone knows a TLS connection to mx.nohats.ca means you are going to email me) > Breaking hashes requires much more "willful intent" than decoding BASE32. But that difference these days is basically zero as soon as someone puts up a module for johntheripper or hashcat or something on github. > The hashing communicates a "don't go here" message, even though it is > technically not a strong protection. If the sysadmin does not respect privacy on base32, they will not respect privacy on hash(very simple names) or even hash(former-lover) > It is like having a closed door vs. no door at all. No door communicates > "come in, no secrets, we're open" while the closed door (even if it can > be opened by minor force) communicates "private space". I might agree but I think the gain for this is so incredibly small, that I think the gain for use of online signers plus email address corrections by the smtp+dnssec combined server is actually a more likely and minorly useful thing to have. And don't get me wrong. I'd rather see zonefiles with a hash than with base32 cut from an esthetical point of view. Paul From nobody Thu Aug 6 01:39:30 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FBBA1ACE84; Thu, 6 Aug 2015 01:39:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.611 X-Spam-Level: X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 QdCMkBHpcBh2; Thu, 6 Aug 2015 01:39:25 -0700 (PDT) Received: from cnnic.cn (smtp13.cnnic.cn [218.241.118.13]) by ietfa.amsl.com (Postfix) with ESMTP id 1BD9F1ACEA2; Thu, 6 Aug 2015 01:39:23 -0700 (PDT) Received: from healthyao-THINK (unknown [218.241.103.53]) by ocmail02.zx.nicx.cn (Coremail) with SMTP id AQAAf0ApMZU5HcNV0rCyBw--.7527S2; Thu, 06 Aug 2015 16:39:21 +0800 (CST) Date: Thu, 6 Aug 2015 16:39:20 +0800 From: "Jiankang Yao" To: "Paul Wouters" , dane References: <87bnf1hair.fsf@alice.fifthhorseman.net> <87bnem2xjq.fsf@alice.fifthhorseman.net> <55C1F35A.5070904@cs.tcd.ie> <55C22D64.9080507@strotmann.de>, X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7.0.1.92[cn] Mime-Version: 1.0 Message-ID: <20150806163914546863148@cnnic.cn> Content-Type: multipart/alternative; boundary="----=_001_NextPart602551245372_=----" X-CM-TRANSID: AQAAf0ApMZU5HcNV0rCyBw--.7527S2 X-Coremail-Antispam: 1UD129KBjvdXoWrZryUGFWkKFyrGFW8WF43GFg_yoW3WFc_Wa y8Wws7Ww4Yyrs7Kws3G3Wjkr48XayqgrWqy348Xr92vry3AFn7Za4vvFy7uF15JF4qv3sr KryfGw4IgrWagjkaLaAFLSUrUUUUUb8apTn2vfkv8UJUUUU8Yxn0WfASr-VFAUDa7-sFnT 9fnUUIcSsGvfJTRUUUbTAYjsxI4VWxJwAYFVCjjxCrM7AC8VAFwI0_Jr0_Gr1l1xkIjI8I 6I8E6xAIw20EY4v20xvaj40_Wr0E3s1l1IIY67AEw4v_Jr0_Jr4l8cAvFVAK0II2c7xJM2 8CjxkF64kEwVA0rcxSw2x7M28EF7xvwVC0I7IYx2IY67AKxVW8JVW5JwA2z4x0Y4vE2Ix0 cI8IcVCY1x0267AKxVW8JVWxJwA2z4x0Y4vEx4A2jsIE14v26rxl6s0DM28EF7xvwVC2z2 80aVCY1x0267AKxVW0oVCq3wAS0I0E0xvYzxvE52x082IY62kv0487Mc02F40E42I26xC2 a48xMcIj6xIIjxv20xvE14v26r1j6r18McIj6I8E87Iv67AKxVW8JVWxJwAm72CE4IkC6x 0Yz7v_Jr0_Gr1lF7xvr2IYc2Ij64vIr41lFcxC0VAYjxAxZF0Ew4CEw7xC0wACY4xI67k0 4243AVC20s07MxkIecxEwVAFwVW8ZwCF04k20xvY0x0EwIxGrwCFx2IqxVCFs4IE7xkEbV WUJVW8JwC20s026c02F40E14v26r106r1rMI8I3I0E7480Y4vE14v26r106r1rMI8E67AF 67kF1VAFwI0_Jrv_JF1lIxkGc2Ij64vIr41lIxAIcVC0I7IYx2IY67AKxVWUJVWUCwCI42 IY6xIIjxv20xvEc7CjxVAFwI0_Jr0_Gr1lIxAIcVCF04k26cxKx2IYs7xG6rW3Jr0E3s1l IxAIcVC2z280aVAFwI0_Gr0_Cr1lIxAIcVC2z280aVCY1x0267AKxVW8JVW8Jr1l6VACY4 xI67k04243AbIYCTnIWIevJa73UjIFyTuYvjxUxOJ5UUUUU X-CM-SenderInfo: x1dryyw6fq0xffof0/ Archived-At: Cc: IETF OpenPGP Subject: Re: [dane] [openpgp] The DANE draft X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: yaojk List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2015 08:39:27 -0000 This is a multi-part message in MIME format. ------=_001_NextPart602551245372_=---- Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 DQoNCkZyb206IFBhdWwgV291dGVycw0KRGF0ZTogMjAxNS0wOC0wNiAxNjoyMw0KVG86IGRhbmUg V0cgbGlzdA0KQ0M6IElFVEYgT3BlblBHUA0KU3ViamVjdDogUmU6IFtkYW5lXSBbb3BlbnBncF0g VGhlIERBTkUgZHJhZnQNCk9uIFdlZCwgNSBBdWcgMjAxNSwgQ2Fyc3RlbiBTdHJvdG1hbm4gd3Jv dGU6DQoNCj4+IGZvciBPUEVOUEdQS0VZL1NNSU1FQ0VSVCB6b25lcywgb3BlcmF0b3JzIGNvdWxk IChtYXliZSBTSE9VTEQpIHVzZQ0KPj4gTlNFQy9OU0VDMyAibmFycm93IiBzaWduaW5nIHRvIHBy ZXZlbnQgInpvbmUtd2Fsa2luZyIuDQo+DQo+ZW1haWwgYWRkcmVzc2VzIGFyZSBub3Qgc2VjcmV0 LiBUaGF0IGlzIG5vdCB0aGUgcHJpdmFjeSB5b3UgY2FuIHByb3RlY3QNCj5hdCBhbGwuIEFueW9u ZSBjYW4gZWl0aGVyIGRvIGEgaW50ZXJuZXQgc2VhcmNoIG9yIGp1c3QgYXR0ZW1wdCB0bw0KPmRl bGl2ZXIgYW4gZW1haWwgdG8gZmlndXJlIG91dCBpZiB0aGUgZW1haWwgYWRkcmVzcyBpcyB2YWxp ZC4NCj4NCj4NCg0KaWYgdGhlcmUgaXMgYSAiZW1haWwgem9uZSB3YWxraW5nIiwgdGhlIGVtYWls IHNwYW1tZXIgY2FuIHVzZSB0aGlzIGZlYXR1cmUgdG8gZ2V0IHRoZSB2YWxpZCBhZGRyZWVzIGVh c2lseSBhbmQgc2VuZCB0cmFzaCBlbWFpbHMuDQpJZiB3ZSBob3BlIHRvIHByZXZlbnQgdGhlIHNw YW1tZXIgZnJvbSBnZXR0aW5nIHRoZSBlbWFpbCBhZGRyZXNzIGVhc2lseSwgdGhlIGVtYWlsIGFk ZHJlc3Mgc2hvdWxkIGJlIHJlZ2FyZGVkIGFzIHNlY3JldC4NCg0KDQpKaWFua2FuZyBZYW8= ------=_001_NextPart602551245372_=---- Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
 
 
From: Paul Wouters<= /DIV>
Date: 2015-08-06 16:23
To: dane WG list
CC: IETF OpenPGP<= /DIV>
Subject: Re: [dane] [openpgp] The DANE draft
<= /DIV>
On Wed, 5 Aug 2015, Carsten Strotmann&n= bsp;wrote:
 
>> for OPENPGPKEY/SMIMECERT zones, operator= s could (maybe SHOULD) use
>> NSEC/NSEC3 "narrow" signing to prev= ent "zone-walking".
>
>email addresses are not secret. That&nbs= p;is not the privacy you can protect
>at all. Anyone can either do a = ;internet search or just attempt to
>deliver an email to figure out if&n= bsp;the email address is valid.
>
>
 
if there is a "email zone walking", the email spammer can use this fe= ature=20 to get the valid addrees easily and send trash emails.
If we hope to prevent the spammer from getting the email address easi= ly,=20 the email address should be regarded as secret.
 
 
Jiankang Yao
------=_001_NextPart602551245372_=------ From nobody Thu Aug 6 01:50:06 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6476E1B2A13; Thu, 6 Aug 2015 01:50:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fV-F1OlNcUO1; Thu, 6 Aug 2015 01:50:02 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D0A21ACE12; Thu, 6 Aug 2015 01:50:01 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BVY33393; Thu, 06 Aug 2015 08:50:00 +0000 (GMT) Received: from LHREML504-MBS.china.huawei.com ([10.125.30.107]) by lhreml402-hub.china.huawei.com ([10.201.5.241]) with mapi id 14.03.0235.001; Thu, 6 Aug 2015 09:49:53 +0100 From: Hosnieh Rafiee To: Paul Wouters Thread-Topic: [dane] [openpgp] The DANE draft Thread-Index: AQHQz1cAG6iEyei+P0uLgSQSGhtjSZ39ND4AgAA+fgCAAAazAIABGZUAgAAThlA= Date: Thu, 6 Aug 2015 08:49:53 +0000 Message-ID: <814D0BFB77D95844A01CA29B44CBF8A7015D6641@lhreml504-mbs> References: <87bnf1hair.fsf@alice.fifthhorseman.net> <87bnem2xjq.fsf@alice.fifthhorseman.net> <55C1F35A.5070904@cs.tcd.ie> <55C22D64.9080507@strotmann.de> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.221.82.162] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: IETF OpenPGP , dane WG list Subject: Re: [dane] [openpgp] The DANE draft X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2015 08:50:04 -0000 > -----Original Message----- > From: dane [mailto:dane-bounces@ietf.org] On Behalf Of Paul Wouters >=20 > On Wed, 5 Aug 2015, Carsten Strotmann wrote: >=20 > > for OPENPGPKEY/SMIMECERT zones, operators could (maybe SHOULD) use > > NSEC/NSEC3 "narrow" signing to prevent "zone-walking". >=20 > email addresses are not secret. That is not the privacy you can protect > at all. Anyone can either do a internet search or just attempt to > deliver an email to figure out if the email address is valid. Disagree! This really depends on the person and scenarios.=20 For some people maybe it is not a problem to share their email addresses or= put them on their public websites because it is a part of their job. For e= xample a company shares its email to others so that other can contact them.= But for someone like a president of a country or a politician it is impor= tant because a criminal can bug them by threatening them, try to hack their= email by sending messages with fake links to do phishing attack or send co= des inside html body of the email to access their computer and infect it. T= herefore, from privacy point of view, as much information as I can have abo= ut a victim, the chance of attack is higher.=20 > The only realy privacy concern is learning who is querying, meaning who > is interested in mailing a particular user - assuming everything else > on the email path is secureb by TLS, and the domain is large enough to > actually hide the userbase (that is, nohats.ca is already a lost cause, > because everyone knows a TLS connection to mx.nohats.ca means you are > going to email me) Nope, some people who really care about their privacy uses different emails= for different purposes (business, family, friends). > > Breaking hashes requires much more "willful intent" than decoding > BASE32. >=20 > But that difference these days is basically zero as soon as someone > puts up a module for johntheripper or hashcat or something on github. Again disagree.=20 =20 Hosnieh From nobody Thu Aug 6 01:54: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 28E5B1B2A39; Thu, 6 Aug 2015 01:54:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.01 X-Spam-Level: X-Spam-Status: No, score=-4.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_I_LETTER=-2, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9fsidvjvlBV8; Thu, 6 Aug 2015 01:54:31 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E7201B2A33; Thu, 6 Aug 2015 01:54:31 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3mn3Xh5LW7z3Nf; Thu, 6 Aug 2015 10:54:28 +0200 (CEST) Authentication-Results: mx.nohats.ca; dkim=pass (1024-bit key) header.d=nohats.ca header.i=@nohats.ca header.b=eK4Ar0JS X-OPENPGPKEY: Message passed unmodified X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id 2wWNJ-tdCu39; Thu, 6 Aug 2015 10:54:27 +0200 (CEST) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Thu, 6 Aug 2015 10:54:27 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id CBC29800B3; Thu, 6 Aug 2015 04:54:26 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1438851266; bh=Rjn9sNIKouiZpqO92bzNP403chbcNLexIH13TprNeA0=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=eK4Ar0JSqhQOx2wEtADUievWWmOrmrkuvWdv+nmAzf6Vm1C8eIHhvElpOdKKMQTpg Qny8KklALgCdnpyXnY6bBauCRls23G7S8ySuOLjZVNx92v9ZI8shW8YYM9n4kxeKx3 CmT0i45LZf06bF8MZO1U0i7svAbrfGnatrUoQWjg= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.15.1/8.15.1/Submit) with ESMTP id t768sOQr025801; Thu, 6 Aug 2015 04:54:26 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Thu, 6 Aug 2015 04:54:24 -0400 (EDT) From: Paul Wouters To: Jiankang Yao In-Reply-To: <20150806163914546863148@cnnic.cn> Message-ID: References: <87bnf1hair.fsf@alice.fifthhorseman.net> <87bnem2xjq.fsf@alice.fifthhorseman.net> <55C1F35A.5070904@cs.tcd.ie> <55C22D64.9080507@strotmann.de>, <20150806163914546863148@cnnic.cn> User-Agent: Alpine 2.11 (LFD 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 8BIT Archived-At: Cc: IETF OpenPGP , dane Subject: Re: [dane] [openpgp] The DANE draft X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2015 08:54:33 -0000 On Thu, 6 Aug 2015, Jiankang Yao wrote: > if there is a "email zone walking", the email spammer can use this feature to get the valid addrees easily and send trash emails. > If we hope to prevent the spammer from getting the email address easily, the email address should be regarded as secret. So if you use NSEC3 and base32, they need to break the NSEC3 hashing, which has various parameters to make it easier or harder, but all are basically in the range of a few days of GPU cracking. If you use NSEC3 and sha256(LHS) then the work increase is basically making a table for every 8 letter combination and dictionary names which should be far less computations than the NSEC3 breaking. And to defend your email address against this, you have to make it so it is not easilly guessable with known names and that makes it harder to convey your email address verbally to other people - the exact opposite of what you want. Also, the only current alternative for people is to push their email address plaintext to a keyserver. So even with base32, we are increasing the privacy of email addresses of openpgp users. I really do believe that the hashing is not an affective security meassure. Paul From nobody Thu Aug 6 01:56:17 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACFDB1B2A36; Thu, 6 Aug 2015 01:56:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XZkCJZhC_6T3; Thu, 6 Aug 2015 01:56:15 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 331741B2A14; Thu, 6 Aug 2015 01:56:15 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BVY34125; Thu, 06 Aug 2015 08:56:07 +0000 (GMT) Received: from LHREML504-MBS.china.huawei.com ([10.125.30.107]) by lhreml405-hub.china.huawei.com ([10.201.5.242]) with mapi id 14.03.0235.001; Thu, 6 Aug 2015 09:56:01 +0100 From: Hosnieh Rafiee To: yaojk Thread-Topic: [dane] [openpgp] The DANE draft Thread-Index: AQHQz1cAG6iEyei+P0uLgSQSGhtjSZ39ND4AgAA+fgCAAAazAIABGZUAgAAVT5OAAAMvkA== Date: Thu, 6 Aug 2015 08:56:01 +0000 Message-ID: <814D0BFB77D95844A01CA29B44CBF8A7015D6656@lhreml504-mbs> References: <87bnf1hair.fsf@alice.fifthhorseman.net> <87bnem2xjq.fsf@alice.fifthhorseman.net> <55C1F35A.5070904@cs.tcd.ie> <55C22D64.9080507@strotmann.de>, <20150806163914546863148@cnnic.cn> In-Reply-To: <20150806163914546863148@cnnic.cn> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.221.82.162] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: IETF OpenPGP , dane Subject: Re: [dane] [openpgp] The DANE draft X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2015 08:56:16 -0000 From: dane [mailto:dane-bounces@ietf.org] On Behalf Of Jiankang Yao >>=A0for=A0OPENPGPKEY/SMIMECERT=A0zones,=A0operators=A0could=A0(maybe=A0SHO= ULD)=A0use >>=A0NSEC/NSEC3=A0"narrow"=A0signing=A0to=A0prevent=A0"zone-walking". > >email=A0addresses=A0are=A0not=A0secret.=A0That=A0is=A0not=A0the=A0privacy= =A0you=A0can=A0protect >at=A0all.=A0Anyone=A0can=A0either=A0do=A0a=A0internet=A0search=A0or=A0just= =A0attempt=A0to >deliver=A0an=A0email=A0to=A0figure=A0out=A0if=A0the=A0email=A0address=A0is= =A0valid. > > =A0 >if there is a "email zone walking", the email spammer can use this feature= to get the valid addrees easily and send trash emails. >If we hope to prevent the spammer from getting the email address easily, t= he email address=A0should be regarded as secret. =A0 =A0 This is, IMO, a nightmare when using IPv6.... spammers sending email with = new IP and sometimes they know how to bypass the content filtering antispam= ming ... Hosnieh =20 From nobody Thu Aug 6 02:04:42 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D98F11B2A39; Thu, 6 Aug 2015 02:04:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id twgLXDKU5Onf; Thu, 6 Aug 2015 02:04:39 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6CD41B2A62; Thu, 6 Aug 2015 02:04:38 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BZO37041; Thu, 06 Aug 2015 09:04:30 +0000 (GMT) Received: from LHREML504-MBS.china.huawei.com ([10.125.30.107]) by lhreml406-hub.china.huawei.com ([10.201.5.243]) with mapi id 14.03.0235.001; Thu, 6 Aug 2015 10:04:24 +0100 From: Hosnieh Rafiee To: Paul Wouters , Jiankang Yao Thread-Topic: [dane] [openpgp] The DANE draft Thread-Index: AQHQz1cAG6iEyei+P0uLgSQSGhtjSZ39ND4AgAA+fgCAAAazAIABGZUAgAAVT5P///M3AIAAEfCg Date: Thu, 6 Aug 2015 09:04:23 +0000 Message-ID: <814D0BFB77D95844A01CA29B44CBF8A7015D666D@lhreml504-mbs> References: <87bnf1hair.fsf@alice.fifthhorseman.net> <87bnem2xjq.fsf@alice.fifthhorseman.net> <55C1F35A.5070904@cs.tcd.ie> <55C22D64.9080507@strotmann.de>, <20150806163914546863148@cnnic.cn> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.221.82.162] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: IETF OpenPGP , dane Subject: Re: [dane] [openpgp] The DANE draft X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2015 09:04:41 -0000 Paul, > I really do believe that the hashing is not an affective security > meassure. >=20 By using hash, we make it harder for an attacker to find email addresses of= another person. Of course, we cannot prevent the attack.=20 Let me give you a real example from a real person that I name him Bob. Bob = hasn't published any email address on his personal website but he used a fo= rm so that others can send me email only via form. The spammer also tried to send hiim message via this form in a hope that th= ey can receive an answer so that they can have his email address. But Bob a= lso used other approaches such as captcha.=20 After that, he no longer received any spamming email because it was too eff= orts for spammer to check the captcha and take more of their time.=20 I hope it is clear, Hosnieh From nobody Thu Aug 6 02:30: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 2D8BB1B2B31; Thu, 6 Aug 2015 02:30:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 81tcgOmxKtdr; Thu, 6 Aug 2015 02:30:19 -0700 (PDT) Received: from mail.mugenguild.com (mugenguild.com [5.135.189.5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 481791B2B16; Thu, 6 Aug 2015 02:30:18 -0700 (PDT) Received: from localhost (p5798E4D9.dip0.t-ipconnect.de [87.152.228.217]) by mail.mugenguild.com (Postfix) with ESMTPSA id 5261C5FCD5; Thu, 6 Aug 2015 11:26:14 +0200 (CEST) References: <87bnf1hair.fsf@alice.fifthhorseman.net> <87bnem2xjq.fsf@alice.fifthhorseman.net> <55C1F35A.5070904@cs.tcd.ie> <55C22D64.9080507@strotmann.de> From: Vincent Breitmoser To: Paul Wouters In-reply-to: Date: Thu, 06 Aug 2015 11:30:12 +0200 Message-ID: <87egjg7oij.fsf@littlepip.fritz.box> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: IETF OpenPGP , dane WG list Subject: Re: [dane] [openpgp] The DANE draft X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2015 09:30:21 -0000 On 6 Aug 2015, Paul Wouters wrote: > I might agree but I think the gain for this is so incredibly small, The same could be said about NSEC vs NSEC3 for a motivated attacker, and still NSEC received strong opposition. - V From nobody Thu Aug 6 02:58:32 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2D4C1B2BC7; Thu, 6 Aug 2015 02:58:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.711 X-Spam-Level: X-Spam-Status: No, score=-3.711 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_46=0.6, 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 i-2whNdJI4kS; Thu, 6 Aug 2015 02:58:26 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92F711B2BC8; Thu, 6 Aug 2015 02:58:26 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id C5449BE7D; Thu, 6 Aug 2015 10:58:24 +0100 (IST) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nZyuWe_zd5oB; Thu, 6 Aug 2015 10:58:24 +0100 (IST) Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id D5998BE4C; Thu, 6 Aug 2015 10:58:18 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1438855104; bh=CWhb7SlnpWA6USU/hLRHp5ZXCjXCHy41KJmSW15tcS8=; h=Date:From:To:CC:Subject:References:In-Reply-To:From; b=mwH09MlLhx1akvP89sCE/7hTObqNsopZkgo1fQXW1yo0ve31upPqpEB+NEZGrjQ2o ssNVWn9Tq7Cnc4l02oL9VJOh6vh7QVBF7YHtrdhzxHCxZjOG8tDXhOOZVRUUXGjjYZ KslIxyQnWK6KSvxMfbjGpTMsmn7iNhAwyXH5Xx0E= Message-ID: <55C32FBA.8080604@cs.tcd.ie> Date: Thu, 06 Aug 2015 10:58:18 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.8.0 MIME-Version: 1.0 To: Paul Wouters , dane WG list References: <87bnf1hair.fsf@alice.fifthhorseman.net> <87bnem2xjq.fsf@alice.fifthhorseman.net> <55C1F35A.5070904@cs.tcd.ie> <55C22D64.9080507@strotmann.de> In-Reply-To: OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: IETF OpenPGP Subject: Re: [dane] [openpgp] The DANE draft X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2015 09:58:30 -0000 Paul, On 06/08/15 09:23, Paul Wouters wrote: > On Wed, 5 Aug 2015, Carsten Strotmann wrote: > >> for OPENPGPKEY/SMIMECERT zones, operators could (maybe SHOULD) use >> NSEC/NSEC3 "narrow" signing to prevent "zone-walking". > > email addresses are not secret. That is not the privacy you can protect > at all. Anyone can either do a internet search or just attempt to > deliver an email to figure out if the email address is valid. That doesn't address my issue with this as a precedent. Nor the case of negative DNS responses trivially leaking that someone at my IP address wants to send a mail to at this time. (And yes, the trivially is a required part of the argument.) And "are not secret" isn't, I think, the right comparison. For me, the question is "if we want to experiment with user identifiers in DNS names, can we do it in the least privacy unfriendly, but yet practical, way as possible?" Yes, some people may oversell the benefits of hashing or may believe hashing is stronger than it is. Such mistaken beliefs however do not make hashing worse than b32. Hashing is still a bit better. > I might agree but I think the gain for this is so incredibly small, that > I think the gain for use of online signers plus email address > corrections by the smtp+dnssec combined server is actually a more likely > and minorly useful thing to have. Can you point me at a DNS server (or real specification for one) that generates responses in any similar fashion? I'm not aware of any that actually do, (even if they could do), but that my just be my ignorance. IMO even if there is a niche of DNS authoritative servers that can operate in that manner, requiring that that niche be used for the experiment makes it highly likely the experiment will fail. So my logic would be: if b32 is needed, the experiment will likely fail as you can't do it on many servers. If b32 is not needed, then let's just hash since that is less bad. > And don't get me wrong. I'd rather see zonefiles with a hash than with > base32 cut from an esthetical point of view. Well, let's do that then:-) S. > > Paul > > _______________________________________________ > openpgp mailing list > openpgp@ietf.org > https://www.ietf.org/mailman/listinfo/openpgp > From nobody Thu Aug 6 03:04:31 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA5911B2BEB for ; Thu, 6 Aug 2015 03:04:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.96 X-Spam-Level: X-Spam-Status: No, score=-0.96 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, J_CHICKENPOX_46=0.6, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U73azMZPi1KO for ; Thu, 6 Aug 2015 03:04:28 -0700 (PDT) Received: from smtp3.strotmann.de (smtp3.strotmann.de [46.38.233.133]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 237551B2BEE for ; Thu, 6 Aug 2015 03:04:28 -0700 (PDT) Received: from debian01.home.strotmann.de (unknown [IPv6:2a01:198:2b6:1000:240:caff:fea0:83b3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp3.strotmann.de (Postfix) with ESMTPS id B721C7FD05 for ; Thu, 6 Aug 2015 12:04:01 +0200 (CEST) Received: from MacMini3-2.local (unknown [IPv6:2a01:198:2b6:0:e07b:1eb3:387a:f24]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by debian01.home.strotmann.de (Postfix) with ESMTPSA id E6DD920005C for ; Thu, 6 Aug 2015 12:03:59 +0200 (CEST) To: dane@ietf.org References: <87bnf1hair.fsf@alice.fifthhorseman.net> <87bnem2xjq.fsf@alice.fifthhorseman.net> <55C1F35A.5070904@cs.tcd.ie> <55C22D64.9080507@strotmann.de> <55C32FBA.8080604@cs.tcd.ie> From: Carsten Strotmann Message-ID: <55C3310C.9050601@strotmann.de> Date: Thu, 6 Aug 2015 12:03:56 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: <55C32FBA.8080604@cs.tcd.ie> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [dane] [openpgp] The DANE draft X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2015 10:04:29 -0000 Hi Stephen, On 06/08/15 11:58 PM, Stephen Farrell wrote: >> > I might agree but I think the gain for this is so incredibly small, that >> > I think the gain for use of online signers plus email address >> > corrections by the smtp+dnssec combined server is actually a more likely >> > and minorly useful thing to have. > Can you point me at a DNS server (or real specification for one) > that generates responses in any similar fashion? I'm not aware of > any that actually do, (even if they could do), but that my just be > my ignorance. PowerDNS with a remote backend could do this, but it would require some glue code to be written by the admin to be able to talk to the smtp-server. I can evision such an installation for a few large mail providers, but not for the majority of mail server installations. Carsten From nobody Thu Aug 6 03:43:45 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D9DA1B2C51; Thu, 6 Aug 2015 03:43:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U52vGmA_TY2Y; Thu, 6 Aug 2015 03:43:43 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF2861B2C6E; Thu, 6 Aug 2015 03:43:38 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3mn5yc1SSRz3Nm; Thu, 6 Aug 2015 12:43:36 +0200 (CEST) Authentication-Results: mx.nohats.ca; dkim=pass (1024-bit key) header.d=nohats.ca header.i=@nohats.ca header.b=VWpcEazm X-OPENPGPKEY: Message passed unmodified X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id SeO7lRpMH3aQ; Thu, 6 Aug 2015 12:43:34 +0200 (CEST) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Thu, 6 Aug 2015 12:43:34 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id CFBDC80042; Thu, 6 Aug 2015 06:43:32 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1438857812; bh=mMNeIkMKtZqwJnAqKCRQPiaFUKiBDHZN2JGsoRmRQGs=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=VWpcEazmU4VJPfrH+ln5nLF/OclbYmp0sL36iblYfJ5gyWg5aKeTUB2+O8krg/wxJ tHlhBGhKh6hZ6F9xSi3Chb3JMwwog8Y8vcWArmcxjyO4Op3rkoezWPBqzgKBb40J1C en3nfu5vHHTOz6ZfEWtTIJQxuiW6+oJgyVSufgm8= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.15.1/8.15.1/Submit) with ESMTP id t76AhVOM017440; Thu, 6 Aug 2015 06:43:32 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Thu, 6 Aug 2015 06:43:31 -0400 (EDT) From: Paul Wouters To: Vincent Breitmoser In-Reply-To: <87egjg7oij.fsf@littlepip.fritz.box> Message-ID: References: <87bnf1hair.fsf@alice.fifthhorseman.net> <87bnem2xjq.fsf@alice.fifthhorseman.net> <55C1F35A.5070904@cs.tcd.ie> <55C22D64.9080507@strotmann.de> <87egjg7oij.fsf@littlepip.fritz.box> User-Agent: Alpine 2.11 (LFD 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: IETF OpenPGP , dane WG list Subject: Re: [dane] [openpgp] The DANE draft X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2015 10:43:45 -0000 On Thu, 6 Aug 2015, Vincent Breitmoser wrote: >> I might agree but I think the gain for this is so incredibly small, > > The same could be said about NSEC vs NSEC3 for a motivated attacker, and > still NSEC received strong opposition. Actually, most users of NSEC3 care more about the OPT-OUT feature than the hashing feature. And there is no OPT-OUT with NSEC. Paul From nobody Thu Aug 6 04:29:47 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91DE61B2D68 for ; Thu, 6 Aug 2015 04:29:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.711 X-Spam-Level: X-Spam-Status: No, score=-5.711 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_I_LETTER=-2, J_CHICKENPOX_46=0.6, 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 pcleRrLReTfF for ; Thu, 6 Aug 2015 04:29:40 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DEB5B1B2D5C for ; Thu, 6 Aug 2015 04:29:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 062C6BDD8; Thu, 6 Aug 2015 12:29:38 +0100 (IST) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3xDpnn_S45Ce; Thu, 6 Aug 2015 12:29:37 +0100 (IST) Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id BC774BE7D; Thu, 6 Aug 2015 12:29:37 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1438860577; bh=8Czp2CTkRk9JJkI8Z+ioeNNKNg+9xMv/a9A1RmEkwS8=; h=Date:From:To:Subject:References:In-Reply-To:From; b=SozYo8DzrT535fKcd4JisW5l7ll3tf9oJjKOU1wC0n5v/g1MTI6ENgobNNXV6031O waHhZVI28+rReb0KWdGHug130cS6FJFH6642PE1biJ0lwc6E7XqhOdhYPz6He5JNKd iwGTvzLpUqvJK5Xi5x3dZSFG4JhvwplXKUeUx6NY= Message-ID: <55C34521.60205@cs.tcd.ie> Date: Thu, 06 Aug 2015 12:29:37 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.8.0 MIME-Version: 1.0 To: Carsten Strotmann , dane@ietf.org References: <87bnf1hair.fsf@alice.fifthhorseman.net> <87bnem2xjq.fsf@alice.fifthhorseman.net> <55C1F35A.5070904@cs.tcd.ie> <55C22D64.9080507@strotmann.de> <55C32FBA.8080604@cs.tcd.ie> <55C3310C.9050601@strotmann.de> In-Reply-To: <55C3310C.9050601@strotmann.de> OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dane] [openpgp] The DANE draft X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2015 11:29:45 -0000 On 06/08/15 11:03, Carsten Strotmann wrote: > Hi Stephen, > > On 06/08/15 11:58 PM, Stephen Farrell wrote: >>>> I might agree but I think the gain for this is so incredibly small, that >>>> I think the gain for use of online signers plus email address >>>> corrections by the smtp+dnssec combined server is actually a more likely >>>> and minorly useful thing to have. >> Can you point me at a DNS server (or real specification for one) >> that generates responses in any similar fashion? I'm not aware of >> any that actually do, (even if they could do), but that my just be >> my ignorance. > > PowerDNS with a remote backend could do this, but it would require some > glue code to be written by the admin to be able to talk to the smtp-server. > > I can evision such an installation for a few large mail providers, but > not for the majority of mail server installations. Thanks. So that implies that b32 can only in practice offer advantage to the large mail providers who want to do PGP like this and fuzzy stuff with "AccountName+JustMadeUp@domain" type addresses. (For other kinds of fuzziness, e.g. upper/lower case initial letters, I think anyone can prepare a few hashes in advance and do almost as well.) I think what you say above also implies that b32 will offer no benefit to the long tail as they'll have zonefiles or the moral equivalent. Seems to me like more reason to not do b32. I would guess that the large mail providers won't do this since we've not heard from them that they would, and in fact we're heard 2nd hand that the won't (iirc, I'm open to correction) and those large mail providers tend to not be shy about saying what it is they would like when they're interested in something;-) Cheers, S. > > Carsten > > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane > > From nobody Thu Aug 6 08:47: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 702221B3A88 for ; Thu, 6 Aug 2015 08:47:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sIECbEnfph2B for ; Thu, 6 Aug 2015 08:47:44 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A5E71B3AA7 for ; Thu, 6 Aug 2015 08:47:26 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id F3FE5284D85; Thu, 6 Aug 2015 15:47:24 +0000 (UTC) Date: Thu, 6 Aug 2015 15:47:24 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20150806154724.GG9139@mournblade.imrryr.org> References: <87bnf1hair.fsf@alice.fifthhorseman.net> <87bnem2xjq.fsf@alice.fifthhorseman.net> <55C1F35A.5070904@cs.tcd.ie> <55C22D64.9080507@strotmann.de> <20150806163914546863148@cnnic.cn> 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] [openpgp] The DANE draft 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, 06 Aug 2015 15:47:45 -0000 On Thu, Aug 06, 2015 at 04:54:24AM -0400, Paul Wouters wrote: > I really do believe that the hashing is not an affective security > meassure. Agreed. Wishful thinking does not make it true. Just because we'd like to sprinkle crypto pixie dust to make magic happen, does not mean it will happen. Hashes may sound more secure, but they're not really more secure, no matter how much we'd like them to be. -- Viktor. From nobody Thu Aug 6 09:01: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 2D0F11B3096 for ; Thu, 6 Aug 2015 09:01:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lL6l3P9wni9O for ; Thu, 6 Aug 2015 09:01:39 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1A001B3095 for ; Thu, 6 Aug 2015 09:01:38 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BZO81378; Thu, 06 Aug 2015 16:01:37 +0000 (GMT) Received: from LHREML504-MBS.china.huawei.com ([10.125.30.107]) by lhreml402-hub.china.huawei.com ([10.201.5.241]) with mapi id 14.03.0235.001; Thu, 6 Aug 2015 17:01:32 +0100 From: Hosnieh Rafiee To: "dane@ietf.org" Thread-Topic: [dane] [openpgp] The DANE draft Thread-Index: AQHQz1cAG6iEyei+P0uLgSQSGhtjSZ39ND4AgAA+fgCAAAazAIABGZUAgAAVT5P///M3AIAAc2QAgAATJGA= Date: Thu, 6 Aug 2015 16:01:31 +0000 Message-ID: <814D0BFB77D95844A01CA29B44CBF8A7015D69D2@lhreml504-mbs> References: <87bnf1hair.fsf@alice.fifthhorseman.net> <87bnem2xjq.fsf@alice.fifthhorseman.net> <55C1F35A.5070904@cs.tcd.ie> <55C22D64.9080507@strotmann.de> <20150806163914546863148@cnnic.cn> <20150806154724.GG9139@mournblade.imrryr.org> In-Reply-To: <20150806154724.GG9139@mournblade.imrryr.org> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.221.97.232] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [dane] [openpgp] The DANE draft X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2015 16:01:43 -0000 Viktor, > -----Original Message----- > From: dane [mailto:dane-bounces@ietf.org] On Behalf Of Viktor Dukhovni > Sent: Thursday, August 06, 2015 5:47 PM > To: dane@ietf.org > Subject: Re: [dane] [openpgp] The DANE draft >=20 > On Thu, Aug 06, 2015 at 04:54:24AM -0400, Paul Wouters wrote: >=20 > > I really do believe that the hashing is not an affective security > > meassure. >=20 > Agreed. Wishful thinking does not make it true. Just because we'd > like to sprinkle crypto pixie dust to make magic happen, does not mean > it will happen. >=20 > Hashes may sound more secure, but they're not really more secure, no > matter how much we'd like them to be. Of course, no one expects to see a miracle from a hash function. But again = this is only making it a bit harder, even you say 1% but this is quite diff= erent than a plain text. Best, Hosnieh From nobody Thu Aug 6 10:04:55 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EE091B3BD8 for ; Thu, 6 Aug 2015 10:04:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.578 X-Spam-Level: X-Spam-Status: No, score=-0.578 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 42mwWd3qnwsQ for ; Thu, 6 Aug 2015 10:04:52 -0700 (PDT) Received: from mail-ob0-f181.google.com (mail-ob0-f181.google.com [209.85.214.181]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21B121B3C1E for ; Thu, 6 Aug 2015 10:04:37 -0700 (PDT) Received: by obnw1 with SMTP id w1so60363378obn.3 for ; Thu, 06 Aug 2015 10:04:36 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=F4VDY1b96+m+xa5uhM4tBn5b9WTkDtEk5AGMt47P9rk=; b=fcxX7dhWpwCjc2ahBX+hacm4kdzS+x5FM/4akX+dhgzSUbj57rt1Qs1h7rpfCagvur K0TxuPk2NmIHRn1SA8/Sj/pWMT8APOjUPdmuVft/RdZm6/1rq01qVXPQxc5SkS+1wbbX NOZFWmfV6IHkPfKbM1qDD3g1kWtuIYceE7m/xz6tzHkMcCSUm+QGExXhyU7GfHvkSmIf 48ffa9yoy0Mocojg5DDiLErsYjoRTOF33nnVrSB1u9niFQqSYcaNi636Fznde3ofQR65 isjvfn4WLBqlRwOFwsd8jl/XsVIan1ARGEQnjMwmGhK+sAgcshdmLRe9NMvqPVyq2ihj 7ndw== X-Gm-Message-State: ALoCoQlXrXbDN6tEliysicxSjMaiIOyux1Hcu2yCJDoUXzThU+9Wlg23S5nERZ9wPFeDJO0PDFFd MIME-Version: 1.0 X-Received: by 10.182.225.169 with SMTP id rl9mr2613915obc.54.1438880676359; Thu, 06 Aug 2015 10:04:36 -0700 (PDT) Received: by 10.202.232.1 with HTTP; Thu, 6 Aug 2015 10:04:36 -0700 (PDT) Date: Thu, 6 Aug 2015 13:04:36 -0400 Message-ID: From: Warren Kumari To: "" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [dane] Consensus on the Hash vs Base32 discussion. X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 06 Aug 2015 17:04:53 -0000 Consensus has been hard to judge here, and seems to have evolved over time, which is a sign that people have been looking at things from different perspectives. The chairs judge that the privacy arguments for the hashing solution tip the scales in it's favor, so we are instructing the authors to keep the hashing text without doing any case folding. These documents are experimental, largely because of the email address encoding. It is entirely possible that deployment experiment this will show that better choices exist - but, at least we have made a choice. We would like to thank the Working Group and the authors in particular for their patience and involvement in this (long) discussion. W -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf From nobody Thu Aug 6 10:07: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 41CAB1B3C48 for ; Thu, 6 Aug 2015 10:07:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UC64ChVF1RFB for ; Thu, 6 Aug 2015 10:07:24 -0700 (PDT) Received: from mail-ob0-f169.google.com (mail-ob0-f169.google.com [209.85.214.169]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96A461B3C43 for ; Thu, 6 Aug 2015 10:07:24 -0700 (PDT) Received: by obbop1 with SMTP id op1so60644493obb.2 for ; Thu, 06 Aug 2015 10:07:24 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=weHIQBlcjA34ZfpGdWyTWLpIh+A4QkQpjCCPdrseWcU=; b=Ku6msGR96flBOfukgJTqLXymjab1gRir07AkcYCWEygkMXRJhhjNQX9bkC2gzFIv6Y jhhQEIxaQGu1CRe5Gi3oFT4Kfvo7UdPRo9EQRXe53Aqdx7hSfxss4Y+TWenvV7Xbc4FF uRZJoCbdeLwBmtZKg38xVqqPjD5ABAzpBIKhf5RzWzXNHuUw1AU7lIEfkD8fC5z08XU8 v3La2B7NFNLvNYgzk8M75hODbFOIggb8nP4o9xi/1u/lcnGYSx/vClxXbFJ8Dh6DQqov dIQa4vX9tar1+CxwI218C1MmjOVv0CzUJqJTWYgVQY7zPxUj6e0vCFQZVWw9SbG4dfTl VPpw== X-Gm-Message-State: ALoCoQmrqQqKPkchJCB5vQcoG4Lyb8Ywm6sexbY9Ne8MUNDAitklREyCPrp0GClCNDfsW78W930H MIME-Version: 1.0 X-Received: by 10.60.76.35 with SMTP id h3mr2657858oew.46.1438880843993; Thu, 06 Aug 2015 10:07:23 -0700 (PDT) Received: by 10.202.232.1 with HTTP; Thu, 6 Aug 2015 10:07:23 -0700 (PDT) In-Reply-To: <814D0BFB77D95844A01CA29B44CBF8A7015D69D2@lhreml504-mbs> References: <87bnf1hair.fsf@alice.fifthhorseman.net> <87bnem2xjq.fsf@alice.fifthhorseman.net> <55C1F35A.5070904@cs.tcd.ie> <55C22D64.9080507@strotmann.de> <20150806163914546863148@cnnic.cn> <20150806154724.GG9139@mournblade.imrryr.org> <814D0BFB77D95844A01CA29B44CBF8A7015D69D2@lhreml504-mbs> Date: Thu, 6 Aug 2015 13:07:23 -0400 Message-ID: From: Warren Kumari To: Hosnieh Rafiee Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "dane@ietf.org" Subject: Re: [dane] [openpgp] The DANE draft X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2015 17:07:26 -0000 ... and we have just called consensus on this topic - see the email with the subject "Consensus on the Hash vs Base32 discussion." This has been a long and involved discussion, and we thank everyone for hanging in there. W On Thu, Aug 6, 2015 at 12:01 PM, Hosnieh Rafiee wrote: > Viktor, > >> -----Original Message----- >> From: dane [mailto:dane-bounces@ietf.org] On Behalf Of Viktor Dukhovni >> Sent: Thursday, August 06, 2015 5:47 PM >> To: dane@ietf.org >> Subject: Re: [dane] [openpgp] The DANE draft >> >> On Thu, Aug 06, 2015 at 04:54:24AM -0400, Paul Wouters wrote: >> >> > I really do believe that the hashing is not an affective security >> > meassure. >> >> Agreed. Wishful thinking does not make it true. Just because we'd >> like to sprinkle crypto pixie dust to make magic happen, does not mean >> it will happen. >> >> Hashes may sound more secure, but they're not really more secure, no >> matter how much we'd like them to be. > > Of course, no one expects to see a miracle from a hash function. But again this is only making it a bit harder, even you say 1% but this is quite different than a plain text. > > Best, > Hosnieh > > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf From nobody Thu Aug 6 13:19:19 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F41E71A87F1; Thu, 6 Aug 2015 13:19:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rKMS75SipXDB; Thu, 6 Aug 2015 13:19:15 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 833EB1A1B66; Thu, 6 Aug 2015 13:19:15 -0700 (PDT) Received: from fifthhorseman.net (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id 1F3E7F984; Thu, 6 Aug 2015 16:19:12 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id C4B461FF70; Thu, 6 Aug 2015 22:19:12 +0200 (CEST) From: Daniel Kahn Gillmor To: Hosnieh Rafiee , Paul Wouters , Jiankang Yao In-Reply-To: <814D0BFB77D95844A01CA29B44CBF8A7015D666D@lhreml504-mbs> References: <87bnf1hair.fsf@alice.fifthhorseman.net> <87bnem2xjq.fsf@alice.fifthhorseman.net> <55C1F35A.5070904@cs.tcd.ie> <55C22D64.9080507@strotmann.de> <20150806163914546863148@cnnic.cn> <814D0BFB77D95844A01CA29B44CBF8A7015D666D@lhreml504-mbs> User-Agent: Notmuch/0.20.2 (http://notmuchmail.org) Emacs/24.5.1 (x86_64-pc-linux-gnu) Date: Thu, 06 Aug 2015 16:19:12 -0400 Message-ID: <877fp8w4ov.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: IETF OpenPGP , dane Subject: Re: [dane] [openpgp] The DANE draft X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2015 20:19:17 -0000 On Thu 2015-08-06 05:04:23 -0400, Hosnieh Rafiee wrote: > Let me give you a real example from a real person that I name him > Bob. Bob hasn't published any email address on his personal website > but he used a form so that others can send me email only via form. > The spammer also tried to send hiim message via this form in a hope > that they can receive an answer so that they can have his email > address. But Bob also used other approaches such as captcha. > > After that, he no longer received any spamming email because it was > too efforts for spammer to check the captcha and take more of their > time. He will also receive no mail from me, because i prefer to mail from my own mail user agent, and not from webforms with a captcha, which have their own set of privacy concerns in common implementations, not to mention UI/UX issues. :P Plus, how does Bob reply to any of his mail? Does his reply use an e-mail address? What stops one recipient from publishing his e-mail address? But this all seems like quite a digression: how is this an argument about which form to use for publication of the OPENPGPKEY record? --dkg From nobody Sat Aug 8 21:43:33 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC87C1ACCF3; Sat, 8 Aug 2015 21:43:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5AgKOk4NE4O7; Sat, 8 Aug 2015 21:43:30 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B7F41ACD11; Sat, 8 Aug 2015 21:43:26 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.4.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150809044326.27289.64991.idtracker@ietfa.amsl.com> Date: Sat, 08 Aug 2015 21:43:26 -0700 Archived-At: Cc: dane@ietf.org Subject: [dane] I-D Action: draft-ietf-dane-ops-15.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Aug 2015 04:43:31 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS-based Authentication of Named Entities Working Group of the IETF. Title : Updates to and Operational Guidance for the DANE Protocol Authors : Viktor Dukhovni Wes Hardaker Filename : draft-ietf-dane-ops-15.txt Pages : 32 Date : 2015-08-08 Abstract: This document clarifies and updates the DNS-Based Authentication of Named Entities (DANE) TLSA specification (RFC6698) based on subsequent implementation experience. It also contains guidance for implementers, operators and protocol developers who want to make use of DANE records. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dane-ops/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-dane-ops-15 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dane-ops-15 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sat Aug 8 21:52: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 613FB1ACD16; Sat, 8 Aug 2015 21:52:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8nux5ZmC_nRd; Sat, 8 Aug 2015 21:52:34 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A7DE01ACD23; Sat, 8 Aug 2015 21:52:32 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.4.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150809045232.3706.76271.idtracker@ietfa.amsl.com> Date: Sat, 08 Aug 2015 21:52:32 -0700 Archived-At: Cc: dane@ietf.org Subject: [dane] I-D Action: draft-ietf-dane-ops-16.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Aug 2015 04:52:35 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS-based Authentication of Named Entities Working Group of the IETF. Title : Updates to and Operational Guidance for the DANE Protocol Authors : Viktor Dukhovni Wes Hardaker Filename : draft-ietf-dane-ops-16.txt Pages : 32 Date : 2015-08-08 Abstract: This document clarifies and updates the DNS-Based Authentication of Named Entities (DANE) TLSA specification (RFC6698) based on subsequent implementation experience. It also contains guidance for implementers, operators and protocol developers who want to make use of DANE records. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dane-ops/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-dane-ops-16 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dane-ops-16 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sat Aug 8 21:56:19 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E979D1AC40F; Sat, 8 Aug 2015 21:56:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mHknnRi5nJMc; Sat, 8 Aug 2015 21:56:13 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7349C1AC3FF; Sat, 8 Aug 2015 21:56:13 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 52E4E282FAF; Sun, 9 Aug 2015 04:56:12 +0000 (UTC) Date: Sun, 9 Aug 2015 04:56:12 +0000 From: Viktor Dukhovni To: iesg@ietf.org Message-ID: <20150809045612.GD9139@mournblade.imrryr.org> References: <55C3A143.4080607@cs.tcd.ie> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <55C3A143.4080607@cs.tcd.ie> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: Wes Hardaker , dane@ietf.org Subject: Re: [dane] Mail regarding draft-ietf-dane-ops X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 09 Aug 2015 04:56:15 -0000 On Thu, Aug 06, 2015 at 07:02:43PM +0100, Stephen Farrell wrote: > I think you've already handled all the comments received > in IESG evaluation in your local copy, is that correct? > > If so, please submit that and I'll give it a quick check (on > Monday, sorrry) and then send a mail to get it sent forward > to the RFC editor. In addition to the changes based on the IESG review comments, I went over the whole thing, and added some more rationale text (as requested in Fred Baker's review). Also some final editorial polish of my own. Please let me know if I changed too much..., I can pare it back closer to -14 if I went too far. It took two revisions to get the indentation of the quote from RFC5246 to work right (sorry about that). So, to review the changes, see: https://www.ietf.org/rfcdiff?url1=draft-ietf-dane-ops-14&url2=draft-ietf-dane-ops-16 -- Viktor. From nobody Sun Aug 9 21:58:56 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14B901A8956 for ; Sun, 9 Aug 2015 21:58:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bEUH22mNhnPm for ; Sun, 9 Aug 2015 21:58:53 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 612601A8966 for ; Sun, 9 Aug 2015 21:58:53 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx.pao1.isc.org (Postfix) with ESMTPS id 0CABB34930F; Mon, 10 Aug 2015 04:58:51 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 8D38C16004F; Mon, 10 Aug 2015 04:59:58 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 49A85160085; Mon, 10 Aug 2015 04:59:58 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id bdqWz2tQZrnN; Mon, 10 Aug 2015 04:59:58 +0000 (UTC) Received: from rock.dv.isc.org (c122-106-161-187.carlnfd1.nsw.optusnet.com.au [122.106.161.187]) by zmx1.isc.org (Postfix) with ESMTPSA id DD4FF16004F; Mon, 10 Aug 2015 04:59:57 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 47A253456A6C; Mon, 10 Aug 2015 14:58:47 +1000 (EST) To: Hosnieh Rafiee From: Mark Andrews References: <1437580854.052529954@apps.rackspace.com> <814D0BFB77D95844A01CA29B44CBF8A7015D2DF4@lhreml504-mbs> In-reply-to: Your message of "Fri, 31 Jul 2015 14:31:22 +0000." <814D0BFB77D95844A01CA29B44CBF8A7015D2DF4@lhreml504-mbs> Date: Mon, 10 Aug 2015 14:58:47 +1000 Message-Id: <20150810045847.47A253456A6C@rock.dv.isc.org> Archived-At: Cc: "dane@ietf.org" Subject: Re: [dane] followup: OPENPGP --- Review draft: draft-ietf-dane-openpgpkey-03 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2015 04:58:55 -0000 In message <814D0BFB77D95844A01CA29B44CBF8A7015D2DF4@lhreml504-mbs>, Hosnieh Rafiee writes: > Followup > However, a few DNS servers support 0x20-Bit Encoding, but this > approach is not supported by base32 which has its own security risk. Hogwash. With base32 is perfectly capable of working with 0x20. You just have to appropriately map alphas when decoding which is inherent when you send base32 through the DNS. > Unless.. we get back to the technique for DNScurve to be able to differentiate lowercase > and uppercase characters in > > > < http://courses.isi.jhu.edu/netsec/papers/increased_dns_resistance.pdf> > > Thanks, > Best, > Hosnieh > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Mon Aug 10 09:00:10 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2D151B37AD for ; Mon, 10 Aug 2015 09:00:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UuZPV62pSP99 for ; Mon, 10 Aug 2015 09:00:07 -0700 (PDT) Received: from mail-oi0-f47.google.com (mail-oi0-f47.google.com [209.85.218.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70FB01B3775 for ; Mon, 10 Aug 2015 08:59:32 -0700 (PDT) Received: by oiev193 with SMTP id v193so59413040oie.3 for ; Mon, 10 Aug 2015 08:59:31 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=HBhJjsIm2YvWVtBkjAYSrS3BUCkrWWwieuyX864a0JE=; b=IpM9i+8FP6YWnDgIepLJl6zUSBw3fjEVp8BLXijLi9Uu6KS1QGlZRLsPrKOjNYBOm3 vE4lj7tRaCOiQ0oRfqPHMtuNmVOYWTW+IVkmy15QevZKQ1AwBetkgDgHKxk0nxFbUM/i mlzd725u1ROPSLFauXhlyp0lMATP8c2JzPmUp2zS9IeiOeg0uGM0E02zBcJ3ExQurMvQ bsP42EQrWezPYlclCDiULEpQ5wPm0m+9dTYPGoFpl6AsFNDsxs8IHp13U98SsdRTKIep sZkXFUW6IZuLzRac36bWn1Up/OZDxcnJWq5fC49b/s36pchDtKpqBeN1UwL1aWph0YXp myUg== X-Gm-Message-State: ALoCoQljNJEPAoASlMmUepO+/R4jvDU1Vmp9+l6cDd/VizMq/R1+Ra3DiKAH5mecGH8yfmsfwyEQ MIME-Version: 1.0 X-Received: by 10.202.108.142 with SMTP id h136mr19334138oic.86.1439222371740; Mon, 10 Aug 2015 08:59:31 -0700 (PDT) Received: by 10.202.232.1 with HTTP; Mon, 10 Aug 2015 08:59:31 -0700 (PDT) In-Reply-To: <20150809045612.GD9139@mournblade.imrryr.org> References: <55C3A143.4080607@cs.tcd.ie> <20150809045612.GD9139@mournblade.imrryr.org> Date: Mon, 10 Aug 2015 11:59:31 -0400 Message-ID: From: Warren Kumari To: Viktor Dukhovni Content-Type: multipart/alternative; boundary=001a1142da9c388811051cf71295 Archived-At: Cc: Wes Hardaker , "iesg@ietf.org" , "dane@ietf.org" Subject: Re: [dane] Mail regarding draft-ietf-dane-ops X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 10 Aug 2015 16:00:09 -0000 --001a1142da9c388811051cf71295 Content-Type: text/plain; charset=UTF-8 On Sunday, August 9, 2015, Viktor Dukhovni wrote: > On Thu, Aug 06, 2015 at 07:02:43PM +0100, Stephen Farrell wrote: > > > I think you've already handled all the comments received > > in IESG evaluation in your local copy, is that correct? > > > > If so, please submit that and I'll give it a quick check (on > > Monday, sorrry) and then send a mail to get it sent forward > > to the RFC editor. > > In addition to the changes based on the IESG review comments, I > went over the whole thing, and added some more rationale text (as > requested in Fred Baker's review). Also some final editorial polish > of my own. > > Please let me know if I changed too much..., I can pare it back > closer to -14 if I went too far. > > It took two revisions to get the indentation of the quote from > RFC5246 to work right (sorry about that). So, to review the changes, > see: > > > https://www.ietf.org/rfcdiff?url1=draft-ietf-dane-ops-14&url2=draft-ietf-dane-ops-16 > > Yup, there is a lot of changes, but they all seem to be clear, reasonable and useful. They were also based upon IESG review, and so I think this is all fine. Thank you *very* much for all your work on this. W > -- > Viktor. > > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane > -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf --001a1142da9c388811051cf71295 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Sunday, August 9, 2015, Viktor Dukhovni <ietf-dane@dukhovni.org> wrote:
On Thu, Aug 06, 2015 at 07:02:43PM +0100, Stephen Farrel= l wrote:

> I think you've already handled all the comments received
> in IESG evaluation in your local copy, is that correct?
>
> If so, please submit that and I'll give it a quick check (on
> Monday, sorrry) and then send a mail to get it sent forward
> to the RFC=C2=A0 editor.

In addition to the changes based on the IESG review comments, I
went over the whole thing, and added some more rationale text (as
requested in Fred Baker's review).=C2=A0 Also some final editorial poli= sh
of my own.

Please let me know if I changed too much..., I can pare it back
closer to -14 if I went too far.

It took two revisions to get the indentation of the quote from
RFC5246 to work right (sorry about that).=C2=A0 So, to review the changes,<= br> see:

=C2=A0 =C2=A0 https://www.i= etf.org/rfcdiff?url1=3Ddraft-ietf-dane-ops-14&url2=3Ddraft-ietf-dane-op= s-16


Yup, there is a lot of changes, but th= ey all seem to be clear, reasonable and useful. They were also based upon I= ESG review, and so I think this is all fine.

Thank= you *very* much for all your work on this.
W
<= div>
=C2=A0
--
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Viktor.

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


--
I don't think the execution is relevant whe= n it was obviously a bad idea in the first place.
This is like putting r= abid weasels in your pants, and later expressing regret at having chosen th= ose particular rabid weasels and that pair of pants.
=C2=A0 =C2=A0---maf=
--001a1142da9c388811051cf71295-- From nobody Mon Aug 10 10:40:35 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C97A1A8977 for ; Mon, 10 Aug 2015 10:40:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dFYoQ-CaEP9R for ; Mon, 10 Aug 2015 10:40:31 -0700 (PDT) Received: from smtp68.iad3a.emailsrvr.com (smtp68.iad3a.emailsrvr.com [173.203.187.68]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0BBFB1A88FD for ; Mon, 10 Aug 2015 10:40:30 -0700 (PDT) Received: from smtp9.relay.iad3a.emailsrvr.com (localhost.localdomain [127.0.0.1]) by smtp9.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 333AD3800A4; Mon, 10 Aug 2015 13:40:30 -0400 (EDT) Received: from app36.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by smtp9.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 228DE3801BC; Mon, 10 Aug 2015 13:40:29 -0400 (EDT) X-Sender-Id: ogud@ogud.com Received: from app36.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by 0.0.0.0:25 (trex/5.4.2); Mon, 10 Aug 2015 17:40:30 GMT Received: from ogud.com (localhost.localdomain [127.0.0.1]) by app36.wa-webapps.iad3a (Postfix) with ESMTP id 06A73380089; Mon, 10 Aug 2015 13:40:29 -0400 (EDT) Received: by apps.rackspace.com (Authenticated sender: ogud@ogud.com, from: ogud@ogud.com) with HTTP; Mon, 10 Aug 2015 13:40:29 -0400 (EDT) Date: Mon, 10 Aug 2015 13:40:29 -0400 (EDT) From: "Olafur Gudmundsson" To: "Viktor Dukhovni" MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_20150810134029000000_89340" Importance: Normal X-Priority: 3 (Normal) X-Type: html In-Reply-To: <20150809045612.GD9139@mournblade.imrryr.org> References: <55C3A143.4080607@cs.tcd.ie> <20150809045612.GD9139@mournblade.imrryr.org> X-Auth-ID: ogud@ogud.com Message-ID: <1439228429.025630410@apps.rackspace.com> X-Mailer: webmail/11.5.5-RC Archived-At: Cc: Wes Hardaker , iesg@ietf.org, dane@ietf.org Subject: Re: [dane] Mail regarding draft-ietf-dane-ops X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 10 Aug 2015 17:40:33 -0000 ------=_20150810134029000000_89340 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =0AVictor =0AI read the whole document and I think version 16 is significan= tly better than 14 in clarity. =0AThank you for being such a good editor = =0AThanks to the IESG and community reviewers for helping making the docume= nt better. =0A =0AOlafur=0A =0A-----Original Message-----=0AFrom: "Viktor D= ukhovni" =0ASent: Sunday, 9 August, 2015 00:56=0ATo= : iesg@ietf.org=0ACc: "Wes Hardaker" , dane@ietf.org=0A= Subject: Re: [dane] Mail regarding draft-ietf-dane-ops=0A=0A=0A=0AOn Thu, A= ug 06, 2015 at 07:02:43PM +0100, Stephen Farrell wrote:=0A=0A> I think you'= ve already handled all the comments received=0A> in IESG evaluation in your= local copy, is that correct?=0A> =0A> If so, please submit that and I'll g= ive it a quick check (on=0A> Monday, sorrry) and then send a mail to get it= sent forward=0A> to the RFC editor.=0A=0AIn addition to the changes based = on the IESG review comments, I=0Awent over the whole thing, and added some = more rationale text (as=0Arequested in Fred Baker's review). Also some fina= l editorial polish=0Aof my own.=0A=0APlease let me know if I changed too mu= ch..., I can pare it back=0Acloser to -14 if I went too far.=0A=0AIt took t= wo revisions to get the indentation of the quote from=0ARFC5246 to work rig= ht (sorry about that). So, to review the changes,=0Asee:=0A=0A https://www.= ietf.org/rfcdiff?url1=3Ddraft-ietf-dane-ops-14&url2=3Ddraft-ietf-dane-ops-1= 6=0A=0A-- =0A Viktor.=0A=0A_______________________________________________= =0Adane mailing list=0Adane@ietf.org=0Ahttps://www.ietf.org/mailman/listinf= o/dane ------=_20150810134029000000_89340 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Victor 

=0A

I read the whole document and I think version 16 is significantly= better than 14 in clarity. 

=0A

Thank you for bein= g such a good editor 

=0A

Thanks to the IESG and co= mmunity reviewers for helping making the document better. 

=0A

 

=0A

Olafur

=0A

&nb= sp;

=0A

-----Original Message-----
From: "Viktor Du= khovni" <ietf-dane@dukhovni.org>
Sent: Sunday, 9 August, 2015 00= :56
To: iesg@ietf.org
Cc: "Wes Hardaker" <ietf@hardakers.net&g= t;, dane@ietf.org
Subject: Re: [dane] Mail regarding draft-ietf-dane-o= ps

=0A
=0A

O= n Thu, Aug 06, 2015 at 07:02:43PM +0100, Stephen Farrell wrote:

= > I think you've already handled all the comments received
> in = IESG evaluation in your local copy, is that correct?
>
> I= f so, please submit that and I'll give it a quick check (on
> Monda= y, sorrry) and then send a mail to get it sent forward
> to the RFC= editor.

In addition to the changes based on the IESG review com= ments, I
went over the whole thing, and added some more rationale text= (as
requested in Fred Baker's review). Also some final editorial poli= sh
of my own.

Please let me know if I changed too much..., = I can pare it back
closer to -14 if I went too far.

It took= two revisions to get the indentation of the quote from
RFC5246 to wor= k right (sorry about that). So, to review the changes,
see:

https://www.ietf.org/rfcdiff?url1=3Ddraft-ietf-dane-ops-14&url2=3Ddra= ft-ietf-dane-ops-16

--
Viktor.

_______________= ________________________________
dane mailing list
dane@ietf.org<= br />https://www.ietf.org/mailman/listinfo/dane

=0A
 ------=_20150810134029000000_89340-- From nobody Mon Aug 10 12:46:25 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E66F11B2EEC; Mon, 10 Aug 2015 12:46:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cfgF0C98YAap; Mon, 10 Aug 2015 12:46:20 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F1DBB1B3D37; Mon, 10 Aug 2015 12:46:12 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.4.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150810194612.14484.55994.idtracker@ietfa.amsl.com> Date: Mon, 10 Aug 2015 12:46:12 -0700 Archived-At: Cc: dane mailing list , dane chair , RFC Editor Subject: [dane] Protocol Action: 'Updates to and Operational Guidance for the DANE Protocol' to Proposed Standard (draft-ietf-dane-ops-16.txt) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2015 19:46:22 -0000 The IESG has approved the following document: - 'Updates to and Operational Guidance for the DANE Protocol' (draft-ietf-dane-ops-16.txt) as Proposed Standard This document is the product of the DNS-based Authentication of Named Entities Working Group. The IESG contact persons are Stephen Farrell and Kathleen Moriarty. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-dane-ops/ Technical Summary This document clarifies and updates the DNS-Based Authentication of Named Entities (DANE) TLSA specification (RFC6698) based on subsequent implementation experience. It also contains guidance for implementers, operators and protocol developers who want to make use of DANE records. Working Group Summary This document received significant discussion, and reflects new understanding of how DANE is being used and deployed. It provides advice to operators and implementers. Document Quality This document describes how to actually use and interpret RFC 6698 now that we have some experience with it. It is very clearly written, easily understood, and makes a good introductory document as well. Personnel Warren Kumari is the Document Shepherd Stephen Farrell is Responsible AD From nobody Wed Aug 19 08:17:22 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EC101B2A9F for ; Wed, 19 Aug 2015 08:17:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.1 X-Spam-Level: X-Spam-Status: No, score=0.1 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VlT4lrqrd-zu for ; Wed, 19 Aug 2015 08:17:15 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9BF631B2A95 for ; Wed, 19 Aug 2015 08:17:15 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 99FE1284DA0; Wed, 19 Aug 2015 15:17:14 +0000 (UTC) Date: Wed, 19 Aug 2015 15:17:14 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20150819151714.GV24426@mournblade.imrryr.org> References: <20150728194641.GZ4347@mournblade.imrryr.org> <20150819111321.Horde.AMN770Q1K6o6vnZD0nEE9KN@webmail.kwsoft.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150819111321.Horde.AMN770Q1K6o6vnZD0nEE9KN@webmail.kwsoft.de> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [dane] [OT] Deployment news (Germany is plowing ahead) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 19 Aug 2015 15:17:21 -0000 On Wed, Aug 19, 2015 at 11:13:21AM +0200, lst_hoe02@kwsoft.de wrote: > FYI : According to the news today the next big deployment in germany is > on the way (german only, sorry) > > http://www.heise.de/newsticker/meldung/Kehrtwende-bei-Mail-Sicherheit-Web-de-und-GMX-fuehren-DANE-ein-2782473.html > > The two brands GMX and web.de affected do around half of the german freemail > traffic. Great news, thanks! Google's "translate" with minor fixes yields in part: At the time United Internet thought DANE "not yet fully mature" by comparison the "E-mail Made in Germany" initiative with Telekom and Strato, founded in August 2013. Therefore, the Emig partners decided to develop their own procedures, explains United Internet now. Since then DANE has attained "sufficient maturity". The launch is scheduled for completion by year end. In response to Heise Networks a company spokesperson explained that the DANE technology will be extended to other domains of the group, including the mail service 1und1.de which uses the same backend as Web.de and GMX. The hosting customers of United Internet are however on Exchange Technology, so DANE is not to be expected in the foreseeable future. The company starts with various additional domains with GMX and will then gradually upgrade the major domains as gmx.de, web.de, gmx.net. So it was easier to deal with any load or quality problems before they come in to customer constraints. I should note that one can publish TLSA records even for Exchange servers, SMTP servers don't need new software to support DANE inbound. Also, just because the mailboxes are on Exchange, does not mean the edge servers sending mail to the rest of the world need to be Exchange. And of course deployment on this scale should help to convince Microsoft to add the required outbound (SMTP client) DANE support. Existing DANE implementors (mostly hobbyists) will soon more quickly notice if they don't do key rollover correctly when they get no inbound mail from these (and I hope soon other similar or larger) providers. -- Viktor. From nobody Sat Aug 22 04:07:56 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FCEB1A1AA8 for ; Sat, 22 Aug 2015 04:07:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.16 X-Spam-Level: X-Spam-Status: No, score=-0.16 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HELO_EQ_DE=0.35, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jj6ebS4dpdSh for ; Sat, 22 Aug 2015 04:07:54 -0700 (PDT) Received: from smtp3.strotmann.de (smtp3.strotmann.de [46.38.233.133]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D9F51A1A99 for ; Sat, 22 Aug 2015 04:07:53 -0700 (PDT) Received: from debian01.home.strotmann.de (unknown [IPv6:2a01:198:2b6:1000:240:caff:fea0:83b3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp3.strotmann.de (Postfix) with ESMTPS id DD2277FE59 for ; Sat, 22 Aug 2015 13:07:26 +0200 (CEST) Received: from MacMini3.local (unknown [IPv6:2a01:198:2b6:0:71d8:e0f1:dd56:caba]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by debian01.home.strotmann.de (Postfix) with ESMTPSA id 4061520008D for ; Sat, 22 Aug 2015 13:07:26 +0200 (CEST) To: dane@ietf.org From: Carsten Strotmann X-Enigmail-Draft-Status: N1110 Message-ID: <55D857EA.80107@strotmann.de> Date: Sat, 22 Aug 2015 13:07:22 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: [dane] DNS-Record type for SMIMEA X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 22 Aug 2015 11:07:55 -0000 Hi, I remember there was a brief discussion during the DANE WG session @ IETF 93 about requesting a DNS record type number for SMIMEA from IANA, but I don't remember if there was a conclusion or an action decided. I cannot find it mentioned in the minutes. Does anyone know the status of this? Testing of SMIMEA will be be done with "normal but security enthusiastic" users, it would be good to have a "well known" DNS record type number for SMIMEA instead of a private type number for these tests. Best regards Carsten From nobody Sat Aug 22 06:47:10 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CABE1A87A7 for ; Sat, 22 Aug 2015 06:47:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UgC4IFcmfN-B for ; Sat, 22 Aug 2015 06:47:07 -0700 (PDT) Received: from smtp116.iad3a.emailsrvr.com (smtp116.iad3a.emailsrvr.com [173.203.187.116]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EEA8F1A87A0 for ; Sat, 22 Aug 2015 06:47:06 -0700 (PDT) Received: from smtp31.relay.iad3a.emailsrvr.com (localhost.localdomain [127.0.0.1]) by smtp31.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id F0B55380133; Sat, 22 Aug 2015 09:47:05 -0400 (EDT) Received: by smtp31.relay.iad3a.emailsrvr.com (Authenticated sender: ogud-AT-ogud.com) with ESMTPSA id 01E01380163; Sat, 22 Aug 2015 09:47:04 -0400 (EDT) X-Sender-Id: ogud@ogud.com Received: from [10.20.30.43] (pool-173-66-187-177.washdc.fios.verizon.net [173.66.187.177]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:587 (trex/5.4.2); Sat, 22 Aug 2015 13:47:05 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: Olafur Gudmundsson In-Reply-To: <55D857EA.80107@strotmann.de> Date: Sat, 22 Aug 2015 09:47:09 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <8321AB9D-ADCD-44BD-8A0F-1D6B5CF1971C@ogud.com> References: <55D857EA.80107@strotmann.de> To: Carsten Strotmann X-Mailer: Apple Mail (2.2102) Archived-At: Cc: dane@ietf.org Subject: Re: [dane] DNS-Record type for SMIMEA X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 22 Aug 2015 13:47:09 -0000 Such a request has not been submitted, but it is good idea to do it.=20 Olafur (as chair)=20 > On Aug 22, 2015, at 7:07 AM, Carsten Strotmann = wrote: >=20 > Hi, >=20 > I remember there was a brief discussion during the DANE WG session @ > IETF 93 about requesting a DNS record type number for SMIMEA from = IANA, > but I don't remember if there was a conclusion or an action decided. I > cannot find it mentioned in the minutes. >=20 > Does anyone know the status of this? >=20 > Testing of SMIMEA will be be done with "normal but security > enthusiastic" users, it would be good to have a "well known" DNS = record > type number for SMIMEA instead of a private type number for these = tests. >=20 > Best regards >=20 > Carsten >=20 > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane From nobody Sun Aug 23 10:29:56 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E779D1AD373 for ; Sun, 23 Aug 2015 10:29:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.439 X-Spam-Level: * X-Spam-Status: No, score=1.439 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jAkDdz4U385x for ; Sun, 23 Aug 2015 10:29:53 -0700 (PDT) Received: from mail.frobbit.se (mail.frobbit.se [IPv6:2a02:80:3ffe::176]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 416A61AD370 for ; Sun, 23 Aug 2015 10:29:53 -0700 (PDT) Received: from [192.168.1.12] (frobbit.cust.teleservice.net [85.30.128.225]) by mail.frobbit.se (Postfix) with ESMTPSA id DED0E1FDE4 for ; Sun, 23 Aug 2015 19:29:50 +0200 (CEST) From: "Patrik =?utf-8?b?RsOkbHRzdHLDtm0=?=" To: dane@ietf.org Date: Sun, 23 Aug 2015 19:29:50 +0200 Message-ID: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=_MailMate_B49909BE-80E3-474F-AD72-0C4CF4E733F4_="; micalg=pgp-sha1; protocol="application/pgp-signature" X-Mailer: MailMate (1.9.2r5107) Archived-At: Subject: [dane] Delivery of email if MX is not signed X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 23 Aug 2015 17:29:55 -0000 This is an OpenPGP/MIME signed message (RFC 3156 and 4880). --=_MailMate_B49909BE-80E3-474F-AD72-0C4CF4E733F4_= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi, I have *not* followed this wg in detail, although I have talked with vari= ous people about how important it is to get DANE deployed. I am also stro= ngly advocating use and deployment of DANE as I personally think the curr= ent CA/X.509 PKI structure is broken beyond ability to fix it. I read a text by Jan =C5=BDor=C5=BE: That made me a bit confused as I interpreted the text as if mail was not = delivered in one case where I think email should be delivered. I have in Facebook had a long discussion with Jan, and the more I think a= bout it, the more I think I am right ;-) I have re-read the very very very long I-D (draft-ietf-dane-smtp-with-dan= e) that is now in RFC-Ed Queue and I think unfortunately the huge number = of words, lack of flow chart (decision making tree) and lack of real worl= d examples makes it hard to know what the document says. At least I can n= ot say directly whether the draft really say anything at all about this e= xample I am to bring up. But all of this might imply I am wrong of course. If nothing else because= I have not followed the discussions. Ok, to the example: Delivery of email consists of two steps: 1. Resolution of MX record. And if no MX exists, fallback to A/AAAA In my example, we DO have an MX record. To me this is 100% normal DNSSEC.= Question on whether the target of the MX is to be trusted is up to the p= olicy we use for DNSSEC. Also, in my example the RRSet the MX is in is _unsigned_: example.com. IN MX 0 mail.example.net. 2. Delivery of the mail over TLS to mail.example.net. This is where DANE comes in. For the cert to be trusted, there must be a = TLSA record for _426._tcp.mail.example.net, and it must be DNSSEC signed,= signatures validated etc etc. This step 100% validates and is correct according to traditional DANE. Ok, how then to put these pieces together? I think these two steps are independent of each other. And DANE should be= used, the cert be accepted, if step 2 is properly validated, TLSA record= signed and validated etc. Regardless of whether the MX was signed. That said, the sender CAN have a policy that say that "For me to base my = trust on DNS (and not X.509 CA hierarchy), MX must be signed with DNSSEC = and properly validated." But, default must be to allow unsigned MX together with a properly setup = with by DANE validated cert that is used in TLS. If not, we will get absolutely zero deployment of DANE with SMTP as we wi= ll never get 100% DNSSEC deployment. And if DANE is so good, which I think, and I hope all of us think, why sh= ould not a TLS connection that is properly secured with DANE not be accep= ted for SMTP? No, I do not think the MiM attack vector is _worse_ with unsigned MX but = properly validated TLSA than what we use today without TLS and unsigned M= X. And no, I do not think todays X.509 CA use is very good at all. As som= e of you know. Best, Patrik --=_MailMate_B49909BE-80E3-474F-AD72-0C4CF4E733F4_= Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlXaAw4ACgkQrMabGguI1823rQCcD1KHTG11G7l1wv4/lBDR9hCA gRkAn3dmJ5UNzNYq2qmJeNau3lNEZgwS =I5ub -----END PGP SIGNATURE----- --=_MailMate_B49909BE-80E3-474F-AD72-0C4CF4E733F4_=-- From nobody Sun Aug 23 10:47: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 D788C1B29DD for ; Sun, 23 Aug 2015 10:47:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.189 X-Spam-Level: X-Spam-Status: No, score=0.189 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JxJUh758uLFO for ; Sun, 23 Aug 2015 10:47:18 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6AB331B29DB for ; Sun, 23 Aug 2015 10:47:18 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3mzkYc1H1zz1K2; Sun, 23 Aug 2015 19:47:16 +0200 (CEST) Authentication-Results: mx.nohats.ca; dkim=pass (1024-bit key) header.d=nohats.ca header.i=@nohats.ca header.b=vCpd2wID X-OPENPGPKEY: Message passed unmodified X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id Gd4-m_iObwpr; Sun, 23 Aug 2015 19:47:14 +0200 (CEST) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Sun, 23 Aug 2015 19:47:14 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id C5127800A0; Sun, 23 Aug 2015 13:47:12 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1440352032; bh=waeXlMwIghcxM90zBOgiOeLGyWuyRbuUWtlsqU99hks=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=vCpd2wIDjEtIs8X3lfuQp9s5Bux/8ZdN8X6BH+QfUmLELC1nVH6BFAz4ufH1LNFZL rKrCfp7YTBQTLlVCLtPyVFOVaVS3PRP1id9msfWG6tD8Ksl1PhWRdM7T4P9dEk8Mk6 B1Es5zEVUGfG8Gxrg3MIiuXvAFDWm+szm6dkVcPQ= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.15.2/8.15.2/Submit) with ESMTP id t7NHlCGR005435; Sun, 23 Aug 2015 13:47:12 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Sun, 23 Aug 2015 13:47:12 -0400 (EDT) From: Paul Wouters To: =?ISO-8859-15?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: Message-ID: References: User-Agent: Alpine 2.20 (LFD 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8BIT Archived-At: Cc: dane@ietf.org Subject: Re: [dane] Delivery of email if MX is not signed X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 23 Aug 2015 17:47:20 -0000 On Sun, 23 Aug 2015, Patrik Fältström wrote: > Also, in my example the RRSet the MX is in is _unsigned_: > > example.com. IN MX 0 mail.example.net. > > 2. Delivery of the mail over TLS to mail.example.net. so example.com is unsigned? and mail.example.net is signed, and the TLSA record in example.net is signed. In that case, I believe TLS will be used but the TLSA cannot be verified, so while delivery happens over TLS, there is no way to verify the identity of the receiver because the MX record could have been spoofed. I think you are arguing that it should deliver TLS only after validation of the TLSA record for mail.example.net. That validation is a false sense of security though. I don't think mail delivery will be halted. since the example.com domain is unsigned, anonymous TLS will be used when available, and no verification will take place. I'm not sure what you are proposing to change? Paul From nobody Sun Aug 23 10:59:42 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 925801B29ED for ; Sun, 23 Aug 2015 10:59:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.261 X-Spam-Level: X-Spam-Status: No, score=-1.261 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZlEhtB1opB1S for ; Sun, 23 Aug 2015 10:59:40 -0700 (PDT) Received: from mail.frobbit.se (mail.frobbit.se [IPv6:2a02:80:3ffe::176]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C85B1B29EC for ; Sun, 23 Aug 2015 10:59:40 -0700 (PDT) Received: from [192.165.72.22] (ibin.frobbit.se [192.165.72.22]) by mail.frobbit.se (Postfix) with ESMTPSA id 2C649200BC; Sun, 23 Aug 2015 19:59:38 +0200 (CEST) From: "Patrik =?utf-8?b?RsOkbHRzdHLDtm0=?=" To: "Paul Wouters" Date: Sun, 23 Aug 2015 19:59:37 +0200 Message-ID: In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=_MailMate_F8B61281-89CB-4ED9-8A01-FFCA12D8601D_="; micalg=pgp-sha1; protocol="application/pgp-signature" X-Mailer: MailMate (1.9.2r5107) Archived-At: Cc: dane@ietf.org Subject: Re: [dane] Delivery of email if MX is not signed X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 23 Aug 2015 17:59:41 -0000 This is an OpenPGP/MIME signed message (RFC 3156 and 4880). --=_MailMate_F8B61281-89CB-4ED9-8A01-FFCA12D8601D_= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 23 Aug 2015, at 19:47, Paul Wouters wrote: > On Sun, 23 Aug 2015, Patrik F=C3=A4ltstr=C3=B6m wrote: > >> Also, in my example the RRSet the MX is in is _unsigned_: >> >> example.com. IN MX 0 mail.example.net. >> >> 2. Delivery of the mail over TLS to mail.example.net. > > so example.com is unsigned? and mail.example.net is signed, and the TLS= A > record in example.net is signed. Correct. > In that case, I believe TLS will be used but the TLSA cannot be > verified, so while delivery happens over TLS, there is no way to > verify the identity of the receiver because the MX record could have > been spoofed. Excuse me for being slow here. What do you mean by "the TLSA cannot be ve= rified"? To be more precise: Unsigned RRSET contain: example.net. IN MX 0 mail.example.com. Signed (and properly validated) RRSETs that contains these two records an= d a few more: mail.example.com. IN A 192.168.1.1 _426._tcp.mail.example.om. IN TLSA .... I.e. if only looking at mail.example.com. and _426._tcp.mail.example.com.= that is a 100% properly setup DANE "thing". > I think you are arguing that it should deliver TLS only after validatio= n > of the TLSA record for mail.example.net. That validation is a false > sense of security though. > > I don't think mail delivery will be halted. since the example.com domai= n > is unsigned, anonymous TLS will be used when available, and no > verification will take place. > > I'm not sure what you are proposing to change? I am not sure I am proposing a change. :-) What seems to have happened in the tests that Jan did was that IF the MX = was not signed, BUT the TLSA was signed and validated correctly, THEN pos= tfix did _NOT_ deliver the email. At all. I think that behaviour is wrong, and am unsure whether it is a bug in pos= tfix or whether it is a bug in the spec. Patrik --=_MailMate_F8B61281-89CB-4ED9-8A01-FFCA12D8601D_= Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlXaCgkACgkQrMabGguI180bggCgkKGpzpzfm4l+V96QmRbj+uWo 5FMAoIklNhNKsC8tP1gnjY4ux1tZcMZs =iHr2 -----END PGP SIGNATURE----- --=_MailMate_F8B61281-89CB-4ED9-8A01-FFCA12D8601D_=-- From nobody Sun Aug 23 11:18: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 0E4811AC3C1 for ; Sun, 23 Aug 2015 11:18:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.71 X-Spam-Level: X-Spam-Status: No, score=-1.71 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ouCQsBIXSjcs for ; Sun, 23 Aug 2015 11:18:43 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83B3B1AC3B3 for ; Sun, 23 Aug 2015 11:18:43 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3mzlFs3ylrz1K2; Sun, 23 Aug 2015 20:18:41 +0200 (CEST) Authentication-Results: mx.nohats.ca; dkim=pass (1024-bit key) header.d=nohats.ca header.i=@nohats.ca header.b=PYicq57b X-OPENPGPKEY: Message passed unmodified X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id eAUd3pvfBIP9; Sun, 23 Aug 2015 20:18:40 +0200 (CEST) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Sun, 23 Aug 2015 20:18:40 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id AE1838009C; Sun, 23 Aug 2015 14:18:39 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1440353919; bh=VD7csweyM5aog2bv2aF9SOkUcb6aDgKMStaC9+4c0Lk=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=PYicq57b7JGKomZd+/zhJWQdvBbzHhTAK7gUW61RFGlzfe/EY2uAdWjzOhEY70jBz 7hVf8KawHxrHVEx4hK50C1EPDi7udeSMyIIsyAOuUIypLdFF4q1pmj0qMncyVOlhdn 67K2BzAOp9/scZst1tQzCJDI1PeSLYt23E79FsMU= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.15.2/8.15.2/Submit) with ESMTP id t7NIIdS5005985; Sun, 23 Aug 2015 14:18:39 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Sun, 23 Aug 2015 14:18:39 -0400 (EDT) From: Paul Wouters To: =?ISO-8859-15?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: Message-ID: References: User-Agent: Alpine 2.20 (LFD 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8BIT Archived-At: Cc: dane@ietf.org Subject: Re: [dane] Delivery of email if MX is not signed X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 23 Aug 2015 18:18:45 -0000 On Sun, 23 Aug 2015, Patrik Fältström wrote: >>> 2. Delivery of the mail over TLS to mail.example.net. >> >> so example.com is unsigned? and mail.example.net is signed, and the TLSA >> record in example.net is signed. > > Correct. > >> In that case, I believe TLS will be used but the TLSA cannot be >> verified, so while delivery happens over TLS, there is no way to >> verify the identity of the receiver because the MX record could have >> been spoofed. > > Excuse me for being slow here. What do you mean by "the TLSA cannot be verified"? > > To be more precise: > > Unsigned RRSET contain: > > example.net. IN MX 0 mail.example.com. > > Signed (and properly validated) RRSETs that contains these two records and a few more: > > mail.example.com. IN A 192.168.1.1 > _426._tcp.mail.example.om. IN TLSA .... so anyone can spoof: example.net. IN MX 0 mail.example.com. pretending "mail.example.com." does not give you more security. What would you do if you saw: example.net. IN MX 0 evil.nohats.ca with proper TLSA records for evil.nohats.ca? > I.e. if only looking at mail.example.com. and _426._tcp.mail.example.com. that is a 100% properly setup DANE "thing". But nothing in that statement securely tells you anything about example.net. >> I don't think mail delivery will be halted. since the example.com domain >> is unsigned, anonymous TLS will be used when available, and no >> verification will take place. >> >> I'm not sure what you are proposing to change? > > I am not sure I am proposing a change. :-) > > What seems to have happened in the tests that Jan did was that IF the MX was not signed, BUT the TLSA was signed and validated correctly, THEN postfix did _NOT_ deliver the email. At all. > > I think that behaviour is wrong, and am unsure whether it is a bug in postfix or whether it is a bug in the spec. That would be a bug in postfix? The spec states: All "insecure" RRSets MUST be handled identically: in either case unvalidated data for the query domain is all that is and can be available, and authentication using the data is impossible. It does not state to not deliver email, it just states there is no authentication possible, so deliver without dane authentication. Paul From nobody Sun Aug 23 11:30:16 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3DB71B2A0E for ; Sun, 23 Aug 2015 11:30:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.961 X-Spam-Level: X-Spam-Status: No, score=-1.961 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, 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 IgzcfzZy__Bk for ; Sun, 23 Aug 2015 11:30:13 -0700 (PDT) Received: from mail.frobbit.se (mail.frobbit.se [85.30.129.185]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 20DE61B2A0D for ; Sun, 23 Aug 2015 11:30:13 -0700 (PDT) Received: from [192.168.1.12] (frobbit.cust.teleservice.net [85.30.128.225]) by mail.frobbit.se (Postfix) with ESMTPSA id 22E1520025; Sun, 23 Aug 2015 20:30:11 +0200 (CEST) From: "Patrik =?utf-8?b?RsOkbHRzdHLDtm0=?=" To: "Paul Wouters" Date: Sun, 23 Aug 2015 20:30:10 +0200 Message-ID: In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=_MailMate_3A5CC493-03BD-4213-BF84-895C0125E245_="; micalg=pgp-sha1; protocol="application/pgp-signature" X-Mailer: MailMate (1.9.2r5107) Archived-At: Cc: dane@ietf.org Subject: Re: [dane] Delivery of email if MX is not signed X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 23 Aug 2015 18:30:14 -0000 This is an OpenPGP/MIME signed message (RFC 3156 and 4880). --=_MailMate_3A5CC493-03BD-4213-BF84-895C0125E245_= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On 23 Aug 2015, at 20:18, Paul Wouters wrote: >> Unsigned RRSET contain: >> >> example.net. IN MX 0 mail.example.com. >> >> Signed (and properly validated) RRSETs that contains these two records= and a few more: >> >> mail.example.com. IN A 192.168.1.1 >> _426._tcp.mail.example.om. IN TLSA .... > > so anyone can spoof: > > example.net. IN MX 0 mail.example.com. Yes, just like today. > pretending "mail.example.com." does not give you more security. What > would you do if you saw: > > example.net. IN MX 0 evil.nohats.ca > > with proper TLSA records for evil.nohats.ca? This is what we have today. I would deliver over the TLS secured connection. The only way to secure that is to DNSSEC sign mail.example.net. >> I.e. if only looking at mail.example.com. and _426._tcp.mail.example.c= om. that is a 100% properly setup DANE "thing". > > But nothing in that statement securely tells you anything about example= =2Enet. Correct. >> I think that behaviour is wrong, and am unsure whether it is a bug in = postfix or whether it is a bug in the spec. > > That would be a bug in postfix? The spec states: > > All > "insecure" RRSets MUST be handled identically: in either case > unvalidated data for the query domain is all that is and can be > available, and authentication using the data is impossible. > > It does not state to not deliver email, it just states there is no > authentication possible, so deliver without dane authentication. Ok, I think what I have issues with is that I think "dane authentication"= is not black or white. We have at least: 1. Signed and validated MX, signed and validated TLSA 2. Unsigned MX, signed and validated TLSA 3. Unsigned MX, no TLSA, unsigned A/AAAA Then we have all of the failed situations, which include: 4. Signed, but broken signatures, on MX, signed and validated TLSA 5. Signed, but broken signatures, on MX, signed but broken signatures on = TLSA 6. Unsigned MX, signed but broken signatures on TLSA Etc So if you look at 1, 2 and 3, if I understand you correctly, [2] is not "= DANE authenticated" even if the TLS connection has properly signed and va= lidated TLSA record? This is a bit confusing to me. I.e. the terminology is confusing. To me, = [2] has proper DANE validated TLS available for the SMTP connection. But I completely agree there is an MiM possible for the unsigned MX. Just= like we have today. And why we want DNSSEC deployed. Patrik --=_MailMate_3A5CC493-03BD-4213-BF84-895C0125E245_= Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlXaETIACgkQrMabGguI180fsQCeIIGuB35MA0NvxM+4vZTh3RZ2 WuAAoJpV/54iFeNvyQFKVbbJENECRtrm =oS1m -----END PGP SIGNATURE----- --=_MailMate_3A5CC493-03BD-4213-BF84-895C0125E245_=-- From nobody Sun Aug 23 11:39:30 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE0BC1B2A1C for ; Sun, 23 Aug 2015 11:39:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.26 X-Spam-Level: X-Spam-Status: No, score=-2.26 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, 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 P4Z41PYL8_N2 for ; Sun, 23 Aug 2015 11:39:26 -0700 (PDT) Received: from mailer.kwsoft.de (mailer.kwsoft.de [213.164.67.65]) (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 22EDD1B2A1A for ; Sun, 23 Aug 2015 11:39:26 -0700 (PDT) Received: from mailer (localhost [127.0.0.1]) by mailer.kwsoft.de (Postfix) with ESMTP id 8030D181156 for ; Sun, 23 Aug 2015 20:39:24 +0200 (CEST) Received: from ftp (ftp.kwsoft.de [213.164.67.83]) by mailer.kwsoft.de (Postfix) with ESMTPS id C8633180DDB for ; Sun, 23 Aug 2015 20:39:23 +0200 (CEST) Received: from p54986CB5.dip0.t-ipconnect.de (p54986CB5.dip0.t-ipconnect.de [84.152.108.181]) by webmail.kwsoft.de (Horde Framework) with HTTP; Sun, 23 Aug 2015 20:39:23 +0200 Date: Sun, 23 Aug 2015 20:39:23 +0200 From: lst_hoe02@kwsoft.de To: dane@ietf.org Message-ID: <20150823203923.Horde.tB2fdE287dvPnQ0vGJjMYhv@webmail.kwsoft.de> In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-1; boundary="----=_Part_875_530035262.1440355164426" User-Agent: Horde Application Framework 5 Archived-At: Subject: Re: [dane] Delivery of email if MX is not signed X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 23 Aug 2015 18:39:27 -0000 ------=_Part_875_530035262.1440355164426 Content-Type: text/plain; charset=utf-8; format=flowed; DelSp=Yes Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Zitat von Patrik F=C3=A4ltstr=C3=B6m : > On 23 Aug 2015, at 19:47, Paul Wouters wrote: > >> On Sun, 23 Aug 2015, Patrik F=C3=A4ltstr=C3=B6m wrote: >> >>> Also, in my example the RRSet the MX is in is _unsigned_: >>> >>> example.com. IN MX 0 mail.example.net. >>> >>> 2. Delivery of the mail over TLS to mail.example.net. >> >> so example.com is unsigned? and mail.example.net is signed, and the TL= SA >> record in example.net is signed. > > Correct. > >> In that case, I believe TLS will be used but the TLSA cannot be >> verified, so while delivery happens over TLS, there is no way to >> verify the identity of the receiver because the MX record could have >> been spoofed. > > Excuse me for being slow here. What do you mean by "the TLSA cannot =20 > be verified"? > > To be more precise: > > Unsigned RRSET contain: > > example.net. IN MX 0 mail.example.com. > > Signed (and properly validated) RRSETs that contains these two =20 > records and a few more: > > mail.example.com. IN A 192.168.1.1 > _426._tcp.mail.example.om. IN TLSA .... > > I.e. if only looking at mail.example.com. and =20 > _426._tcp.mail.example.com. that is a 100% properly setup DANE =20 > "thing". > >> I think you are arguing that it should deliver TLS only after validati= on >> of the TLSA record for mail.example.net. That validation is a false >> sense of security though. >> >> I don't think mail delivery will be halted. since the example.com doma= in >> is unsigned, anonymous TLS will be used when available, and no >> verification will take place. >> >> I'm not sure what you are proposing to change? > > I am not sure I am proposing a change. :-) > > What seems to have happened in the tests that Jan did was that IF =20 > the MX was not signed, BUT the TLSA was signed and validated =20 > correctly, THEN postfix did _NOT_ deliver the email. At all. > > I think that behaviour is wrong, and am unsure whether it is a bug =20 > in postfix or whether it is a bug in the spec. To my knowledge with Postfix this should lead to a "normal" TLS =20 connection with no DANE at all for "dane" level: "The Postfix SMTP client will not look for TLSA records associated =20 with MX hosts whose "A" or "AAAA" records lie in an "insecure" DNS =20 zone." With dane-only the connection might fail. Regards Andreas ------=_Part_875_530035262.1440355164426 Content-Type: application/pkcs7-signature; name=smime.p7s; smime-type=signed-data Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIAwggYnMIIF D6ADAgECAgMLUQowDQYJKoZIhvcNAQELBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFy dENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgw NgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAe Fw0xNDA5MjUxMDA5NTVaFw0xNTA5MjUyMjI2MDBaMEIxHDAaBgNVBAMME2xzdF9ob2UwMkBrd3Nv ZnQuZGUxIjAgBgkqhkiG9w0BCQEWE2xzdF9ob2UwMkBrd3NvZnQuZGUwggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQDA7+a1L8qfgq/e2rtcY2c40Ds/1/jAEho66qHzmc/u7OUkWM7RtJ7q NN00ff/Fua7dnrXUQZ7KyfLXLad5mAgAgcxlgq8TFOy8S36fYJybTdy6jjFnH/Qkb1OOgFNNltt+ 8hVJXG6jVIu2X3d3DCxtfsE/H4HFcwbO+Qf1lvJTaDx4DTHq9xBaVQigE/UQVyQnjCqxUZPlZST/ 49v70MT9f8gwZPdiHB/5Pn/ThqWdINoFkTWvfrs5Mw22LsHURmwjmGeWZXEw5bfrHDdd5AfZBopM KrRyMcm8Y15XIX9c/F+TeOGeXhhByFdsb54ukg/BqgG5YdUAKa9Y2xpMJIk7AgMBAAGjggLZMIIC 1TAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQw HQYDVR0OBBYEFAbLyy+g1nAk+Oy8wEbHvqik9KjFMB8GA1UdIwQYMBaAFFNy7ZKc4NrLAVx8fpY1 TvLUuFGCMB4GA1UdEQQXMBWBE2xzdF9ob2UwMkBrd3NvZnQuZGUwggFMBgNVHSAEggFDMIIBPzCC ATsGCysGAQQBgbU3AQIDMIIBKjAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20v cG9saWN5LnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRo b3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRpbmcgdG8gdGhl IENsYXNzIDEgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGlj eSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4gY29tcGxpYW5jZSBv ZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDov L2NybC5zdGFydHNzbC5jb20vY3J0dTEtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEF BQcwAYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczEvY2xpZW50L2NhMEIGCCsG AQUFBzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MxLmNsaWVudC5j YS5jcnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBCwUA A4IBAQAuCQ1tMkfhoITrQEKC+9WaBwGPy00bElZOY2rz7IzM3PqY5CpUfF3BvkR9wZona1oUSS66 mGtn3zNWlIh/W1tCLa+5WGiH0zV0Xpo02ifPvtuYCaOiubHRsCcATfmnoc10mPXNnDDjqlYgHCS0 HzsNg1zRDP6fX59Tlz0O/TIJzqcmJvaFF6r5HBum3vPvM7TNdOhrRTFioZAsj3oHphxKIO+Ei3d3 E6ChDy58aDxbgNhcJg1n3MdoVOojUtTNtLStbYuVwXMrROwNrpJbOCuDXGdm9ayE/zfrjTGB86i5 sbyvRK7AjI4qp0d97G5vI55rkQO0ujaq061Mw04huTlLMIIF2TCCA8GgAwIBAgIHFmdU48JwUTAN BgkqhkiG9w0BAQsFADB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkG A1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UEAxMgU3RhcnRD b20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNMDcxMDE0MjEwMTU1WhcNMjIxMDE0MjEwMTU1 WjCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3Vy ZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEg UHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEAxwmDzM4t2BqxKaQuE6uWvooyg4ymiEGWVUet1G8SD+rqvyNH4QrvnEIaFHxOhESip7vM z39ScLpNLbL1QpOlPW/tFIzNHS3qd2XRNYG5Sv9RcGE+T4qbLtsjjJbi6sL7Ls/f/X9ftTyhxvxW kf8KW37iKrueKsxw2HqolH7GM6FX5UfNAwAu4ZifkpmZzU1slBhyWwaQPEPPZRsWoTb7q8hmgv6N v3Hg9rmA1/VPBIOQ6SKRkHXG0Hhmq1dOFoAFI411+a/9nWm5rcVjGcIWZ2v/43Yksq60jExipA4l 5uv9/+Hm33mbgmCszdj/Dthf13tgAv2O83hLJ0exTqfrlwIDAQABo4IBTDCCAUgwEgYDVR0TAQH/ BAgwBgEB/wIBADAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFFNy7ZKc4NrLAVx8fpY1TvLUuFGC MB8GA1UdIwQYMBaAFE4L7xqkQFulF2mHMMo0aEPQQa7yMGkGCCsGAQUFBwEBBF0wWzAnBggrBgEF BQcwAYYbaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL2NhMDAGCCsGAQUFBzAChiRodHRwOi8vYWlh LnN0YXJ0c3NsLmNvbS9jZXJ0cy9jYS5jcnQwMgYDVR0fBCswKTAnoCWgI4YhaHR0cDovL2NybC5z dGFydHNzbC5jb20vc2ZzY2EuY3JsMEMGA1UdIAQ8MDowOAYEVR0gADAwMC4GCCsGAQUFBwIBFiJo dHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMA0GCSqGSIb3DQEBCwUAA4ICAQB0Cof6 Mt74mLfqrzMskIaloiG/ZD9SkYalhxhTCA+zgG6H6FIAylVCe1LIgZz5pXhmtqVML39geu6j6nNn vRnvf5AbybVfK0hEt8/vyla8elMJV/Fclp5ETRldDy7wg/t+HCDqoRd045reI6X2Ek45F3DqWuxe ERmW5rtPo9RzuOlwGMqTorIFw911nnKql8xDIpmVaxdw5bDGE2DJhbc0WAHmg4dgcXMyZVeB3gbP IMO3eFElKA1h3JDEeECtMy1VZkNReuoq5bVlrCfQhSlcs/WUwbKYtxQyQk/d130eDqzlBwfiOT9f JU1hww9af/XV+2YfG3cJTkinRH7Cr82sVWWypLl16OxTBtr+i0NiZr+hnOIyfI0so2racvOpZSSU 9kd7SRT0RpXz3GdYHtwHf6lw2SjyOKTfA+bKPPVlDwCe8/WXg6khXRk1msp02WgkTwCAv3t+VbU8 jbiGpvp+p7mmRYHHKQAsOdb5IBVIo+gCsQcquwjYAdWZ/xUV9eamQPW7tmSPEExyU//MzN541wIF egLBTn+vNrdeKrGEgc9I6Xn/JFNKteblfaGUho8taYf9MrEA/t+NjCIdz0JSqetnY93llj9zARe4 LUE2xEV9T5jM30yLMjG46vqb/T+IikTsNPvDDadD1DbYpTBtnyiwUaHMy4me4TC48nnQlzCCB8kw ggWxoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA2MDkxNzE5NDYzNloX DTM2MDkxNzE5NDYzNlowfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzAp BgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0 Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKC AgEAwYjbCbxsRnx4n5V7tTOQ8nJi1sE2ICIkXs7pd/JDCqIGZKTMjjb4OOYj8G5tsTzdcqOFHKHT PbQzK9Mvr/7qsEFZZ7bEBn0KnnSF1nlMgDd63zkFUln39BtGQ6TShYXSw3HzdWI0uiyKfx6P7u00 0BHHls1SPboz1t1N3gs7SkufwiYv+rUWHHI1d8o8XebK4SaLGjZ2XAHbdBQl/u21oIgP3XjKLR8H lzABLXJ5+kbWEyqouaarg0kd5fLv3eQBjhgKj2NTFoViqQ4ZOsy1ZqbCa3QH5Cvhdj60bdj2ROFz Yh87xL6gU1YlbFEJ96qryr92/W2b853bvz1mvAxWqq+YSJU6S9+nWFDZOHWpW+pDDAL/mevobE1w WyllnN2qXcyvATHsDOvSjejqnHvmbvcnZgwaSNduQuM/3iE+e+ENcPtjqqhsGlS0XCV6yaLJixam uyx+F14FTVhuEh0B7hIQDcYyfxj//PT6zW6R6DZJvhpIaYvClk0aErJpF8EKkNb6eSJIv7p7afhw x/p6N9jYDdJ2T1f/kLfjkdLd78Jgt2c63f6qnPDUi39yIs7Gn5e2+K+KoBCo2fsYxra1XFI8ibYZ KnMBCg8DsxJg8novgdujbv8mMJf1i92JV7atPbOvK8W3dgLwpdYrmoYUKnL24zOMXQlLE9+7jHQT UksCAwEAAaOCAlIwggJOMAwGA1UdEwQFMAMBAf8wCwYDVR0PBAQDAgGuMB0GA1UdDgQWBBROC+8a pEBbpRdphzDKNGhD0EGu8jBkBgNVHR8EXTBbMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5v cmcvc2ZzY2EtY3JsLmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydGNvbS5vcmcvc2ZzY2EtY3Js LmNybDCCAV0GA1UdIASCAVQwggFQMIIBTAYLKwYBBAGBtTcBAQEwggE7MC8GCCsGAQUFBwIBFiNo dHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjA1BggrBgEFBQcCARYpaHR0cDovL2Nl cnQuc3RhcnRjb20ub3JnL2ludGVybWVkaWF0ZS5wZGYwgdAGCCsGAQUFBwICMIHDMCcWIFN0YXJ0 IENvbW1lcmNpYWwgKFN0YXJ0Q29tKSBMdGQuMAMCAQEagZdMaW1pdGVkIExpYWJpbGl0eSwgcmVh ZCB0aGUgc2VjdGlvbiAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENvbSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly9jZXJ0LnN0YXJ0Y29t Lm9yZy9wb2xpY3kucGRmMBEGCWCGSAGG+EIBAQQEAwIABzA4BglghkgBhvhCAQ0EKxYpU3RhcnRD b20gRnJlZSBTU0wgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwDQYJKoZIhvcNAQEFBQADggIBABZs mfRmDDT10IVefQrs2hBOOBxe36YlBUuRMsHoO/E93UQJWwdJiinLZgK3sZr3JZgJPI4b4d02hytL u2jTOWY9oCbH8jmRHVGrgnt+1c5a5OIDV3Bplwj5XlimCt+MBppFFhY4Cl5X9mLHegIF5rwetfKe 9Kkpg/iyFONuKIdEw5Aa3jipPKxDTWRFzt0oqVzyc3sE+Bfoq7HzLlxkbnMxOhK4vLMR5H2PgVGa O42J9E2TZns8A+3Tmh2a82VQ9aDQdZ8vr/DqgkOY+GmciXnEQ45GcuNkNhKv9yUeOImQd37Da2q5 w8tES6x4kIvnxyweSxFEyDRSJ80KXZ+FwYnVGnjylRBTMt2AhGZ12bVoKPthLr6EqDjAmRKGpR5n ZK0GLi+pcIXHlg98iWX1jkNUDqvdpYA5lGDANMmWcCyjEvUfSHu9HH5rt52Q9CI7rvj8Ksr6glKg 769LVZPrwbXwIousNE4mIgShhyx1SrflfRPXuAxkwDbSyS+GEowjCcEbgjtzSaNqV4eU5dZ4xZlD Y+NN4Hct4WWZcmkEGkcJ5g8BViT7H78OealYLrnECQF+lbptAAY+supKEDnY0Cv1v+x1v5cCxQkb CNxVN+KB+zeEQ2IgyudWS2Xq/mzBJJMkoTTrBf+aIq6bfT/xZVEKpjBqs/SIHIAN/HKK6INeAAAx ggK9MIICuQIBATCBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzAp BgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMLUQowCQYFKw4DAhoF AKCB/jAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNTA4MjMxODM5 MjRaMCMGCSqGSIb3DQEJBDEWBBS7q2jE3mUqloRRZA58tUz47kUi9jCBngYJKoZIhvcNAQkPMYGQ MIGNMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4G CCqGSIb3DQMCAgIAgDAPBgkqhkiG9n0HQgoCAgCAMA0GCyqDCIyaSz0BAQEEMA0GCyqDCIyaSz0B AQEDMA0GCyqDCIyaSz0BAQECMAoGCCqDGoyaRAEEMA0GCSqGSIb3DQEBAQUABIIBAGKta4CaUPnB mwYRoXKdZELlKY93oiM6+IBCFgxLZNrg+nTvZyciHPmi0UL4gsEjyFM+iQu5rOGVap7sMO9rKiiN dXFGcNWsZlbiVPN67vQZpJ+/sCwcr881E91W0YsLrNW1SyzckJv9R8Pln+Q9ZuONXkhhp+lIQGk/ VQdUE0aj2CEFp9nclhHBAVBi8OVTNxDqQ1V+eHLTbQ+TMClUDE3iw+ro7fVvdwKc2ud2TqtLJpVk WUtfssKtiN1KRTH2LOyPIRFGYHJRkoKRXloJzlUtWnEOJd8fMfBexRksQ+RqEmPH2su+6aKuxc5W 2/J/MlyQqKhiy8wEzUju20VEj4QAAAAAAAA= ------=_Part_875_530035262.1440355164426-- From nobody Sun Aug 23 11:46:27 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3BCE1B2A2A for ; Sun, 23 Aug 2015 11:46:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.26 X-Spam-Level: X-Spam-Status: No, score=-2.26 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, 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 55gwP_P9V1tr for ; Sun, 23 Aug 2015 11:46:25 -0700 (PDT) Received: from mailer.kwsoft.de (mailer.kwsoft.de [213.164.67.65]) (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 2A3491B2A29 for ; Sun, 23 Aug 2015 11:46:25 -0700 (PDT) Received: from mailer (localhost [127.0.0.1]) by mailer.kwsoft.de (Postfix) with ESMTP id E6CF31810B2 for ; Sun, 23 Aug 2015 20:46:23 +0200 (CEST) Received: from ftp (ftp.kwsoft.de [213.164.67.83]) by mailer.kwsoft.de (Postfix) with ESMTPS id 46A6B1811BF for ; Sun, 23 Aug 2015 20:46:23 +0200 (CEST) Received: from p54986CB5.dip0.t-ipconnect.de (p54986CB5.dip0.t-ipconnect.de [84.152.108.181]) by webmail.kwsoft.de (Horde Framework) with HTTP; Sun, 23 Aug 2015 20:46:23 +0200 Date: Sun, 23 Aug 2015 20:46:23 +0200 From: lst_hoe02@kwsoft.de To: dane@ietf.org Message-ID: <20150823204623.Horde.i2QJGPg9ASEBX9mspfXLZc-@webmail.kwsoft.de> In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-1; boundary="----=_Part_881_1151073186.1440355583852" User-Agent: Horde Application Framework 5 Archived-At: Subject: Re: [dane] Delivery of email if MX is not signed X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 23 Aug 2015 18:46:27 -0000 ------=_Part_881_1151073186.1440355583852 Content-Type: text/plain; charset=utf-8; format=flowed; DelSp=Yes Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Zitat von Patrik F=C3=A4ltstr=C3=B6m : > On 23 Aug 2015, at 20:18, Paul Wouters wrote: > >>> Unsigned RRSET contain: >>> >>> example.net. IN MX 0 mail.example.com. >>> >>> Signed (and properly validated) RRSETs that contains these two =20 >>> records and a few more: >>> >>> mail.example.com. IN A 192.168.1.1 >>> _426._tcp.mail.example.om. IN TLSA .... >> >> so anyone can spoof: >> >> example.net. IN MX 0 mail.example.com. > > Yes, just like today. > >> pretending "mail.example.com." does not give you more security. What >> would you do if you saw: >> >> example.net. IN MX 0 evil.nohats.ca >> >> with proper TLSA records for evil.nohats.ca? > > This is what we have today. > > I would deliver over the TLS secured connection. > > The only way to secure that is to DNSSEC sign mail.example.net. > >>> I.e. if only looking at mail.example.com. and =20 >>> _426._tcp.mail.example.com. that is a 100% properly setup DANE =20 >>> "thing". >> >> But nothing in that statement securely tells you anything about exampl= e.net. > > Correct. > >>> I think that behaviour is wrong, and am unsure whether it is a bug =20 >>> in postfix or whether it is a bug in the spec. >> >> That would be a bug in postfix? The spec states: >> >> All >> "insecure" RRSets MUST be handled identically: in either case >> unvalidated data for the query domain is all that is and can be >> available, and authentication using the data is impossible. >> >> It does not state to not deliver email, it just states there is no >> authentication possible, so deliver without dane authentication. > > Ok, I think what I have issues with is that I think "dane =20 > authentication" is not black or white. > > We have at least: > > 1. Signed and validated MX, signed and validated TLSA > > 2. Unsigned MX, signed and validated TLSA > > 3. Unsigned MX, no TLSA, unsigned A/AAAA > > Then we have all of the failed situations, which include: > > 4. Signed, but broken signatures, on MX, signed and validated TLSA > > 5. Signed, but broken signatures, on MX, signed but broken signatures o= n TLSA > > 6. Unsigned MX, signed but broken signatures on TLSA > > Etc > > So if you look at 1, 2 and 3, if I understand you correctly, [2] is =20 > not "DANE authenticated" even if the TLS connection has properly =20 > signed and validated TLSA record? > > This is a bit confusing to me. I.e. the terminology is confusing. To =20 > me, [2] has proper DANE validated TLS available for the SMTP =20 > connection. > > But I completely agree there is an MiM possible for the unsigned MX. =20 > Just like we have today. And why we want DNSSEC deployed. You are https biased i guess. With an unsigned MX your secure chain is =20 broken because the target you try to reach by an E-Mail address is =20 directed to a target by an "unsecure" link. If the unsecure resolved =20 target is then secured doesn't matter because you might be already on =20 the wrong track. Security is only as strong as the weakest point in the chain. Regards Andreas ------=_Part_881_1151073186.1440355583852 Content-Type: application/pkcs7-signature; name=smime.p7s; smime-type=signed-data Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIAwggYnMIIF D6ADAgECAgMLUQowDQYJKoZIhvcNAQELBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFy dENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgw NgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAe Fw0xNDA5MjUxMDA5NTVaFw0xNTA5MjUyMjI2MDBaMEIxHDAaBgNVBAMME2xzdF9ob2UwMkBrd3Nv ZnQuZGUxIjAgBgkqhkiG9w0BCQEWE2xzdF9ob2UwMkBrd3NvZnQuZGUwggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQDA7+a1L8qfgq/e2rtcY2c40Ds/1/jAEho66qHzmc/u7OUkWM7RtJ7q NN00ff/Fua7dnrXUQZ7KyfLXLad5mAgAgcxlgq8TFOy8S36fYJybTdy6jjFnH/Qkb1OOgFNNltt+ 8hVJXG6jVIu2X3d3DCxtfsE/H4HFcwbO+Qf1lvJTaDx4DTHq9xBaVQigE/UQVyQnjCqxUZPlZST/ 49v70MT9f8gwZPdiHB/5Pn/ThqWdINoFkTWvfrs5Mw22LsHURmwjmGeWZXEw5bfrHDdd5AfZBopM KrRyMcm8Y15XIX9c/F+TeOGeXhhByFdsb54ukg/BqgG5YdUAKa9Y2xpMJIk7AgMBAAGjggLZMIIC 1TAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQw HQYDVR0OBBYEFAbLyy+g1nAk+Oy8wEbHvqik9KjFMB8GA1UdIwQYMBaAFFNy7ZKc4NrLAVx8fpY1 TvLUuFGCMB4GA1UdEQQXMBWBE2xzdF9ob2UwMkBrd3NvZnQuZGUwggFMBgNVHSAEggFDMIIBPzCC ATsGCysGAQQBgbU3AQIDMIIBKjAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20v cG9saWN5LnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRo b3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRpbmcgdG8gdGhl IENsYXNzIDEgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGlj eSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4gY29tcGxpYW5jZSBv ZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDov L2NybC5zdGFydHNzbC5jb20vY3J0dTEtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEF BQcwAYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczEvY2xpZW50L2NhMEIGCCsG AQUFBzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MxLmNsaWVudC5j YS5jcnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBCwUA A4IBAQAuCQ1tMkfhoITrQEKC+9WaBwGPy00bElZOY2rz7IzM3PqY5CpUfF3BvkR9wZona1oUSS66 mGtn3zNWlIh/W1tCLa+5WGiH0zV0Xpo02ifPvtuYCaOiubHRsCcATfmnoc10mPXNnDDjqlYgHCS0 HzsNg1zRDP6fX59Tlz0O/TIJzqcmJvaFF6r5HBum3vPvM7TNdOhrRTFioZAsj3oHphxKIO+Ei3d3 E6ChDy58aDxbgNhcJg1n3MdoVOojUtTNtLStbYuVwXMrROwNrpJbOCuDXGdm9ayE/zfrjTGB86i5 sbyvRK7AjI4qp0d97G5vI55rkQO0ujaq061Mw04huTlLMIIF2TCCA8GgAwIBAgIHFmdU48JwUTAN BgkqhkiG9w0BAQsFADB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkG A1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UEAxMgU3RhcnRD b20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNMDcxMDE0MjEwMTU1WhcNMjIxMDE0MjEwMTU1 WjCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3Vy ZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEg UHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEAxwmDzM4t2BqxKaQuE6uWvooyg4ymiEGWVUet1G8SD+rqvyNH4QrvnEIaFHxOhESip7vM z39ScLpNLbL1QpOlPW/tFIzNHS3qd2XRNYG5Sv9RcGE+T4qbLtsjjJbi6sL7Ls/f/X9ftTyhxvxW kf8KW37iKrueKsxw2HqolH7GM6FX5UfNAwAu4ZifkpmZzU1slBhyWwaQPEPPZRsWoTb7q8hmgv6N v3Hg9rmA1/VPBIOQ6SKRkHXG0Hhmq1dOFoAFI411+a/9nWm5rcVjGcIWZ2v/43Yksq60jExipA4l 5uv9/+Hm33mbgmCszdj/Dthf13tgAv2O83hLJ0exTqfrlwIDAQABo4IBTDCCAUgwEgYDVR0TAQH/ BAgwBgEB/wIBADAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFFNy7ZKc4NrLAVx8fpY1TvLUuFGC MB8GA1UdIwQYMBaAFE4L7xqkQFulF2mHMMo0aEPQQa7yMGkGCCsGAQUFBwEBBF0wWzAnBggrBgEF BQcwAYYbaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL2NhMDAGCCsGAQUFBzAChiRodHRwOi8vYWlh LnN0YXJ0c3NsLmNvbS9jZXJ0cy9jYS5jcnQwMgYDVR0fBCswKTAnoCWgI4YhaHR0cDovL2NybC5z dGFydHNzbC5jb20vc2ZzY2EuY3JsMEMGA1UdIAQ8MDowOAYEVR0gADAwMC4GCCsGAQUFBwIBFiJo dHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMA0GCSqGSIb3DQEBCwUAA4ICAQB0Cof6 Mt74mLfqrzMskIaloiG/ZD9SkYalhxhTCA+zgG6H6FIAylVCe1LIgZz5pXhmtqVML39geu6j6nNn vRnvf5AbybVfK0hEt8/vyla8elMJV/Fclp5ETRldDy7wg/t+HCDqoRd045reI6X2Ek45F3DqWuxe ERmW5rtPo9RzuOlwGMqTorIFw911nnKql8xDIpmVaxdw5bDGE2DJhbc0WAHmg4dgcXMyZVeB3gbP IMO3eFElKA1h3JDEeECtMy1VZkNReuoq5bVlrCfQhSlcs/WUwbKYtxQyQk/d130eDqzlBwfiOT9f JU1hww9af/XV+2YfG3cJTkinRH7Cr82sVWWypLl16OxTBtr+i0NiZr+hnOIyfI0so2racvOpZSSU 9kd7SRT0RpXz3GdYHtwHf6lw2SjyOKTfA+bKPPVlDwCe8/WXg6khXRk1msp02WgkTwCAv3t+VbU8 jbiGpvp+p7mmRYHHKQAsOdb5IBVIo+gCsQcquwjYAdWZ/xUV9eamQPW7tmSPEExyU//MzN541wIF egLBTn+vNrdeKrGEgc9I6Xn/JFNKteblfaGUho8taYf9MrEA/t+NjCIdz0JSqetnY93llj9zARe4 LUE2xEV9T5jM30yLMjG46vqb/T+IikTsNPvDDadD1DbYpTBtnyiwUaHMy4me4TC48nnQlzCCB8kw ggWxoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA2MDkxNzE5NDYzNloX DTM2MDkxNzE5NDYzNlowfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzAp BgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0 Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKC AgEAwYjbCbxsRnx4n5V7tTOQ8nJi1sE2ICIkXs7pd/JDCqIGZKTMjjb4OOYj8G5tsTzdcqOFHKHT PbQzK9Mvr/7qsEFZZ7bEBn0KnnSF1nlMgDd63zkFUln39BtGQ6TShYXSw3HzdWI0uiyKfx6P7u00 0BHHls1SPboz1t1N3gs7SkufwiYv+rUWHHI1d8o8XebK4SaLGjZ2XAHbdBQl/u21oIgP3XjKLR8H lzABLXJ5+kbWEyqouaarg0kd5fLv3eQBjhgKj2NTFoViqQ4ZOsy1ZqbCa3QH5Cvhdj60bdj2ROFz Yh87xL6gU1YlbFEJ96qryr92/W2b853bvz1mvAxWqq+YSJU6S9+nWFDZOHWpW+pDDAL/mevobE1w WyllnN2qXcyvATHsDOvSjejqnHvmbvcnZgwaSNduQuM/3iE+e+ENcPtjqqhsGlS0XCV6yaLJixam uyx+F14FTVhuEh0B7hIQDcYyfxj//PT6zW6R6DZJvhpIaYvClk0aErJpF8EKkNb6eSJIv7p7afhw x/p6N9jYDdJ2T1f/kLfjkdLd78Jgt2c63f6qnPDUi39yIs7Gn5e2+K+KoBCo2fsYxra1XFI8ibYZ KnMBCg8DsxJg8novgdujbv8mMJf1i92JV7atPbOvK8W3dgLwpdYrmoYUKnL24zOMXQlLE9+7jHQT UksCAwEAAaOCAlIwggJOMAwGA1UdEwQFMAMBAf8wCwYDVR0PBAQDAgGuMB0GA1UdDgQWBBROC+8a pEBbpRdphzDKNGhD0EGu8jBkBgNVHR8EXTBbMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5v cmcvc2ZzY2EtY3JsLmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydGNvbS5vcmcvc2ZzY2EtY3Js LmNybDCCAV0GA1UdIASCAVQwggFQMIIBTAYLKwYBBAGBtTcBAQEwggE7MC8GCCsGAQUFBwIBFiNo dHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjA1BggrBgEFBQcCARYpaHR0cDovL2Nl cnQuc3RhcnRjb20ub3JnL2ludGVybWVkaWF0ZS5wZGYwgdAGCCsGAQUFBwICMIHDMCcWIFN0YXJ0 IENvbW1lcmNpYWwgKFN0YXJ0Q29tKSBMdGQuMAMCAQEagZdMaW1pdGVkIExpYWJpbGl0eSwgcmVh ZCB0aGUgc2VjdGlvbiAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENvbSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly9jZXJ0LnN0YXJ0Y29t Lm9yZy9wb2xpY3kucGRmMBEGCWCGSAGG+EIBAQQEAwIABzA4BglghkgBhvhCAQ0EKxYpU3RhcnRD b20gRnJlZSBTU0wgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwDQYJKoZIhvcNAQEFBQADggIBABZs mfRmDDT10IVefQrs2hBOOBxe36YlBUuRMsHoO/E93UQJWwdJiinLZgK3sZr3JZgJPI4b4d02hytL u2jTOWY9oCbH8jmRHVGrgnt+1c5a5OIDV3Bplwj5XlimCt+MBppFFhY4Cl5X9mLHegIF5rwetfKe 9Kkpg/iyFONuKIdEw5Aa3jipPKxDTWRFzt0oqVzyc3sE+Bfoq7HzLlxkbnMxOhK4vLMR5H2PgVGa O42J9E2TZns8A+3Tmh2a82VQ9aDQdZ8vr/DqgkOY+GmciXnEQ45GcuNkNhKv9yUeOImQd37Da2q5 w8tES6x4kIvnxyweSxFEyDRSJ80KXZ+FwYnVGnjylRBTMt2AhGZ12bVoKPthLr6EqDjAmRKGpR5n ZK0GLi+pcIXHlg98iWX1jkNUDqvdpYA5lGDANMmWcCyjEvUfSHu9HH5rt52Q9CI7rvj8Ksr6glKg 769LVZPrwbXwIousNE4mIgShhyx1SrflfRPXuAxkwDbSyS+GEowjCcEbgjtzSaNqV4eU5dZ4xZlD Y+NN4Hct4WWZcmkEGkcJ5g8BViT7H78OealYLrnECQF+lbptAAY+supKEDnY0Cv1v+x1v5cCxQkb CNxVN+KB+zeEQ2IgyudWS2Xq/mzBJJMkoTTrBf+aIq6bfT/xZVEKpjBqs/SIHIAN/HKK6INeAAAx ggK9MIICuQIBATCBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzAp BgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMLUQowCQYFKw4DAhoF AKCB/jAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNTA4MjMxODQ2 MjNaMCMGCSqGSIb3DQEJBDEWBBTz/R6aaR6xeiwHTBsx9Xck9Ld5+TCBngYJKoZIhvcNAQkPMYGQ MIGNMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4G CCqGSIb3DQMCAgIAgDAPBgkqhkiG9n0HQgoCAgCAMA0GCyqDCIyaSz0BAQEEMA0GCyqDCIyaSz0B AQEDMA0GCyqDCIyaSz0BAQECMAoGCCqDGoyaRAEEMA0GCSqGSIb3DQEBAQUABIIBADIaAIQnYGQA V79m6+KwCi1puw+hiTjjv9Uj1G5ao76VViy0r9iShwSWlFBtZaxzijF8v0SRdXNPXXDmPxNy+c3c pX1U5bBOxS0XzTB5w0j1WcbWAWj+yDMLJMs5bFBrNWxvbTiQy+vbTBB2MlzvVTK3N85XEexYlR4Z iHSiSgH1hS0CkV9OThKpmgaxRICex4cHmdcjE8yh7GKSVI37eqp11ejQInzUaOgxGUB7An4TkjSC GIG5ZX6TdzVv6K3WGootGffo1D2kYPiusxhs+t+IZRyJCEJ4En920AoT4gyDE6haWCb1nUP3wJXg pATkGfq1dcZf8DnEkI/Zw5PkKPYAAAAAAAA= ------=_Part_881_1151073186.1440355583852-- From nobody Sun Aug 23 11:51: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 D6BC21B2A37 for ; Sun, 23 Aug 2015 11:51:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.661 X-Spam-Level: X-Spam-Status: No, score=-1.661 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AaLqiPxBF0Pi for ; Sun, 23 Aug 2015 11:51:06 -0700 (PDT) Received: from office.denic.de (office.denic.de [81.91.160.182]) (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 E3D881B2A35 for ; Sun, 23 Aug 2015 11:51:05 -0700 (PDT) Received: from office.denic.de (mailout-6.osl.denic.de [10.122.34.32]) by office.denic.de (Postfix) with ESMTP id 8C9911FB7E; Sun, 23 Aug 2015 20:50:58 +0200 (CEST) Received: from x27.adm.denic.de (x28.fra2.if.denic.de [10.122.64.17]) by office.denic.de with esmtps (TLSv1:DHE-RSA-AES256-SHA:256) id 1ZTaM6-00025B-7u; Sun, 23 Aug 2015 20:50:58 +0200 Received: from localhost by x27.adm.denic.de with local id 1ZTaM5-00051a-Uc; Sun, 23 Aug 2015 20:50:57 +0200 Date: Sun, 23 Aug 2015 20:50:57 +0200 From: Peter Koch To: Patrik =?iso-8859-1?B?RuRsdHN0cvZt?= Message-ID: <20150823185057.GJ5112@x28.adm.denic.de> Mail-Followup-To: Patrik =?iso-8859-1?B?RuRsdHN0cvZt?= , dane@ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.4.2.3i Sender: Peter Koch Archived-At: Cc: dane@ietf.org Subject: Re: [dane] Delivery of email if MX is not signed X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 23 Aug 2015 18:51:08 -0000 On Sun, Aug 23, 2015 at 08:30:10PM +0200, Patrik Fältström wrote: > This is a bit confusing to me. I.e. the terminology is confusing. To me, [2] has proper DANE validated TLS available for the SMTP connection. > > But I completely agree there is an MiM possible for the unsigned MX. Just like we have today. And why we want DNSSEC deployed. If we'd only be worried about a passive attacker, we'd not address the spoofed MX RR, but we'd want the SMTP connection encrypted. In that case (passive only), opportunistic (pre DANE) STARTTLS would be sufficient. If we'd worry enough about active attacks, we'd want the endpoint identity verified (thus DANE[1]) as well as its capabilities (thus DANE[2]), and at the same time we'd probably prefer (or even demand) signed/validated MX RRs. Apparently there are multiple potential attackers of different background, motivation, and means. If your enemy is the helpful corporate firewall that intercepts SMTP to 'optimize away' STARTTLS, maybe its next version will 'enhance' MX responses? -Peter From nobody Sun Aug 23 12:07:16 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B1F21B2A51 for ; Sun, 23 Aug 2015 12:07:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.961 X-Spam-Level: X-Spam-Status: No, score=-1.961 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, 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 MYVcnSTYHXYu for ; Sun, 23 Aug 2015 12:07:13 -0700 (PDT) Received: from mail.frobbit.se (mail.frobbit.se [85.30.129.185]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29DEA1B2A38 for ; Sun, 23 Aug 2015 12:07:13 -0700 (PDT) Received: from [192.168.1.12] (frobbit.cust.teleservice.net [85.30.128.225]) by mail.frobbit.se (Postfix) with ESMTPSA id 5C4D620025; Sun, 23 Aug 2015 21:07:11 +0200 (CEST) From: "Patrik =?utf-8?b?RsOkbHRzdHLDtm0=?=" To: "Peter Koch" Date: Sun, 23 Aug 2015 21:07:10 +0200 Message-ID: <0E722F2F-510C-4060-86C2-41190F724DBA@frobbit.se> In-Reply-To: <20150823185057.GJ5112@x28.adm.denic.de> References: <20150823185057.GJ5112@x28.adm.denic.de> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=_MailMate_962F0AF4-B498-4A20-AE5A-2B579DCC209A_="; micalg=pgp-sha1; protocol="application/pgp-signature" X-Mailer: MailMate (1.9.2r5107) Archived-At: Cc: dane@ietf.org Subject: Re: [dane] Delivery of email if MX is not signed X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 23 Aug 2015 19:07:14 -0000 This is an OpenPGP/MIME signed message (RFC 3156 and 4880). --=_MailMate_962F0AF4-B498-4A20-AE5A-2B579DCC209A_= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On 23 Aug 2015, at 20:50, Peter Koch wrote: > If we'd only be worried about a passive attacker, we'd not > address the spoofed MX RR, but we'd want the SMTP connection > encrypted. In that case (passive only), opportunistic (pre DANE) > STARTTLS would be sufficient. > > If we'd worry enough about active attacks, we'd want the endpoint > identity verified (thus DANE[1]) as well as its capabilities > (thus DANE[2]), and at the same time we'd probably prefer (or > even demand) signed/validated MX RRs. > > Apparently there are multiple potential attackers of different backgrou= nd, > motivation, and means. If your enemy is the helpful corporate > firewall that intercepts SMTP to 'optimize away' STARTTLS, maybe > its next version will 'enhance' MX responses? Agree. What I think I see in the draft is that "DANE and SMTP" is either "on" or= "off", and I want more shades of gray. 1. Unsigned MX, Unsigned A/AAAA, not using TLS at all 2. Unsigned MX, Unsigned A/AAAA, TLS used with self-signed cert 3. Unsigned MX, Unsigned A/AAAA, TLS used with cert signed by CA (i.e. tr= usted cert) 4. Unsigned MX, Signed A/AAAA, TLS used with cert signed by CA (i.e. trus= ted cert) 5. Unsigned MX, Signed A/AAAA, TLS used with cert validated with signed T= LSA (i.e. trusted cert) 6. Signed MX, Signed A/AAAA, TLS used with cert validated with signed TLS= A I think 4 and 5 are equivalent, both better than 3 (which is better than = 1, 2 and 3). And of course there are more permutations, specifically with signed MX, b= ut the for me interesting alternatives are the ones above, where MX is un= signed. Patrik --=_MailMate_962F0AF4-B498-4A20-AE5A-2B579DCC209A_= Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlXaGd4ACgkQrMabGguI182cPACglM9oZmifnp7FUgOBocb7dV// GVgAn3hCzBhReQIOPi1HaLVofodad3Jt =bJP5 -----END PGP SIGNATURE----- --=_MailMate_962F0AF4-B498-4A20-AE5A-2B579DCC209A_=-- From nobody Sun Aug 23 12:11:06 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09F5F1B2A5E for ; Sun, 23 Aug 2015 12:11:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.261 X-Spam-Level: X-Spam-Status: No, score=-1.261 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tdr7SkAoZCvv for ; Sun, 23 Aug 2015 12:10:56 -0700 (PDT) Received: from mail.frobbit.se (mail.frobbit.se [IPv6:2a02:80:3ffe::176]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF50F1B2A5D for ; Sun, 23 Aug 2015 12:10:56 -0700 (PDT) Received: from [192.168.1.12] (frobbit.cust.teleservice.net [85.30.128.225]) by mail.frobbit.se (Postfix) with ESMTPSA id 2BE821FDE4; Sun, 23 Aug 2015 21:10:55 +0200 (CEST) From: "Patrik =?utf-8?b?RsOkbHRzdHLDtm0=?=" To: lst_hoe02@kwsoft.de Date: Sun, 23 Aug 2015 21:10:54 +0200 Message-ID: <61FB75B0-F29A-4D70-9977-1546B81FCDFC@frobbit.se> In-Reply-To: <20150823204623.Horde.i2QJGPg9ASEBX9mspfXLZc-@webmail.kwsoft.de> References: <20150823204623.Horde.i2QJGPg9ASEBX9mspfXLZc-@webmail.kwsoft.de> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=_MailMate_0D28460E-C339-47CE-81A5-A545B67715CC_="; micalg=pgp-sha1; protocol="application/pgp-signature" X-Mailer: MailMate (1.9.2r5107) Archived-At: Cc: dane@ietf.org Subject: Re: [dane] Delivery of email if MX is not signed X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 23 Aug 2015 19:11:04 -0000 This is an OpenPGP/MIME signed message (RFC 3156 and 4880). --=_MailMate_0D28460E-C339-47CE-81A5-A545B67715CC_= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On 23 Aug 2015, at 20:46, lst_hoe02@kwsoft.de wrote: > You are https biased i guess. With an unsigned MX your secure chain is = broken because the target you try to reach by an E-Mail address is direct= ed to a target by an "unsecure" link. If the unsecure resolved target is = then secured doesn't matter because you might be already on the wrong tra= ck. > > Security is only as strong as the weakest point in the chain. Agree, but I think the cert for the TLS can be trusted in two ways: Eithe= r by looking at TLSA record or by looking at CA X.509 chain. I think they= are equivalent and both have exactly the same weakness if the MX is unsi= gned. I do not see why one of these two mechanisms should be "invalid" just bec= ause the MX is unsigned. Patrik --=_MailMate_0D28460E-C339-47CE-81A5-A545B67715CC_= Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlXaGr4ACgkQrMabGguI182IIwCghu1kB0lhPK3PgJVg3iUSxX6o MksAnjONPtTYEh2TuEOnncU9LL1BfK74 =mDLl -----END PGP SIGNATURE----- --=_MailMate_0D28460E-C339-47CE-81A5-A545B67715CC_=-- From nobody Sun Aug 23 12:34:03 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 939EF1B2A89 for ; Sun, 23 Aug 2015 12:34:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.71 X-Spam-Level: X-Spam-Status: No, score=-1.71 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Du-r73Xn0vEu for ; Sun, 23 Aug 2015 12:34:00 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17A961B2A88 for ; Sun, 23 Aug 2015 12:34:00 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3mzmwj4XlDz1bq; Sun, 23 Aug 2015 21:33:57 +0200 (CEST) Authentication-Results: mx.nohats.ca; dkim=pass (1024-bit key) header.d=nohats.ca header.i=@nohats.ca header.b=eRyYCo2i X-OPENPGPKEY: Message passed unmodified X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id N08KqYNZJMFG; Sun, 23 Aug 2015 21:33:55 +0200 (CEST) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Sun, 23 Aug 2015 21:33:55 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 933078009C; Sun, 23 Aug 2015 15:33:54 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1440358434; bh=xxIe8IrpV4RDas12IDVZCZKkffUj7m140VdG35pn/sQ=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=eRyYCo2ibTPlfWLn6O+DEzrssR6tbujlBCabsuslytidrDeZg/glA8HKKaX440pjP wfsCe4iCftGPgB5CDehawgcGehgtD9LduMHWLe7JinyROQkbu5PpF/aVwwSzNnaROw 6w74TeGgBksPZcrwsZREyFVHCtjztUN9ehBnIFXc= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.15.2/8.15.2/Submit) with ESMTP id t7NJXro7008452; Sun, 23 Aug 2015 15:33:54 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Sun, 23 Aug 2015 15:33:53 -0400 (EDT) From: Paul Wouters To: =?ISO-8859-15?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: <0E722F2F-510C-4060-86C2-41190F724DBA@frobbit.se> Message-ID: References: <20150823185057.GJ5112@x28.adm.denic.de> <0E722F2F-510C-4060-86C2-41190F724DBA@frobbit.se> User-Agent: Alpine 2.20 (LFD 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=ISO-8859-15 Content-Transfer-Encoding: 8BIT Archived-At: Cc: dane WG list Subject: Re: [dane] Delivery of email if MX is not signed X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 23 Aug 2015 19:34:01 -0000 On Sun, 23 Aug 2015, Patrik Fältström wrote: > What I think I see in the draft is that "DANE and SMTP" is either "on" or "off", and I want more shades of gray. Well yes. Because you either authenticate or fail to authenticate and refuse to deliver. We cannot decide whether or not to deliver in shades of grey. So we have: - unsigned domain -> deliver without authentication, allow any TLS credential - signed domain with unsined mx target -> deliver without authentication, allow any TLS credential - signed domain with signed mx target -> deliver only if authentication succeeded. You seem to want something like: - unsigned domain with signed mx target -> deliver if authentication succeeds - despite possible spoofed MX record What is the result of the last one? "Verified TLS to potential rogue server" ? I don't think we would call that verified. Paul From nobody Sun Aug 23 16:09: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 E84361B2C45 for ; Sun, 23 Aug 2015 16:09:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v4CqoIM5VZWY for ; Sun, 23 Aug 2015 16:09:18 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 372EB1B2C44 for ; Sun, 23 Aug 2015 16:09:17 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 91DD9284DA0; Sun, 23 Aug 2015 23:09:16 +0000 (UTC) Date: Sun, 23 Aug 2015 23:09:16 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20150823230916.GB9021@mournblade.imrryr.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [dane] Delivery of email if MX is not signed X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Aug 2015 23:09:20 -0000 On Sun, Aug 23, 2015 at 02:18:39PM -0400, Paul Wouters wrote: > >mail.example.com. IN A 192.168.1.1 > >_426._tcp.mail.example.om. IN TLSA .... _25._tcp for SMTP, no idea where _426 is from. > >What seems to have happened in the tests that Jan did was that IF the MX > > was not signed, BUT the TLSA was signed and validated correctly, THEN > > postfix did _NOT_ deliver the email. At all. The tests were badly executed or profoundly misinterpreted. > >I think that behaviour is wrong, and am unsure whether it is a bug in > > postfix or whether it is a bug in the spec. Neither. > > That would be a bug in postfix? The spec states: Would be, but is not, because Postfix does not behave as claimed. -- Viktor. From nobody Sun Aug 23 16:17:29 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE4861B2C4E for ; Sun, 23 Aug 2015 16:17:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eU8qG4pPU0Vn for ; Sun, 23 Aug 2015 16:17:27 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B32D1B2C4D for ; Sun, 23 Aug 2015 16:17:27 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id E90FC284DA0; Sun, 23 Aug 2015 23:17:26 +0000 (UTC) Date: Sun, 23 Aug 2015 23:17:26 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20150823231726.GC9021@mournblade.imrryr.org> References: <20150823185057.GJ5112@x28.adm.denic.de> <0E722F2F-510C-4060-86C2-41190F724DBA@frobbit.se> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0E722F2F-510C-4060-86C2-41190F724DBA@frobbit.se> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [dane] Delivery of email if MX is not signed X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Aug 2015 23:17:29 -0000 On Sun, Aug 23, 2015 at 09:07:10PM +0200, Patrik F?ltstr?m wrote: > What I think I see in the draft is that "DANE and SMTP" is either "on" or "off", and I want more shades of gray. > > 1. Unsigned MX, Unsigned A/AAAA, not using TLS at all No, this correctly uses opportunistic *unauthenticated* TLS, and the certificate is irrelevant. > 4. Unsigned MX, Signed A/AAAA, TLS used with cert signed by CA (i.e. trusted cert) This is useless, without per-destination static configuration. > 5. Unsigned MX, Signed A/AAAA, TLS used with cert validated with signed TLSA (i.e. trusted cert) This does not provide adequate MiTM protection, but the draft does not rule out clients that might do this, rather it does not specify use of DANE for this case. If enough users want this, such features could be added to Postfix. The delivery is not immune to active attacks, but arguably somewhat stronger than ignoring such TLSA RRs. The primary use-case would be a provider that is MX hosting lots of domains, many of which are not DNSSEC signed, but the MX hosts are. > 6. Signed MX, Signed A/AAAA, TLS used with cert validated with signed TLSA The draft (soon to be RFC) is about case 6. -- Viktor. From nobody Sun Aug 23 19:51: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 996DA1B30A8 for ; Sun, 23 Aug 2015 19:51:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.261 X-Spam-Level: X-Spam-Status: No, score=-1.261 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o6lGxuxl1vSS for ; Sun, 23 Aug 2015 19:51:22 -0700 (PDT) Received: from mail.frobbit.se (mail.frobbit.se [IPv6:2a02:80:3ffe::176]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E4F11B30A7 for ; Sun, 23 Aug 2015 19:51:22 -0700 (PDT) Received: from [192.168.1.12] (frobbit.cust.teleservice.net [85.30.128.225]) by mail.frobbit.se (Postfix) with ESMTPSA id D35772074C; Mon, 24 Aug 2015 04:51:19 +0200 (CEST) From: "Patrik =?utf-8?b?RsOkbHRzdHLDtm0=?=" To: "Paul Wouters" Date: Mon, 24 Aug 2015 04:51:19 +0200 Message-ID: In-Reply-To: References: <20150823185057.GJ5112@x28.adm.denic.de> <0E722F2F-510C-4060-86C2-41190F724DBA@frobbit.se> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=_MailMate_3A0EDC3E-E5D5-4EFC-91E1-C863C16B3763_="; micalg=pgp-sha1; protocol="application/pgp-signature" X-Mailer: MailMate (1.9.2r5107) Archived-At: Cc: dane WG list Subject: Re: [dane] Delivery of email if MX is not signed X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 24 Aug 2015 02:51:23 -0000 This is an OpenPGP/MIME signed message (RFC 3156 and 4880). --=_MailMate_3A0EDC3E-E5D5-4EFC-91E1-C863C16B3763_= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On 23 Aug 2015, at 21:33, Paul Wouters wrote: > So we have: > > - unsigned domain -> deliver without authentication, allow any TLS cred= ential > - signed domain with unsined mx target -> deliver without authenticatio= n, allow any TLS credential > - signed domain with signed mx target -> deliver only if authentication= succeeded. > > You seem to want something like: > > - unsigned domain with signed mx target -> deliver if authentication > succeeds - despite possible spoofed MX record I more and more think I understand what I am asking for and what I want. My apologies if what I now write seems to be different from what I wrote = earlier. I want the validation of the cert used for the TLS connection to use the = same rules for trust regardless of whether DANE is used (i.e. signed and = properly validated TLSA record for the peer) or if X.509 cert/PKI from so= me CA is in use. What I read in the draft, and what I read in the paper Jan wrote after te= sting Postfix and what I read here in the responses I get is that DANE is= trusted LESS than X.509 certs. And I think that is wrong. I.e. we have two cases: 1. X.509 1.1 Unsigned MX 1.2 cert validated from some CA that is trusted 2. DANE 2.1 Unsigned MX 2.2 cert validated via signed TLSA with DNSSEC chain of trust to some TA I think they should be equivalent. If they are, also in the implementation in postfix, then just tell me and= I'll shut up. Patrik --=_MailMate_3A0EDC3E-E5D5-4EFC-91E1-C863C16B3763_= Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlXahqcACgkQrMabGguI181oeQCePg8MRFUrPiwTT5IjBV3TAUxY Ad8AoIBagYyLL9G0CTCvlJ78lK6oVh/q =v/Uj -----END PGP SIGNATURE----- --=_MailMate_3A0EDC3E-E5D5-4EFC-91E1-C863C16B3763_=-- From nobody Sun Aug 23 19:53:57 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC8F71A004B for ; Sun, 23 Aug 2015 19:53:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.961 X-Spam-Level: X-Spam-Status: No, score=-1.961 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, 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 U8NEnTH50KjX for ; Sun, 23 Aug 2015 19:53:54 -0700 (PDT) Received: from mail.frobbit.se (mail.frobbit.se [85.30.129.185]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A53F1A002C for ; Sun, 23 Aug 2015 19:53:54 -0700 (PDT) Received: from [192.168.1.12] (frobbit.cust.teleservice.net [85.30.128.225]) by mail.frobbit.se (Postfix) with ESMTPSA id BAF56206BD for ; Mon, 24 Aug 2015 04:53:52 +0200 (CEST) From: "Patrik =?utf-8?b?RsOkbHRzdHLDtm0=?=" To: dane@ietf.org Date: Mon, 24 Aug 2015 04:53:52 +0200 Message-ID: <63F22325-1D0B-4801-B7B7-712A96E701F3@frobbit.se> In-Reply-To: <20150823230916.GB9021@mournblade.imrryr.org> References: <20150823230916.GB9021@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=_MailMate_5B508FA7-6844-4E6A-8E9B-F8B5A87B9FAC_="; micalg=pgp-sha1; protocol="application/pgp-signature" X-Mailer: MailMate (1.9.2r5107) Archived-At: Subject: Re: [dane] Delivery of email if MX is not signed X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 24 Aug 2015 02:53:56 -0000 This is an OpenPGP/MIME signed message (RFC 3156 and 4880). --=_MailMate_5B508FA7-6844-4E6A-8E9B-F8B5A87B9FAC_= Content-Type: text/plain On 24 Aug 2015, at 1:09, Viktor Dukhovni wrote: > On Sun, Aug 23, 2015 at 02:18:39PM -0400, Paul Wouters wrote: > >>> mail.example.com. IN A 192.168.1.1 >>> _426._tcp.mail.example.om. IN TLSA .... > > _25._tcp for SMTP, no idea where _426 is from. Sorry, 465. But we could as well use 25 in the example. >>> What seems to have happened in the tests that Jan did was that IF the MX >>> was not signed, BUT the TLSA was signed and validated correctly, THEN >>> postfix did _NOT_ deliver the email. At all. > > The tests were badly executed or profoundly misinterpreted. > >>> I think that behaviour is wrong, and am unsure whether it is a bug in >>> postfix or whether it is a bug in the spec. > > Neither. > >>> That would be a bug in postfix? The spec states: > > Would be, but is not, because Postfix does not behave as claimed. Ok, thanks!!! paf --=_MailMate_5B508FA7-6844-4E6A-8E9B-F8B5A87B9FAC_= Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlXah0AACgkQrMabGguI182BZgCeKcG4yLEjwSPB7h+JRh/PL9wO gYkAn1UQUJo+/BInFR4THlV9J20I2T1Q =RD5P -----END PGP SIGNATURE----- --=_MailMate_5B508FA7-6844-4E6A-8E9B-F8B5A87B9FAC_=-- From nobody Sun Aug 23 19:57: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 B87171A00E4 for ; Sun, 23 Aug 2015 19:57:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.961 X-Spam-Level: X-Spam-Status: No, score=-1.961 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, 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 wOqZB2MFF594 for ; Sun, 23 Aug 2015 19:57:09 -0700 (PDT) Received: from mail.frobbit.se (mail.frobbit.se [85.30.129.185]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A8CE1A00E2 for ; Sun, 23 Aug 2015 19:57:09 -0700 (PDT) Received: from [192.168.1.12] (frobbit.cust.teleservice.net [85.30.128.225]) by mail.frobbit.se (Postfix) with ESMTPSA id 09C9822733 for ; Mon, 24 Aug 2015 04:57:08 +0200 (CEST) From: "Patrik =?utf-8?b?RsOkbHRzdHLDtm0=?=" To: dane@ietf.org Date: Mon, 24 Aug 2015 04:57:07 +0200 Message-ID: <713F9852-A7C3-440B-AC9C-75417A79C9FE@frobbit.se> In-Reply-To: <20150823231726.GC9021@mournblade.imrryr.org> References: <20150823185057.GJ5112@x28.adm.denic.de> <0E722F2F-510C-4060-86C2-41190F724DBA@frobbit.se> <20150823231726.GC9021@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=_MailMate_D1F0E1B5-24E3-47FF-9E06-6C4CC0088DF3_="; micalg=pgp-sha1; protocol="application/pgp-signature" X-Mailer: MailMate (1.9.2r5107) Archived-At: Subject: Re: [dane] Delivery of email if MX is not signed X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 24 Aug 2015 02:57:10 -0000 This is an OpenPGP/MIME signed message (RFC 3156 and 4880). --=_MailMate_D1F0E1B5-24E3-47FF-9E06-6C4CC0088DF3_= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On 24 Aug 2015, at 1:17, Viktor Dukhovni wrote: > 5. Unsigned MX, Signed A/AAAA, TLS used with cert validated with signed= TLSA (i.e. trusted cert) > > > This does not provide adequate MiTM protection, but the draft does > not rule out clients that might do this, rather it does not specify > use of DANE for this case. Good, then I am not crazy! :-) > If enough users want this, such features > could be added to Postfix. The delivery is not immune to active > attacks, but arguably somewhat stronger than ignoring such TLSA > RRs. > > The primary use-case would be a provider that is MX hosting lots > of domains, many of which are not DNSSEC signed, but the MX hosts > are. Exactly. I think it is important to be able to tell people they SHOULD ABSOLUTELY = get DANE for their port 25/465 incoming SMTP servers, regardless of wheth= er they have X.509 certs for them or not. When hosting providers have TLS= A records, then it is only up to the domain holder in such hosting enviro= nments to sign their zone to get complete protection. I think it would be unfortunate if we end up in a catch 22 here as well r= egarding DNSSEC deployment. Patrik --=_MailMate_D1F0E1B5-24E3-47FF-9E06-6C4CC0088DF3_= Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlXaiAMACgkQrMabGguI180t3gCff5jxNfNseR5fJqXXe4awZ8q/ QC4An0LsyKtwmvPJS0hpU5C2bj97Foym =CE8I -----END PGP SIGNATURE----- --=_MailMate_D1F0E1B5-24E3-47FF-9E06-6C4CC0088DF3_=-- From nobody Sun Aug 23 20:00:19 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BC0E1A0103 for ; Sun, 23 Aug 2015 20:00:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KDXfXrreacrm for ; Sun, 23 Aug 2015 20:00:16 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30DA61A0102 for ; Sun, 23 Aug 2015 20:00:16 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 5B281284DA0; Mon, 24 Aug 2015 03:00:15 +0000 (UTC) Date: Mon, 24 Aug 2015 03:00:15 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20150824030015.GD9021@mournblade.imrryr.org> References: <20150823185057.GJ5112@x28.adm.denic.de> <0E722F2F-510C-4060-86C2-41190F724DBA@frobbit.se> 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] Delivery of email if MX is not signed X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Aug 2015 03:00:17 -0000 On Mon, Aug 24, 2015 at 04:51:19AM +0200, Patrik F?ltstr?m wrote: > I want the validation of the cert used for the TLS connection to use the > same rules for trust regardless of whether DANE is used (i.e. signed and > properly validated TLSA record for the peer) or if X.509 cert/PKI from > some CA is in use. What rules would that be? Without DANE or local configuration, SMTP does no authentication of the peer, for reasons explained in Section 1.3 of the draft, that we don't need to repeat. > What I read in the draft, and what I read in the paper Jan wrote after > testing Postfix and what I read here in the responses I get is that DANE > is trusted LESS than X.509 certs. This is a misapprehesion on your part. > 1. X.509 > > 1.1 Unsigned MX > 1.2 cert validated from some CA that is trusted No. Non-DANE SMTP does unauthenticated TLS, and the cert is ignored, whether its trust chain verifies or not. > 2. DANE > > 2.1 Unsigned MX > 2.2 cert validated via signed TLSA with DNSSEC chain of trust to some TA In both cases no authentication is performed. > I think they should be equivalent. They are equivalent, you get no protection from active attacks. > If they are, also in the implementation in postfix, then just tell me and I'll shut up. With "smtp_tls_security_level = dane", the two cases are treated identically, neither authenticate the peer, and both deliver the mail regardless of the content of the peer certificate if any. -- Viktor. From nobody Sun Aug 23 20:06: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 181391A01AA for ; Sun, 23 Aug 2015 20:06:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yOJo5A84Ltvx for ; Sun, 23 Aug 2015 20:06:05 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A64DB1A017D for ; Sun, 23 Aug 2015 20:06:05 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id D5212284DA0; Mon, 24 Aug 2015 03:06:04 +0000 (UTC) Date: Mon, 24 Aug 2015 03:06:04 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20150824030604.GE9021@mournblade.imrryr.org> References: <20150823185057.GJ5112@x28.adm.denic.de> <0E722F2F-510C-4060-86C2-41190F724DBA@frobbit.se> <20150823231726.GC9021@mournblade.imrryr.org> <713F9852-A7C3-440B-AC9C-75417A79C9FE@frobbit.se> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <713F9852-A7C3-440B-AC9C-75417A79C9FE@frobbit.se> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [dane] Delivery of email if MX is not signed X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Aug 2015 03:06:07 -0000 On Mon, Aug 24, 2015 at 04:57:07AM +0200, Patrik F?ltstr?m wrote: > > This does not provide adequate MiTM protection, but the draft does > > not rule out clients that might do this, rather it does not specify > > use of DANE for this case. > > Good, then I am not crazy! :-) Don't jump to hasty conclusions. :-) > > The primary use-case would be a provider that is MX hosting lots > > of domains, many of which are not DNSSEC signed, but the MX hosts > > are. > > Exactly. It is not clear this is worthwhile, and the security properties are rather questionable. This might get implemented anyway, as an optional mitigation against MiTM where for some reason the MiTM chooses to not modify unsigned DNS. The only visible sign of this working would be deferred mail when verification of the MX host fails. There should be no claim of security in the success case. > I think it is important to be able to tell people they SHOULD ABSOLUTELY > get DANE for their port 25/465 incoming SMTP servers, regardless of whether > they have X.509 certs for them or not. When hosting providers have TLSA > records, then it is only up to the domain holder in such hosting > environments to sign their zone to get complete protection. > > I think it would be unfortunate if we end up in a catch 22 here as well > regarding DNSSEC deployment. There is no catch-22. For secure SMTP, sign your domain, and if hosted by a provider, choose one that signs the provider domain and publishes TLSA RRs. -- Viktor. From nobody Sun Aug 23 20:19:29 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 691C41A6F03 for ; Sun, 23 Aug 2015 20:19:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_14=0.6, J_CHICKENPOX_15=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 FUYsJxO-ALvQ for ; Sun, 23 Aug 2015 20:19:27 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 410DA1A6F1D for ; Sun, 23 Aug 2015 20:19:27 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 90D64284D64; Mon, 24 Aug 2015 03:19:26 +0000 (UTC) Date: Mon, 24 Aug 2015 03:19:26 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20150824031926.GF9021@mournblade.imrryr.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [dane] DANE for MX host via insecure MX RR? (was: Delivery of email if MX is not signed) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Aug 2015 03:19:28 -0000 On Sun, Aug 23, 2015 at 07:29:50PM +0200, Patrik F?ltstr?m wrote: > If not, we will get absolutely zero deployment of DANE with SMTP as we > will never get 100% DNSSEC deployment. We already have non-zero deployment, in fact ~2000 domains now, and soon gmx.de and web.de as announced last week. I think this thread needs to end, or else needs a more relevant (to this WG) reboot. If you want to propose an update that requires SMTP clients to employ DANE TLSA verification of MX hosts in signed zones even when the MX RRset was not "secure", read the previous discussion of this question in the list archives (yes, it has come up before) and make a clear-cut proposal with as solid a rationale as you can. I am not sure this can get enough support to reach "rough consensus", but I'm open to the possibility. If we don't misrepresent the resulting security, it may be an acceptable deterrent to downgrade attacks against the MX host when for some reason the attack is unable or reluctant to tamper with DNS. I'll survey the larger providers on this question at M3AAWG in Atlanta in October. In the mean-time we're making progress on deploying DANE for SMTP as specified in the draft (upcoming RFC). -- Viktor. From nobody Sun Aug 23 20:22:13 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70A821A700B for ; Sun, 23 Aug 2015 20:22:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l6OEOiuxbwKM for ; Sun, 23 Aug 2015 20:22:10 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA2E71A700A for ; Sun, 23 Aug 2015 20:22:10 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3mzzJx0CgSzpK for ; Mon, 24 Aug 2015 05:22:09 +0200 (CEST) Authentication-Results: mx.nohats.ca; dkim=pass (1024-bit key) header.d=nohats.ca header.i=@nohats.ca header.b=HAgaxtA4 X-OPENPGPKEY: Message passed unmodified X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id KkdBdElQnjlz for ; Mon, 24 Aug 2015 05:22:07 +0200 (CEST) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS for ; Mon, 24 Aug 2015 05:22:06 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 56C7A800A0 for ; Sun, 23 Aug 2015 23:22:05 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1440386525; bh=7Jgnzxy7zb+aK4KhBOQeGpEy1w5sFbCbWKwtU+FKvVo=; h=Date:From:To:Subject:In-Reply-To:References; b=HAgaxtA4BDQ6kcs2xm18VFS51akkG+WzzWBfVISjh9I8lPk8fm+/0lGhloZTP8q0I 7aJjMnjwiDKW/mGxBOvQdeExrMbzTIJDlFKmxSC5P++byaiPbuSaxN/GlvFOhSjuGj aEiAVE+MsnZWMv/YLNKnpiBqPoi3gjuHzOJ8Qico= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.15.2/8.15.2/Submit) with ESMTP id t7O3M4Ux018123 for ; Sun, 23 Aug 2015 23:22:05 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Sun, 23 Aug 2015 23:22:04 -0400 (EDT) From: Paul Wouters To: dane WG list In-Reply-To: <20150824030015.GD9021@mournblade.imrryr.org> Message-ID: References: <20150823185057.GJ5112@x28.adm.denic.de> <0E722F2F-510C-4060-86C2-41190F724DBA@frobbit.se> <20150824030015.GD9021@mournblade.imrryr.org> User-Agent: Alpine 2.20 (LFD 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII Archived-At: Subject: Re: [dane] Delivery of email if MX is not signed X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 24 Aug 2015 03:22:12 -0000 On Mon, 24 Aug 2015, Viktor Dukhovni wrote: >> I want the validation of the cert used for the TLS connection to use the >> same rules for trust regardless of whether DANE is used (i.e. signed and >> properly validated TLSA record for the peer) or if X.509 cert/PKI from >> some CA is in use. > > What rules would that be? Without DANE or local configuration, > SMTP does no authentication of the peer, for reasons explained in > Section 1.3 of the draft, that we don't need to repeat. Exactly. >> 1.1 Unsigned MX >> 1.2 cert validated from some CA that is trusted > > No. Non-DANE SMTP does unauthenticated TLS, and the cert is ignored, > whether its trust chain verifies or not. I think what Patrik is asking for is that if the target mx hostname is signed and has a TLSA record, why not validate that and do not use it for mail delivery if the TLSA record fails? The logs would still NOT say that the mail was delivered seucrely, because it was not as the MX record itself was not secure. I can't see a reason why not to do that, although I can also see why implementations wouldn't care about this case and just skip all certificate validation. Paul From nobody Sun Aug 23 23:22: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 8FA201B30F1 for ; Sun, 23 Aug 2015 23:22:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.661 X-Spam-Level: X-Spam-Status: No, score=-0.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, J_CHICKENPOX_15=0.6, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XkGeBt9qc6iu for ; Sun, 23 Aug 2015 23:22:31 -0700 (PDT) Received: from mail.frobbit.se (mail.frobbit.se [IPv6:2a02:80:3ffe::176]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91B061B30DA for ; Sun, 23 Aug 2015 23:22:31 -0700 (PDT) Received: from [172.20.10.3] (dyn-fg143.sth.netnod.se [77.72.226.143]) by mail.frobbit.se (Postfix) with ESMTPSA id BBD392074C for ; Mon, 24 Aug 2015 08:22:28 +0200 (CEST) From: "Patrik =?utf-8?b?RsOkbHRzdHLDtm0=?=" To: dane@ietf.org Date: Mon, 24 Aug 2015 08:22:27 +0200 Message-ID: In-Reply-To: <20150824030015.GD9021@mournblade.imrryr.org> References: <20150823185057.GJ5112@x28.adm.denic.de> <0E722F2F-510C-4060-86C2-41190F724DBA@frobbit.se> <20150824030015.GD9021@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=_MailMate_93F697EE-F4AE-473B-BEBB-A321E7F5B5AB_="; micalg=pgp-sha1; protocol="application/pgp-signature" X-Mailer: MailMate (1.9.2r5107) Archived-At: Subject: Re: [dane] Delivery of email if MX is not signed X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 24 Aug 2015 06:22:32 -0000 This is an OpenPGP/MIME signed message (RFC 3156 and 4880). --=_MailMate_93F697EE-F4AE-473B-BEBB-A321E7F5B5AB_= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On 24 Aug 2015, at 5:00, Viktor Dukhovni wrote: > On Mon, Aug 24, 2015 at 04:51:19AM +0200, Patrik F?ltstr?m wrote: > >> What I read in the draft, and what I read in the paper Jan wrote after= >> testing Postfix and what I read here in the responses I get is that DA= NE >> is trusted LESS than X.509 certs. > > This is a misapprehesion on your part. Thank you! >> 1. X.509 >> >> 1.1 Unsigned MX >> 1.2 cert validated from some CA that is trusted > > No. Non-DANE SMTP does unauthenticated TLS, and the cert is ignored, w= hether its trust chain verifies or not. > >> 2. DANE >> >> 2.1 Unsigned MX >> 2.2 cert validated via signed TLSA with DNSSEC chain of trust to some = TA > > In both cases no authentication is performed. > >> I think they should be equivalent. > > They are equivalent, you get no protection from active attacks. Thanks! >> If they are, also in the implementation in postfix, then just tell me = and I'll shut up. > > With "smtp_tls_security_level =3D dane", the two cases are treated iden= tically, neither authenticate the peer, and both deliver the mail regardl= ess of the content of the peer certificate if any. Excellent! That was what I was hoping. Then I misunderstood the tests Jan did. Patrik --=_MailMate_93F697EE-F4AE-473B-BEBB-A321E7F5B5AB_= Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlXauCMACgkQrMabGguI183LRwCeJGV4aLUFZHf5ASBoQ3Hl7gLC 6r4AnjrJoPnw5PCbizBdprSMfIs927g7 =stU9 -----END PGP SIGNATURE----- --=_MailMate_93F697EE-F4AE-473B-BEBB-A321E7F5B5AB_=-- From nobody Mon Aug 24 09:05: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 BE4FB1A87B3 for ; Mon, 24 Aug 2015 09:05:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hovItBGkUd25 for ; Mon, 24 Aug 2015 09:05:37 -0700 (PDT) Received: from mail-oi0-f49.google.com (mail-oi0-f49.google.com [209.85.218.49]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F7631A8868 for ; Mon, 24 Aug 2015 09:05:37 -0700 (PDT) Received: by oiey141 with SMTP id y141so83110132oie.1 for ; Mon, 24 Aug 2015 09:05:37 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=9O8mKIsQsDsRScN/1c/2HJBA/vCIPIn0OS/qM5vp6l0=; b=Kb47F1c3svaM9QmeVUlcrXonX7xXiSTUSvRZZKbcNf8zH9+oKd7BDiI7braPss9dM5 gXw47fEsAT9NCOiR0f9RHdmPQTiByF+ugdxMDsdZzffrHqph6f13yWJjl6A5s8MZHmjC X8wtaZD6iWu2L057g+wNNHhmpDXuKMoFg/MIsYsQgCiH1Q9rRgbpHOSD84HJ4SL15H7J jYyRCIEkE0Zvld/EF4A3kx+GRJXwEOCSjRo3Z8YfsQV7FM9r/LTvPlvqFxuqtA7rvuyw f1aG35n1opk7z+Adwx1DCNvCf1KWY+YDP7lsHOA3fGndTcDMuwxOl/fJnzsQcvHZle8h 6ZvA== X-Gm-Message-State: ALoCoQnGsWCdCyzhJxg1/3N+T4qJQsmngLXfqQ61Uj+5RtH/n9Pgkn9N/ha4lCA9TCz3k28M9bPO MIME-Version: 1.0 X-Received: by 10.202.195.71 with SMTP id t68mr20419319oif.117.1440432336865; Mon, 24 Aug 2015 09:05:36 -0700 (PDT) Received: by 10.202.174.144 with HTTP; Mon, 24 Aug 2015 09:05:36 -0700 (PDT) Date: Mon, 24 Aug 2015 12:05:36 -0400 Message-ID: From: Warren Kumari To: "" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [dane] Not meeting in Yokohama. X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 24 Aug 2015 16:05:38 -0000 Hi all, DANE is planning on not meeting in Yokohama. Olafur has a conflict at that time, and I don't think that we have anything sufficiently pressing that we cannot handle on-list. W -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf From nobody Tue Aug 25 06:59: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 029281B3200 for ; Tue, 25 Aug 2015 06:59:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.261 X-Spam-Level: X-Spam-Status: No, score=-1.261 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XOxHh_fizwWU for ; Tue, 25 Aug 2015 06:59:13 -0700 (PDT) Received: from mout01.posteo.de (mout01.posteo.de [185.67.36.65]) (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 E2C551B307A for ; Tue, 25 Aug 2015 06:59:09 -0700 (PDT) Received: from dovecot03.posteo.de (dovecot03.posteo.de [172.16.0.13]) by mout01.posteo.de (Postfix) with ESMTPS id D94242085A for ; Tue, 25 Aug 2015 15:59:06 +0200 (CEST) Received: from mail.posteo.de (localhost [127.0.0.1]) by dovecot03.posteo.de (Postfix) with ESMTPSA id 3n0sPQ0vCpz5vN5 for ; Tue, 25 Aug 2015 15:59:05 +0200 (CEST) Message-ID: <55DC74A3.6060206@posteo.de> Date: Tue, 25 Aug 2015 15:58:59 +0200 From: =?windows-1252?Q?Patrik_L=F6hr?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: dane@ietf.org References: <55D857EA.80107@strotmann.de> <8321AB9D-ADCD-44BD-8A0F-1D6B5CF1971C@ogud.com> In-Reply-To: <8321AB9D-ADCD-44BD-8A0F-1D6B5CF1971C@ogud.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms080507000203090300070600" Archived-At: Subject: Re: [dane] DNS-Record type for SMIMEA X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 25 Aug 2015 13:59:27 -0000 This is a cryptographically signed message in MIME format. --------------ms080507000203090300070600 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Olafur and Carsten, it would be very useful for the tests to have the DNS record type number. Just for clarification: Did anyone request it? Thanks and best regards Patrik Am 22.08.2015 um 15:47 schrieb Olafur Gudmundsson: > Such a request has not been submitted, but it is good idea to do it.=20 > Olafur (as chair)=20 >=20 >=20 >> On Aug 22, 2015, at 7:07 AM, Carsten Strotmann = wrote: >> >> Hi, >> >> I remember there was a brief discussion during the DANE WG session @ >> IETF 93 about requesting a DNS record type number for SMIMEA from IANA= , >> but I don't remember if there was a conclusion or an action decided. I= >> cannot find it mentioned in the minutes. >> >> Does anyone know the status of this? >> >> Testing of SMIMEA will be be done with "normal but security >> enthusiastic" users, it would be good to have a "well known" DNS recor= d >> type number for SMIMEA instead of a private type number for these test= s. >> >> Best regards >> >> Carsten >> >> _______________________________________________ >> dane mailing list >> dane@ietf.org >> https://www.ietf.org/mailman/listinfo/dane >=20 > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane >=20 --=20 Patrik L=F6hr Posteo e.K. Methfesselstr. 38 10965 Berlin tel. +49 30 85074618 mail web USt-IdNr.: DE186713958 Handelsregister: Berlin-Charlottenburg =B7 HRA 47592 B --------------ms080507000203090300070600 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMbDCC BjAwggUYoAMCAQICAw2zGTANBgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRl IFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlh dGUgQ2xpZW50IENBMB4XDTE1MDQxNDEzNDUzNFoXDTE2MDQxNDEzMjcwNVowSDEfMB0GA1UE AwwWcGF0cmlrLmxvZWhyQHBvc3Rlby5kZTElMCMGCSqGSIb3DQEJARYWcGF0cmlrLmxvZWhy QHBvc3Rlby5kZTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL4AsH4F/E5sb3xc 7+8rPfCcBHjuZk5LHc3JBJ48t2wgdIRliSkiK1VtIp5SHTMDBGKy7O6z1JQiB9mmJkQ2F6/T 62SsisSHctrCybHSufP8c4Vlr2vJScJIqzLVdg/WHo+UosmCwaZ8XCeLFr8g/lhNlZ5BKcb+ OUFYSeEfcb0AZc/gIhrQ6nnDARQVWpj3S2SXeGutkrrifjU1niqViMUxbE8TNitg2R3XoFJc a4e8rLACP0m6UoJ1JelHiaKdCYOCk+w8GGRrDTXecF1RzCU/9CIvdMzpurxSN6zfSvUg58dE xGv+4hFxydbR0+GN8+KWshFFumTa0xCIVfYzKskCAwEAAaOCAtwwggLYMAkGA1UdEwQCMAAw CwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQU TvYppnwFOAQKigRZCBsApLfBzTAwHwYDVR0jBBgwFoAUU3Ltkpzg2ssBXHx+ljVO8tS4UYIw IQYDVR0RBBowGIEWcGF0cmlrLmxvZWhyQHBvc3Rlby5kZTCCAUwGA1UdIASCAUMwggE/MIIB OwYLKwYBBAGBtTcBAgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNv bS9wb2xpY3kucGRmMIH3BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9u IEF1dGhvcml0eTADAgEBGoG+VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGlu ZyB0byB0aGUgQ2xhc3MgMSBWYWxpZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRD b20gQ0EgcG9saWN5LCByZWxpYW5jZSBvbmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBp biBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5nIHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8E LzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1MS1jcmwuY3JsMIGOBggr BgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5zdGFydHNzbC5jb20vc3Vi L2NsYXNzMS9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly9haWEuc3RhcnRzc2wuY29t L2NlcnRzL3N1Yi5jbGFzczEuY2xpZW50LmNhLmNydDAjBgNVHRIEHDAahhhodHRwOi8vd3d3 LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBAJnKy35YtxD0cETG0zygXYrCFQTX zjOgEPPunCIJw9O3BAgYS4z7NGdpJv2U1hru38QTdV8gtTv/BVwkyfnWQbCgopkVYvQ4hE94 3G9QIDtEffB9FhXj93BECa7Avqz+jvt1BAHG4IobsBfpJyOKtLFFQfJx7zM5QRWxnudIZVbj mKGlB6UfOOcglcfQyF28/JI4SY8qafWVxqGoL17rzuoqWq89dxWxljaCeUpLL9jp7txUMyJ1 9f8LTU+N27vAw1DShxljz4pIiH9wKzAEisZcFA5ocWvZVXxCKTKXAu7Vgyv07OtcUrhJaAmn 0feBFoyoDofwq7JKx2XDCkgjEPEwggY0MIIEHKADAgECAgEeMA0GCSqGSIb3DQEBBQUAMH0x CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUg RGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAxNTVaFw0xNzEwMjQyMTAxNTVaMIGMMQsw CQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERp Z2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQ cmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDHCYPMzi3YGrEppC4Tq5a+ijKDjKaIQZZVR63UbxIP6uq/I0fhCu+cQhoUfE6E RKKnu8zPf1Jwuk0tsvVCk6U9b+0UjM0dLep3ZdE1gblK/1FwYT5Pipsu2yOMluLqwvsuz9/9 f1+1PKHG/FaR/wpbfuIqu54qzHDYeqiUfsYzoVflR80DAC7hmJ+SmZnNTWyUGHJbBpA8Q89l GxahNvuryGaC/o2/ceD2uYDX9U8Eg5DpIpGQdcbQeGarV04WgAUjjXX5r/2dabmtxWMZwhZn a//jdiSyrrSMTGKkDiXm6/3/4ebfeZuCYKzN2P8O2F/Xe2AC/Y7zeEsnR7FOp+uXAgMBAAGj ggGtMIIBqTAPBgNVHRMBAf8EBTADAQH/MA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUU3Lt kpzg2ssBXHx+ljVO8tS4UYIwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwZgYI KwYBBQUHAQEEWjBYMCcGCCsGAQUFBzABhhtodHRwOi8vb2NzcC5zdGFydHNzbC5jb20vY2Ew LQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNydDBbBgNVHR8E VDBSMCegJaAjhiFodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwJ6AloCOGIWh0 dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDCBgAYDVR0gBHkwdzB1BgsrBgEEAYG1 NwECATBmMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRm MDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRm MA0GCSqGSIb3DQEBBQUAA4ICAQAKgwh9eKssBly4Y4xerhy5I3dNoXHYfYa8PlVLL/qtXnkF gdtY1o95CfegFJTwqBBmf8pyTUnFsukDFUI22zF5bVHzuJ+GxhnSqN2sD1qetbYwBYK2iyYA 5Pg7Er1A+hKMIzEzcduRkIMmCeUTyMyikfbUFvIBivtvkR8ZFAk22BZy+pJfAoedO61HTz4q SfQoCRcLN5A0t4DkuVhTMXIzuQ8CnykhExD6x4e6ebIbrjZLb7L+ocR0y4YjCl/Pd4MXU91y 0vTipgr/O75CDUHDRHCCKBVmz/Rzkc/b970MEeHt5LC3NiWTgBSvrLEuVzBKM586YoRD9Dy3 OHQgWI270g+5MYA8GfgI/EPT5G7xPbCDz+zjdH89PeR3U4So4lSXur6H6vp+m9TQXPF3a0Lw Zrp8MQ+Z77U1uL7TelWO5lApsbAonrqASfTpaprFVkL4nyGH+NHST2ZJPWIBk81i6Vw0ny0q ZW2Niy/QvVNKbb43A43ny076khXO7cNbBIRdJ/6qQNq9Bqb5C0Q5nEsFcj75oxQRqlKf6Tcv GbjxkJh8BYtv9ePsXklAxtm8J7GCUBthHSQgepbkOexhJ0wP8imUkyiPHQ0GvEnd83129fZj oEhdGwXV27ioRKbj/cIq7JRXun0NbeY+UdMYu9jGfIpDLtUUGSgsg2zMGs5R4jGCA90wggPZ AgEBMIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD b20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAw2zGTAJBgUrDgMC GgUAoIICHTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNTA4 MjUxMzU4NTlaMCMGCSqGSIb3DQEJBDEWBBRAyNUg+YrNEqdFA1qDiaUWdtCLuTBsBgkqhkiG 9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZI hvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGlBgkr BgEEAYI3EAQxgZcwgZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQu MSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQD Ey9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDDbMZ MIGnBgsqhkiG9w0BCRACCzGBl6CBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBAgMNsxkwDQYJKoZIhvcNAQEBBQAEggEAjx1rmtVIZ7TB0/y5LY8rTUfdRc2X7SqnvucH KxmaNmdQ8t77al1collhrtoeT7GZTHuTr77wKeAq9aLWLiGoH6VFPI/cwXwify+w35pF10Fn M4aJ4lVkq8BXm9/JhyhNMr7duOp4W3HJqsMsDnjzPrbUg1WL2vaeSUt5hJqjKW3PpHh5QRUk MCWtQxknp64BkEcL3u493z7jgdqeaQ//jtlrtMjUWCPD25HLjYcs7HedacEg8SiFITFX2ec5 McT2022LkWOZ/a4M5uL9n9ID5RjUEubs5s2HVI6Krxz8eFpgywi2E8Z10Mz5BmqRC5ypCzxC 6PtxSjW0dW3b4ACAjAAAAAAAAA== --------------ms080507000203090300070600-- From nobody Tue Aug 25 10:31:10 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4D971A8F38 for ; Tue, 25 Aug 2015 10:31:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.601 X-Spam-Level: X-Spam-Status: No, score=-1.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, 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 oDShGFtR-dvr for ; Tue, 25 Aug 2015 10:31:07 -0700 (PDT) Received: from smtp108.iad3a.emailsrvr.com (smtp108.iad3a.emailsrvr.com [173.203.187.108]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4BB2D1A8AE4 for ; Tue, 25 Aug 2015 10:31:07 -0700 (PDT) Received: from smtp6.relay.iad3a.emailsrvr.com (localhost.localdomain [127.0.0.1]) by smtp6.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 3619518037B; Tue, 25 Aug 2015 13:31:06 -0400 (EDT) Received: by smtp6.relay.iad3a.emailsrvr.com (Authenticated sender: ogud-AT-ogud.com) with ESMTPSA id 1533B1804A1; Tue, 25 Aug 2015 13:31:06 -0400 (EDT) X-Sender-Id: ogud@ogud.com Received: from [10.20.30.43] (pool-173-66-187-177.washdc.fios.verizon.net [173.66.187.177]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:587 (trex/5.4.2); Tue, 25 Aug 2015 17:31:06 GMT Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Olafur Gudmundsson In-Reply-To: <55DC74A3.6060206@posteo.de> Date: Tue, 25 Aug 2015 13:31:05 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <55D857EA.80107@strotmann.de> <8321AB9D-ADCD-44BD-8A0F-1D6B5CF1971C@ogud.com> <55DC74A3.6060206@posteo.de> To: =?windows-1252?Q?Patrik_L=F6hr?= X-Mailer: Apple Mail (2.2104) Archived-At: Cc: dane@ietf.org Subject: Re: [dane] DNS-Record type for SMIMEA X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 25 Aug 2015 17:31:08 -0000 Nobody has submitted the request form.=20 Olafur > On Aug 25, 2015, at 9:58 AM, Patrik L=F6hr = wrote: >=20 > Hi Olafur and Carsten, >=20 > it would be very useful for the tests to have the DNS record type > number. Just for clarification: Did anyone request it? >=20 > Thanks and best regards > Patrik >=20 > Am 22.08.2015 um 15:47 schrieb Olafur Gudmundsson: >> Such a request has not been submitted, but it is good idea to do it.=20= >> Olafur (as chair)=20 >>=20 >>=20 >>> On Aug 22, 2015, at 7:07 AM, Carsten Strotmann = wrote: >>>=20 >>> Hi, >>>=20 >>> I remember there was a brief discussion during the DANE WG session @ >>> IETF 93 about requesting a DNS record type number for SMIMEA from = IANA, >>> but I don't remember if there was a conclusion or an action decided. = I >>> cannot find it mentioned in the minutes. >>>=20 >>> Does anyone know the status of this? >>>=20 >>> Testing of SMIMEA will be be done with "normal but security >>> enthusiastic" users, it would be good to have a "well known" DNS = record >>> type number for SMIMEA instead of a private type number for these = tests. >>>=20 >>> Best regards >>>=20 >>> Carsten >>>=20 >>> _______________________________________________ >>> dane mailing list >>> dane@ietf.org >>> https://www.ietf.org/mailman/listinfo/dane >>=20 >> _______________________________________________ >> dane mailing list >> dane@ietf.org >> https://www.ietf.org/mailman/listinfo/dane >>=20 >=20 > --=20 > Patrik L=F6hr >=20 > Posteo e.K. > Methfesselstr. 38 > 10965 Berlin >=20 > tel. +49 30 85074618 > mail > web >=20 > USt-IdNr.: DE186713958 > Handelsregister: Berlin-Charlottenburg =B7 HRA 47592 B >=20 > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane From nobody Tue Aug 25 13:51:51 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DDE81B3058 for ; Tue, 25 Aug 2015 13:51:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y8IvNheNKsFd for ; Tue, 25 Aug 2015 13:51:48 -0700 (PDT) Received: from mail-ob0-f175.google.com (mail-ob0-f175.google.com [209.85.214.175]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F8091B3057 for ; Tue, 25 Aug 2015 13:51:47 -0700 (PDT) Received: by obkg7 with SMTP id g7so153434496obk.3 for ; Tue, 25 Aug 2015 13:51:47 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=yyXcb2t/I292/8zkbzDTzwZLmDuHdjHf7MgpDe5jKOo=; b=DUye04IJIHC+axRsGgyILBjvHsH3C7/JvKvz8vzS9EQPTlxDlg7AxB7zqkAJPm0I3z e6hJFNL0K0lIR8iG/iAChjigzyKi34ZzphJz7TBWd0j422JtBbkaLH1WqxwQlgZREj8C XQJyZArrctzNN/DgwbLrOQuWQwXnibOvJytkcVEWDROklXZY/83d/JXkPcCp7n0i0MtS W/PxOY3lzotk4Y2a7e3dqMGQQFQeo0LEwfr9PYTejIuMlic0hPPOETxlOu91ghhdnTnI n97OUYO7IwuzdJcouBHMaG0Tgryol79zuDP8mjlTAIZ79zOep+pTFbKz3qyf4YuZbhXa akvA== X-Gm-Message-State: ALoCoQllLzc5DaKp6eBwJL9R0HVDlcmAKBevna/zvGFnwiW53OmcofYaRt8tm2mUS+i8gxxMN0+6 MIME-Version: 1.0 X-Received: by 10.60.16.228 with SMTP id j4mr30345270oed.59.1440535907038; Tue, 25 Aug 2015 13:51:47 -0700 (PDT) Received: by 10.202.174.144 with HTTP; Tue, 25 Aug 2015 13:51:46 -0700 (PDT) In-Reply-To: References: <55D857EA.80107@strotmann.de> <8321AB9D-ADCD-44BD-8A0F-1D6B5CF1971C@ogud.com> <55DC74A3.6060206@posteo.de> Date: Tue, 25 Aug 2015 16:51:46 -0400 Message-ID: From: Warren Kumari To: Olafur Gudmundsson Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "" Subject: Re: [dane] DNS-Record type for SMIMEA X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 25 Aug 2015 20:51:50 -0000 On Tue, Aug 25, 2015 at 1:31 PM, Olafur Gudmundsson wrote: > Nobody has submitted the request form. ... also known as: If someone would like a DNS RR for SMIMEA, please write up a short draft and we can consider it... W > > Olafur > >> On Aug 25, 2015, at 9:58 AM, Patrik L=C3=B6hr w= rote: >> >> Hi Olafur and Carsten, >> >> it would be very useful for the tests to have the DNS record type >> number. Just for clarification: Did anyone request it? >> >> Thanks and best regards >> Patrik >> >> Am 22.08.2015 um 15:47 schrieb Olafur Gudmundsson: >>> Such a request has not been submitted, but it is good idea to do it. >>> Olafur (as chair) >>> >>> >>>> On Aug 22, 2015, at 7:07 AM, Carsten Strotmann = wrote: >>>> >>>> Hi, >>>> >>>> I remember there was a brief discussion during the DANE WG session @ >>>> IETF 93 about requesting a DNS record type number for SMIMEA from IANA= , >>>> but I don't remember if there was a conclusion or an action decided. I >>>> cannot find it mentioned in the minutes. >>>> >>>> Does anyone know the status of this? >>>> >>>> Testing of SMIMEA will be be done with "normal but security >>>> enthusiastic" users, it would be good to have a "well known" DNS recor= d >>>> type number for SMIMEA instead of a private type number for these test= s. >>>> >>>> Best regards >>>> >>>> Carsten >>>> >>>> _______________________________________________ >>>> 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 >>> >> >> -- >> Patrik L=C3=B6hr >> >> Posteo e.K. >> Methfesselstr. 38 >> 10965 Berlin >> >> tel. +49 30 85074618 >> mail >> web >> >> USt-IdNr.: DE186713958 >> Handelsregister: Berlin-Charlottenburg =C2=B7 HRA 47592 B >> >> _______________________________________________ >> 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 Tue Aug 25 14:32:02 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E2CF1B3052 for ; Tue, 25 Aug 2015 14:32:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.347 X-Spam-Level: X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ii4mz9BAnF-Q for ; Tue, 25 Aug 2015 14:31:59 -0700 (PDT) Received: from hoffman.proper.com (Opus1.Proper.COM [207.182.41.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6791D1B3050 for ; Tue, 25 Aug 2015 14:31:59 -0700 (PDT) Received: from [10.32.60.23] (142-254-17-100.dsl.dynamic.fusionbroadband.com [142.254.17.100]) (authenticated bits=0) by hoffman.proper.com (8.15.1/8.14.9) with ESMTPSA id t7PLVuue028451 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 25 Aug 2015 14:31:57 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 142-254-17-100.dsl.dynamic.fusionbroadband.com [142.254.17.100] claimed to be [10.32.60.23] From: "Paul Hoffman" To: "Warren Kumari" Date: Tue, 25 Aug 2015 14:31:56 -0700 Message-ID: <16074F28-D0DD-4AA3-A83E-8D8750947395@vpnc.org> In-Reply-To: References: <55D857EA.80107@strotmann.de> <8321AB9D-ADCD-44BD-8A0F-1D6B5CF1971C@ogud.com> <55DC74A3.6060206@posteo.de> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.1r5084) Archived-At: Cc: "" Subject: Re: [dane] DNS-Record type for SMIMEA X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 25 Aug 2015 21:32:00 -0000 On 25 Aug 2015, at 13:51, Warren Kumari wrote: > On Tue, Aug 25, 2015 at 1:31 PM, Olafur Gudmundsson > wrote: >> Nobody has submitted the request form. > > ... also known as: If someone would like a DNS RR for SMIMEA, please > write up a short draft and we can consider it... Already done so in draft-ietf-dane-smime. We're waiting on PaulW to update his draft so we can update ours. --Paul Hoffman From nobody Tue Aug 25 14:34: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 BD3FA1A902B for ; Tue, 25 Aug 2015 14:33:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.511 X-Spam-Level: X-Spam-Status: No, score=-5.511 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HewGlRPwrOuI for ; Tue, 25 Aug 2015 14:33:57 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [199.6.1.65]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0346E1A8AA1 for ; Tue, 25 Aug 2015 14:33:57 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx.ams1.isc.org (Postfix) with ESMTPS id 45DCC1FCAB9; Tue, 25 Aug 2015 21:33:54 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 120C1160094; Tue, 25 Aug 2015 21:35:10 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id E6282160092; Tue, 25 Aug 2015 21:35:09 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id Jle2wehNKp6a; Tue, 25 Aug 2015 21:35:09 +0000 (UTC) Received: from rock.dv.isc.org (c122-106-161-187.carlnfd1.nsw.optusnet.com.au [122.106.161.187]) by zmx1.isc.org (Postfix) with ESMTPSA id A2921160047; Tue, 25 Aug 2015 21:35:09 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 8D88135F4133; Wed, 26 Aug 2015 07:33:50 +1000 (EST) To: Warren Kumari From: Mark Andrews References: <55D857EA.80107@strotmann.de> <8321AB9D-ADCD-44BD-8A0F-1D6B5CF1971C@ogud.com> <55DC74A3.6060206@posteo.de> In-reply-to: Your message of "Tue, 25 Aug 2015 16:51:46 -0400." Date: Wed, 26 Aug 2015 07:33:50 +1000 Message-Id: <20150825213350.8D88135F4133@rock.dv.isc.org> Archived-At: Cc: "" Subject: Re: [dane] DNS-Record type for SMIMEA X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 25 Aug 2015 21:33:58 -0000 Or you can all just agree to use a private value then once you are happy it all works apply for a the final value. This allows you to fiddle with wire format etc. without permanently tainting a assigned value if you need to change wire format. Grab a new private value if you change the wire format etc. 65499 looks good to use and as you have a prefix it shouldn't cause problems for anyone else. It is just a opaque blob to nameservers. It shouldn't be that hard to have something like this in a config file. smime-type = 65499; masterfiles get .