From nobody Sun Apr 10 08:22:37 2016 Return-Path: X-Original-To: dane@ietf.org Delivered-To: dane@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2256512D0A2; Sun, 10 Apr 2016 08:22:33 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "Alexey Melnikov" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160410152233.10340.97826.idtracker@ietfa.amsl.com> Date: Sun, 10 Apr 2016 08:22:33 -0700 Archived-At: Cc: draft-ietf-dane-openpgpkey@ietf.org, dane-chairs@ietf.org, dane@ietf.org Subject: [dane] Alexey Melnikov's No Record on draft-ietf-dane-openpgpkey-08: (with COMMENT) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.17 List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Apr 2016 15:22:33 -0000 Alexey Melnikov has entered the following ballot position for draft-ietf-dane-openpgpkey-08: No Record 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-openpgpkey/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I might have more comments/questions before the telechat. Here is my initial batch: 5.1. Obtaining an OpenPGP key for a specific email address If no OpenPGP public keys are known for an email address, an OPENPGPKEY DNS lookup MAY be performed to seek the OpenPGP public key that corresponds to that email address. This public key can then be used to verify a received signed message or can be used to send out an encrypted email message. An application whose attempt fails to retrieve a DNSSEC verified OPENPGPKEY RR from the DNS should remember that failure for some time to avoid sending out a DNS request for each email message the application is sending out; such DNS requests constitute a privacy leak Should the document give a specific recommendation about "remember for some time"? TTL for the corresponding RR? In section 7: What is the difference between "an email client" and MUA? In 7.1: If the DNS request for an OPENPGPKEY record returned an Indeterminate or Bogus answer as specified in [RFC4035], the MTA MUST NOT send the message and queue the plaintext message for encrypted delivery at a later time. If the problem persists, the email should be returned via the regular bounce methods. Is this behaviour only specific to encrypting gateways? I want to make sure that this is not applied uncondionally to general MTAs, which don't need to understand this specification. In 7.2: If the public key for a recipient obtained from the locally stored sender’s public keyring differs from the recipient’s OPENPGPKEY RR, the MUA MUST NOT accept the message for delivery. Minor terminology issue: It is better to say here "accept the message for submission", because "delivery" is a recipient side operation which is not done my MUAs, it is performed by MDAs. In 7.5: The hashing of the user name in this document is not a security feature. Please use "local part" instead of username here, email addresses are not user names. From nobody Tue Apr 12 21:04:50 2016 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBCC012DB66; Tue, 12 Apr 2016 21:04:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, RP_MATCHES_RCVD=-0.996] autolearn=no autolearn_force=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 GLyORreLpVCp; Tue, 12 Apr 2016 21:04:43 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (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 A4F5912DB5B; Tue, 12 Apr 2016 21:04:42 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3ql9DQ6zqcz1Jy; Wed, 13 Apr 2016 06:04:38 +0200 (CEST) X-OPENPGPKEY: Message passed unmodified X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id nJjM4_bTifWt; Wed, 13 Apr 2016 06:04: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; Wed, 13 Apr 2016 06:04:37 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 30E4C614B000; Wed, 13 Apr 2016 00:04:36 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.10.3 bofh.nohats.ca 30E4C614B000 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 2BC26D5103; Wed, 13 Apr 2016 00:04:36 -0400 (EDT) Date: Wed, 13 Apr 2016 00:04:36 -0400 (EDT) From: Paul Wouters To: Alexey Melnikov In-Reply-To: <20160410152233.10340.97826.idtracker@ietfa.amsl.com> Message-ID: References: <20160410152233.10340.97826.idtracker@ietfa.amsl.com> 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: draft-ietf-dane-openpgpkey@ietf.org, The IESG , dane-chairs@ietf.org, dane@ietf.org Subject: Re: [dane] Alexey Melnikov's No Record on draft-ietf-dane-openpgpkey-08: (with COMMENT) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.17 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, 13 Apr 2016 04:04:44 -0000 On Sun, 10 Apr 2016, Alexey Melnikov wrote: > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > I might have more comments/questions before the telechat. Here is my > initial batch: Thanks for the review and comments.... > 5.1. Obtaining an OpenPGP key for a specific email address > > If no OpenPGP public keys are known for an email address, an > OPENPGPKEY DNS lookup MAY be performed to seek the OpenPGP public key > that corresponds to that email address. This public key can then be > used to verify a received signed message or can be used to send out > an encrypted email message. An application whose attempt fails to > retrieve a DNSSEC verified OPENPGPKEY RR from the DNS should remember > that failure for some time to avoid sending out a DNS request for > each email message the application is sending out; such DNS requests > constitute a privacy leak > > Should the document give a specific recommendation about "remember for > some time"? > TTL for the corresponding RR? TTL advise for this RRTYPE is not different from other RRTYPEs. After talking to implementors, they stated they have their own methods for dealing with things like attacks using short TTLs or overly long TTLs. > In section 7: > > What is the difference between "an email client" and MUA? Nothing. I can pick one of the two terms and make it consistent. > In 7.1: > > If the DNS request for an OPENPGPKEY record returned an Indeterminate > or Bogus answer as specified in [RFC4035], the MTA MUST NOT send the > message and queue the plaintext message for encrypted delivery at a > later time. If the problem persists, the email should be returned > via the regular bounce methods. > > Is this behaviour only specific to encrypting gateways? I want to make > sure that this is not applied uncondionally to general MTAs, which don't > need to understand this specification. This document only refers to those MTA's and MUA's (or their plugins) that implement/support this document. I am not sure what you mean with "encrypting gateways", but it applies to all those that implement encrypting using OPENPGPKEY records. If the DNS returns Indeterminate or Bogus, it means the DNSSEC records are bad or mangled, or withheld by a MITM. To prevent a downgrade to plaintext, the above process is defined to ensure no unencrypted message is sent out. > In 7.2: > If the public key for a recipient obtained from the locally stored > sender’s public keyring differs from the recipient’s OPENPGPKEY RR, > the MUA MUST NOT accept the message for delivery. > > Minor terminology issue: It is better to say here "accept the message for > submission", because "delivery" is a recipient side operation which is > not done my MUAs, it is performed by MDAs. How about: [...] the MUA MUST abort sending the message and seek user assistance. > In 7.5: > > The hashing of the user name in this document is not a security > feature. > > Please use "local part" instead of username here, email addresses are not > user names. Agreed. Paul From nobody Wed Apr 13 03:01:25 2016 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F8D512D85B for ; Wed, 13 Apr 2016 03:01:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 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, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fastmail.fm header.b=Mt4r88tG; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=nugWVKy3 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GNT2qG7CjwwM for ; Wed, 13 Apr 2016 03:01:22 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B7C212E35B for ; Wed, 13 Apr 2016 03:01:21 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id D22F920BDA for ; Wed, 13 Apr 2016 06:01:19 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute3.internal (MEProxy); Wed, 13 Apr 2016 06:01:19 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=fastmail.fm; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=mesmtp; bh=CSEKVnPhM6e0FhMT6KyuDiooc3Q=; b=Mt4r88 tGOX/DwjYKEvwb69JwcM6CzCVBCOeDpu9CPKcRTzwzC2SLAS74brfYg1ld43EDjm pqVPe4FAWbG3xFW0CBdpnjz/FAA9DrpoVN9ZmH5LCgEpzQ+cSZRlO4Ak/WNX2n+y d237BRILVXkfSkMkl0uocewdg5E+DOyByRDu0= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=CSEKVnPhM6e0FhM T6KyuDiooc3Q=; b=nugWVKy3H1EfoViuoD7lcvqoYMQDGBW+BcA5jxhdbEShXu5 Vtmhwh3x7QZksGkDrO7FEmPhr8QYWh/lIVAytKAgn5/2+bTK1jZgeMoHt/ItuiLG hwjp0oWvzC5dUpcqreCbSUe7K/xibk6zN16CU2gvx5xTSRW4s3RRa3WBLUww= X-Sasl-enc: pETuBi/kGaL0V9GtxEMnB5TNAnxDvAqUP/aiMJwmEyd2 1460541679 Received: from [10.15.162.96] (unknown [85.255.235.191]) by mail.messagingengine.com (Postfix) with ESMTPA id 7A8F1C00013; Wed, 13 Apr 2016 06:01:19 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Alexey Melnikov X-Mailer: iPhone Mail (13E238) In-Reply-To: Date: Wed, 13 Apr 2016 11:05:16 +0100 Content-Transfer-Encoding: 7bit Message-Id: References: <20160410152233.10340.97826.idtracker@ietfa.amsl.com> To: Paul Wouters Archived-At: Cc: draft-ietf-dane-openpgpkey@ietf.org, The IESG , dane-chairs@ietf.org, dane@ietf.org Subject: Re: [dane] Alexey Melnikov's No Record on draft-ietf-dane-openpgpkey-08: (with COMMENT) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.17 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, 13 Apr 2016 10:01:23 -0000 Hi Paul, On 13 Apr 2016, at 05:04, Paul Wouters wrote: >> In section 7: >> >> What is the difference between "an email client" and MUA? > > Nothing. I can pick one of the two terms and make it consistent. Please do. You have separate sections for them, they need to be merged. From nobody Wed Apr 13 03:27:39 2016 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA9B212E04C; Wed, 13 Apr 2016 03:27:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.297 X-Spam-Level: X-Spam-Status: No, score=-5.297 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, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CYskMtJNJIea; Wed, 13 Apr 2016 03:27:35 -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 56E5412DFCE; Wed, 13 Apr 2016 03:27:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 94F49BE33; Wed, 13 Apr 2016 11:27:32 +0100 (IST) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MOFRjiuav6IY; Wed, 13 Apr 2016 11:27:32 +0100 (IST) Received: from [134.226.36.93] (bilbo.dsg.cs.tcd.ie [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id DE419BDF9; Wed, 13 Apr 2016 11:27:31 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1460543252; bh=wPqdHcTK59jFVRHOk7Bffh7P++iz4Yoc0KkDLaMQIb8=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=J4ChQyaGqkDiaM4lu6bBt1kWq52R25nkGK1JfYSSJ41ESZS5YvbdVemF2u5b+tIwo f9XKzz3SfPZ6AGDsMCgnrYkyvA3gn4GT2VKwaC9bJq9VIOHIRj6pH47HWouFfZgiAk iYPEdo0M1efbQ1CnVmW2A7okmNhSrE1LsoESQqSA= To: Paul Wouters References: <20160410152233.10340.97826.idtracker@ietfa.amsl.com> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <570E1F13.5070509@cs.tcd.ie> Date: Wed, 13 Apr 2016 11:27:31 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms010503050108010708020701" Archived-At: Cc: draft-ietf-dane-openpgpkey@ietf.org, dane@ietf.org, The IESG , dane-chairs@ietf.org, Alexey Melnikov Subject: Re: [dane] Alexey Melnikov's No Record on draft-ietf-dane-openpgpkey-08: (with COMMENT) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.17 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, 13 Apr 2016 10:27:38 -0000 This is a cryptographically signed message in MIME format. --------------ms010503050108010708020701 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Paul, If you can make changes easily now, say before Friday, please feel free to do so. Better to not make too many changes when other ADs are reading the draft but I suspect Alexey's in early so the next few days should be fine. It's also fine if we fix things after the 21st too, if you don't have time right now. Cheers, S. On 13/04/16 11:05, Alexey Melnikov wrote: > Hi Paul, >=20 > On 13 Apr 2016, at 05:04, Paul Wouters wrote: >=20 >>> In section 7: >>> >>> What is the difference between "an email client" and MUA? >> >> Nothing. I can pick one of the two terms and make it consistent. >=20 > Please do. You have separate sections for them, they need to be merged.= >=20 --------------ms010503050108010708020701 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjA0MTMx MDI3MzFaMC8GCSqGSIb3DQEJBDEiBCDg8if30QCEtlponEeWsuE3KbI219dwKYro5War/onL PzBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQAhXXckM8PM8sRNh10lBkLXe6BeUr/h/3CBRbvFCqwnnq/pGWpDs8HZ BMiI7ymaYI9P+580cyqqFOwnYiMLUdQ9VWCWVlaRaHh+XDQ13SYaJ2/ism6K11sKHMoBq0kz qod5VtivAa7kWRNq+RVXmvVnrW4J4gvSYIWbi4L/vypUKMoQngAZuxR6eInkfPPiKFTMMXiw +FX2khdZ8cw8UyhoCMsPPHNmBQcsh/VnpXcPj4xH4k6lc02LOCuUHrqILvkQhnD0KKMv7tjn +8CwpHguWo4vSsKVY97LGexws47+UAD84OyKsOlYU+zXmz0ECX2qWZHQ3O+9/IBN5W5qFqMe AAAAAAAA --------------ms010503050108010708020701-- From nobody Wed Apr 13 07:04:23 2016 Return-Path: X-Original-To: dane@ietf.org Delivered-To: dane@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A3F812D0F2; Wed, 13 Apr 2016 07:04:21 -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.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160413140421.5968.73785.idtracker@ietfa.amsl.com> Date: Wed, 13 Apr 2016 07:04:21 -0700 Archived-At: Cc: dane@ietf.org Subject: [dane] I-D Action: draft-ietf-dane-openpgpkey-09.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.17 List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2016 14:04:21 -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 of the IETF. Title : Using DANE to Associate OpenPGP public keys with email addresses Author : Paul Wouters Filename : draft-ietf-dane-openpgpkey-09.txt Pages : 19 Date : 2016-04-13 Abstract: OpenPGP is a message format for email (and file) encryption that lacks a standardized lookup mechanism to securely obtain OpenPGP public keys. DNS-Based Authentication of Named Entities ("DANE") is a method for publishing public keys in DNS. This document specifies a DANE method for publishing and locating OpenPGP public keys in DNS for a specific email address using a new OPENPGPKEY DNS Resource Record. Security is provided via Secure DNS, however the OPENPGPKEY record is not a replacement for verification of authenticity via the "Web Of Trust" or manual verification. The OPENPGPKEY record can be used to encrypt an email that would otherwise have to be sent unencrypted. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dane-openpgpkey/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-dane-openpgpkey-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dane-openpgpkey-09 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Apr 13 07:05:50 2016 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B65E612DE45; Wed, 13 Apr 2016 07:05:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.898 X-Spam-Level: X-Spam-Status: No, score=-7.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.996, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 AnKMpniIH8Uw; Wed, 13 Apr 2016 07:05:40 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93DCF12D898; Wed, 13 Apr 2016 07:05:40 -0700 (PDT) Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 269AC7264B; Wed, 13 Apr 2016 14:05:40 +0000 (UTC) Received: from thinkpad.nohats.ca (unused [10.10.51.184] (may be forged)) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u3DE5b2H028042; Wed, 13 Apr 2016 10:05:38 -0400 To: Stephen Farrell , Paul Wouters References: <20160410152233.10340.97826.idtracker@ietfa.amsl.com> <570E1F13.5070509@cs.tcd.ie> From: Paul Wouters Message-ID: <570E5230.40203@redhat.com> Date: Wed, 13 Apr 2016 11:05:36 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <570E1F13.5070509@cs.tcd.ie> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.39]); Wed, 13 Apr 2016 14:05:40 +0000 (UTC) Archived-At: Cc: draft-ietf-dane-openpgpkey@ietf.org, dane@ietf.org, The IESG , dane-chairs@ietf.org, Alexey Melnikov Subject: Re: [dane] Alexey Melnikov's No Record on draft-ietf-dane-openpgpkey-08: (with COMMENT) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.17 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, 13 Apr 2016 14:05:44 -0000 On 04/13/2016 07:27 AM, Stephen Farrell wrote: > > Paul, > > If you can make changes easily now, say before Friday, please feel > free to do so. Better to not make too many changes when other ADs > are reading the draft but I suspect Alexey's in early so the next > few days should be fine. It's also fine if we fix things after the > 21st too, if you don't have time right now. Done, - Resolve IETF LC comments from Alexey Melnikov regarding "email client" vs MUA and change "user name" to "local-part". https://www.ietf.org/rfcdiff?url2=draft-ietf-dane-openpgpkey-09 Paul From nobody Thu Apr 14 11:39:01 2016 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3752712D6D5; Thu, 14 Apr 2016 11:39:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=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 3ZC1ymrTmI2H; Thu, 14 Apr 2016 11:38:58 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B848A12D5D6; Thu, 14 Apr 2016 11:38:57 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id D4C76284DCA; Thu, 14 Apr 2016 18:38:56 +0000 (UTC) Date: Thu, 14 Apr 2016 18:38:56 +0000 From: Viktor Dukhovni To: uta@ietf.org, dane@ietf.org Message-ID: <20160414183856.GL26423@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: [dane] NEWSFLASH: DANE TLSA records published for web.de! X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: dane-users@sys4.de List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2016 18:39:00 -0000 The web.de domain has just published DANE TLSA records for its MX hosts. This follows earlier "pilot" deployments with the smaller mail.com and mail.de domains. web.de. IN MX 100 mx-ha02.web.de. ; AD=1 _25._tcp.mx-ha02.web.de. IN TLSA 3 1 1 409c9e91a2a9f4d7881dbf0094b3839d4343a4a57d9bf559fdeb0c1f4c5b8b3e ; passed Subject = CN=mx-ha02.web.de,emailAddress=server-certs@1und1.de,L=Montabaur,ST=Rhineland-Palatinate,O=1&1 Mail & Media GmbH,C=DE Issuer = CN=TeleSec ServerPass DE-2,street=Untere Industriestr. 20,L=Netphen,postalCode=57250,ST=Nordrhein Westfalen,OU=T-Systems Trust Center,O=T-Systems International GmbH,C=DE Inception = 2014-07-22T11:21:46Z Expiration = 2017-07-27T23:59:59Z web.de. IN MX 100 mx-ha03.web.de. ; AD=1 _25._tcp.mx-ha03.web.de. IN TLSA 3 1 1 33fccf0e82584b6133cf18d24ae592cc6cbc9cfcab13291a5585a2b20a30eb19 ; passed Subject = CN=mx-ha03.web.de,emailAddress=server-certs@1und1.de,L=Montabaur,ST=Rhineland-Palatinate,O=1&1 Mail & Media GmbH,C=DE Issuer = CN=TeleSec ServerPass DE-2,street=Untere Industriestr. 20,L=Netphen,postalCode=57250,ST=Nordrhein Westfalen,OU=T-Systems Trust Center,O=T-Systems International GmbH,C=DE Inception = 2014-07-22T11:22:46Z Expiration = 2017-07-27T23:59:59Z This is a major milestone in DANE adoption. [ IIRC they host mailboxes for a substantial fraction of the population of Germany. ] One approach to making sure that DANE TLSA records are less likely to fail that should work well for sites using CA-issued certificates is to publish both "3 1 1" and "2 1 1" TLSA records: mx.example. IN TLSA 3 1 1 mx.example. IN TLSA 2 1 1 * The "3 1 1" record protects against "expiration" accidents, and unexpected changes in the issuer's public key (if new certificate chain deployment is automated). * The "2 1 1" record protects against key rotation errors should a a new server private key be deployed without updating the TLSA RRs. Provided the new certificate is issued by the same CA is unexpired, ... the "2 1 1" record will match. With a bit of monitoring to ensure that both records match, simultaneous failures of both is much less likely. This even makes it possible to avoid pre-deployment DNS TLSA records updates when rotating certificates, provided at least one of the issuer public key or the server public key is unchanged in the new chain. In particular, this is the best practice with Let's Encrypt issued SMTP server certificates, as explained in: https://www.internetsociety.org/deploy360/blog/2016/03/lets-encrypt-certificates-for-mail-servers-and-dane-part-2-of-2/ -- Viktor. From nobody Thu Apr 14 12:58:31 2016 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00F7912E2CA for ; Thu, 14 Apr 2016 12:58:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.997 X-Spam-Level: X-Spam-Status: No, score=-2.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=phpgangsta.de Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b0U_A1MSN8ce for ; Thu, 14 Apr 2016 12:58:27 -0700 (PDT) Received: from michael01.phpgangsta.de (phpgangsta.de [IPv6:2001:1608:10:43::31]) (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 2BC1512E36D for ; Thu, 14 Apr 2016 12:58:26 -0700 (PDT) Received: from [192.168.2.19] (dslb-178-001-010-158.178.001.pools.vodafone-ip.de [178.1.10.158]) by michael01.phpgangsta.de (Postfix) with ESMTPSA id 9A93E485E32 for ; Thu, 14 Apr 2016 21:58:23 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=phpgangsta.de; s=mail201210; t=1460663903; bh=ageoR0iySnWZPEsIUQrvYIIMmCCLbdA6K8IwYcrS2P0=; h=Subject:To:References:From:Date:In-Reply-To; b=c5OVUGjJajuOVtIhz0j8GXMf9O6y8P96UtF2yzzX1f5766GRM9Vl2IXIuTxzq2qpt GlITaIV6L3MzncYr78w3kXBHgdR3HlEXYBd3Pvp01w0D1cfEC3ohvTcTmSXydfiyEJ WS525jQJkt+mnfKT8i39lJ9wNyUI83WS1+wCpdNk= To: dane@ietf.org References: <20160414183856.GL26423@mournblade.imrryr.org> From: Michael Kliewe Message-ID: <570FF65A.5070601@phpgangsta.de> Date: Thu, 14 Apr 2016 21:58:18 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <20160414183856.GL26423@mournblade.imrryr.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dane] NEWSFLASH: DANE TLSA records published for web.de! X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.17 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, 14 Apr 2016 19:58:30 -0000 I totally love it! 11:30am GMT we saw the first DANE connection to web.de: Verified TLS connection established to mx-ha02.web.de[212.227.17.8]:25: TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits) It would be awesome to get some insights into this big deployment, to show and help others to also deploy DNSSEC and DANE. Which software is used, which steps were taken to slowly start using it, which problems came up on the way and how were they solved. Any information about increased traffic or load on the DNS-Servers, or failed mail transfers because of buggy mailservers, would be very helpful during the next days. Is DANE verification activated for outbound mail traffic? I hope we get some insights here. By the way: mail.de does not belong to United Internet (web.de, mail.com, GMX, 1&1...) Michael Am 14.04.2016 um 20:38 schrieb Viktor Dukhovni: > The web.de domain has just published DANE TLSA records for its MX > hosts. This follows earlier "pilot" deployments with the smaller > mail.com and mail.de domains. > > web.de. IN MX 100 mx-ha02.web.de. ; AD=1 > _25._tcp.mx-ha02.web.de. IN TLSA 3 1 1 409c9e91a2a9f4d7881dbf0094b3839d4343a4a57d9bf559fdeb0c1f4c5b8b3e ; passed > > Subject = CN=mx-ha02.web.de,emailAddress=server-certs@1und1.de,L=Montabaur,ST=Rhineland-Palatinate,O=1&1 Mail & Media GmbH,C=DE > Issuer = CN=TeleSec ServerPass DE-2,street=Untere Industriestr. 20,L=Netphen,postalCode=57250,ST=Nordrhein Westfalen,OU=T-Systems Trust Center,O=T-Systems International GmbH,C=DE > Inception = 2014-07-22T11:21:46Z > Expiration = 2017-07-27T23:59:59Z > > web.de. IN MX 100 mx-ha03.web.de. ; AD=1 > _25._tcp.mx-ha03.web.de. IN TLSA 3 1 1 33fccf0e82584b6133cf18d24ae592cc6cbc9cfcab13291a5585a2b20a30eb19 ; passed > > Subject = CN=mx-ha03.web.de,emailAddress=server-certs@1und1.de,L=Montabaur,ST=Rhineland-Palatinate,O=1&1 Mail & Media GmbH,C=DE > Issuer = CN=TeleSec ServerPass DE-2,street=Untere Industriestr. 20,L=Netphen,postalCode=57250,ST=Nordrhein Westfalen,OU=T-Systems Trust Center,O=T-Systems International GmbH,C=DE > Inception = 2014-07-22T11:22:46Z > Expiration = 2017-07-27T23:59:59Z > > This is a major milestone in DANE adoption. [ IIRC they host > mailboxes for a substantial fraction of the population of Germany. ] > > One approach to making sure that DANE TLSA records are less likely > to fail that should work well for sites using CA-issued certificates > is to publish both "3 1 1" and "2 1 1" TLSA records: > > mx.example. IN TLSA 3 1 1 > mx.example. IN TLSA 2 1 1 > > * The "3 1 1" record protects against "expiration" accidents, and > unexpected changes in the issuer's public key (if new certificate > chain deployment is automated). > > * The "2 1 1" record protects against key rotation errors should a > a new server private key be deployed without updating the TLSA > RRs. Provided the new certificate is issued by the same CA > is unexpired, ... the "2 1 1" record will match. > > With a bit of monitoring to ensure that both records match, > simultaneous failures of both is much less likely. > > This even makes it possible to avoid pre-deployment DNS TLSA records > updates when rotating certificates, provided at least one of the > issuer public key or the server public key is unchanged in the new > chain. > > In particular, this is the best practice with Let's Encrypt > issued SMTP server certificates, as explained in: > > https://www.internetsociety.org/deploy360/blog/2016/03/lets-encrypt-certificates-for-mail-servers-and-dane-part-2-of-2/ > From nobody Tue Apr 19 10:42:44 2016 Return-Path: X-Original-To: dane@ietf.org Delivered-To: dane@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 94A4A12DF88; Tue, 19 Apr 2016 10:42:40 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Alexey Melnikov" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160419174240.31613.95778.idtracker@ietfa.amsl.com> Date: Tue, 19 Apr 2016 10:42:40 -0700 Archived-At: Cc: draft-ietf-dane-openpgpkey@ietf.org, dane-chairs@ietf.org, dane@ietf.org Subject: [dane] Alexey Melnikov's Discuss on draft-ietf-dane-openpgpkey-09: (with DISCUSS and COMMENT) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.17 List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2016 17:42:40 -0000 Alexey Melnikov has entered the following ballot position for draft-ietf-dane-openpgpkey-09: Discuss 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-openpgpkey/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- NOTE to editors: Thank you for addressing my earlier comments in -09. If you need any more specific suggestions about text being added/deleted/updated, please let me know. Despite many objections to publishing this specification I believe we should run the experiment. I will vote "Yes" once DISCUSS-points are addressed. I would rather see this experiment being done and fail (or better - succeed), than to block publication of this document because it is not perfect. 1). As per Sean Leonard/Ned Freed: There's also - as noted by Sean Leonard - a technical glitch in the current specification: The local-part is not the correct input to the hash function. A canonicalization step is needed because all of these addresses are equivalent: (1) first.last@example.com (2) first . last @example.com (3) "first.last"@example.com (4) "\f\i\r\s\t.last"@example.com (2) is equivalent to (1) because CWS has no semantics, (3) is equivalent to (1) because the enclosing quotes are not properly part of the address, and (4) is equivalent to (1) because quoted-pairs are semantically equivalent to just the quoted character. I believe this is the entire list, so the obvious canonicalization to use on the local-part portion of an address prior to hashing is: (a) If the local-part is unquoted remove any whitespace (CFWS) around "."s. (b) Remove any enclosing double quotes. (c) Remove any literal quoting. 2). Ned Freed wrote: > First, there's no way to define a mapping of local-parts to a new set of > identifiers *without* effectively interpreting the local-part! If you define > the mapping as the draft currently does, implicit in that definition is that > local-parts are case-sensitive. And similarly, if you convert the local-part to > lower (or upper) case, you're now assuming the local-part is case-insensitive. > > And in the case of EAI, without some sort of normalization you're assuming that > different UTF-8 representations of the same string of characters correspond to > different recipients. (Which, as Harald Alvestrand and I both pointed out on > the IETF list, is technically untenable and needs to be addressed. My > suggestion was and is to specify that the same case-folding and normalization > algorithm used for IDNs also be employed here.) RFC 6532 and Section 10.1 of RFC 6530 recommend using NFC Unicode Normalization Form. (This is similar to what IDN recommends, although there is no standard mapping there.) I think it would be reasonable for this document to say SHOULD apply NFC before hashing. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Some (edited) comments from Ned Freed that I (mostly) agree with: 1) In Section 3: Finally, a couple of observations about terminology are in order. The current text covering the hashing of local-parts begins with: The user name (the "left-hand side" of the email address, called the "local-part" in the mail message format definition [RFC5322] and the local-part in the specification for internationalized email [RFC6530]) is encoded in UTF-8 (or its subset ASCII). If the local-part is written in another encoding it MUST be converted to UTF-8. First, the left hand side of an email address is not a "user name" and should not be referred to as such. (The entire address is in some cases a "user name" of sorts, and in some cases the local-part is identical to some kind of login credential. But neither of these are universally true, and more to the point, none of this is relevant to the matter at hand.) Second, it probably makes sense to note that local-part is an ABNF production contained in a broader syntax, not just a name. Third, the term "encoding" here is inaccurate; it should be "charset". 2) Ned Freed wrote: > So when a domain owner publishes such records in the DNS, a reasonable way to > look at it is that they are effectively saying, "Everyone is allowed to > interpret the local-parts of our addresses as specified in this document in > this one narrow context." I'm pretty confident there's nothing in any standard > that forbids such a delegation of authority. > > And once you realize this is what is going on, not only does it become clear > that this draft is *not* violating the longstanding rules about local-part > interpretation, it casts the decision not to normalize the local-parts to lower > (or upper) case in an entirely different light. By choosing not to normalize > this specification is effectively restricting its own applicability to domains > with case-sensitive local parts. That is, IMO, a highly suboptimal choice - the > overwhelming majority of domains treat the local part in a case-insensitive > fashion, and so should the mechanism specified in this draft. > > Or, to put this another way, the inherent limitations of using the DNS to > provide the mapping from address to PGP key restricts the domain of > applicability of this specification to domains with particular local-part > policies, and the way in which the local-part to DNS mapping is specified > determines which policies the specification supports. And while it seems > logical to support a policy that's known to be in wide use, the specification > also needs to be very clear that domains that employ case-sensitive local-parts > MUST NOT avail themselves of this mechanism. I don't think I agree on "MUST NOT" here, because I think an email owner can publish the preferred form (which can be lowercased) or even multiple common forms of the email address. E.g. I can publish DNS records for alexey.melnikov@isode.com, Alexey.Melnikov@isode.com and ALEXEY.MELNIKOV@isode.com, but not others. > What needs to happen here is that the specification be revised to make it clear > that this is what is going on: That by publishing such records a domain is > granting a limited right to interpret the local parts of its addresses. I agree with this. A sentence or two on this would suffice. --------------- 3) The following issues/comments/questions were reported earlier: 5.1. Obtaining an OpenPGP key for a specific email address If no OpenPGP public keys are known for an email address, an OPENPGPKEY DNS lookup MAY be performed to seek the OpenPGP public key that corresponds to that email address. This public key can then be used to verify a received signed message or can be used to send out an encrypted email message. An application whose attempt fails to retrieve a DNSSEC verified OPENPGPKEY RR from the DNS should remember that failure for some time to avoid sending out a DNS request for each email message the application is sending out; such DNS requests constitute a privacy leak Should the document give a specific recommendation about "remember for some time"? Is it tied to TTL for the corresponding RR? If you can provide some additional text explaining what is reasonable (or not) here, that would improve the specification. From nobody Tue Apr 19 12:58:12 2016 Return-Path: X-Original-To: dane@ietf.org Delivered-To: dane@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8155B12DA85; Tue, 19 Apr 2016 12:58:08 -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.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160419195808.31577.44566.idtracker@ietfa.amsl.com> Date: Tue, 19 Apr 2016 12:58:08 -0700 Archived-At: Cc: dane@ietf.org Subject: [dane] I-D Action: draft-ietf-dane-openpgpkey-10.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.17 List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2016 19:58:08 -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 of the IETF. Title : Using DANE to Associate OpenPGP public keys with email addresses Author : Paul Wouters Filename : draft-ietf-dane-openpgpkey-10.txt Pages : 19 Date : 2016-04-19 Abstract: OpenPGP is a message format for email (and file) encryption that lacks a standardized lookup mechanism to securely obtain OpenPGP public keys. DNS-Based Authentication of Named Entities ("DANE") is a method for publishing public keys in DNS. This document specifies a DANE method for publishing and locating OpenPGP public keys in DNS for a specific email address using a new OPENPGPKEY DNS Resource Record. Security is provided via Secure DNS, however the OPENPGPKEY record is not a replacement for verification of authenticity via the "Web Of Trust" or manual verification. The OPENPGPKEY record can be used to encrypt an email that would otherwise have to be sent unencrypted. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dane-openpgpkey/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-dane-openpgpkey-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dane-openpgpkey-10 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Apr 19 13:06:00 2016 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99DCC12E61E; Tue, 19 Apr 2016 13:05:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.918 X-Spam-Level: X-Spam-Status: No, score=-7.918 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 c8Xep3hajO1a; Tue, 19 Apr 2016 13:05:52 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E37612E50E; Tue, 19 Apr 2016 13:05:52 -0700 (PDT) Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 1DA2746267; Tue, 19 Apr 2016 20:05:52 +0000 (UTC) Received: from thinkpad.nohats.ca (vpn-54-190.rdu2.redhat.com [10.10.54.190]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u3JK5oX1005255; Tue, 19 Apr 2016 16:05:50 -0400 To: Alexey Melnikov , The IESG References: <20160419174240.31613.95778.idtracker@ietfa.amsl.com> From: Paul Wouters X-Enigmail-Draft-Status: N1110 Message-ID: <57168F9E.7080309@redhat.com> Date: Tue, 19 Apr 2016 16:05:50 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <20160419174240.31613.95778.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26 Archived-At: Cc: draft-ietf-dane-openpgpkey@ietf.org, dane-chairs@ietf.org, dane@ietf.org Subject: Re: [dane] Alexey Melnikov's Discuss on draft-ietf-dane-openpgpkey-09: (with DISCUSS and COMMENT) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.17 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, 19 Apr 2016 20:05:54 -0000 On 04/19/2016 01:42 PM, Alexey Melnikov wrote: > Alexey Melnikov has entered the following ballot position for > draft-ietf-dane-openpgpkey-09: Discuss > > 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-openpgpkey/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > NOTE to editors: Thank you for addressing my earlier comments in -09. > If you need any more specific suggestions about text being > added/deleted/updated, please let me know. I have addressed most issues and incorporated most suggestions. See below for the two issues left. https://tools.ietf.org/rfcdiff?url2=draft-ietf-dane-openpgpkey-10.txt > Despite many objections to publishing this specification I believe we > should run the experiment. I will vote "Yes" once DISCUSS-points are > addressed. I would rather see this experiment being done and fail (or > better - succeed), than to block publication of this document because it > is not perfect. > > 1). As per Sean Leonard/Ned Freed: > > There's also - as noted by Sean Leonard - a technical glitch in the > current > specification: The local-part is not the correct input to the hash > function. A > canonicalization step is needed because all of these addresses are > equivalent: > > (1) first.last@example.com > (2) first . last @example.com > (3) "first.last"@example.com > (4) "\f\i\r\s\t.last"@example.com > > (2) is equivalent to (1) because CWS has no semantics, (3) is equivalent > to > (1) because the enclosing quotes are not properly part of the address, > and (4) > is equivalent to (1) because quoted-pairs are semantically equivalent to > just the quoted character. > > I believe this is the entire list, so the obvious canonicalization to > use > on the local-part portion of an address prior to hashing is: > > (a) If the local-part is unquoted remove any whitespace (CFWS) around > "."s. > (b) Remove any enclosing double quotes. > (c) Remove any literal quoting. I have added this to the document. > 2). Ned Freed wrote: > >> First, there's no way to define a mapping of local-parts to a new set > of >> identifiers *without* effectively interpreting the local-part! If you > define >> the mapping as the draft currently does, implicit in that definition is > that >> local-parts are case-sensitive. And similarly, if you convert the > local-part to >> lower (or upper) case, you're now assuming the local-part is > case-insensitive. >> >> And in the case of EAI, without some sort of normalization you're > assuming that >> different UTF-8 representations of the same string of characters > correspond to >> different recipients. (Which, as Harald Alvestrand and I both pointed > out on >> the IETF list, is technically untenable and needs to be addressed. My >> suggestion was and is to specify that the same case-folding and > normalization >> algorithm used for IDNs also be employed here.) > > RFC 6532 and Section 10.1 of RFC 6530 recommend using NFC Unicode > Normalization Form. (This is similar to what IDN recommends, although > there is no standard mapping there.) I think it would be reasonable for > this document to say SHOULD apply NFC before hashing. I have added this to the document. > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Some (edited) comments from Ned Freed that I (mostly) agree with: > > 1) In Section 3: > > Finally, a couple of observations about terminology are in order. The > current > text covering the hashing of local-parts begins with: > > The user name (the "left-hand side" of the email address, called > the "local-part" in the mail message format definition [RFC5322] > and the local-part in the specification for internationalized > email [RFC6530]) is encoded in UTF-8 (or its subset ASCII). If > the local-part is written in another encoding it MUST be > converted > to UTF-8. > > First, the left hand side of an email address is not a "user name" and > should > not be referred to as such. (The entire address is in some cases a "user > name" > of sorts, and in some cases the local-part is identical to some kind of > login > credential. But neither of these are universally true, and more to the > point, > none of this is relevant to the matter at hand.) This has been changed to use local-part instead of user name. > Second, it probably makes sense to note that local-part is an ABNF > production contained in a broader syntax, not just a name. See above. text was changed. > Third, the term "encoding" here is inaccurate; it should be "charset". Fixed. > 2) Ned Freed wrote: > >> So when a domain owner publishes such records in the DNS, a reasonable > way to >> look at it is that they are effectively saying, "Everyone is allowed > to >> interpret the local-parts of our addresses as specified in this > document in >> this on e narrow context." I'm pretty confident there's nothing in any > standard >> that forbids such a delegation of authority. >> >> And once you realize this is what is going on, not only does it become > clear >> that this draft is *not* violating the longstanding rules about > local-part >> interpretation, it casts the decision not to normalize the local-parts > to lower >> (or upper) case in an entirely different light. By choosing not to > normalize >> this specification is effectively restricting its own applicability to > domains >> with case-sensitive local parts. That is, IMO, a highly suboptimal > choice - the >> overwhelming majority of domains treat the local part in a > case-insensitive >> fashion, and so should the mechanism specified in this draft. >> >> Or, to put this another way, the inherent limitations of using the DNS > to >> provide the mapping from address to PGP key restricts the domain of >> applicability of this specification to domains with particular > local-part >> policies, and the way in which the local-part to DNS mapping is > specified >> determines which policies the specification supports. And while it > seems >> logical to support a policy that's known to be in wide use, the > specification >> also needs to be very clear that domains that employ case-sensitive > local-parts >> MUST NOT avail themselves of this mechanism. > > I don't think I agree on "MUST NOT" here, because I think an email owner > can publish the preferred form (which can be lowercased) or even multiple > common forms of the email address. E.g. I can publish DNS records for > alexey.melnikov@isode.com, Alexey.Melnikov@isode.com and > ALEXEY.MELNIKOV@isode.com, but not others. The problem with putting any text into the document regarding case is that a few people in the working group deemed that mentioning the case issue would only lead implementations to "illegally" lowercase it. I was explicitly prevented from adding any text about lowercase/uppercase. What you are asking me to do here, is exactly that - introduce text to mention the lowercase problem. I do believe it is only logical to lowercase and that case-sensitive local-parts do not effectively exist on the internet. This can further be seen by the references implemention section that lists only software that performs this "illegal" lowercase. I will need guidance from the IESG on how to proceed. If we do not add lowercasing as a step before hashing, please let me know what text should be added where, so that I do not run into new objections within the working group. >> What needs to happen here is that the specification be revised to make > it clear >> that this is what is going on: That by publishing such records a domain > is >> granting a limited right to interpret the local parts of its > addresses. > > I agree with this. A sentence or two on this would suffice. Can the IESG please provide the text and location for this, as some in the working group are loudly opposed to any such text. > --------------- > > 3) The following issues/comments/questions were reported earlier: > > 5.1. Obtaining an OpenPGP key for a specific email address > > If no OpenPGP public keys are known for an email address, an > OPENPGPKEY DNS lookup MAY be performed to seek the OpenPGP public key > that corresponds to that email address. This public key can then be > used to verify a received signed message or can be used to send out > an encrypted email message. An application whose attempt fails to > retrieve a DNSSEC verified OPENPGPKEY RR from the DNS should remember > that failure for some time to avoid sending out a DNS request for > each email message the application is sending out; such DNS requests > constitute a privacy leak > > Should the document give a specific recommendation about "remember for > some time"? Is it tied to TTL for the corresponding RR? > If you can provide some additional text explaining what is reasonable (or > not) here, that would improve the specification. I do not think the TTL should be used here for key management. The TTL relates to the DNS transport and caching only. Paul From nobody Tue Apr 19 13:10:20 2016 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7A8612DBE1; Tue, 19 Apr 2016 13:10:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.297 X-Spam-Level: X-Spam-Status: No, score=-5.297 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, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2TCqs8A7HZqa; Tue, 19 Apr 2016 13:10:15 -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 802BC12B056; Tue, 19 Apr 2016 13:10:15 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id D6570BE54; Tue, 19 Apr 2016 21:10:13 +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 VEdtIpOJUA0Z; Tue, 19 Apr 2016 21:10:06 +0100 (IST) Received: from [10.87.49.100] (unknown [86.46.28.69]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id D53DEBE49; Tue, 19 Apr 2016 21:10:04 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1461096605; bh=iANZMBiFUEMtI7t/jAjtfrGoQVDTibgCa+MvI3SQIRM=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=knvJeS0SSAinBbFE76pO5U0jsGSPbcKyPKIT/8ewHccyY2BNHD3hm5SQGedNrwi5K BVJ0NwJjy5jiv61Z6jH1xLDqQzMbdZyxjL+ZrqK7Q+MKEV2uQhB75hLuq9b7/uQGPl GrC4cSM7zOIUeHkgnX5ZBcbCohvzNCyiDkwR3qto= To: Paul Wouters , Alexey Melnikov , The IESG References: <20160419174240.31613.95778.idtracker@ietfa.amsl.com> <57168F9E.7080309@redhat.com> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <5716909C.9030606@cs.tcd.ie> Date: Tue, 19 Apr 2016 21:10:04 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <57168F9E.7080309@redhat.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms080003010307000006020103" Archived-At: Cc: draft-ietf-dane-openpgpkey@ietf.org, dane-chairs@ietf.org, dane@ietf.org Subject: Re: [dane] Alexey Melnikov's Discuss on draft-ietf-dane-openpgpkey-09: (with DISCUSS and COMMENT) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.17 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, 19 Apr 2016 20:10:19 -0000 This is a cryptographically signed message in MIME format. --------------ms080003010307000006020103 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Thanks Paul for the really speedy response. I'll raise the outstanding points on the IESG telechat and respond after the IESG has discussed those. (Alexey and/or other ADs might choose to also respond in the meantime which is also fine.) Cheers, S. On 19/04/16 21:05, Paul Wouters wrote: > On 04/19/2016 01:42 PM, Alexey Melnikov wrote: >> Alexey Melnikov has entered the following ballot position for >> draft-ietf-dane-openpgpkey-09: Discuss >> >> 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 thi= s >> introductory paragraph, however.) >> >> >> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.h= tml >> 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-openpgpkey/ >> >> >> >> ----------------------------------------------------------------------= >> DISCUSS: >> ----------------------------------------------------------------------= >> >> NOTE to editors: Thank you for addressing my earlier comments in -09. >> If you need any more specific suggestions about text being >> added/deleted/updated, please let me know. >=20 > I have addressed most issues and incorporated most suggestions. See bel= ow for the two issues left. >=20 > https://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-dane-openpgpkey-10.txt= >=20 >> Despite many objections to publishing this specification I believe we >> should run the experiment. I will vote "Yes" once DISCUSS-points are >> addressed. I would rather see this experiment being done and fail (or >> better - succeed), than to block publication of this document because = it >> is not perfect. >> >> 1). As per Sean Leonard/Ned Freed: >> >> There's also - as noted by Sean Leonard - a technical glitch in the >> current >> specification: The local-part is not the correct input to the hash >> function. A >> canonicalization step is needed because all of these addresses are >> equivalent: >> >> (1) first.last@example.com >> (2) first . last @example.com >> (3) "first.last"@example.com >> (4) "\f\i\r\s\t.last"@example.com >> >> (2) is equivalent to (1) because CWS has no semantics, (3) is equivale= nt >> to >> (1) because the enclosing quotes are not properly part of the address,= >> and (4) >> is equivalent to (1) because quoted-pairs are semantically equivalent = to >> just the quoted character. >> =20 >> I believe this is the entire list, so the obvious canonicalization to >> use >> on the local-part portion of an address prior to hashing is: >> =20 >> (a) If the local-part is unquoted remove any whitespace (CFWS) around >> "."s. >> (b) Remove any enclosing double quotes. >> (c) Remove any literal quoting. >=20 > I have added this to the document. >=20 >=20 >> 2). Ned Freed wrote: >> >>> First, there's no way to define a mapping of local-parts to a new set= >> of >>> identifiers *without* effectively interpreting the local-part! If you= >> define >>> the mapping as the draft currently does, implicit in that definition = is >> that >>> local-parts are case-sensitive. And similarly, if you convert the >> local-part to >>> lower (or upper) case, you're now assuming the local-part is >> case-insensitive. >>> >>> And in the case of EAI, without some sort of normalization you're >> assuming that >>> different UTF-8 representations of the same string of characters >> correspond to >>> different recipients. (Which, as Harald Alvestrand and I both pointed= >> out on >>> the IETF list, is technically untenable and needs to be addressed. My= >>> suggestion was and is to specify that the same case-folding and >> normalization >>> algorithm used for IDNs also be employed here.) >> >> RFC 6532 and Section 10.1 of RFC 6530 recommend using NFC Unicode >> Normalization Form. (This is similar to what IDN recommends, although >> there is no standard mapping there.) I think it would be reasonable fo= r >> this document to say SHOULD apply NFC before hashing. >=20 > I have added this to the document. >=20 >=20 >=20 >> >> >> ----------------------------------------------------------------------= >> COMMENT: >> ----------------------------------------------------------------------= >> >> Some (edited) comments from Ned Freed that I (mostly) agree with: >> >> 1) In Section 3: >> >> Finally, a couple of observations about terminology are in order. The >> current >> text covering the hashing of local-parts begins with: >> =20 >> The user name (the "left-hand side" of the email address, calle= d >> the "local-part" in the mail message format definition [RFC5322= ] >> and the local-part in the specification for internationalized >> email [RFC6530]) is encoded in UTF-8 (or its subset ASCII). If= >> the local-part is written in another encoding it MUST be >> converted >> to UTF-8. >> =20 >> First, the left hand side of an email address is not a "user name" and= >> should >> not be referred to as such. (The entire address is in some cases a "us= er >> name" >> of sorts, and in some cases the local-part is identical to some kind o= f >> login >> credential. But neither of these are universally true, and more to the= >> point, >> none of this is relevant to the matter at hand.) >=20 > This has been changed to use local-part instead of user name. >=20 >> Second, it probably makes sense to note that local-part is an ABNF >> production contained in a broader syntax, not just a name. >=20 > See above. text was changed. >=20 >> Third, the term "encoding" here is inaccurate; it should be "charset".= >=20 > Fixed. >=20 >> 2) Ned Freed wrote: >> >>> So when a domain owner publishes such records in the DNS, a reasonabl= e >> way to >>> look at it is that they are effectively saying, "Everyone is allowed >> to >>> interpret the local-parts of our addresses as specified in this >> document in >>> this on e narrow context." I'm pretty confident there's nothing in an= y >> standard >>> that forbids such a delegation of authority. >>> >>> And once you realize this is what is going on, not only does it becom= e >> clear >>> that this draft is *not* violating the longstanding rules about >> local-part >>> interpretation, it casts the decision not to normalize the local-part= s >> to lower >>> (or upper) case in an entirely different light. By choosing not to >> normalize >>> this specification is effectively restricting its own applicability t= o >> domains >>> with case-sensitive local parts. That is, IMO, a highly suboptimal >> choice - the >>> overwhelming majority of domains treat the local part in a >> case-insensitive >>> fashion, and so should the mechanism specified in this draft. >>> >>> Or, to put this another way, the inherent limitations of using the DN= S >> to >>> provide the mapping from address to PGP key restricts the domain of >>> applicability of this specification to domains with particular >> local-part >>> policies, and the way in which the local-part to DNS mapping is >> specified >>> determines which policies the specification supports. And while it >> seems >>> logical to support a policy that's known to be in wide use, the >> specification >>> also needs to be very clear that domains that employ case-sensitive >> local-parts >>> MUST NOT avail themselves of this mechanism. >> >> I don't think I agree on "MUST NOT" here, because I think an email own= er >> can publish the preferred form (which can be lowercased) or even multi= ple >> common forms of the email address. E.g. I can publish DNS records for >> alexey.melnikov@isode.com, Alexey.Melnikov@isode.com and >> ALEXEY.MELNIKOV@isode.com, but not others. >=20 > The problem with putting any text into the document regarding case is t= hat a few people in the working group > deemed that mentioning the case issue would only lead implementations t= o "illegally" lowercase it. I was > explicitly prevented from adding any text about lowercase/uppercase. Wh= at you are asking me to do here, > is exactly that - introduce text to mention the lowercase problem. >=20 > I do believe it is only logical to lowercase and that case-sensitive lo= cal-parts do not effectively exist on > the internet. This can further be seen by the references implemention s= ection that lists only software that > performs this "illegal" lowercase. >=20 > I will need guidance from the IESG on how to proceed. If we do not add = lowercasing as a step before hashing, > please let me know what text should be added where, so that I do not ru= n into new objections within the working group. >=20 >>> What needs to happen here is that the specification be revised to mak= e >> it clear >>> that this is what is going on: That by publishing such records a doma= in >> is >>> granting a limited right to interpret the local parts of its >> addresses. >> >> I agree with this. A sentence or two on this would suffice. >=20 > Can the IESG please provide the text and location for this, as some in = the working group are loudly opposed to any such text. >=20 >=20 >> --------------- >> >> 3) The following issues/comments/questions were reported earlier: >> >> 5.1. Obtaining an OpenPGP key for a specific email address >> >> If no OpenPGP public keys are known for an email address, an >> OPENPGPKEY DNS lookup MAY be performed to seek the OpenPGP public k= ey >> that corresponds to that email address. This public key can then b= e >> used to verify a received signed message or can be used to send out= >> an encrypted email message. An application whose attempt fails to >> retrieve a DNSSEC verified OPENPGPKEY RR from the DNS should rememb= er >> that failure for some time to avoid sending out a DNS request for >> each email message the application is sending out; such DNS request= s >> constitute a privacy leak >> >> Should the document give a specific recommendation about "remember for= >> some time"? Is it tied to TTL for the corresponding RR? >> If you can provide some additional text explaining what is reasonable = (or >> not) here, that would improve the specification. >=20 > I do not think the TTL should be used here for key management. The TTL = relates to the DNS transport and caching only. >=20 > Paul >=20 > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane >=20 --------------ms080003010307000006020103 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjA0MTky MDEwMDRaMC8GCSqGSIb3DQEJBDEiBCAeo/HgrX7qRfs0p+ik4f0Ig5NaZcl1f61Q43QXLnfn gjBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQCIAQj5fNIEXZfY/e7Yp9VEpnLcva52rRntVgXroiwdQCnbG3p4UvAO gYPcwka0L6fY4xp86usT5gh1sgDI/XBBkA2zmD6b/cqmPB1C5Hwcm+mBdnmiH9AYgFS7F3qc kFiXA/l7pWES0AJ5T7soKOwJscq6EzjtkMBx3dYBzRxFNn5ROMgtR6Vjwvr3A+qNWhMH/9JI uoyEvChCHrWnqNAA0URwWThl8tfdlWhAgyD7Wh/GqgHDgv2YYz2/yHPDE/0hwy7V2WToBnHR 1Ryn2OsS820/jyYwBQyRRgUkpto8B2NiRglfMYFdkd/LVeYNpVbV7I72ew13dy4Ja0rI4DTX AAAAAAAA --------------ms080003010307000006020103-- From nobody Wed Apr 20 04:02:42 2016 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21E7912E48A for ; Wed, 20 Apr 2016 04:02:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 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, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fastmail.fm header.b=jK0iO3Pp; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=Q9ICXnq/ Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fwMDRkkkFBnz for ; Wed, 20 Apr 2016 04:02:39 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 50F3D12E3EF for ; Wed, 20 Apr 2016 04:02:39 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id A20A8208B2 for ; Wed, 20 Apr 2016 07:02:38 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute2.internal (MEProxy); Wed, 20 Apr 2016 07:02:38 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=fastmail.fm; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=mesmtp; bh=D9wYMt9GvypTX+y0oOo9Bk5NdOg=; b=jK0iO3 Ppk4Q0aHlIfySQ2dB1p0HhG4/Vh/lvkLTfQkueAND3pKHzpSzr8xROOVsvCQTZWt QCwQ2A+6GtltMVmOUifosfx5W+oeZy0uBnZbP6gcRhR7Rm6plscb0179JB9Q/xOl FIB7bq5EXfO9YAbQExXQOUakqDjeQY54iwMEk= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=D9wYMt9GvypTX+y 0oOo9Bk5NdOg=; b=Q9ICXnq/nL0ud87BnAZqXFR7VkZWeXUYXc6icx04+H+jUb6 PLpmmhIFVWFeh3+AP0dWDGf4UTvEHG+kzWZsyha+YepJebWNz4Jow2bQLl1HrwBT pRoa4ZvNGPcHyO+s2K0ii93sgcK3H/+0ZoUEsBzgOvxbyx3kutpOkTe/VK9E= X-Sasl-enc: 1Xvt5KuFRlYKxeHqN+O5/IAeNNVyCBfxSYONQhJniQSD 1461150157 Received: from [10.11.57.169] (unknown [212.183.128.113]) by mail.messagingengine.com (Postfix) with ESMTPA id DDE13680185; Wed, 20 Apr 2016 07:02:36 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Alexey Melnikov X-Mailer: iPhone Mail (13E238) In-Reply-To: <57168F9E.7080309@redhat.com> Date: Wed, 20 Apr 2016 12:04:25 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20160419174240.31613.95778.idtracker@ietfa.amsl.com> <57168F9E.7080309@redhat.com> To: Paul Wouters Archived-At: Cc: draft-ietf-dane-openpgpkey@ietf.org, The IESG , dane-chairs@ietf.org, dane@ietf.org Subject: Re: [dane] Alexey Melnikov's Discuss on draft-ietf-dane-openpgpkey-09: (with DISCUSS and COMMENT) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.17 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, 20 Apr 2016 11:02:41 -0000 Hi Paul, A very quick reply, as I am travelling. I will do a longer version later: > On 19 Apr 2016, at 21:05, Paul Wouters wrote: >=20 > I will need guidance from the IESG on how to proceed. If we do not add low= ercasing as a step before hashing, > please let me know what text should be added where, so that I do not run i= nto new objections within the working group. I will suggest some text. I think we shouldn't add text about unconditional lower casing, but instead w= e should acknowledge that some systems are case sensitive (I think MTA from m= y employer can be like that when gatewaying to other email systems) and some= are not. >=20 >>> What needs to happen here is that the specification be revised to make >> it clear >>> that this is what is going on: That by publishing such records a domain >> is >>> granting a limited right to interpret the local parts of its >> addresses. >>=20 >> I agree with this. A sentence or two on this would suffice. >=20 > Can the IESG please provide the text and location for this, as some in the= working group are loudly opposed to any such text. Considering that this proposal came from an email expert, I don't think it w= ould be controversial. (Earlier objection were from email experts.) But mayb= e I am optimistic. I will suggest some text. From nobody Wed Apr 20 05:20:25 2016 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5FCF12E375 for ; Wed, 20 Apr 2016 05:20:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 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, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fastmail.fm header.b=qzmCJdi5; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=aSUyxN7V Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b1DIwghClGsU for ; Wed, 20 Apr 2016 05:20:20 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD5A212E528 for ; Wed, 20 Apr 2016 05:20:18 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 3801C21333 for ; Wed, 20 Apr 2016 08:20:18 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute3.internal (MEProxy); Wed, 20 Apr 2016 08:20:18 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=fastmail.fm; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=mesmtp; bh=XTSYvSJvV7NNKzLJUEw/lfQwqAo=; b=qzmCJd i5JX88JFmviiqQ6uBa62YKkhUH5Pi8Q4II29hZqDg57sP8S4+vIBLFUrD3o0dsuh PfydwPu5kvLG4aII0Djp0K/DFQByiEEWMdxxRLEiNgjKyhGwU/UedozDfjYKl4G9 wt0cSKjnJczrel2QWryjYHG2H9Udam5jiHr8w= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=XTSYvSJvV7NNKzL JUEw/lfQwqAo=; b=aSUyxN7VJ0QH3nyiU4xjcJr39U1UAdINVNJAYqkKzxxk+CI QhT+y/rh3f9yTsc5jgYKqzvrTmccGW2QDBuNNH4K4DdkNHHinrC71j8suBv+fpwy DMyTL0qFyF+QZ7m213PiEZLmG8Dr977xXg+6q/mmal6C1v3ybenaKcHXo+Ow= X-Sasl-enc: Z4QYCRAGQ0nrFIBp/J7loxQE5VPxs8sRioarpLkk1Gwz 1461154817 Received: from [10.11.57.169] (unknown [212.183.128.116]) by mail.messagingengine.com (Postfix) with ESMTPA id AD31AC00017; Wed, 20 Apr 2016 08:20:17 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (1.0) From: Alexey Melnikov In-Reply-To: <57168F9E.7080309@redhat.com> Date: Wed, 20 Apr 2016 13:01:01 +0100 Message-Id: <4D583599-C07B-4E89-95F3-DD76B62CB751@fastmail.fm> References: <20160419174240.31613.95778.idtracker@ietfa.amsl.com> <57168F9E.7080309@redhat.com> To: Paul Wouters X-Mailer: iPhone Mail (13E238) Archived-At: Cc: draft-ietf-dane-openpgpkey@ietf.org, The IESG , dane-chairs@ietf.org, dane@ietf.org Subject: Re: [dane] Alexey Melnikov's Discuss on draft-ietf-dane-openpgpkey-09: (with DISCUSS and COMMENT) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.17 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, 20 Apr 2016 12:20:24 -0000 Hi Paul, On 19 Apr 2016, at 21:05, Paul Wouters wrote: >> 5.1. Obtaining an OpenPGP key for a specific email address >>=20 >> If no OpenPGP public keys are known for an email address, an >> OPENPGPKEY DNS lookup MAY be performed to seek the OpenPGP public key >> that corresponds to that email address. This public key can then be >> used to verify a received signed message or can be used to send out >> an encrypted email message. An application whose attempt fails to >> retrieve a DNSSEC verified OPENPGPKEY RR from the DNS should remember >> that failure for some time to avoid sending out a DNS request for >> each email message the application is sending out; such DNS requests >> constitute a privacy leak >>=20 >> Should the document give a specific recommendation about "remember for >> some time"? Is it tied to TTL for the corresponding RR? >> If you can provide some additional text explaining what is reasonable (or= >> not) here, that would improve the specification. >=20 > I do not think the TTL should be used here for key management. The TTL rel= ates to the DNS transport and caching only. That is fine, but you don't say that one way or another. My concern is that t= he document doesn't provide any specific details here on what is reasonable a= nd what is not. Even putting a specific number here (if you think you can) w= ould be better, IMHO. Best Regards, Alexey From nobody Wed Apr 20 12:29:28 2016 Return-Path: X-Original-To: dane@ietf.org Delivered-To: dane@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C266812E3BE; Wed, 20 Apr 2016 12:29:23 -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.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160420192923.808.61947.idtracker@ietfa.amsl.com> Date: Wed, 20 Apr 2016 12:29:23 -0700 Archived-At: Cc: draft-ietf-dane-openpgpkey@ietf.org, dane-chairs@ietf.org, dane@ietf.org Subject: [dane] Ben Campbell's No Objection on draft-ietf-dane-openpgpkey-10: (with COMMENT) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.17 List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2016 19:29:24 -0000 Ben Campbell has entered the following ballot position for draft-ietf-dane-openpgpkey-10: 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-openpgpkey/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I agree with Mirja that it would be nice if the shepherd's writeup were updated to reflect the experimental status. From nobody Wed Apr 20 14:45:46 2016 Return-Path: X-Original-To: dane@ietf.org Delivered-To: dane@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3292C12DC7A; Wed, 20 Apr 2016 14:45:45 -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.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160420214545.800.62731.idtracker@ietfa.amsl.com> Date: Wed, 20 Apr 2016 14:45:45 -0700 Archived-At: Cc: draft-ietf-dane-openpgpkey@ietf.org, dane-chairs@ietf.org, dane@ietf.org Subject: [dane] Alissa Cooper's No Objection on draft-ietf-dane-openpgpkey-10: (with COMMENT) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.17 List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2016 21:45:45 -0000 Alissa Cooper has entered the following ballot position for draft-ietf-dane-openpgpkey-10: 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-openpgpkey/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I know there has been a lot of list discussion of this draft so I apologize if these issues have already been discussed before. I think if this sees any sizable deployment, it will be trivial for attackers to use it to harvest email addresses from the DNS. Section 7.4 therefore seems to be quite misleading. I don't see why a zone walk is necessary to do this kind of harvesting when an attacker could just send one query per entry in its dictionary. I think it would be more accurate to say that by using this mechanism, people are effectively making their email addresses public. I also think the mechanism could facilitate pervasive monitoring as described in RFC 7258, as it potentially makes a whole class of entities (resolvers) into repositories of detailed data about who has communicated with whom via email. To the extent that large DNS providers keep logs about individual queries, it seems like those logs could become prime attack targets. The mechanism specified here can obviously help mitigate pervasive monitoring in other ways, but I think the draft needs to be up front about the trade-offs between potentially exposing metadata to a wider pool of entities and attackers in exchange for more easily being able to protect content. From nobody Wed Apr 20 15:00:04 2016 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9699012DA1D for ; Wed, 20 Apr 2016 15:00:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jn_KuVjRoF8f for ; Wed, 20 Apr 2016 15:00:01 -0700 (PDT) Received: from mail-qg0-x234.google.com (mail-qg0-x234.google.com [IPv6:2607:f8b0:400d:c04::234]) (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 E45EC12DB00 for ; Wed, 20 Apr 2016 15:00:00 -0700 (PDT) Received: by mail-qg0-x234.google.com with SMTP id d90so7176781qgd.3 for ; Wed, 20 Apr 2016 15:00:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=TDYpd1zmUf1SoJqXPFx9n8yu8PzCSYPbMsOmp61abGw=; b=l7pfnC801hzbL12A3b7kZFqywM02J6tg4IbpDiUewoykcckEfAYGrjadF49fDcryQ5 llNGJ7NTxAWkoBrwmxr49OEqz++CW4VBOIbhxL37UB4bN4gM4EwbcSek3hcxmK7ZqBsd 4eZaZT5uP9LCH+f+IFWxNmSGYsJwJzgNmibLwrHhAwgp7sI4dBdCARhE1RwE2r0HzIZX RysmvGHhNxwtL/Rs+7WDMz3B2B5CUh/pT6HOZqBk4CTn8z7q5hx1inIi9UHmQhqMOom2 dozwH1vf/gjztNUQOwiFk3q3Z2MPpOPVHILoD71rd/+uaXh77xal2gypwCTbOt1A3t7j ZCKQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=TDYpd1zmUf1SoJqXPFx9n8yu8PzCSYPbMsOmp61abGw=; b=Mnc+fy0k8tCDd7CKNW2tl3wzt0ZS/DZBnWZHrokb0wDd0rTt4HjBPo57x/o5eG0+sE btmMbLjUXJJ9+dXZN6uH04zrfHiKzKkCiitV+ztQdaxvJD3zMfr4WiTEMHleYNl0/Eoo o/35mhbSLZ2iIAtq2W9g9BzYY7PRw+FTXnUJXCFJ8Tc0DYKAqPKt75Y08TZ4Ejgl4Jts kT+BRiPsQdztbSioVGVBlW+dvFxtKpSZaUKG2nanPOmwWVFJkPGMNW+ehIJb06gEFCGe kQBcDkLoIuMuJ/u2iLU7rUw/xs9WgdMDZfX5UAGiFtlMwDH3FA9Om9Qj/SvAWokDj3Hm WeQw== X-Gm-Message-State: AOPr4FWiDX68HnEXDs197bgJNg5WN4nMO+1k/i7eIQMk/soqSvZkjzPl+ekAFBzRZKT/ZQkgHDMt4yXc65RBshO2 X-Received: by 10.140.158.15 with SMTP id e15mr14869015qhe.12.1461189599944; Wed, 20 Apr 2016 14:59:59 -0700 (PDT) MIME-Version: 1.0 References: <20160419174240.31613.95778.idtracker@ietfa.amsl.com> <57168F9E.7080309@redhat.com> In-Reply-To: From: Warren Kumari Date: Wed, 20 Apr 2016 21:59:49 +0000 Message-ID: To: Alexey Melnikov , Paul Wouters Content-Type: multipart/alternative; boundary=001a1139d5f00df7570530f1b787 Archived-At: Cc: draft-ietf-dane-openpgpkey@ietf.org, The IESG , dane-chairs@ietf.org, dane@ietf.org Subject: Re: [dane] Alexey Melnikov's Discuss on draft-ietf-dane-openpgpkey-09: (with DISCUSS and COMMENT) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.17 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, 20 Apr 2016 22:00:02 -0000 --001a1139d5f00df7570530f1b787 Content-Type: text/plain; charset=UTF-8 On Wed, Apr 20, 2016 at 7:02 AM Alexey Melnikov wrote: > Hi Paul, > A very quick reply, as I am travelling. I will do a longer version later: > > > On 19 Apr 2016, at 21:05, Paul Wouters wrote: > > > > I will need guidance from the IESG on how to proceed. If we do not add > lowercasing as a step before hashing, > > please let me know what text should be added where, so that I do not run > into new objections within the working group. > > I will suggest some text. > Thank you! > > I think we shouldn't add text about unconditional lower casing, but > instead we should acknowledge that some systems are case sensitive (I think > MTA from my employer can be like that when gatewaying to other email > systems) and some are not. > > > >>> What needs to happen here is that the specification be revised to make > >> it clear > >>> that this is what is going on: That by publishing such records a domain > >> is > >>> granting a limited right to interpret the local parts of its > >> addresses. > >> > >> I agree with this. A sentence or two on this would suffice. > > > > Can the IESG please provide the text and location for this, as some in > the working group are loudly opposed to any such text. > > Considering that this proposal came from an email expert, I don't think it > would be controversial. (Earlier objection were from email experts.) But > maybe I am optimistic. > I suspect you are being optimistic, but hopefully correctly so :-P W > > I will suggest some text. > > > --001a1139d5f00df7570530f1b787 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed= , Apr 20, 2016 at 7:02 AM Alexey Melnikov <aamelnikov@fastmail.fm> wrote:
Hi Paul,
A very quick reply, as I am travelling. I will do a longer version later:
> On 19 Apr 2016, at 21:05, Paul Wouters <pwouters@redhat.com> wrote:
>
> I will need guidance from the IESG on how to proceed. If we do not add= lowercasing as a step before hashing,
> please let me know what text should be added where, so that I do not r= un into new objections within the working group.

I will suggest some text.

Thank you!
=C2=A0

I think we shouldn't add text about unconditional lower casing, but ins= tead we should acknowledge that some systems are case sensitive (I think MT= A from my employer can be like that when gatewaying to other email systems)= and some are not.
>
>>> What needs to happen here is that the specification be revised= to make
>> it clear
>>> that this is what is going on: That by publishing such records= a domain
>> is
>>> granting a limited right to interpret the local parts of its >> addresses.
>>
>> I agree with this. A sentence or two on this would suffice.
>
> Can the IESG please provide the text and location for this, as some in= the working group are loudly opposed to any such text.

Considering that this proposal came from an email expert, I don't think= it would be controversial. (Earlier objection were from email experts.) Bu= t maybe I am optimistic.

I suspect you = are being optimistic, but hopefully correctly so :-P
W
= =C2=A0

I will suggest some text.


--001a1139d5f00df7570530f1b787-- From nobody Wed Apr 20 17:02:20 2016 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0BC312EE1B for ; Wed, 20 Apr 2016 17:02:18 -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 autolearn_force=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 ppdaomt2GmOl for ; Wed, 20 Apr 2016 17:02:17 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5552912EE1A for ; Wed, 20 Apr 2016 17:02:17 -0700 (PDT) Received: (qmail 82396 invoked from network); 21 Apr 2016 00:02:15 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 21 Apr 2016 00:02:15 -0000 Date: 21 Apr 2016 00:01:53 -0000 Message-ID: <20160421000153.18739.qmail@ary.lan> From: "John Levine" To: dane@ietf.org In-Reply-To: <20160420214545.800.62731.idtracker@ietfa.amsl.com> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Cc: alissa@cooperw.in Subject: Re: [dane] Alissa Cooper's No Objection on draft-ietf-dane-openpgpkey-10: (with COMMENT) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.17 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, 21 Apr 2016 00:02:18 -0000 >I think if this sees any sizable deployment, it will be trivial for >attackers to use it to harvest email addresses from the DNS. Section 7.4 >therefore seems to be quite misleading. I don't see why a zone walk is >necessary to do this kind of harvesting when an attacker could just send >one query per entry in its dictionary. I think it would be more accurate >to say that by using this mechanism, people are effectively making their >email addresses public. I think this draft is a bad idea and should not be published at all, but that isn't one of the reasons. Address harvesting has been a problem for decades, since anyone can do a partial SMTP transaction up to the RCPT TO stage to verify addresses. There are even companies that will check lists of addresses for you to try and weed out the invalid ones. Countermeasures are widely known in the e-mail community. The obvious one is rate limiting, but it turns out that a more effective one is to lie and say all addresses are valid (in this case by returning fake but plausible certificates.) We often see the validation places start by probing a bunch of random made up addresses to see if a domain says yes to everything and then give up when it sees that we do. >I also think the mechanism could facilitate pervasive monitoring as >described in RFC 7258, ... That, on the other hand is a problem: this draft has no security model beyond saying it's not the web of trust. With SMTP address probes, the target system has some idea who it's talking to, and can require TLS to prevent third parties from observing the traffic. With DNS, the traffic all goes unencrypted via caches. The caches are often not under the same management as the end system, and caches routinely provide data to third parties for forensic and other purposes. See, for example, Farsight Security, run by people we all know, which provides a large and interesting database of DNS query traffic to its clients who use it to track down various sorts of online badness. Everything published in the DNS has traditionally been public. Some people imagine that the contents of their zone files are proprietary, but we know they're silly. Publishing information that's semi-private, or that contains PII, is a significant change of DNS semantics, and its implications need far more careful evaluation than this draft does. R's, John PS: It also has downgrade problems, see prior messages on that topic. From nobody Thu Apr 21 07:07:07 2016 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A947912E6B2; Thu, 21 Apr 2016 07:07:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, RP_MATCHES_RCVD=-0.996] autolearn=no autolearn_force=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 Za9CN2XVAt4o; Thu, 21 Apr 2016 07:06:58 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (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 5382412E324; Thu, 21 Apr 2016 07:06:58 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3qrLCf28j9z389; Thu, 21 Apr 2016 16:06:54 +0200 (CEST) X-OPENPGPKEY: Message passed unmodified X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id JH4I2LQF_N9n; Thu, 21 Apr 2016 16:06:51 +0200 (CEST) Received: from ns0.nohats.ca (ns0.nohats.ca [IPv6:2a03:6000:1004:1::102]) by mx.nohats.ca (Postfix) with ESMTP; Thu, 21 Apr 2016 16:06:51 +0200 (CEST) Received: by ns0.nohats.ca (Postfix, from userid 500) id 797E641BE1; Thu, 21 Apr 2016 10:06:49 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by ns0.nohats.ca (Postfix) with ESMTP id 738F23F4C3; Thu, 21 Apr 2016 10:06:49 -0400 (EDT) Date: Thu, 21 Apr 2016 10:06:49 -0400 (EDT) From: Paul Wouters To: Alissa Cooper In-Reply-To: <20160420214545.800.62731.idtracker@ietfa.amsl.com> Message-ID: References: <20160420214545.800.62731.idtracker@ietfa.amsl.com> User-Agent: Alpine 2.20 (LRH 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Cc: draft-ietf-dane-openpgpkey@ietf.org, The IESG , dane-chairs@ietf.org, dane@ietf.org Subject: Re: [dane] Alissa Cooper's No Objection on draft-ietf-dane-openpgpkey-10: (with COMMENT) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.17 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, 21 Apr 2016 14:07:05 -0000 On Wed, 20 Apr 2016, Alissa Cooper wrote: Hi Alissa, Thanks for the review. Comments inline, > I think if this sees any sizable deployment, it will be trivial for > attackers to use it to harvest email addresses from the DNS. Email addresses when used area really hard to keep secret. See also John's remarks on this. This just moves the online-smtp attack to an online-dns attack. Not that different. > Section 7.4 > therefore seems to be quite misleading. I don't see why a zone walk is > necessary to do this kind of harvesting when an attacker could just send > one query per entry in its dictionary. I think it would be more accurate > to say that by using this mechanism, people are effectively making their > email addresses public. Why send a DNS query for a hashed name when you can send a probe to the SMTP server? The only additional issue is that one could zonewalk to harvest the records, then perform an offline dictionary attack. But with DNSSEC white/black lies with an online signer these could be mitigated. One could even add records of non-existing users to bump the failure rate similar to John's described defense of always claiming any email address is valid. > I also think the mechanism could facilitate pervasive monitoring as > described in RFC 7258, as it potentially makes a whole class of entities > (resolvers) into repositories of detailed data about who has communicated > with whom via email. One could argue this deployment will actually more decentralise this. When a pervasive monitor sees an OPENPGPKEY query from 8.8.8.8 it knows less then if it sees a HTTP/HTTPS connect from some ISP owned DSL IP to a keyserver IP address. A pervasive monitor would also be able to keep track of that DSL IP and figure out the target domain or even target user at the domain. Match that with keyserver contents and TLS traffic size, they could pinpoint who you obtained a key for even if everything between keyserver, user and SMTP was protected by TLS. Currently, the only somewhat automated method is to query well known key servers or a search engine. There are only very few of these so much easier to pervasively monitor. For keyservers, I tend to use pgp.mit.edu and pgp.surfnet.nl. Both accept HTTP without redirect to HTTPS. One of them even does not work on HTTPS. > To the extent that large DNS providers keep logs > about individual queries, it seems like those logs could become prime > attack targets. DNS is gaining protection with both DNS-over-TLS and Query Minimalization. Endusers can pick DNS servers they trust. > The mechanism specified here can obviously help mitigate > pervasive monitoring in other ways, but I think the draft needs to be up > front about the trade-offs between potentially exposing metadata to a > wider pool of entities and attackers in exchange for more easily being > able to protect content. In fact, using the DNS and caches and a method of securely querying the DNS from any point on the network actually gives you a nice and good pool of anonimity required to hide. I would not know of a better method to do that currently. For instance, using TOR for DNS. Paul From nobody Thu Apr 21 07:12:18 2016 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52AA112E8D5; Thu, 21 Apr 2016 07:12:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.297 X-Spam-Level: X-Spam-Status: No, score=-5.297 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, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vXZPbq1EX16t; Thu, 21 Apr 2016 07:12:14 -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 DE54E12E825; Thu, 21 Apr 2016 07:12:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id A2F28BE73; Thu, 21 Apr 2016 15:12:10 +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 ovE0yh77cuER; Thu, 21 Apr 2016 15:12:10 +0100 (IST) Received: from [134.226.36.93] (bilbo.dsg.cs.tcd.ie [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id E43A9BE79; Thu, 21 Apr 2016 15:12:01 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1461247922; bh=Z1kgLT7kC0OfNEhIpzGMARpYVJEAZ7GJxKC5V13EU8k=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=KFA9YajbNhKkI39+BhEMrAsVpR3uF7FWGCDN3PWRnqmwiC0013B/DTC6GPrDhQYGw HIb4dYoznQQWK5k35jDMDdQJeCukwGonPpuk/QuwBmslPZOo0vfqzVGHTwtPhCiLkx Foql10ErjcQye9X6UTf/JeRacmc1egbHBFn/+8W8= To: Paul Wouters , Alissa Cooper References: <20160420214545.800.62731.idtracker@ietfa.amsl.com> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <5718DFB1.2030303@cs.tcd.ie> Date: Thu, 21 Apr 2016 15:12:01 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms050106040000000807060301" Archived-At: Cc: draft-ietf-dane-openpgpkey@ietf.org, The IESG , dane-chairs@ietf.org, dane@ietf.org Subject: Re: [dane] Alissa Cooper's No Objection on draft-ietf-dane-openpgpkey-10: (with COMMENT) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.17 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, 21 Apr 2016 14:12:16 -0000 This is a cryptographically signed message in MIME format. --------------ms050106040000000807060301 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Paul, On Alissa's 2nd point, I think there might be a useful sentence or two to add about the PM-relevant trade-offs between this approach and others, (if we can ensure those sentences aren't inflammatory:-). Do you think we could craft something along those lines to include? Cheers, S. On 21/04/16 15:06, Paul Wouters wrote: > On Wed, 20 Apr 2016, Alissa Cooper wrote: >=20 > Hi Alissa, >=20 > Thanks for the review. Comments inline, >=20 >> I think if this sees any sizable deployment, it will be trivial for >> attackers to use it to harvest email addresses from the DNS. >=20 > Email addresses when used area really hard to keep secret. See also > John's remarks on this. This just moves the online-smtp attack to an > online-dns attack. Not that different. >=20 >> Section 7.4 >> therefore seems to be quite misleading. I don't see why a zone walk is= >> necessary to do this kind of harvesting when an attacker could just se= nd >> one query per entry in its dictionary. I think it would be more accura= te >> to say that by using this mechanism, people are effectively making the= ir >> email addresses public. >=20 > Why send a DNS query for a hashed name when you can send a probe to the= > SMTP server? >=20 > The only additional issue is that one could zonewalk to harvest the > records, then perform an offline dictionary attack. But with DNSSEC > white/black lies with an online signer these could be mitigated. One co= uld > even add records of non-existing users to bump the failure rate similar= > to John's described defense of always claiming any email address is val= id. >=20 >> I also think the mechanism could facilitate pervasive monitoring as >> described in RFC 7258, as it potentially makes a whole class of entiti= es >> (resolvers) into repositories of detailed data about who has communica= ted >> with whom via email. >=20 > One could argue this deployment will actually more decentralise this. > When a pervasive monitor sees an OPENPGPKEY query from 8.8.8.8 it knows= > less then if it sees a HTTP/HTTPS connect from some ISP owned DSL IP to= > a keyserver IP address. A pervasive monitor would also be able to keep > track of that DSL IP and figure out the target domain or even target > user at the domain. Match that with keyserver contents and TLS traffic > size, they could pinpoint who you obtained a key for even if everything= > between keyserver, user and SMTP was protected by TLS. >=20 > Currently, the only somewhat automated method is to query well known > key servers or a search engine. There are only very few of these so muc= h > easier to pervasively monitor. For keyservers, I tend to use pgp.mit.ed= u > and pgp.surfnet.nl. Both accept HTTP without redirect to HTTPS. One of > them even does not work on HTTPS. >=20 >> To the extent that large DNS providers keep logs >> about individual queries, it seems like those logs could become prime >> attack targets. >=20 > DNS is gaining protection with both DNS-over-TLS and Query > Minimalization. Endusers can pick DNS servers they trust. >=20 >> The mechanism specified here can obviously help mitigate >> pervasive monitoring in other ways, but I think the draft needs to be = up >> front about the trade-offs between potentially exposing metadata to a >> wider pool of entities and attackers in exchange for more easily being= >> able to protect content. >=20 > In fact, using the DNS and caches and a method of securely querying the= > DNS from any point on the network actually gives you a nice and good > pool of anonimity required to hide. I would not know of a better method= > to do that currently. For instance, using TOR for DNS. >=20 > Paul >=20 > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane --------------ms050106040000000807060301 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjA0MjEx NDEyMDFaMC8GCSqGSIb3DQEJBDEiBCCfjJTJ4MKWbdHlqLKQZmefJQDvYkJE2M0BbZjscnG4 JDBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQB/cyC/YrbEGiCNN90t6Jm1HwTHyc0F0QjqcEn0+eKB8dkuQLEWjFTn FYVHWktroFHWGLERfbKgKeN2WqHt7eB1+r/H7MmD2BD7hZsMvbT4k3reZvGceCjiuFTcFJcx SDAIdnHbNthrNKOpUqJfC5U31MQacCHGMDOLBTppUK95N56EQCwgvhT+40ivYiFWaNU/fesA jf+C4hIEFFwEbZC7lF4CgjAr5iKQXDs4JITmzpyQBCPi9yXpCbnJMla3nKCGVPn0khsaXR1y +jKFynPS/v+ghDJLvzCgiOLQsli+yZ8OUsjg0LSGmBAObQZOm1D0EwkfBvDqzmYvyKiJWNuB AAAAAAAA --------------ms050106040000000807060301-- From nobody Thu Apr 21 09:17:42 2016 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE72E12DAA9; Thu, 21 Apr 2016 09:17:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=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 CGGS1JKiyVrV; Thu, 21 Apr 2016 09:17:37 -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 5B57712E082; Thu, 21 Apr 2016 09:17:36 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 1AE41284951; Thu, 21 Apr 2016 16:17:35 +0000 (UTC) Date: Thu, 21 Apr 2016 16:17:35 +0000 From: Viktor Dukhovni To: uta@ietf.org, dane@ietf.org Message-ID: <20160421161734.GO26423@mournblade.imrryr.org> References: <20160414183856.GL26423@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160414183856.GL26423@mournblade.imrryr.org> User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [dane] [Uta] NEWSFLASH: DANE TLSA records published for web.de! X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: uta@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, 21 Apr 2016 16:17:39 -0000 On Thu, Apr 14, 2016 at 06:38:56PM +0000, Viktor Dukhovni wrote: > The web.de domain has just published DANE TLSA records for its MX > hosts. And today also the rest of the major 1&1 (Mail&Media) email domains: gmx.de gmx.net gmx.com gmx.ch gmx.at > This is a major milestone in DANE adoption. [ IIRC they host > mailboxes for a substantial fraction of the population of Germany. ] https://icannwiki.com/.gmx With over 32 million customers Mail&Media covers nearly 50% of the German Webmail market. With its brands, Mail&Media is the largest free email provider in the German speaking countries of Germany, Switzerland, Austria, Luxembourg and Liechtenstein. Together with web.de this likely makes over 30 million recently added mailboxes with DANE TLSA records. DANE is now supported by the below home internet / email / hosting providers. gmx.at gmx.ch gmx.com mail.com gmx.de posteo.de unitymedia.de web.de comcast.net gmx.net t-2.net xs4all.net xs4all.nl transip.nl udmedia.de nederhost.net DANE is no longer just at hobbyist domains and a few smaller early adopters like Posteo and Unitymedia. This is starting to get interesting. While the even larger Gmail, Outlook.com/Hotmail, Yahoo ... are not in the near term in a position to deploy DNSSEC, I expect that doing so is simpler for outlook.com, because this domain does not overlap with major web properties whose scale makes the transition considerably more difficult. So it would be great to add Microsoft to the above list some time in 2017 (or sooner). DANE for gmail.com is also plausible without impacting all of Google, but requires moving the MX hosts out of the present google.com. -- Viktor. From nobody Fri Apr 22 02:39:09 2016 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32FF312E879 for ; Fri, 22 Apr 2016 02:39:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.896 X-Spam-Level: X-Spam-Status: No, score=-2.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996] autolearn=ham autolearn_force=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 UZobSqLKqkaZ for ; Fri, 22 Apr 2016 02:39:05 -0700 (PDT) Received: from mailer.kwsoft.de (mailer.kwsoft.de [IPv6:2a03:3500:111:4::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C8B012EBF6 for ; Fri, 22 Apr 2016 02:39:05 -0700 (PDT) Received: from mailer (localhost [127.0.0.1]) by mailer.kwsoft.de (Postfix) with ESMTP id 7082118128C for ; Fri, 22 Apr 2016 11:39:02 +0200 (CEST) Received: from webmail (ftp.kwsoft.de [213.164.67.83]) by mailer.kwsoft.de (Postfix) with ESMTPS id CFABA1810C9 for ; Fri, 22 Apr 2016 11:39:01 +0200 (CEST) Received: from hoedlepc.hq.kwsoft.de (hoedlepc.hq.kwsoft.de [10.1.53.102]) by webmail.kwsoft.de (Horde Framework) with HTTP; Fri, 22 Apr 2016 11:39:01 +0200 Date: Fri, 22 Apr 2016 11:39:01 +0200 From: lst_hoe02@kwsoft.de To: dane@ietf.org Message-ID: <20160422113901.Horde.bvaiK9UFQkE4OOmIZCUpVYa@webmail.kwsoft.de> In-Reply-To: <20160421161734.GO26423@mournblade.imrryr.org> References: <20160414183856.GL26423@mournblade.imrryr.org> <20160421161734.GO26423@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-1; boundary="----=_Part_1182_1818298352.1461317942362" User-Agent: Horde Application Framework 5 Archived-At: Subject: Re: [dane] [Uta] NEWSFLASH: DANE TLSA records published for web.de! X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2016 09:39:08 -0000 ------=_Part_1182_1818298352.1461317942362 Content-Type: text/plain; charset=utf-8; format=flowed; DelSp=Yes Content-Disposition: inline Zitat von Viktor Dukhovni : > On Thu, Apr 14, 2016 at 06:38:56PM +0000, Viktor Dukhovni wrote: > >> The web.de domain has just published DANE TLSA records for its MX >> hosts. > > And today also the rest of the major 1&1 (Mail&Media) email domains: > > gmx.de > gmx.net > gmx.com > gmx.ch > gmx.at > >> This is a major milestone in DANE adoption. [ IIRC they host >> mailboxes for a substantial fraction of the population of Germany. ] Hello, congratulation, good work in pushing a useful security standard forward. Do you some information if they are also doing DANE outbound? Regards Andreas ------=_Part_1182_1818298352.1461317942362 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 D6ADAgECAgMPYLcwDQYJKoZIhvcNAQELBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFy dENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgw NgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAe Fw0xNTA5MTUwNzQxMTdaFw0xNjA5MTQxMTE0MTVaMEIxHDAaBgNVBAMME2xzdF9ob2UwMkBrd3Nv ZnQuZGUxIjAgBgkqhkiG9w0BCQEWE2xzdF9ob2UwMkBrd3NvZnQuZGUwggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQDg2S8KTDs140O0zbyuQUpaRQDtwEu8SjDNyhOn8Y1FJvDh8gYEloSi UJRhVPEBQJJPtYZJs+JaiPlr55l2L1l5eH7b1vzExBxEQyHYlz65zFMUgA/KpZopAGYvnszLpMST kJTHjYU8dayPnt/1VXddtC+yGe+pYnjn7e3v1r3Kaw8M5hydzAvBu15MScMfVr2rxTO5z5Lr1UrH hkfQDGNFuyXXeGedDiwbc+wmh3Z6GzyMUvelDIEFAK22Gdy2vke26kHFIw/czCXP9K1eUDGgllid 6O0qVcCE64K5/o4qDA2P4nwcbbtu2+Wd9e9GAiKuQ14X2rlH5pBvaFwpIvpxAgMBAAGjggLZMIIC 1TAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQw HQYDVR0OBBYEFCDdq3sc/rJbYCdP2FrQCCagC1n2MB8GA1UdIwQYMBaAFFNy7ZKc4NrLAVx8fpY1 TvLUuFGCMB4GA1UdEQQXMBWBE2xzdF9ob2UwMkBrd3NvZnQuZGUwggFMBgNVHSAEggFDMIIBPzCC ATsGCysGAQQBgbU3AQIDMIIBKjAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20v cG9saWN5LnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRo b3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRpbmcgdG8gdGhl IENsYXNzIDEgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGlj eSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4gY29tcGxpYW5jZSBv ZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDov L2NybC5zdGFydHNzbC5jb20vY3J0dTEtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEF BQcwAYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczEvY2xpZW50L2NhMEIGCCsG AQUFBzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MxLmNsaWVudC5j YS5jcnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBCwUA A4IBAQB5UBooZ+OTgu0Az+nsz188Z+/fsdIC/sOMltf7wbuhDgCvRT/9J7+rAwo2oYBIP7SwvD5A ePiMrixTW4TkHfpR6TO/5Ct2/ep6iux2CTpfcyWYRvnhh8Z/Avo9XZ++PUKlj3olCCbi6HVsdwtz OsVAXjfyZxoyJRV+nVV8ordmr838f2xy4mgOw7xRT2sS0XBWewfTkiySpqY1RDMuESYxaglsRHD/ xaMEyo9BNbpc8kAGmAoTK1ZCPt17w/3S3kLC6dXDt6VNjcZzcxY5o9m927BGzi6mkxiNPo4vs5a6 NlJxRjY0dsXVlucVRN4TxTZzAwb866g51pkQiLtk2nEbMIIF2TCCA8GgAwIBAgIHFmdU48JwUTAN 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 Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMPYLcwCQYFKw4DAhoF AKCB/jAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjA0MjIwOTM5 MDJaMCMGCSqGSIb3DQEJBDEWBBQNb1E6tP6aqU1wdaLUzZe+vpq0/jCBngYJKoZIhvcNAQkPMYGQ MIGNMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4G CCqGSIb3DQMCAgIAgDAPBgkqhkiG9n0HQgoCAgCAMA0GCyqDCIyaSz0BAQEEMA0GCyqDCIyaSz0B AQEDMA0GCyqDCIyaSz0BAQECMAoGCCqDGoyaRAEEMA0GCSqGSIb3DQEBAQUABIIBAF+aIPcvFrYs 31UqQzKJUQ7oB2+pWNE2RoJzgkh3b/Q1nZUd+SWM5eZxNlDDY4nIqlrzErzjj5TZZQD+jnP2FVfa WrV2NNYIZwbYg5lrY2r0A+dWMHAZFIc8sznfRc1+RsKMDk3czRuREfKMZB38AsOzHEc56U615joF +MkqVXp+8JsL2UgPHVA8+8AjfvkmKasP4XmWAPqe5CYlVLJrd2Far0LgLevFJ13gu0XLG5zN+KS2 ehEyfcGDExKHi+krsh6AeMJQ/ICFvsELeGu2qGKb3EeGIvb/+keUKrADbvGjb32K0/uNGQ5ZCia5 waz1Sgy1auN94WDr6KX4ChCwrKgAAAAAAAA= ------=_Part_1182_1818298352.1461317942362-- From nobody Fri Apr 22 08:36:41 2016 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FC9012E3E7 for ; Fri, 22 Apr 2016 08:36:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=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 q0rKxXvLhrUJ for ; Fri, 22 Apr 2016 08:36:38 -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 7693C12E3DA for ; Fri, 22 Apr 2016 08:36:38 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 2D3D9284D99; Fri, 22 Apr 2016 15:36:37 +0000 (UTC) Date: Fri, 22 Apr 2016 15:36:37 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20160422153636.GT26423@mournblade.imrryr.org> References: <20160414183856.GL26423@mournblade.imrryr.org> <20160421161734.GO26423@mournblade.imrryr.org> <20160422113901.Horde.bvaiK9UFQkE4OOmIZCUpVYa@webmail.kwsoft.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160422113901.Horde.bvaiK9UFQkE4OOmIZCUpVYa@webmail.kwsoft.de> User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [dane] [Uta] NEWSFLASH: DANE TLSA records published for web.de! X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2016 15:36:40 -0000 On Fri, Apr 22, 2016 at 11:39:01AM +0200, lst_hoe02@kwsoft.de wrote: > >>The web.de domain has just published DANE TLSA records for its MX > >>hosts. > > > >And today also the rest of the major 1&1 (Mail&Media) email domains: > > > > gmx.de ... > > > >>This is a major milestone in DANE adoption. [ IIRC they host > >>mailboxes for a substantial fraction of the population of Germany. ] > > Congratulation, good work in pushing a useful security standard forward. Thanks. It's taken a bunch of work behind the scenes. > Do you some information if they are also doing DANE outbound? I've not asked yet. I expect that they will soon, if they've not already. It would be great if they posted some operational experience of how this affected their outbound mail flow. DANE is still quite new, and so some bumps in the road are to be expected. I've smoothed out many of the larger ones in the DNSSEC space (notified DNS operators of issues to fix that then got fixed), and also managed to help many an early adopter to get key rotation right. So today, out of the ~300,000 DANE-capable domains (DNSSEC signed and MX hosting not outsourced to an unsigned domain) that I've been able to find, ~15,000 have TLSA RRs, while ~200 still have some DNS issues and ~50 have invalid TLSA records. Just one MX host is doggedly sticking with PKIX-EE(1) TLSA records despite RFC7672 and my attempts to reason with the operator: dougbarton.us. IN MX 10 dougbarton.us So overall, the deployment picture picture is pretty good. I've not heard of any significant issues from posteo.de, they I believe have enabled DANE outbound some time ago. On the DNS front, while progress is slow, I still expect the number of problem domains to fall as more DNS providers upgrade or remediate their systems. Next on the list are isphuset.no and axc.nl, with the former responsive, but very slow (ticket open since Aug/2015) and the latter as yet unresponsive. Help appreciated from anyone who has a working relationship with either provider, particularly axc.nl. -- Viktor. From mario.gumprich@unitymedia.de Fri Apr 22 09:28:58 2016 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 697B612E8CE for ; Fri, 22 Apr 2016 09:28:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.597 X-Spam-Level: X-Spam-Status: No, score=-3.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 p9zHSSnZ9gyH for ; Fri, 22 Apr 2016 09:28:55 -0700 (PDT) Received: from chekov.unitymedia.de (chekov.unitymedia.de [80.69.97.12]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6856112DBDB for ; Fri, 22 Apr 2016 09:28:55 -0700 (PDT) X-Originating-IP: 172.25.1.124 Received: from kerp-smx004.unitymedia.de (kerp-smx004.unity.media [172.25.1.124]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by chekov.unitymedia.de (Postfix) with ESMTPS id 4CE9FCC0154 for ; Fri, 22 Apr 2016 18:28:53 +0200 (CEST) Received: from kerp-smx004.unitymedia.de (localhost [127.0.0.1]) by kerp-smx004.unitymedia.de (Postfix) with ESMTP id 3C9649804F for ; Fri, 22 Apr 2016 18:28:53 +0200 (CEST) Received: from KERP-EXC001.unity.media.corp (kerp-pex001.unity.media.corp [172.25.39.230]) by kerp-smx004.unitymedia.de (Postfix) with ESMTP id 36B3C9804E for ; Fri, 22 Apr 2016 18:28:53 +0200 (CEST) Received: from KERP-CAS001.unity.media.corp ([172.25.43.11]) by KERP-EXC001.unity.media.corp with Microsoft SMTPSVC(6.0.3790.4675); Fri, 22 Apr 2016 18:28:52 +0200 Received: from KERP-MBR002.unity.media.corp ([fe80::cc29:5090:4ab2:d354]) by KERP-CAS001.unity.media.corp ([fe80::f004:4e71:3527:c8bc%12]) with mapi id 14.02.0318.004; Fri, 22 Apr 2016 18:28:52 +0200 From: "Gumprich, Mario" To: "dane@ietf.org" Thread-Topic: [dane] [Uta] NEWSFLASH: DANE TLSA records published for web.de! Thread-Index: AQHRm+lsQNzd7N3Q30yIqXlwu3THlp+VnECAgABj6YCAAA6eAA== Date: Fri, 22 Apr 2016 16:28:51 +0000 Message-ID: References: <20160414183856.GL26423@mournblade.imrryr.org> <20160421161734.GO26423@mournblade.imrryr.org> <20160422113901.Horde.bvaiK9UFQkE4OOmIZCUpVYa@webmail.kwsoft.de> <20160422153636.GT26423@mournblade.imrryr.org> In-Reply-To: <20160422153636.GT26423@mournblade.imrryr.org> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [172.25.1.53] Content-Type: multipart/signed; boundary="Apple-Mail=_0F414DDB-0523-4162-94F9-9E2FBB3BFFE6"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 X-OriginalArrivalTime: 22 Apr 2016 16:28:52.0793 (UTC) FILETIME=[0EDDFA90:01D19CB4] X-TBoneOriginalFrom: "Gumprich, Mario" X-TBoneOriginalTo: "dane@ietf.org" X-TBoneDomainSigned: false Archived-At: X-Mailman-Approved-At: Sun, 24 Apr 2016 20:03:41 -0700 Subject: Re: [dane] [Uta] NEWSFLASH: DANE TLSA records published for web.de! X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2016 16:32:29 -0000 --Apple-Mail=_0F414DDB-0523-4162-94F9-9E2FBB3BFFE6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > So overall, the deployment picture picture is pretty good. I've > not heard of any significant issues from posteo.de, they I believe > have enabled DANE outbound some time ago. We from Unitymedia has enabled DANE outbound a couple of month ago. Today=E2=80=99s list of DANE inbound enabled domains / MX-IPs extracted = from logs. mail.lux01.de[194.117.254.21] mail.lux01.de[2a05:d580:0:1337::15] mail.ud11.udmedia.de[194.117.254.51] mail.ud11.udmedia.de[2a05:d580:0:1337::33] mail.zeus06.de[194.117.254.36] mail.zeus06.de[2a05:d580:0:1337::24] mail.zeus08.de[194.117.254.38] mail.zeus08.de[2a05:d580:0:1337::26] mi.ruhr-uni-bochum.de[134.147.42.228] mi.ruhr-uni-bochum.de[134.147.53.148] mx00.emig.gmx.net[212.227.15.9] mx00.gmx.net[212.227.15.10] mx00.mail.com[74.208.5.20] mx01.emig.gmx.net[212.227.17.5] mx01.gmx.net[212.227.17.4] mx01.mail.com[74.208.5.22] mx01.mail.de[2001:868:100:600::210] mx01.mail.de[213.128.151.210] mx-01.ngi-net.de[2a01:4f8:161:302c::1:1] mx-01.ngi-net.de[5.9.41.38] mx01.posteo.de[185.67.36.61] mx01.xworks.net[31.25.48.11] mx02.mail.de[2001:868:100:600::211] mx02.mail.de[213.128.151.211] mx-02.ngi-net.de[2a01:4f8:161:302d::1:1] mx-02.ngi-net.de[5.9.41.39] mx02.posteo.de[89.146.194.165] mx1.alpha-labs.net[46.229.47.141] mx1.bund.de[77.87.224.131] mx1.jpberlin.de[91.198.250.10] mx1.mailbox.org[80.241.60.212] mx2.bund.de[77.87.228.110] mx2.comcast.net[2001:558:fe21:2a::6] mx2.denic.de[2a02:568:102:211::1:2] mx2.denic.de[81.91.161.38] mx2.jpberlin.de[91.198.250.20] mx2.mailbox.org[80.241.60.215] mx2.xs4all.nl[194.109.24.138] mx3.xs4all.nl[194.109.24.134] mx4.xs4all.nl[194.109.24.139] mx-ha02.web.de[212.227.17.8] mx-ha02.Web.de[212.227.17.8] mx-ha02.Web.De[212.227.17.8] mx-ha02.WEB.de[212.227.17.8]: mx-ha03.web.de[212.227.15.17] postrelay1.lrz.de[2001:4ca0:0:103:0:25:1:1] smtp4.rz.tu-harburg.de[134.28.205.34] uhura.unitymedia.de[80.69.97.11] Pretty cool, the list grows from month to month. //br Mario --Apple-Mail=_0F414DDB-0523-4162-94F9-9E2FBB3BFFE6 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKBzCCBK8w ggOXoAMCAQICEQDgI8sVEoNTia1hbnpUZ2shMA0GCSqGSIb3DQEBCwUAMG8xCzAJBgNVBAYTAlNF MRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQGA1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5l dHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4dGVybmFsIENBIFJvb3QwHhcNMTQxMjIyMDAwMDAw WhcNMjAwNTMwMTA0ODM4WjCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hl c3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNV BAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWls IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAibEN2npTGU5wUh28VqYGJre4SeCW 51Gr8fBaE0kVo7SMG2C8elFCp3mMpCLfF2FOkdV2IwoU00oCf7YdCYBupQQ92bq7Fv6hh6kuQ1JD FnyvMlDIpk9a6QjYz5MlnHuI6DBk5qT4VoD9KiQUMxeZrETlaYujRgZLwjPU6UCfBrCxrJNAubUI kzqcKlOjENs9IGE8VQOO2U52JQIhKfqjfHF2T+7hX4Hp+1SA28N7NVK3hN4iPSwwLTF/Wb1SN7Az aS1D6/rWpfGXd2dRjNnuJ+u8pQc4doykqTj/34z1A6xJvsr3c5k6DzKrnJU6Ez0ORjpXdGFQvsZA P8vk4p+iIQIDAQABo4IBFzCCARMwHwYDVR0jBBgwFoAUrb2YejS0Jvf6xCZU7wO94CTLVBowHQYD VR0OBBYEFJJha4LhoqCqT+xn8cKj97SAAMHsMA4GA1UdDwEB/wQEAwIBhjASBgNVHRMBAf8ECDAG AQH/AgEAMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAw RAYDVR0fBD0wOzA5oDegNYYzaHR0cDovL2NybC51c2VydHJ1c3QuY29tL0FkZFRydXN0RXh0ZXJu YWxDQVJvb3QuY3JsMDUGCCsGAQUFBwEBBCkwJzAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNl cnRydXN0LmNvbTANBgkqhkiG9w0BAQsFAAOCAQEAGypurFXBOquIxdjtzVXzqmthK8AJECOZD8Vm am+x9bS1d14PAmEA330F/hKzpICAAPz7HVtqcgIKQbwFusFY1SbC6tVNhPv+gpjPWBvjImOcUvi7 BTarfVil3qs7Y+Xa1XPv7OD7e+Kj//BCI5zKto1NPuRLGAOyqC3U2LtCS5BphRDbpjc06HvgARCl nMo6x59PiDRuimXQGoq7qdzKyjbR9PzCZCk1r9axp3ER0gNDsY8+muyeMlP0dpLKhjQHuSzK5hxK 2JkNwYbikJL7WkJqIyEQ6WXH9dW7fuqMhSACYurROgcsWcWZM/I4ieW26RZ6H3kU9koQGib6fIr7 mzCCBVAwggQ4oAMCAQICEQDvdYSZ7QjFCdeh24cW3w55MA0GCSqGSIb3DQEBCwUAMIGbMQswCQYD VQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRow GAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50 IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwHhcNMTYwMTA0MDAwMDAwWhcNMTcw MTAzMjM1OTU5WjAtMSswKQYJKoZIhvcNAQkBFhxtYXJpby5ndW1wcmljaEB1bml0eW1lZGlhLmRl MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA00phbtQus4Y34gqrXdLSi2d5uh0I9ZZG R9Y65rv1ncHggt0P0mX7x6XAotLdvEStccvHD1HOcUptbke+SoTvaC9QVifn3eVHTjYcJjCVNZz2 UEQ7mLKvylrRmvQwRi4OWAo8ioxzEy/YcoENx8tId/dFjbC7qEk5f5xkrTWyWep0pm//jia6eQcB F3cRU/cC3wZF14ccfsUWS31RuTYImhFaYETMNlKaXWv3dzwgGNueBt4U8DmAtaVA2NXMB9CMAKFh 7cshErviwRcUSrvYFM3TlHgMfbQ+G0YtimQ2TZJ4RrXpyUH5lUJJkIEd46++0qjmUTp0/pKeiAVg pMQmawIDAQABo4IB+jCCAfYwHwYDVR0jBBgwFoAUkmFrguGioKpP7GfxwqP3tIAAwewwHQYDVR0O BBYEFGmrEzS4GyeMtxWK1so0DKNEJHmKMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAG A1UdJQQZMBcGCCsGAQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEEBAMCBSAwRgYDVR0g BD8wPTA7BgwrBgEEAbIxAQIBAQEwKzApBggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2Rv Lm5ldC9DUFMwXQYDVR0fBFYwVDBSoFCgToZMaHR0cDovL2NybC5jb21vZG9jYS5jb20vQ09NT0RP U0hBMjU2Q2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBkAYIKwYBBQUH AQEEgYMwgYAwWAYIKwYBBQUHMAKGTGh0dHA6Ly9jcnQuY29tb2RvY2EuY29tL0NPTU9ET1NIQTI1 NkNsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcnQwJAYIKwYBBQUHMAGGGGh0 dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTAnBgNVHREEIDAegRxtYXJpby5ndW1wcmljaEB1bml0eW1l ZGlhLmRlMA0GCSqGSIb3DQEBCwUAA4IBAQBj1r32qH5vvrgpl1gdtBxyFJDbg91uBSrSZtYmv4YO Et5Bf2NjGGZpthsERPbTQXkI6r/8wVH9iabQJDk9l40llpr521oVnIvrEjjTQ72/KQdwbJa4KaU5 aCaOFEYgRBZjsisQldtQ0rofcNwb9I7Gw/XjD+jluH8e2RTmE6rO1UHJeC+LPx8GxrydkNzAeL5R Wla2bcrZOxO+v3BAdzFVVXL7brS5/5hkMGLEKVgwp9y8tVMca8UjJRMH3MSuZ34YRs2sZd7jjiPX shFjtOy5XoxIYiJbWZ9CIwnnP02r0mCD3QznKFRNGTRfS/q7FfNdTV/iAUxuUj+gf4Tf5WhSMYID xjCCA8ICAQEwgbEwgZsxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIx EDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhD T01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIR AO91hJntCMUJ16HbhxbfDnkwCQYFKw4DAhoFAKCCAekwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAcBgkqhkiG9w0BCQUxDxcNMTYwNDIyMTYyODU3WjAjBgkqhkiG9w0BCQQxFgQUeuG2i5iraV0C fMbzY3bDhzQFt28wgcIGCSsGAQQBgjcQBDGBtDCBsTCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgT EkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENB IExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBh bmQgU2VjdXJlIEVtYWlsIENBAhEA73WEme0IxQnXoduHFt8OeTCBxAYLKoZIhvcNAQkQAgsxgbSg gbEwgZsxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcT B1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hB LTI1NiBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAO91hJntCMUJ 16HbhxbfDnkwDQYJKoZIhvcNAQEBBQAEggEAOEds8D0w+hQPlnj2bPcazeKh9eqCdtveSd/DLQuG //A3WP+uYGWCb+lw2ky2GJn8frF/Als4W9AybUewrlabU7aYh6INaZWqxYluBrLMwUWxOTIWc6pr vz0oI35CjVasL4a9+geZD66H/ybw+eK3V/9tQT83xLjb+BD0TuFl3RlRTqTEIV9+yJIEC/A+iT5b 908xihTebTcYoKaZDE8vrWuy/1DoskjcowT0HMEmaG+BSuQLuFLtEkyATnoLKyCioKgxVEWOJE9I HuxwLBT9APE398YNMgIqPZAlXEUKRKnwa4BOUbyp4uSrqpzufK/lE6RXQ+ZgCspkVHAVfOsPSAAA AAAAAA== --Apple-Mail=_0F414DDB-0523-4162-94F9-9E2FBB3BFFE6-- From nobody Sun Apr 24 20:48:38 2016 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEDC412D097 for ; Sun, 24 Apr 2016 20:48:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=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 PDch3nFBm2g4 for ; Sun, 24 Apr 2016 20:48:34 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC22B12B063 for ; Sun, 24 Apr 2016 20:48:34 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 76F22284B6F; Mon, 25 Apr 2016 03:48:33 +0000 (UTC) Date: Mon, 25 Apr 2016 03:48:33 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20160425034833.GW26423@mournblade.imrryr.org> References: <20160414183856.GL26423@mournblade.imrryr.org> <20160421161734.GO26423@mournblade.imrryr.org> <20160422113901.Horde.bvaiK9UFQkE4OOmIZCUpVYa@webmail.kwsoft.de> <20160422153636.GT26423@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [dane] [Uta] NEWSFLASH: DANE TLSA records published for web.de! X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.17 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, 25 Apr 2016 03:48:37 -0000 On Fri, Apr 22, 2016 at 04:28:51PM +0000, Gumprich, Mario wrote: > We from Unitymedia has enabled DANE outbound a couple of month ago. Thanks for the update. > Today’s list of DANE inbound enabled domains / MX-IPs extracted from logs. > mail.lux01.de[194.117.254.21] > ... > uhura.unitymedia.de[80.69.97.11] > > Pretty cool, the list grows from month to month. Do you ever run into any of the domains whose TLSA records are incorrect, or whose DNS servers fail authenticated denial of existence? In other words, is there any mail you bounce because of DANE that you might otherwise have delivered? Today's stats are: ~280000 DNSSEC domains that could have an MX host with TLSA RRs. 15097 domains with valid TLSA RRs 245 of those have 1+ MX hosts sans TLSA RRs (partial deployment) 227 domains with DNSSEC problems when doing TLSA lookups 56 domains with TLSA records that don't match the cert Given that the problem domans are rather few, perhaps you've never run into them? Of the ~15k, 56 domains that have at some point in the last ~2 years appeared in the Google email transparency report dataset. Of these 30 are in the most recent report: gmx.at conjur.com.br registro.br gmx.ch gmx.com mail.com bayern.de bund.de gmx.de jpberlin.de lrz.de posteo.de ruhr-uni-bochum.de tum.de unitymedia.de web.de octopuce.fr comcast.net dd24.net gmx.net t-2.net xs4all.net xs4all.nl debian.org freebsd.org gentoo.org ietf.org openssl.org samba.org torproject.org I'm still waiting for icann.org to show up on the list, and ideally a few prominent ".edu" domains that have gone to all the trouble of deploying DNSSEC, but have not yet published SMTP TLSA records. The ones from Gmail's transparentcy report would be: berkeley.edu fhsu.edu iastate.edu indiana.edu iu.edu iupui.edu nau.edu stanford.edu temple.edu ucdavis.edu ucr.edu uiowa.edu umbc.edu yale.edu None of these have made the leap as yet. It is possible, though not very likely that some departments have, I only scan domains directly delegated from public suffixes. A substantial outlier with problem TLSA records is ".br". The registry/sole-registrar provides a web interface for adding TLSA records, but no API for keeping them up to date. As a result, a large fraction of ".br" domains with TLSA RRs have invalid records, or related issues. Many don't promptly/ever act on email notices (at least in English). It may be wise to not enable DANE for ".br" domains. .BR TLSA records don't match reality: allispdv.com.br bebidaliberada.com.br giantit.com.br idsys.com.br lojabrum.com.br netlig.com.br prodnsbr.com.br simplesestudio.com.br solucoesglobais.com.br ticketmt.com.br twsolutions.net.br .BR DNSSEC lookup problems: bb.b.br dpf.gov.br pf.gov.br justicaeleitoral.jus.br tre-al.jus.br tre-ce.jus.br tre-ma.jus.br tre-mg.jus.br tre-ms.jus.br tre-mt.jus.br tre-pa.jus.br tre-pb.jus.br tre-pe.jus.br tre-pi.jus.br tre-pr.jus.br tre-rn.jus.br tre-rr.jus.br tre-sp.jus.br m3ganet.net.br -- Viktor. From nobody Wed Apr 27 06:31:24 2016 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C86112D1A0 for ; Wed, 27 Apr 2016 06:31:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 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, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fastmail.fm header.b=Eea22A/h; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=R/lcNkqG Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dbX1Bw110GwC for ; Wed, 27 Apr 2016 06:31:17 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A646B12D19F for ; Wed, 27 Apr 2016 06:31:16 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 18A1220A7C for ; Wed, 27 Apr 2016 09:31:16 -0400 (EDT) Received: from web5 ([10.202.2.215]) by compute3.internal (MEProxy); Wed, 27 Apr 2016 09:31:16 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=fastmail.fm; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=mesmtp; bh=xMRuirveStUm6ynRATkXbmpwkLI=; b=Eea22A /h3Wph7a9QzycuMpxIk9NEf3zhjdFvI+OYGY87q7jxrEqSTCI0TIt1dUmR+GA3w/ hsRnTS+feEroV82ARTIbXG8xx7foPCrmRPMPLogWJ3b/lJvgODXBQX8wAqh2iHZH +cQykyjdllfEKuIEYLOsKxCTU/BUU//h1COkI= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=xMRuirveStUm6yn RATkXbmpwkLI=; b=R/lcNkqGuUH2cC9rCQr4HFAjxGQgGmWjr8D40k1KJYYfr86 0tJvXED0ABHs5/qnTLaF6tPw5OA4QNyaIHUrWZstHeXgOj6IvjNSc6vQCXiWtfXK 5iXt72KdxziJpPDbjdWQz9PXzN23+5+H/J85loFNNLwMnsfGnUoJGecBhows= Received: by web5.nyi.internal (Postfix, from userid 99) id D9C0FA66592; Wed, 27 Apr 2016 09:31:15 -0400 (EDT) Message-Id: <1461763875.3817595.591158305.340A82A0@webmail.messagingengine.com> X-Sasl-Enc: 63XKy07R5tX2YWbbiaSI/lDbXy5O+ToJrDSnK7oXO8nK 1461763875 From: Alexey Melnikov To: Paul Wouters MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Mailer: MessagingEngine.com Webmail Interface - ajax-f1265324 Date: Wed, 27 Apr 2016 14:31:15 +0100 In-Reply-To: References: <20160419174240.31613.95778.idtracker@ietfa.amsl.com> <57168F9E.7080309@redhat.com> Archived-At: Cc: draft-ietf-dane-openpgpkey@ietf.org, The IESG , dane-chairs@ietf.org, dane@ietf.org Subject: Re: [dane] Alexey Melnikov's Discuss on draft-ietf-dane-openpgpkey-09: (with DISCUSS and COMMENT) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.17 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, 27 Apr 2016 13:31:18 -0000 Hi Paul, On Wed, Apr 20, 2016, at 12:04 PM, Alexey Melnikov wrote: > Hi Paul, [snip] > >>> What needs to happen here is that the specification be revised to make > >> it clear > >>> that this is what is going on: That by publishing such records a domain > >> is > >>> granting a limited right to interpret the local parts of its > >> addresses. > >> > >> I agree with this. A sentence or two on this would suffice. > > > > Can the IESG please provide the text and location for this, as some in the working group are loudly opposed to any such text. > > Considering that this proposal came from an email expert, I don't think > it would be controversial. (Earlier objection were from email experts.) > But maybe I am optimistic. > > I will suggest some text. After thinking more about this: as the document [correctly] prohibits any modifications of local-parts, the OPENPGP RRs don't really provide any information on whether a particular domain supports case-sensitive or case-insensitive local-parts (or any other variants a la Gmail). So I think leaving existing text "as is" is fine. I will separately suggest text to address other comments. From nobody Wed Apr 27 17:25:00 2016 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD04412D511; Wed, 27 Apr 2016 17:24:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 02YFtNLjqKZj; Wed, 27 Apr 2016 17:24:56 -0700 (PDT) Received: from mail-ob0-x230.google.com (mail-ob0-x230.google.com [IPv6:2607:f8b0:4003:c01::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07F7812D50F; Wed, 27 Apr 2016 17:24:56 -0700 (PDT) Received: by mail-ob0-x230.google.com with SMTP id x1so11880787obt.0; Wed, 27 Apr 2016 17:24:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=b2kzeI44ju3rh49+hLjIyZ2ajo7SurHrVoARht+2EF8=; b=wIwXMIzijMQyZo8U8lvcEvko9nDNkBVKPwrcL9fYodEbb3eTDEK76CMchJoplI9VLC 2wopj3v6d5YidyfsjplE3Nj6qrMWH99ndG6nk1toOhNldEMJeXcLeTrIPnOr8eW4Y9xZ 2lswx3n+j1g8G6kyJ0fy1n6Ajb0WIg2GbbScM/3bEdcmnEhFQxLeAzKqcLZ5PApuTjrz BXyv+BIMmqLJqHO21p8tvJwQgm9ffbx+UOnJm4JEuHhRFsEfNyBQtBAjjbZiB3PaIQj9 Erii1x/vhka6VxXC6y7PUakNyuTNFjSpwy4GSZV3VnPzvqfjhbCmvtW7e4jYInYEXxLt krlQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=b2kzeI44ju3rh49+hLjIyZ2ajo7SurHrVoARht+2EF8=; b=V0LssRrmKo+nycbQvYotU9nDmbaeuXpwTd6HqXvXjOiBt1m1Rq17tzqM1A0e55cQ7u 9ZGUX2yXS/1njfU8tBnRiG2q5MhGEXlSIbLyUxh8uM3c9300NmqhXybDQQvGwgVymAlM m75ymCrX4+6rKKZ8wJpfUvvyf9qSqXoAVfMTZUst/eZSz2ox6PqLwO+YFUVkPt4CYbXo m20k54fp7HR+5dXxhtb32/TthBe3FUGrRdy92+Jy9A/ZN3ZY2sHi6pg68rID717J6IF8 lsiQk6/rvbFLn4gdVX2g+8ASI+UTrZt6H/T5j8gLbWhU4C5bBqseUEqxTz7SQe1NxXrU llcw== X-Gm-Message-State: AOPr4FUoYEpEO2IzlNZvUOsSWGMS6u0mlKGo44EzrQzHeUtoJR82GWetjfTbLiPQu3EAurmGMCpWGFnPXQmM7w== X-Received: by 10.182.240.232 with SMTP id wd8mr5075765obc.74.1461803095256; Wed, 27 Apr 2016 17:24:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.22.216 with HTTP; Wed, 27 Apr 2016 17:24:40 -0700 (PDT) In-Reply-To: References: From: Donald Eastlake Date: Wed, 27 Apr 2016 20:24:40 -0400 Message-ID: To: Paul Wouters Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: draft-ietf-dane-openpgpkey.all@tools.ietf.org, dane WG list , "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [dane] [secdir] draft-ietf-dane-openpgpkey-06 SECDIR Review X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.17 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, 28 Apr 2016 00:24:59 -0000 Hi Paul, I have reviewed all change from -06 through the current -10 and I am satisfied with the resolution of my comments. Thanks, Donald ============================= Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com On Wed, Jan 27, 2016 at 6:06 AM, Paul Wouters wrote: > > Hi Donald, > > Thanks for the secdir review. I've incorporated your suggestions and > hopefully resolved your issues in the -07 draft I just posted at > > https://tools.ietf.org/html/draft-ietf-dane-openpgpkey-07 > > > Comments inline below. > > >> I think this draft is not ready for publication. It probably minimal >> technical changes but there are significant wording problems with it. >> >> Security: >> ------------ >> >> This document is "DANE for OpenPGP ..." but never says how what it >> documents is a use of DANE or what DANE is. While there is a reference >> to RFC 6698, at a minimum the DANE acronym should be expanded at first >> use and/or in Section 1.2. Preferably two or three sentences should be >> added to fix this gap. > > > I added a sentence to the introduction: > > DNSSEC Authentication of Networked Entities ("DANE") is a method > for publishing public keys and certificates in DNS. > >> I am concerned about the use of the words "validate" and "verify" in >> this document in a wide variety of different ways, and in particular >> their use in connection with OPENPGPKEY RRs. The ordinary and usual >> meaning of these words, when they are not qualified in some way, is >> that something is completely valid/verified for use and can be used >> without further checking. But that isn't what seems to be meant in >> this document. Here it just seems to sometimes mean that it has >> validated under DNSSEC. It might also mean that it is of valid syntax >> and a bit more -- the document is unclear on whether that is included. >> But the use of these words for OPENPGPKEY RRs seems to exclude the >> validation under the web of trust or human judgement even though that >> step is mandated at a couple of places in the document. > > > The term "verify" is in common use with OpenPPGP, for instance using > the gnupg command where the command is "gpg --verify". I have made > some changes to avoid possible confusion. I have changed the usage > of validation or verification in the context of DNSSEC to consitently > be "DNSSEC validation". I've also changed the word "verification" when > used in a context that is not related to OpenPGP. (for instance by > changing "source ip verification" to "source ip confirmation"). > >> Looking at Section 5, the "obtain or verify" in the first sentence >> seems odd. Shouldn't it use "and" and be more like "obtain and DNSSEC >> verify"? And in the following sentence, I would say "... ; if DNSSEC >> validation reaches ..." Also, if you are going to start talking about >> a specific DNSSEC state name as is done here, there should be a >> reference to the specific DNSSEC RFC where that state name is defined. > > > Changed to: > > The OPENPGPKEY record allows an application or service to obtain an > OpenPGP public key and use it for verifying a digital signature or > encrypting a message to the public key. The DNS answer MUST pass > DNSSEC validation; if DNSSEC validation reaches any state other than > "Secure" (as specified in RFC-4035), the DNSSEC validation MUST be > treated as a failure. > > RFF-4035 has been added as a normative reference. > >> In Section 5.1, in the first sentence, I would say "to seek" rather >> than "to discover". "discover" makes it sound like it will always >> un-cover/find something; also I think it would be a bit better to say >> "corresponding to" rather than "belongs to". > > > Changed as suggested. > >> The last sentence in 5.1 >> has too many confusing "this"s. Suggest, assuming I have correctly >> understood what you want to say, replacing the current last sentence >> with "An application whose attempt fails to retrieve a DNSSEC verified >> OPENPGPKEY RR from the DNS should remember that failure for some time >> to avoid sending out a DNS request for each email message the >> application is sending out; such DNS requests constitute a privacy >> leak". > > > Changed. > >> I suggest changing the title of Section 5.2 to "Confirming that an >> OpenPGP key is current" since that is what it is about, not about >> general validity. > > > Changed. > >> The third sentence of Section 5.2 ("If verifying ... >> a failure") is unclear and not grammatical. Trying to re-write this >> third sentence I come up with "If a locally stored OpenPGP public key >> is found to be different from an OpenPGP retrieved from the DNS and >> DNSSEC verified as described herein, then ...." But I don't understand >> this and don't understand what the "..." should be. > > > I have changed it to: > > If the locally stored OpenPGP public key is different from the DNSSEC > validated OpenPGP public key currently published in DNS, the verification > MUST be treated as a failure unless if the locally stored OpenPGP key > signed the newly published OpenPGP public key found in DNS. > >> Can't there can be >> multiple good OpenPGP keys for the same email address? > > > Yes, there can be. But a locally stored OpenPGP public key must be > considered more secure than a new one observed in DNS, until a human > has confirmed the new key. Unless the old key has confirmed the new key. > >> What if one key >> is stored locally and you retrieve two keys, one of which is equal to >> the local key and one of which is different? Presumably it depends on >> the local/user's policy what to do in such a case of different keys. > > > What I tried to accomplish is that if you have a local key, any key > update must be confirmed by the old key or the user. Switching keys > without further confirmation is just too dangerous. > >> How is it helpful to say "the verification MUST be treated as a >> failure"? (This certainly further confuses what "verification" means >> in this document.) > > > The presence of a new key might mean the old (locally stored) key > was compromised. But the new key cannot just be trusted even if it > passed DNSSEC validation. Unless the old key signed the new key, > human intervention should be used to resolve the conflict. By saying > "verification failure" it blocks the application from sending the data > encrypted to either key - and require a user to resolve the situation. > >> It is not clear exactly what that means but if it >> says that a DNSSEC verified OpenPGP key retrieved from the DNS should >> be dropped/ignored, why is that always the right thing? > > > I did not mean say drop or ignored. A conflict of keys should be > resolved by the user. > >> In the second sentence of the first paragraph of Section 7, what does >> the initial "It" stand for? > > > Changed to: > > DANE for OpenPGP as specified in this document is a solution aimed to > ease obtaining someone's public key. Without manual verification of > the OpenPGP key obtained via DANE, this retrieved key should only be > used for encryption if the only other alternative is sending the message > in plaintext. > >> If you were faked-out and believed a false key so email was encrypted >> to the bad guy and could not be read by the intended recipient, I >> would say that was worse than plaintext. > > > That really depends on the situation. If an attacker can replace > OPENPGPKEY records, they can most likely also change MX records > to just get everything. > > >> This paragraph goes on to >> talk about active attacks, which usually. in the email context, refers >> to active attacks on the email on the wire, but I would guess this >> text is actually talking about active attacks in the form of storing a >> wrong key in the DNS... > > > The active attacks refer to everything that can cause a third party to > gain access to the unencrypted email content. > >> In re Section 7.5, why isn't the domain name included in the hash? It >> seems to improve security a little and the effort is small. > > > As stated in that section 7.5: > > The domain name part of the email address is not used as part of the > hash so that hashes can be used in multiple zones deployed using > DNAME [RFC6672] > >> Other: >> -------- >> >> Section 1: >> >> The references for Secure DNS should be given when Secure DNS is first >> mentioned on page 3. > > > Done. > >> Section 1.1: >> >> I do not think there is such a thing as an "Experimental RRtype". It >> would be better to say something like "This document specifies an >> RRtype whose use is Experimental." > > > Done. > >> I don't quite grok the use of "generality of" on page 4. Perhaps it >> should be replaced with "diffuse support of" or something. > > > Changed to "general application" > >> Section 2: >> >> As long as you are bothering to say that the OPENPGPKEY RR has no >> special TTL requirements, you might as well say it has no special >> Additional section retrieval requirements, since I think that is the >> most common type of RR special processing. But I think the lack of >> such special requirements is the default so you could probably just >> leave these negative statements out. > > > Done. > >> Section 2.3: >> >> "textual zone files" -> "master files [RFC1035]" and add [RFC1035] to >> the normative references. > > > Done. > >> Section 3: >> >> The following statement seems at least a little misleading: >> The DNS does not allow the use of all characters that are supported >> in the "local-part" of email addresses as defined in [RFC5322] and >> [RFC6530]. >> DNS is binary clean. What left hand side characters allowed in >> [RFC5322] are now allowed in DNS? Seems to me that only international >> text as such [RFC6530] is a problem for DNS. > > > And the "." or a NULL. There is also the case sensitivity argument > raised by some. > >> Probably the first bullet should be split in two. The first time I >> read it, it seemed that the first sentence was talking about some >> encodings. Then the second sentence talks about other encodings and >> says they are hashed. So, of course, I thought that the encodings >> talked about in the first sentence were not hashed. But the example >> appears to show that the current text had conveyed the wrong thing to >> me and that it is always hashes. I suggest that after "If it is >> written in another encoding it should be converted to UTF-8" be >> followed by a period and then there should be a new bullet item >> talking about hashing, etc., to make it clear that the hashing, etc., > > > Done. > >> apply to all encodings in the first bullet. Furthermore, I don't >> understand why the text fragment I quote says "should" rather than >> "must" or perhaps just replace "should be" with "is". > > > Done (with "is") > >> Then we get to the truncation. "Truncation comes from the right-most >> octets." is completely ambiguous. At a minimum, a word needs to be >> added so it says "Truncation comes from using the right-most octets." >> or "Truncation comes from dropping the right-most octets." >> Alternatively some other non-ambiguous wording is needed. > > > Actually I think the whole two sentence that start from this can be > dropped. These add no new information. > >> Presumably it is believed that the probability of a hash collision is >> small enough that it can be ignored. If so, it wouldn't hurt to say >> so. > > > Added to the security section: > > In theory, two different local-parts could hash to the same value. This > document assumes that such a hash collision has a negliable chance of > happening. > >> Section 7: >> >> The last paragraph of Section 7 seems to equate "Organizations" and >> "mail servers". Suggest recasting the second sentence as "Mail servers >> of such organizations MAY optionally re-encrypt a received message to >> an individual's OpenPGP key.". > > > Done. > >> Section 7.1: >> >> Again, I assume "indeterminate" and "bogus" are used in their DNSSEC >> meaning. So there needs to be a reference here to the DNSSEC RFC that >> explains those words. > > > Done, Added pointer to RFC-4035 > >> Author's Address: >> >> I understand that many do not agree with me but I believe that first >> page authors should normally list a postal address and a telephone >> number to which a message could be sent or at which a message could be >> left for them in addition to an email address. This section looks like >> schlock corner cutting to me. > > > I do not agree. Any address and phone number listed would be too > ephemeral or too generic to be of value to anyone. > >> Trivia: >> -------- >> >> "twart" -> "thwart" and "twarts" -> "thwarts" > > > Fixed. > >> Section 6: "properties are not exported" -> "properties not be >> exported" and in the following sentence "have" -> "has" > > > Fixed. > >> Section 7: "direct" -> "ask" (a mail client has no power to order the >> user to do anything) > > > Fixed. Also changed "human" to "user" everywhere. > >> Section 7.1: 5th paragraph, "sent" -> "send" > > > Fixed. > > Paul From nobody Thu Apr 28 02:45:43 2016 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE1A512D619 for ; Thu, 28 Apr 2016 02:45:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.897 X-Spam-Level: X-Spam-Status: No, score=-7.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 lj4yTR9rPaK9 for ; Thu, 28 Apr 2016 02:45:38 -0700 (PDT) Received: from teruel.switch.ch (teruel.switch.ch [IPv6:2001:620:0:1b::28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 274CA12D616 for ; Thu, 28 Apr 2016 02:45:37 -0700 (PDT) Received: from surlej.switch.ch (surlej.switch.ch [IPv6:2001:620:0:1001::69]) by teruel.switch.ch (8.14.4/8.14.4/Debian-4+deb7u1) with ESMTP id u3S9jU4J004695 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 28 Apr 2016 11:45:31 +0200 Received: from macdst.switch.ch ([2001:620:0:49:6a5b:35ff:feca:4248]) by surlej.switch.ch with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from ) id 1aviVm-0005V9-FB; Thu, 28 Apr 2016 11:45:30 +0200 To: dane@ietf.org, ietf-dane@dukhovni.org References: <20160414183856.GL26423@mournblade.imrryr.org> <20160421161734.GO26423@mournblade.imrryr.org> <20160422113901.Horde.bvaiK9UFQkE4OOmIZCUpVYa@webmail.kwsoft.de> <20160422153636.GT26423@mournblade.imrryr.org> <20160425034833.GW26423@mournblade.imrryr.org> From: Daniel Stirnimann Message-ID: <5721DBBA.6000106@switch.ch> Date: Thu, 28 Apr 2016 11:45:30 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 MIME-Version: 1.0 In-Reply-To: <20160425034833.GW26423@mournblade.imrryr.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-SWITCHham-Score: X-CanIt-Geo: ip=2001:620:0:1001::69; country=CH; region=Zurich; city=Zurich; latitude=47.3720; longitude=8.5413; http://maps.google.com/maps?q=47.3720,8.5413&z=6 X-CanItPRO-Stream: switch-ch:outbound (inherits from switch-ch:default, base:default) X-Canit-Stats-ID: Bayes signature not available X-Scanned-By: CanIt (www . roaringpenguin . com) Archived-At: Subject: Re: [dane] [Uta] NEWSFLASH: DANE TLSA records published for web.de! X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.17 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, 28 Apr 2016 09:45:41 -0000 Hello I noticed that web.de uses a NSEC3 Hash Algorithm Type 8. But 8 is not assigned: http://www.iana.org/assignments/dnssec-nsec3-parameters/dnssec-nsec3-parameters.xhtml#dnssec-nsec3-parameters-3 ; <<>> DiG 9.8.3-P1 <<>> web.de NSEC3PARAM +noall +answer ;; global options: +cmd web.de. 600 IN NSEC3PARAM 8 0 333 - ; <<>> DiG 9.8.3-P1 <<>> gmx.ch NSEC3PARAM +noall +answer ;; global options: +cmd gmx.ch. 600 IN NSEC3PARAM 8 0 350 - On a related note, I'm also confused why the browser plugin from https://www.dnssec-validator.cz/ does not recognize that gmx.ch is DNSSEC signed. It works for web.de though! Any idea? Daniel On 25.04.16 05:48, Viktor Dukhovni wrote: > On Fri, Apr 22, 2016 at 04:28:51PM +0000, Gumprich, Mario wrote: > >> We from Unitymedia has enabled DANE outbound a couple of month ago. > > Thanks for the update. > >> Today’s list of DANE inbound enabled domains / MX-IPs extracted from logs. >> mail.lux01.de[194.117.254.21] >> ... >> uhura.unitymedia.de[80.69.97.11] >> >> Pretty cool, the list grows from month to month. > > Do you ever run into any of the domains whose TLSA records are > incorrect, or whose DNS servers fail authenticated denial of > existence? In other words, is there any mail you bounce because > of DANE that you might otherwise have delivered? > > Today's stats are: > > ~280000 DNSSEC domains that could have an MX host with TLSA RRs. > 15097 domains with valid TLSA RRs > 245 of those have 1+ MX hosts sans TLSA RRs (partial deployment) > 227 domains with DNSSEC problems when doing TLSA lookups > 56 domains with TLSA records that don't match the cert > > Given that the problem domans are rather few, perhaps you've never > run into them? > > Of the ~15k, 56 domains that have at some point in the last ~2 > years appeared in the Google email transparency report dataset. > Of these 30 are in the most recent report: > > gmx.at > conjur.com.br > registro.br > gmx.ch > gmx.com > mail.com > bayern.de > bund.de > gmx.de > jpberlin.de > lrz.de > posteo.de > ruhr-uni-bochum.de > tum.de > unitymedia.de > web.de > octopuce.fr > comcast.net > dd24.net > gmx.net > t-2.net > xs4all.net > xs4all.nl > debian.org > freebsd.org > gentoo.org > ietf.org > openssl.org > samba.org > torproject.org > > I'm still waiting for icann.org to show up on the list, and ideally > a few prominent ".edu" domains that have gone to all the trouble > of deploying DNSSEC, but have not yet published SMTP TLSA records. > The ones from Gmail's transparentcy report would be: > > berkeley.edu > fhsu.edu > iastate.edu > indiana.edu > iu.edu > iupui.edu > nau.edu > stanford.edu > temple.edu > ucdavis.edu > ucr.edu > uiowa.edu > umbc.edu > yale.edu > > None of these have made the leap as yet. It is possible, though > not very likely that some departments have, I only scan domains > directly delegated from public suffixes. > > A substantial outlier with problem TLSA records is ".br". The > registry/sole-registrar provides a web interface for adding TLSA > records, but no API for keeping them up to date. As a result, a > large fraction of ".br" domains with TLSA RRs have invalid records, > or related issues. Many don't promptly/ever act on email notices > (at least in English). It may be wise to not enable DANE for ".br" > domains. > > .BR TLSA records don't match reality: > > allispdv.com.br > bebidaliberada.com.br > giantit.com.br > idsys.com.br > lojabrum.com.br > netlig.com.br > prodnsbr.com.br > simplesestudio.com.br > solucoesglobais.com.br > ticketmt.com.br > twsolutions.net.br > > .BR DNSSEC lookup problems: > > bb.b.br > dpf.gov.br > pf.gov.br > justicaeleitoral.jus.br > tre-al.jus.br > tre-ce.jus.br > tre-ma.jus.br > tre-mg.jus.br > tre-ms.jus.br > tre-mt.jus.br > tre-pa.jus.br > tre-pb.jus.br > tre-pe.jus.br > tre-pi.jus.br > tre-pr.jus.br > tre-rn.jus.br > tre-rr.jus.br > tre-sp.jus.br > m3ganet.net.br > From nobody Thu Apr 28 03:11:20 2016 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2D0D12D636 for ; Thu, 28 Apr 2016 03:11:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.897 X-Spam-Level: X-Spam-Status: No, score=-7.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 iDn1nDCvxOiP for ; Thu, 28 Apr 2016 03:11:15 -0700 (PDT) Received: from iberico.switch.ch (iberico.switch.ch [IPv6:2001:620:0:1002::27]) (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 8A6BC12D619 for ; Thu, 28 Apr 2016 03:11:14 -0700 (PDT) Received: from surlej.switch.ch (surlej.switch.ch [IPv6:2001:620:0:1001::69]) by iberico.switch.ch (8.14.4/8.14.4/Debian-4+deb7u1) with ESMTP id u3SAB9fd030665 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 28 Apr 2016 12:11:10 +0200 Received: from macdst.switch.ch ([2001:620:0:49:6a5b:35ff:feca:4248]) by surlej.switch.ch with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from ) id 1aviub-0000yY-KW; Thu, 28 Apr 2016 12:11:09 +0200 To: dane@ietf.org, ietf-dane@dukhovni.org References: <20160414183856.GL26423@mournblade.imrryr.org> <20160421161734.GO26423@mournblade.imrryr.org> <20160422113901.Horde.bvaiK9UFQkE4OOmIZCUpVYa@webmail.kwsoft.de> <20160422153636.GT26423@mournblade.imrryr.org> <20160425034833.GW26423@mournblade.imrryr.org> <5721DBBA.6000106@switch.ch> From: Daniel Stirnimann Message-ID: <5721E1BD.7040407@switch.ch> Date: Thu, 28 Apr 2016 12:11:09 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 MIME-Version: 1.0 In-Reply-To: <5721DBBA.6000106@switch.ch> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-SWITCHham-Score: X-CanIt-Geo: ip=2001:620:0:1001::69; country=CH; region=Zurich; city=Zurich; latitude=47.3720; longitude=8.5413; http://maps.google.com/maps?q=47.3720,8.5413&z=6 X-CanItPRO-Stream: switch-ch:outbound (inherits from switch-ch:default, base:default) X-Canit-Stats-ID: Bayes signature not available X-Scanned-By: CanIt (www . roaringpenguin . com) Archived-At: Subject: Re: [dane] [Uta] NEWSFLASH: DANE TLSA records published for web.de! X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.17 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, 28 Apr 2016 10:11:20 -0000 The NSEC3 record contains the hash algorithm type 1 4c82sp2ag0m9hm9lfkb6d141t4qclui8.gmx.ch. 556 IN NSEC3 1 0 350 - 5AEHEF49CLPKJ5CHHRCND7VKKM7MKMJ4 CNAME RRSIG So, it's only the NSEC3PARAM Hash Algorithm which confuses me. Daniel On 28.04.16 11:45, Daniel Stirnimann wrote: > Hello > > I noticed that web.de uses a NSEC3 Hash Algorithm Type 8. > > But 8 is not assigned: > http://www.iana.org/assignments/dnssec-nsec3-parameters/dnssec-nsec3-parameters.xhtml#dnssec-nsec3-parameters-3 > > ; <<>> DiG 9.8.3-P1 <<>> web.de NSEC3PARAM +noall +answer > ;; global options: +cmd > web.de. 600 IN NSEC3PARAM 8 0 333 - > > ; <<>> DiG 9.8.3-P1 <<>> gmx.ch NSEC3PARAM +noall +answer > ;; global options: +cmd > gmx.ch. 600 IN NSEC3PARAM 8 0 350 - > > On a related note, I'm also confused why the browser plugin from > https://www.dnssec-validator.cz/ does not recognize that gmx.ch is > DNSSEC signed. It works for web.de though! > > Any idea? > > Daniel > > On 25.04.16 05:48, Viktor Dukhovni wrote: >> On Fri, Apr 22, 2016 at 04:28:51PM +0000, Gumprich, Mario wrote: >> >>> We from Unitymedia has enabled DANE outbound a couple of month ago. >> >> Thanks for the update. >> >>> Today’s list of DANE inbound enabled domains / MX-IPs extracted from logs. >>> mail.lux01.de[194.117.254.21] >>> ... >>> uhura.unitymedia.de[80.69.97.11] >>> >>> Pretty cool, the list grows from month to month. >> >> Do you ever run into any of the domains whose TLSA records are >> incorrect, or whose DNS servers fail authenticated denial of >> existence? In other words, is there any mail you bounce because >> of DANE that you might otherwise have delivered? >> >> Today's stats are: >> >> ~280000 DNSSEC domains that could have an MX host with TLSA RRs. >> 15097 domains with valid TLSA RRs >> 245 of those have 1+ MX hosts sans TLSA RRs (partial deployment) >> 227 domains with DNSSEC problems when doing TLSA lookups >> 56 domains with TLSA records that don't match the cert >> >> Given that the problem domans are rather few, perhaps you've never >> run into them? >> >> Of the ~15k, 56 domains that have at some point in the last ~2 >> years appeared in the Google email transparency report dataset. >> Of these 30 are in the most recent report: >> >> gmx.at >> conjur.com.br >> registro.br >> gmx.ch >> gmx.com >> mail.com >> bayern.de >> bund.de >> gmx.de >> jpberlin.de >> lrz.de >> posteo.de >> ruhr-uni-bochum.de >> tum.de >> unitymedia.de >> web.de >> octopuce.fr >> comcast.net >> dd24.net >> gmx.net >> t-2.net >> xs4all.net >> xs4all.nl >> debian.org >> freebsd.org >> gentoo.org >> ietf.org >> openssl.org >> samba.org >> torproject.org >> >> I'm still waiting for icann.org to show up on the list, and ideally >> a few prominent ".edu" domains that have gone to all the trouble >> of deploying DNSSEC, but have not yet published SMTP TLSA records. >> The ones from Gmail's transparentcy report would be: >> >> berkeley.edu >> fhsu.edu >> iastate.edu >> indiana.edu >> iu.edu >> iupui.edu >> nau.edu >> stanford.edu >> temple.edu >> ucdavis.edu >> ucr.edu >> uiowa.edu >> umbc.edu >> yale.edu >> >> None of these have made the leap as yet. It is possible, though >> not very likely that some departments have, I only scan domains >> directly delegated from public suffixes. >> >> A substantial outlier with problem TLSA records is ".br". The >> registry/sole-registrar provides a web interface for adding TLSA >> records, but no API for keeping them up to date. As a result, a >> large fraction of ".br" domains with TLSA RRs have invalid records, >> or related issues. Many don't promptly/ever act on email notices >> (at least in English). It may be wise to not enable DANE for ".br" >> domains. >> >> .BR TLSA records don't match reality: >> >> allispdv.com.br >> bebidaliberada.com.br >> giantit.com.br >> idsys.com.br >> lojabrum.com.br >> netlig.com.br >> prodnsbr.com.br >> simplesestudio.com.br >> solucoesglobais.com.br >> ticketmt.com.br >> twsolutions.net.br >> >> .BR DNSSEC lookup problems: >> >> bb.b.br >> dpf.gov.br >> pf.gov.br >> justicaeleitoral.jus.br >> tre-al.jus.br >> tre-ce.jus.br >> tre-ma.jus.br >> tre-mg.jus.br >> tre-ms.jus.br >> tre-mt.jus.br >> tre-pa.jus.br >> tre-pb.jus.br >> tre-pe.jus.br >> tre-pi.jus.br >> tre-pr.jus.br >> tre-rn.jus.br >> tre-rr.jus.br >> tre-sp.jus.br >> m3ganet.net.br >> > > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane > -- SWITCH Daniel Stirnimann, SWITCH-CERT Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland phone +41 44 268 15 15, direct +41 44 268 16 24 daniel.stirnimann@switch.ch, http://www.switch.ch From nobody Thu Apr 28 05:40:29 2016 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EE2E12D69E for ; Thu, 28 Apr 2016 05:40:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.897 X-Spam-Level: X-Spam-Status: No, score=-7.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 yWRLfM6pLjBv for ; Thu, 28 Apr 2016 05:40:25 -0700 (PDT) Received: from iberico.switch.ch (iberico.switch.ch [IPv6:2001:620:0:1002::27]) (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 DDCBB12D660 for ; Thu, 28 Apr 2016 05:40:23 -0700 (PDT) Received: from surlej.switch.ch (surlej.switch.ch [IPv6:2001:620:0:1001::69]) by iberico.switch.ch (8.14.4/8.14.4/Debian-4+deb7u1) with ESMTP id u3SCeHxW015873 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 28 Apr 2016 14:40:18 +0200 Received: from macdst.switch.ch ([2001:620:0:49:6a5b:35ff:feca:4248]) by surlej.switch.ch with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from ) id 1avlEv-0003AH-Ki; Thu, 28 Apr 2016 14:40:17 +0200 To: dane@ietf.org, ietf-dane@dukhovni.org References: <20160414183856.GL26423@mournblade.imrryr.org> <20160421161734.GO26423@mournblade.imrryr.org> <20160422113901.Horde.bvaiK9UFQkE4OOmIZCUpVYa@webmail.kwsoft.de> <20160422153636.GT26423@mournblade.imrryr.org> <20160425034833.GW26423@mournblade.imrryr.org> <5721DBBA.6000106@switch.ch> <5721E1BD.7040407@switch.ch> From: Daniel Stirnimann Message-ID: <572204B1.5030401@switch.ch> Date: Thu, 28 Apr 2016 14:40:17 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 MIME-Version: 1.0 In-Reply-To: <5721E1BD.7040407@switch.ch> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-SWITCHham-Score: X-CanIt-Geo: ip=2001:620:0:1001::69; country=CH; region=Zurich; city=Zurich; latitude=47.3720; longitude=8.5413; http://maps.google.com/maps?q=47.3720,8.5413&z=6 X-CanItPRO-Stream: switch-ch:outbound (inherits from switch-ch:default, base:default) X-Canit-Stats-ID: Bayes signature not available X-Scanned-By: CanIt (www . roaringpenguin . com) Archived-At: Subject: Re: [dane] [Uta] NEWSFLASH: DANE TLSA records published for web.de! X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.17 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, 28 Apr 2016 12:40:28 -0000 Seems to be a typo and their signer (PowerDNS) correctly ignored it and used the correct value of 1. Daniel On 28.04.16 12:11, Daniel Stirnimann wrote: > The NSEC3 record contains the hash algorithm type 1 > > 4c82sp2ag0m9hm9lfkb6d141t4qclui8.gmx.ch. 556 IN NSEC3 1 0 350 - > 5AEHEF49CLPKJ5CHHRCND7VKKM7MKMJ4 CNAME RRSIG > > So, it's only the NSEC3PARAM Hash Algorithm which confuses me. > > Daniel > > On 28.04.16 11:45, Daniel Stirnimann wrote: >> Hello >> >> I noticed that web.de uses a NSEC3 Hash Algorithm Type 8. >> >> But 8 is not assigned: >> http://www.iana.org/assignments/dnssec-nsec3-parameters/dnssec-nsec3-parameters.xhtml#dnssec-nsec3-parameters-3 >> >> ; <<>> DiG 9.8.3-P1 <<>> web.de NSEC3PARAM +noall +answer >> ;; global options: +cmd >> web.de. 600 IN NSEC3PARAM 8 0 333 - >> >> ; <<>> DiG 9.8.3-P1 <<>> gmx.ch NSEC3PARAM +noall +answer >> ;; global options: +cmd >> gmx.ch. 600 IN NSEC3PARAM 8 0 350 - >> >> On a related note, I'm also confused why the browser plugin from >> https://www.dnssec-validator.cz/ does not recognize that gmx.ch is >> DNSSEC signed. It works for web.de though! >> >> Any idea? >> >> Daniel >> >> On 25.04.16 05:48, Viktor Dukhovni wrote: >>> On Fri, Apr 22, 2016 at 04:28:51PM +0000, Gumprich, Mario wrote: >>> >>>> We from Unitymedia has enabled DANE outbound a couple of month ago. >>> >>> Thanks for the update. >>> >>>> Today’s list of DANE inbound enabled domains / MX-IPs extracted from logs. >>>> mail.lux01.de[194.117.254.21] >>>> ... >>>> uhura.unitymedia.de[80.69.97.11] >>>> >>>> Pretty cool, the list grows from month to month. >>> >>> Do you ever run into any of the domains whose TLSA records are >>> incorrect, or whose DNS servers fail authenticated denial of >>> existence? In other words, is there any mail you bounce because >>> of DANE that you might otherwise have delivered? >>> >>> Today's stats are: >>> >>> ~280000 DNSSEC domains that could have an MX host with TLSA RRs. >>> 15097 domains with valid TLSA RRs >>> 245 of those have 1+ MX hosts sans TLSA RRs (partial deployment) >>> 227 domains with DNSSEC problems when doing TLSA lookups >>> 56 domains with TLSA records that don't match the cert >>> >>> Given that the problem domans are rather few, perhaps you've never >>> run into them? >>> >>> Of the ~15k, 56 domains that have at some point in the last ~2 >>> years appeared in the Google email transparency report dataset. >>> Of these 30 are in the most recent report: >>> >>> gmx.at >>> conjur.com.br >>> registro.br >>> gmx.ch >>> gmx.com >>> mail.com >>> bayern.de >>> bund.de >>> gmx.de >>> jpberlin.de >>> lrz.de >>> posteo.de >>> ruhr-uni-bochum.de >>> tum.de >>> unitymedia.de >>> web.de >>> octopuce.fr >>> comcast.net >>> dd24.net >>> gmx.net >>> t-2.net >>> xs4all.net >>> xs4all.nl >>> debian.org >>> freebsd.org >>> gentoo.org >>> ietf.org >>> openssl.org >>> samba.org >>> torproject.org >>> >>> I'm still waiting for icann.org to show up on the list, and ideally >>> a few prominent ".edu" domains that have gone to all the trouble >>> of deploying DNSSEC, but have not yet published SMTP TLSA records. >>> The ones from Gmail's transparentcy report would be: >>> >>> berkeley.edu >>> fhsu.edu >>> iastate.edu >>> indiana.edu >>> iu.edu >>> iupui.edu >>> nau.edu >>> stanford.edu >>> temple.edu >>> ucdavis.edu >>> ucr.edu >>> uiowa.edu >>> umbc.edu >>> yale.edu >>> >>> None of these have made the leap as yet. It is possible, though >>> not very likely that some departments have, I only scan domains >>> directly delegated from public suffixes. >>> >>> A substantial outlier with problem TLSA records is ".br". The >>> registry/sole-registrar provides a web interface for adding TLSA >>> records, but no API for keeping them up to date. As a result, a >>> large fraction of ".br" domains with TLSA RRs have invalid records, >>> or related issues. Many don't promptly/ever act on email notices >>> (at least in English). It may be wise to not enable DANE for ".br" >>> domains. >>> >>> .BR TLSA records don't match reality: >>> >>> allispdv.com.br >>> bebidaliberada.com.br >>> giantit.com.br >>> idsys.com.br >>> lojabrum.com.br >>> netlig.com.br >>> prodnsbr.com.br >>> simplesestudio.com.br >>> solucoesglobais.com.br >>> ticketmt.com.br >>> twsolutions.net.br >>> >>> .BR DNSSEC lookup problems: >>> >>> bb.b.br >>> dpf.gov.br >>> pf.gov.br >>> justicaeleitoral.jus.br >>> tre-al.jus.br >>> tre-ce.jus.br >>> tre-ma.jus.br >>> tre-mg.jus.br >>> tre-ms.jus.br >>> tre-mt.jus.br >>> tre-pa.jus.br >>> tre-pb.jus.br >>> tre-pe.jus.br >>> tre-pi.jus.br >>> tre-pr.jus.br >>> tre-rn.jus.br >>> tre-rr.jus.br >>> tre-sp.jus.br >>> m3ganet.net.br >>> >> >> _______________________________________________ >> dane mailing list >> dane@ietf.org >> https://www.ietf.org/mailman/listinfo/dane >> > -- SWITCH Daniel Stirnimann, SWITCH-CERT Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland phone +41 44 268 15 15, direct +41 44 268 16 24 daniel.stirnimann@switch.ch, http://www.switch.ch From nobody Thu Apr 28 07:19:25 2016 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E06512D7B0 for ; Thu, 28 Apr 2016 07:19:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.922 X-Spam-Level: X-Spam-Status: No, score=-6.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 1gWdctnIyQqV for ; Thu, 28 Apr 2016 07:19:22 -0700 (PDT) Received: from smtpde01.smtp.sap-ag.de (smtpde01.smtp.sap-ag.de [155.56.68.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5547A12D0B1 for ; Thu, 28 Apr 2016 07:19:22 -0700 (PDT) Received: from mail05.wdf.sap.corp (mail05.sap.corp [194.39.131.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde01.smtp.sap-ag.de (Postfix) with ESMTPS id 58F812B060 for ; Thu, 28 Apr 2016 16:19:20 +0200 (CEST) X-purgate-ID: 152705::1461853160-00003552-BBB61618/0/0 X-purgate-size: 1718 X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate-type: clean X-SAP-SPAM-Status: clean Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail05.wdf.sap.corp (Postfix) with ESMTP id 4BB4241190 for ; Thu, 28 Apr 2016 16:19:20 +0200 (CEST) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 21A021A4AD; Thu, 28 Apr 2016 16:19:20 +0200 (CEST) In-Reply-To: <20160425034833.GW26423@mournblade.imrryr.org> To: dane@ietf.org Date: Thu, 28 Apr 2016 16:19:20 +0200 (CEST) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20160428141920.21A021A4AD@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: Subject: Re: [dane] [Uta] NEWSFLASH: DANE TLSA records published for web.de! X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: mrex@sap.com List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2016 14:19:24 -0000 Viktor Dukhovni wrote: > > Do you ever run into any of the domains whose TLSA records are > incorrect, or whose DNS servers fail authenticated denial of > existence? In other words, is there any mail you bounce because > of DANE that you might otherwise have delivered? > > Today's stats are: > > ~280000 DNSSEC domains that could have an MX host with TLSA RRs. > 15097 domains with valid TLSA RRs > 245 of those have 1+ MX hosts sans TLSA RRs (partial deployment) > 227 domains with DNSSEC problems when doing TLSA lookups > 56 domains with TLSA records that don't match the cert > > Given that the problem domans are rather few, perhaps you've never > run into them? doing DNSSEC verification is not exactly easy, more like sufficiently close to the "beware of the leopard" in THHGTTG for practical matters. None of the regular Linux distro builds of the "dig" tool from the bind package seem to have the necessary code compiled into the binaries. After download bind source and compiling dig myself (which requires some non-intuitive wrangling with the build tool), I see the following DNSSEC outputs: $ bin/dig/dig +sigchase +trusted-key=./root.keys www.ietf.org. | tail -2 ;; Ok this DNSKEY is a Trusted Key, DNSSEC validation is ok: SUCCESS $ bin/dig/dig +sigchase +trusted-key=./root.keys datatracker.ietf.org. | tail -2 ;; Ok this DNSKEY is a Trusted Key, DNSSEC validation is ok: SUCCESS $ bin/dig/dig +sigchase +trusted-key=./root.keys tools.ietf.org. | tail -2 ;; RRSIG is missing for continue validation: FAILED and the latter failure is something that I don't understand. If the IETF can not get DNSSEC right, who should? -Martin From nobody Thu Apr 28 07:39:53 2016 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBD6112D175 for ; Thu, 28 Apr 2016 07:39:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.897 X-Spam-Level: X-Spam-Status: No, score=-7.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 i2lEo8xxihjx for ; Thu, 28 Apr 2016 07:39:49 -0700 (PDT) Received: from teruel.switch.ch (teruel.switch.ch [IPv6:2001:620:0:1b::28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8461D12D14B for ; Thu, 28 Apr 2016 07:39:49 -0700 (PDT) Received: from surlej.switch.ch (surlej.switch.ch [IPv6:2001:620:0:1001::69]) by teruel.switch.ch (8.14.4/8.14.4/Debian-4+deb7u1) with ESMTP id u3SEdimQ031987 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 28 Apr 2016 16:39:46 +0200 Received: from [2001:620:0:69::101] (helo=vpn-ho-b-131.switch.ch) by surlej.switch.ch with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from ) id 1avn6W-0000Kr-Lk; Thu, 28 Apr 2016 16:39:44 +0200 To: mrex@sap.com, dane@ietf.org References: <20160428141920.21A021A4AD@ld9781.wdf.sap.corp> From: Daniel Stirnimann Message-ID: <572220B0.6030208@switch.ch> Date: Thu, 28 Apr 2016 16:39:44 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 MIME-Version: 1.0 In-Reply-To: <20160428141920.21A021A4AD@ld9781.wdf.sap.corp> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SWITCHham-Score: X-CanIt-Geo: ip=2001:620:0:1001::69; country=CH; region=Zurich; city=Zurich; latitude=47.3720; longitude=8.5413; http://maps.google.com/maps?q=47.3720,8.5413&z=6 X-CanItPRO-Stream: switch-ch:outbound (inherits from switch-ch:default, base:default) X-Canit-Stats-ID: Bayes signature not available X-Scanned-By: CanIt (www . roaringpenguin . com) Archived-At: Subject: Re: [dane] [Uta] NEWSFLASH: DANE TLSA records published for web.de! X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.17 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, 28 Apr 2016 14:39:52 -0000 > $ bin/dig/dig +sigchase +trusted-key=./root.keys tools.ietf.org. | tail -2 > ;; RRSIG is missing for continue validation: FAILED > > > and the latter failure is something that I don't understand. > If the IETF can not get DNSSEC right, who should? tools.ietf.org is not signed (http://dnsviz.net/d/tools.ietf.org/Vx-T4Q/dnssec/). You forced dig to validate its signature but there are none. Daniel From nobody Thu Apr 28 07:40:44 2016 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5505812D175 for ; Thu, 28 Apr 2016 07:40:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.896 X-Spam-Level: X-Spam-Status: No, score=-2.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996] autolearn=ham autolearn_force=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 OETeJHmFg681 for ; Thu, 28 Apr 2016 07:40:36 -0700 (PDT) Received: from shaun.rfc1035.com (smtp.v6.rfc1035.com [IPv6:2001:4b10:100:7::25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1703412D18B for ; Thu, 28 Apr 2016 07:40:32 -0700 (PDT) Received: from gromit.rfc1035.com (gromit.rfc1035.com [195.54.233.69]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by shaun.rfc1035.com (Postfix) with ESMTPSA id BE36E2421030; Thu, 28 Apr 2016 14:40:29 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Jim Reid In-Reply-To: <20160428141920.21A021A4AD@ld9781.wdf.sap.corp> Date: Thu, 28 Apr 2016 15:40:29 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <99FD74A6-3DF4-4048-9078-45CCA7162D4A@rfc1035.com> References: <20160428141920.21A021A4AD@ld9781.wdf.sap.corp> To: mrex@sap.com X-Mailer: Apple Mail (2.3124) Archived-At: Cc: dane@ietf.org Subject: [dane] DNSSEC for tools.ietf.org X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.17 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, 28 Apr 2016 14:40:39 -0000 > On 28 Apr 2016, at 15:19, Martin Rex wrote: >=20 > $ bin/dig/dig +sigchase +trusted-key=3D./root.keys tools.ietf.org. | = tail -2 > ;; RRSIG is missing for continue validation: FAILED >=20 >=20 > and the latter failure is something that I don't understand. tools.ietf.org is an unsigned delegation of the signed ietf.org. Now = maybe tools.ietf.org should be signed. Maybe it doesn=E2=80=99t. But it = doesn=E2=80=99t *have* to be signed just because its parent zone is = siged. After all the root is signed and we=E2=80=99re some way off = universal deployment of DNSSEC. Or DANE. BTW, you should be using proper DNSSEC debugging tools. The latest = versions of bind ship with delv and there=E2=80=99s drill from = NLnetLabs. Both are FAR superior to dig's ugly sigchase hack when it = comes to looking at DNSSEC stuff. If you prefer GUIs, try dnsviz. > If the IETF can not get DNSSEC right, who should? They are getting it right AFAICT. From nobody Thu Apr 28 09:15:55 2016 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B850C12D9DE for ; Thu, 28 Apr 2016 09:15:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=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 rl7DeOo5FhFI for ; Thu, 28 Apr 2016 09:15:51 -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 1275F12DA12 for ; Thu, 28 Apr 2016 09:10:01 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 1825D284AED; Thu, 28 Apr 2016 16:10:01 +0000 (UTC) Date: Thu, 28 Apr 2016 16:10:01 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20160428161000.GI3300@mournblade.imrryr.org> References: <20160428141920.21A021A4AD@ld9781.wdf.sap.corp> <99FD74A6-3DF4-4048-9078-45CCA7162D4A@rfc1035.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <99FD74A6-3DF4-4048-9078-45CCA7162D4A@rfc1035.com> User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [dane] DNSSEC for tools.ietf.org X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.17 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, 28 Apr 2016 16:15:54 -0000 On Thu, Apr 28, 2016 at 03:40:29PM +0100, Jim Reid wrote: > > If the IETF can not get DNSSEC right, who should? > > They are getting it right AFAICT. Yes, basically right, here's the DS-free delegation: tools.ietf.org. NS gamay.levkowetz.com. tools.ietf.org. NS zinfandel.levkowetz.com. tools.ietf.org. NS merlot.levkowetz.com. tools.ietf.org. NSEC trac.ietf.org. NS RRSIG NSEC tools.ietf.org. RRSIG NSEC 5 3 1800 20170308083312 20160308073501 40452 ietf.org. The thing one might quibble about is the IMHO much too long RRSIG validity interval. One year signatures are rather long. With this signature in hand, an attacker can deny any signature for tools.ietf.org until March 2017 even if the zone were signed tomorrow. -- Viktor. From nobody Fri Apr 29 11:33:54 2016 Return-Path: X-Original-To: dane@ietf.org Delivered-To: dane@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E28EA12D6F8; Fri, 29 Apr 2016 11:33:47 -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.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160429183347.4745.99919.idtracker@ietfa.amsl.com> Date: Fri, 29 Apr 2016 11:33:47 -0700 Archived-At: Cc: dane@ietf.org Subject: [dane] I-D Action: draft-ietf-dane-openpgpkey-11.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.17 List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Apr 2016 18:33:48 -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 of the IETF. Title : Using DANE to Associate OpenPGP public keys with email addresses Author : Paul Wouters Filename : draft-ietf-dane-openpgpkey-11.txt Pages : 22 Date : 2016-04-29 Abstract: OpenPGP is a message format for email (and file) encryption that lacks a standardized lookup mechanism to securely obtain OpenPGP public keys. DNS-Based Authentication of Named Entities ("DANE") is a method for publishing public keys in DNS. This document specifies a DANE method for publishing and locating OpenPGP public keys in DNS for a specific email address using a new OPENPGPKEY DNS Resource Record. Security is provided via Secure DNS, however the OPENPGPKEY record is not a replacement for verification of authenticity via the "Web Of Trust" or manual verification. The OPENPGPKEY record can be used to encrypt an email that would otherwise have to be sent unencrypted. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dane-openpgpkey/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-dane-openpgpkey-11 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dane-openpgpkey-11 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 Fri Apr 29 13:23:07 2016 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA71E12D1BF for ; Fri, 29 Apr 2016 13:23:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=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 qN57YZX0wPZ9 for ; Fri, 29 Apr 2016 13:23:02 -0700 (PDT) Received: from shannon.7bits.nl (shannon.7bits.nl [IPv6:2a01:1b0:202:40::1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A2FF12D096 for ; Fri, 29 Apr 2016 13:23:02 -0700 (PDT) Received: from [192.168.137.1] (unknown [92.110.143.62]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: peter) by shannon.7bits.nl (Postfix) with ESMTPSA id C2D33C1B96; Fri, 29 Apr 2016 22:22:58 +0200 (CEST) From: "Peter van Dijk" To: dane@ietf.org Date: Fri, 29 Apr 2016 22:22:59 +0200 Message-ID: In-Reply-To: <572204B1.5030401@switch.ch> References: <20160414183856.GL26423@mournblade.imrryr.org> <20160421161734.GO26423@mournblade.imrryr.org> <20160422113901.Horde.bvaiK9UFQkE4OOmIZCUpVYa@webmail.kwsoft.de> <20160422153636.GT26423@mournblade.imrryr.org> <20160425034833.GW26423@mournblade.imrryr.org> <5721DBBA.6000106@switch.ch> <5721E1BD.7040407@switch.ch> <572204B1.5030401@switch.ch> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Mailer: MailMate (1.9.4r5234) Archived-At: Subject: Re: [dane] [Uta] NEWSFLASH: DANE TLSA records published for web.de! X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Apr 2016 20:23:06 -0000 I=E2=80=99ve spoken to web.de/1und1 and they are aware of the weirdness t= hey = put in there. I trust they will rectify it soon. Kind regards, -- = Peter van Dijk PowerDNS.COM BV - https://www.powerdns.com/ On 28 Apr 2016, at 14:40, Daniel Stirnimann wrote: > Seems to be a typo and their signer (PowerDNS) correctly ignored it = > and > used the correct value of 1. > > Daniel > > On 28.04.16 12:11, Daniel Stirnimann wrote: >> The NSEC3 record contains the hash algorithm type 1 >> >> 4c82sp2ag0m9hm9lfkb6d141t4qclui8.gmx.ch. 556 IN NSEC3 1 0 350 - >> 5AEHEF49CLPKJ5CHHRCND7VKKM7MKMJ4 CNAME RRSIG >> >> So, it's only the NSEC3PARAM Hash Algorithm which confuses me. >> >> Daniel >> >> On 28.04.16 11:45, Daniel Stirnimann wrote: >>> Hello >>> >>> I noticed that web.de uses a NSEC3 Hash Algorithm Type 8. >>> >>> But 8 is not assigned: >>> http://www.iana.org/assignments/dnssec-nsec3-parameters/dnssec-nsec3-= parameters.xhtml#dnssec-nsec3-parameters-3 >>> >>> ; <<>> DiG 9.8.3-P1 <<>> web.de NSEC3PARAM +noall +answer >>> ;; global options: +cmd >>> web.de. 600 IN NSEC3PARAM 8 0 333 - >>> >>> ; <<>> DiG 9.8.3-P1 <<>> gmx.ch NSEC3PARAM +noall +answer >>> ;; global options: +cmd >>> gmx.ch. 600 IN NSEC3PARAM 8 0 350 - >>> >>> On a related note, I'm also confused why the browser plugin from >>> https://www.dnssec-validator.cz/ does not recognize that gmx.ch is >>> DNSSEC signed. It works for web.de though! >>> >>> Any idea? >>> >>> Daniel >>> >>> On 25.04.16 05:48, Viktor Dukhovni wrote: >>>> On Fri, Apr 22, 2016 at 04:28:51PM +0000, Gumprich, Mario wrote: >>>> >>>>> We from Unitymedia has enabled DANE outbound a couple of month = >>>>> ago. >>>> >>>> Thanks for the update. >>>> >>>>> Today=E2=80=99s list of DANE inbound enabled domains / MX-IPs extra= cted = >>>>> from logs. >>>>> mail.lux01.de[194.117.254.21] >>>>> ... >>>>> uhura.unitymedia.de[80.69.97.11] >>>>> >>>>> Pretty cool, the list grows from month to month. >>>> >>>> Do you ever run into any of the domains whose TLSA records are >>>> incorrect, or whose DNS servers fail authenticated denial of >>>> existence? In other words, is there any mail you bounce because >>>> of DANE that you might otherwise have delivered? >>>> >>>> Today's stats are: >>>> >>>> ~280000 DNSSEC domains that could have an MX host with TLSA RRs. >>>> 15097 domains with valid TLSA RRs >>>> 245 of those have 1+ MX hosts sans TLSA RRs (partial = >>>> deployment) >>>> 227 domains with DNSSEC problems when doing TLSA lookups >>>> 56 domains with TLSA records that don't match the cert >>>> >>>> Given that the problem domans are rather few, perhaps you've never >>>> run into them? >>>> >>>> Of the ~15k, 56 domains that have at some point in the last ~2 >>>> years appeared in the Google email transparency report dataset. >>>> Of these 30 are in the most recent report: >>>> >>>> gmx.at >>>> conjur.com.br >>>> registro.br >>>> gmx.ch >>>> gmx.com >>>> mail.com >>>> bayern.de >>>> bund.de >>>> gmx.de >>>> jpberlin.de >>>> lrz.de >>>> posteo.de >>>> ruhr-uni-bochum.de >>>> tum.de >>>> unitymedia.de >>>> web.de >>>> octopuce.fr >>>> comcast.net >>>> dd24.net >>>> gmx.net >>>> t-2.net >>>> xs4all.net >>>> xs4all.nl >>>> debian.org >>>> freebsd.org >>>> gentoo.org >>>> ietf.org >>>> openssl.org >>>> samba.org >>>> torproject.org >>>> >>>> I'm still waiting for icann.org to show up on the list, and ideally >>>> a few prominent ".edu" domains that have gone to all the trouble >>>> of deploying DNSSEC, but have not yet published SMTP TLSA records. >>>> The ones from Gmail's transparentcy report would be: >>>> >>>> berkeley.edu >>>> fhsu.edu >>>> iastate.edu >>>> indiana.edu >>>> iu.edu >>>> iupui.edu >>>> nau.edu >>>> stanford.edu >>>> temple.edu >>>> ucdavis.edu >>>> ucr.edu >>>> uiowa.edu >>>> umbc.edu >>>> yale.edu >>>> >>>> None of these have made the leap as yet. It is possible, though >>>> not very likely that some departments have, I only scan domains >>>> directly delegated from public suffixes. >>>> >>>> A substantial outlier with problem TLSA records is ".br". The >>>> registry/sole-registrar provides a web interface for adding TLSA >>>> records, but no API for keeping them up to date. As a result, a >>>> large fraction of ".br" domains with TLSA RRs have invalid records, >>>> or related issues. Many don't promptly/ever act on email notices >>>> (at least in English). It may be wise to not enable DANE for ".br" >>>> domains. >>>> >>>> .BR TLSA records don't match reality: >>>> >>>> allispdv.com.br >>>> bebidaliberada.com.br >>>> giantit.com.br >>>> idsys.com.br >>>> lojabrum.com.br >>>> netlig.com.br >>>> prodnsbr.com.br >>>> simplesestudio.com.br >>>> solucoesglobais.com.br >>>> ticketmt.com.br >>>> twsolutions.net.br >>>> >>>> .BR DNSSEC lookup problems: >>>> >>>> bb.b.br >>>> dpf.gov.br >>>> pf.gov.br >>>> justicaeleitoral.jus.br >>>> tre-al.jus.br >>>> tre-ce.jus.br >>>> tre-ma.jus.br >>>> tre-mg.jus.br >>>> tre-ms.jus.br >>>> tre-mt.jus.br >>>> tre-pa.jus.br >>>> tre-pb.jus.br >>>> tre-pe.jus.br >>>> tre-pi.jus.br >>>> tre-pr.jus.br >>>> tre-rn.jus.br >>>> tre-rr.jus.br >>>> tre-sp.jus.br >>>> m3ganet.net.br >>>> >>> >>> _______________________________________________ >>> dane mailing list >>> dane@ietf.org >>> https://www.ietf.org/mailman/listinfo/dane >>> >> > > -- = > SWITCH > Daniel Stirnimann, SWITCH-CERT > Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland > phone +41 44 268 15 15, direct +41 44 268 16 24 > daniel.stirnimann@switch.ch, http://www.switch.ch > > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane From nobody Sat Apr 30 10:11:55 2016 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB88012D17F for ; Sat, 30 Apr 2016 10:11:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, RP_MATCHES_RCVD=-0.996] autolearn=no autolearn_force=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 nMeBWEOFLxud for ; Sat, 30 Apr 2016 10:11:51 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (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 4A85312B012 for ; Sat, 30 Apr 2016 10:11:51 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3qxxtq6JymzCWf for ; Sat, 30 Apr 2016 19:11:47 +0200 (CEST) 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 8GVtoNlo_XWa for ; Sat, 30 Apr 2016 19:11:44 +0200 (CEST) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS for ; Sat, 30 Apr 2016 19:11:44 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 007513531BD; Sat, 30 Apr 2016 13:11:43 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.10.3 bofh.nohats.ca 007513531BD Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id EBEE640D35B5 for ; Sat, 30 Apr 2016 13:11:43 -0400 (EDT) Date: Sat, 30 Apr 2016 13:11:43 -0400 (EDT) From: Paul Wouters To: dane WG list In-Reply-To: <20160429183347.4745.99919.idtracker@ietfa.amsl.com> Message-ID: References: <20160429183347.4745.99919.idtracker@ietfa.amsl.com> User-Agent: Alpine 2.20 (LRH 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII Archived-At: Subject: Re: [dane] I-D Action: draft-ietf-dane-openpgpkey-11.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.17 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, 30 Apr 2016 17:11:54 -0000 On Fri, 29 Apr 2016, internet-drafts@ietf.org wrote: > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-dane-openpgpkey-11 The changes in -11 are in response to comments receiveing during the IESG review: https://datatracker.ietf.org/doc/draft-ietf-dane-openpgpkey/ballot/ It also adds the RRTYPE request template in Appendix B as requested. This should address all the comments I have received. Please let me know if you have any unaddressed or unresolved issues. Paul From nobody Sat Apr 30 10:14:58 2016 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC59912D15E for ; Sat, 30 Apr 2016 10:14:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, RP_MATCHES_RCVD=-0.996] autolearn=no autolearn_force=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 NIeYHTIlVvFP for ; Sat, 30 Apr 2016 10:14:55 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (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 985B612D17E for ; Sat, 30 Apr 2016 10:14:55 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3qxxyQ1Bwnz1kf for ; Sat, 30 Apr 2016 19:14:54 +0200 (CEST) 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 MS5pGsD2pDDt for ; Sat, 30 Apr 2016 19:14:52 +0200 (CEST) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS for ; Sat, 30 Apr 2016 19:14:52 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 740633531BD; Sat, 30 Apr 2016 13:14:51 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.10.3 bofh.nohats.ca 740633531BD Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 6B9A740D35B5 for ; Sat, 30 Apr 2016 13:14:51 -0400 (EDT) Date: Sat, 30 Apr 2016 13:14:51 -0400 (EDT) From: Paul Wouters To: dane@ietf.org In-Reply-To: <20160428161000.GI3300@mournblade.imrryr.org> Message-ID: References: <20160428141920.21A021A4AD@ld9781.wdf.sap.corp> <99FD74A6-3DF4-4048-9078-45CCA7162D4A@rfc1035.com> <20160428161000.GI3300@mournblade.imrryr.org> User-Agent: Alpine 2.20 (LRH 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [dane] DNSSEC for tools.ietf.org X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.17 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, 30 Apr 2016 17:14:56 -0000 On Thu, 28 Apr 2016, Viktor Dukhovni wrote: > > Yes, basically right, here's the DS-free delegation: > > tools.ietf.org. NS gamay.levkowetz.com. > tools.ietf.org. NS zinfandel.levkowetz.com. > tools.ietf.org. NS merlot.levkowetz.com. > tools.ietf.org. NSEC trac.ietf.org. NS RRSIG NSEC > tools.ietf.org. RRSIG NSEC 5 3 1800 20170308083312 20160308073501 40452 ietf.org. > > The thing one might quibble about is the IMHO much too long RRSIG > validity interval. One year signatures are rather long. With this > signature in hand, an attacker can deny any signature for tools.ietf.org > until March 2017 even if the zone were signed tomorrow. or until ietf.org rolls the ZSK, whichever time period is shorter. Paul From nobody Sat Apr 30 21:18:07 2016 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83A5812D1C7 for ; Sat, 30 Apr 2016 21:18:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=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 hFeYyQmeIHQx for ; Sat, 30 Apr 2016 21:18:03 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE84512D1C1 for ; Sat, 30 Apr 2016 21:18:03 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id C8FBD284B6F; Sun, 1 May 2016 04:18:01 +0000 (UTC) Date: Sun, 1 May 2016 04:18:01 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20160501041801.GL3300@mournblade.imrryr.org> References: <20160428141920.21A021A4AD@ld9781.wdf.sap.corp> <99FD74A6-3DF4-4048-9078-45CCA7162D4A@rfc1035.com> <20160428161000.GI3300@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [dane] DNSSEC for tools.ietf.org X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.17 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, 01 May 2016 04:18:05 -0000 On Sat, Apr 30, 2016 at 01:14:51PM -0400, Paul Wouters wrote: > >Yes, basically right, here's the DS-free delegation: > > > > tools.ietf.org. NS gamay.levkowetz.com. > > tools.ietf.org. NS zinfandel.levkowetz.com. > > tools.ietf.org. NS merlot.levkowetz.com. > > tools.ietf.org. NSEC trac.ietf.org. NS RRSIG NSEC > > tools.ietf.org. RRSIG NSEC 5 3 1800 20170308083312 20160308073501 40452 ietf.org. > > > >The thing one might quibble about is the IMHO much too long RRSIG > >validity interval. One year signatures are rather long. With this > >signature in hand, an attacker can deny any signature for tools.ietf.org > >until March 2017 even if the zone were signed tomorrow. > > or until ietf.org rolls the ZSK, whichever time period is shorter. No, they have to roll the KSK, because the attacker can also replay the current DNSKEY RRset along with the current unsigned delegation, the DNSKEY RRset is not surprisingly also good for a year. The DS RRset at the .org level has a more sensible lifetime (21d+1h), so if a new KSK were deployed now, the insecure delegation could be invalidated around May 17th. $ dig +noall +ans +nocl +nottl +dnssec +multi -t dnskey ietf.org ietf.org. DNSKEY 257 3 5 ( AwEAAavjQ1H6pE8FV8LGP0wQBFVL0EM9BRfqxz9p/sZ+ 8AByqyFHLdZcHoOGF7CgB5OKYMvGOgysuYQloPlwbq7W s5WywbutbXyG24lMWy4jijlJUsaFrS5EvUu4ydmuRc/T GnEXnN1XQkO+waIT4cLtrmcWjoY8Oqud6lDaJdj1cKr2 nX1NrmMRowIu3DIVtGbQJmzpukpDVZaYMMAm8M5vz4U2 vRCVETLgDoQ7rhsiD127J8gVExjO8B0113jCajbFRcMt UtFTjH4z7jXP2ZzDcXsgpe4LYFuenFQAcRBRlE6oaykH R7rlPqqmw58nIELJUFoMcb/BdRLgbyTeurFlnxs= ) ; key id = 45586 ietf.org. DNSKEY 256 3 5 ( AwEAAdDECajHaTjfSoNTY58WcBah1BxPKVIHBz4IfLjf qMvium4lgKtKZLe97DgJ5/NQrNEGGQmr6fKvUj67cfrZ UojZ2cGRizVhgkOqZ9scaTVXNuXLM5Tw7VWOVIceeXAu uH2mPIiEV6MhJYUsW6dvmNsJ4XwCgNgroAmXhoMEiWEj BB+wjYZQ5GtZHBFKVXACSWTiCtddHcueOeSVPi5WH94V lubhHfiytNPZLrObhUCHT6k0tNE6phLoHnXWU+6vpsYp z6GhMw/R9BFxW5PdPFIWBgoWk2/XFVRSKG9Lr61b2z1R 126xeUwvw46RVy3hanV3vNO7LM5HniqaYclBbhk= ) ; key id = 40452 ietf.org. RRSIG DNSKEY 5 2 1800 20170308083223 ( 20160308073501 45586 ietf.org. IOQgHR12mJD0TO9+wnJLDh7N/2lhnIrcvf5ZlwtwBWn6 LDg2OJVN/CGtoOaNUYMPxgrzG5Ww7qAMn84vAhunBf1c +yfX5XCO99+K3tXsqRg+znMnAmOTFRcTztG2B8u4keRu beKYWfXFk9LGmGd7BXczKa0F+HjhyeLpOeXOnfTMn1Gy RvcVetJJqp7HpKowc23rxSEADC/NB+3euARWUTlrk9AX P9OThWMzOlYk6hvBPNQtrl5iM8eZGw9QqF3SDlduHyFd bmNdD3QR9XjfYpOq3MuqWCMbrBTUmljNRLO8eswUCYxl IrE5vggDraAZiSGHmTf5g3YToPchp3DkTg== ) ietf.org. RRSIG DNSKEY 5 2 1800 20170308083248 ( 20160308073501 40452 ietf.org. n5vYSrmnnylmFVP6KmqjujHDOVlr+A8o8RldrXZENJNU BBGs/HsA/WkEQiLOBE3dv8CpOtF7fCH4fwNzS8J47K/K 64Zb4Z13Z0aEWtpKo1lJDGKr/UWn0s9PQelMWu3z2tQa vfUeCHuZZDwhhHf2jSxiq5AOtRCOzbDCvAmPhzW4/sXX QzVanXbQzBWAlIBIDO065zUla08ldkWC4xPE0S9MzAwA MEWkhcfau6FfI0+W5ePRdcVpXKywZq8VmWjxV/g2f5sT Ws+dXMvWVKfsvyYx94NIwxL+hbMUX+eik50d5S3T946s AzyN5WzzkVR6QTxCs7THASBPuiruC2Luqw== ) $ dig +noall +ans +nocl +nottl +dnssec +multi -t ds ietf.org ietf.org. DS 45586 5 1 ( D0FDF996D1AF2CCDBDC942B02CB02D379629E20B ) ietf.org. DS 45586 5 2 ( 67FCD7E0B9E0366309F3B6F7476DFF931D5226EDC534 8CD80FD82A081DFCF6EE ) ietf.org. RRSIG DS 7 2 86400 20160516150430 ( 20160425140430 20264 org. gL/MRQuOAoHDE25R3K9pvSFjJdd6ugmdSuwZSvnhEqP2 FemzlHFbPV0eNwJlezIAV4p95U/Hxikb3dgGSTac6jch 9RIyfdtDU/Rp6nk2SYjJRnrc4VxBTSfugcBHPGOmlHtq SPDrjk8iNM0x9r+ZTXwGod40oX9dobwCE3OQ5NM= ) -- Viktor.