From nobody Mon Apr 3 12:45:16 2017 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 CE6A1129515; Mon, 3 Apr 2017 12:45:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 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.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14c1DmycaWMb; Mon, 3 Apr 2017 12:45:07 -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 CA1801294C3; Mon, 3 Apr 2017 12:45:06 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3vxjHg4cHRzCvC; Mon, 3 Apr 2017 21:45:03 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1491248703; bh=Tu0tHCk+qnP2VLTZep4I6cCNKs67wfa2G2aUOAXXkCM=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=HYj5CKjhcn/KnfPX6LoYq9SvyRivwYTBJgWk1q/xICsINN8FXkzBe0IN5tRtngRu9 FTB0J+24Jv8adHk3EEHOu6fUU2G+ueqkTxzwRHciTG4Bs+xkT1T+HluctT5mQinR3X 5XULvi+f4Th/3thU8s9ZBBONVDBGSEu9TuPoHwu4= 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 Me1BQHzcV7ZS; Mon, 3 Apr 2017 21:45:01 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Mon, 3 Apr 2017 21:45:00 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 852C73943A4; Mon, 3 Apr 2017 15:44:59 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 852C73943A4 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 60EC74000880; Mon, 3 Apr 2017 15:44:59 -0400 (EDT) Date: Mon, 3 Apr 2017 15:44:59 -0400 (EDT) From: Paul Wouters To: Viktor Dukhovni cc: trans@ietf.org, dane@ietf.org In-Reply-To: Message-ID: References: <455EC3FC-9140-40D3-88F8-77990B7C7DD0@vpnc.org> <1DA6DC8F-CA06-4453-96E6-D8D257555437@dukhovni.org> <9FC39E28-4285-40F8-8FE9-283FA83B1A0A@dukhovni.org> User-Agent: Alpine 2.20.999 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [dane] [Trans] CT for DNSSEC X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Apr 2017 19:45:09 -0000 On Wed, 29 Mar 2017, Viktor Dukhovni wrote: >> Why not create an explicit Non-existence of DS (NDS) RR that gets logged along with DS and NS? > > This is not needed, the NSEC/NSEC3 RRs already serve that role. > > For NSEC records (RFC4034), an unsigned delegation looks like: > > example.com. IN NS ns1.example.com. > example.com. IN NSEC examplf.com NS > example.com. IN RRSIG NSEC ... > > this proves that NS (or other depending on the content of the type > bitmap of the NSEC record) records exist for example.com, but DS > records do not. I don't think so? Because this is the parental NS RRset for the child, which the parent does not sign. The NSEC only covers the existance of the DS record, not of the glue records. And those glue records can still be maliciously pointing elsewhere. Or the zone cut can be temporarilly removed at the parent to sign the child's TLSA record directly. You really need to find the NSEC(3) record that proves the parent has no DS record for the child zone, and really have to find and submit the TLSA record and RRSIG. That way the logs can tell who signed the DS and/or TLSA record. Checking the child APEX is of no use because the parent might be overriding the delegation briefly. Eg remove the DS record and/or NS records, publish a childzone TLSA record as "without a zone cut", and then restoring the DS/NS chain again. The only way out I see is to log the TLSA records, so you know which key signed it. If this is done, we clearly need a ratelimit and/or some method of finding conflicting overlapping-in-time records. > With NSEC3 (rfc5155), and the "opt-out" bit the situation can be > more complex because the answer may not establish the existence of > example.com. Instead we may get an existence proof for the closest > encloser (ancestor domain) and proof that "example.com" is not signed, > but no proof of its existence. This means that to avoid spam, a log > might want to independently verify the existence of the insecure > delegation by repeating the query, so as to avoid storing data for > non-existent domains with the insecure NXDOMAIN modified to NOERROR > with made up NS records. Repeating the query is not a real solution, as the malicious parent could open a small time window for the attack and close it again. Clients really need to submit state their validation reached. This cannot include any unsigned state as that cannot be trusted itself, but should include the signatures proving the unsigned state. Paul From nobody Tue Apr 4 02:51:38 2017 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 9F6BF126DC2; Tue, 4 Apr 2017 02:51:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, URIBL_BLOCKED=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 4zj3PaK9Ty4V; Tue, 4 Apr 2017 02:51:33 -0700 (PDT) Received: from ppsw-42.csi.cam.ac.uk (ppsw-42.csi.cam.ac.uk [131.111.8.142]) (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 80705128896; Tue, 4 Apr 2017 02:51:33 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://help.uis.cam.ac.uk/email-scanner-virus Received: from grey.csi.cam.ac.uk ([131.111.57.57]:59388) by ppsw-42.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.138]:25) with esmtps (TLSv1:ECDHE-RSA-AES256-SHA:256) id 1cvL7X-000Z0o-80 (Exim 4.89) (return-path ); Tue, 04 Apr 2017 10:51:27 +0100 Date: Tue, 4 Apr 2017 10:51:27 +0100 From: Tony Finch To: Paul Wouters cc: Viktor Dukhovni , trans@ietf.org, dane@ietf.org In-Reply-To: Message-ID: References: <455EC3FC-9140-40D3-88F8-77990B7C7DD0@vpnc.org> <1DA6DC8F-CA06-4453-96E6-D8D257555437@dukhovni.org> <9FC39E28-4285-40F8-8FE9-283FA83B1A0A@dukhovni.org> User-Agent: Alpine 2.11 (DEB 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Archived-At: Subject: Re: [dane] [Trans] CT for DNSSEC X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Apr 2017 09:51:36 -0000 Paul Wouters wrote: > > Because this is the parental NS RRset for the child, which the parent > does not sign. Right. > The NSEC only covers the existance of the DS record, not of the glue > records. Not quite. A delegation NSEC record lists NS NSEC RRSIG and maybe DS, even though NS isn't signed. (You are right that glue records aren't in the NSEC chain, though.) > You really need to find the NSEC(3) record that proves the parent has > no DS record for the child zone, and really have to find and submit > the TLSA record and RRSIG. That way the logs can tell who signed the > DS and/or TLSA record. Yes. Should probably log the whole DS/DNSKEY/RRSIG chain. You don't need to log NSEC(3) unless you need to log a proof of nonexistence - maybe to prove lack of delegation points if there are intermediate labels? Tony. -- f.anthony.n.finch http://dotat.at/ - I xn--zr8h punycode Fitzroy: Northerly veering northeasterly 4 or 5, increasing 5 to 7 in east. Rough or very rough. Drizzle. Moderate or good. From nobody Tue Apr 11 10:16:09 2017 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 8FE3712704A for ; Tue, 11 Apr 2017 10:16:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 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.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=domblogger.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1T9FUIUnlfmt for ; Tue, 11 Apr 2017 10:16:05 -0700 (PDT) Received: from mail.domblogger.net (mail.domblogger.net [IPv6:2600:3c00::f03c:91ff:fe56:d6a2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D92A12EB29 for ; Tue, 11 Apr 2017 10:16:05 -0700 (PDT) Received: from localhost.localdomain (68-189-44-253.dhcp.rdng.ca.charter.com [68.189.44.253]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.domblogger.net (Postfix) with ESMTPSA id 0F9E55F1 for ; Tue, 11 Apr 2017 17:16:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=domblogger.net; s=default; t=1491930965; bh=xXnKtSNwoStCjcp9EshF4Fr4/0+pOW8RG0ZWGxabQNw=; h=To:From:Subject:Date; b=WobcM0XSrvV2Qidaudo54+FXV1D5y0otp2rXMJ0C6IorHdxYDqF3nLWSCGfrUmkLB AN6Ec8h0VPQE3xlBys1h4gx7yxp77+FlNJO3Jv0EZQcEpOVMU/kaZoukdaKGT6CTrt b8in1BoCwRqNvRnZO4Kp3oxcmGdNbKxb4CmXI2h0= To: dane@ietf.org From: Alice Wonder Message-ID: Date: Tue, 11 Apr 2017 10:16:04 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [dane] Improving DANE S/MIME Privacy X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.22 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, 11 Apr 2017 17:16:07 -0000 Hello, This is respect to DNSSEC validation for S/MIME When generating a hash for use in DNS, the draft for DANE/SMIME currently only uses the username portion of the address. The obvious (and noted) privacy implications are that someone could discover e-mail addresses by rainbow table DNS queries and/or zone walking. I believe this can be mitigated. S/MIME makes use of x.509 certificates, so I suggest using the serial number from the x.509 certificate as a salt with the username before taking the hash. This could be done optionally rather than mandatory, though I certainly would want to do it on mail systems I administer. One of the things I worry about is spammers discovering valid e-mail addresses through the DANE S/MIME and then using the public key of that user to send encrypted malware that can not be filtered on the SMTP servers because it is hidden. If the serial number for the x.509 certificate is a salt for the hash, then spammers can not determine the validity of an e-mail address from DNS but those who already have the certificate can use DNS to DANE validate the certificate. Thank you for your time, Michael A. Peters (aka Alice Wonder) From nobody Tue Apr 11 10:39:00 2017 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 1482A129584 for ; Tue, 11 Apr 2017 10:38:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=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 az9x3-UVewPU for ; Tue, 11 Apr 2017 10:38:57 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7858C12704A for ; Tue, 11 Apr 2017 10:38:57 -0700 (PDT) Received: from vpro.lan (cpe-74-71-8-253.nyc.res.rr.com [74.71.8.253]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id A17167A32F1 for ; Tue, 11 Apr 2017 17:38:56 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) From: Viktor Dukhovni Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Tue, 11 Apr 2017 13:38:55 -0400 References: To: IETF DANE Mailinglist In-Reply-To: Message-Id: <4BE233BA-D524-4D05-87C5-E898DD646E7C@dukhovni.org> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [dane] Improving DANE S/MIME Privacy X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.22 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, 11 Apr 2017 17:38:59 -0000 > On Apr 11, 2017, at 1:16 PM, Alice Wonder = wrote: >=20 >=20 > One of the things I worry about is spammers discovering valid e-mail = addresses > through the DANE S/MIME and then using the public key of that user to = send > encrypted malware that can not be filtered on the SMTP servers because = it > is hidden. The simplest solution is to publish only "2 1 1" records in the DNS that identify the CA that signs the user's certificate, and does not vend the underlying public key. Then a first-contact message to any recipient goes in the clear, signed by the originator, along with the originator's certificate. The recipient can then respond with an encrypted and signed message that makes it possible for all further communication to be fully protected. If the sender is a spammer, the recipient should not respond with a message that enables further communication to be encrypted. Note also that the problem you're concerned about already exists with PGP keyservers, but the authenticity of the data on those servers has much lower assurance. DANE SMIMEA records are largely an improvement on the PGP keyserver model. If the design were up to me, I'd not have published per-user keys. Instead a site-wide trust-anchor record scales better to large user communities, and mostly addresses your concerns. Of course user keys can leak by various means (posting signed messages to a list, replying to a spammer, ...). Preventing that entirely seems impossible, but policy mechanisms in the MUA could make accidential leakage less likely (e.g. not signing messages that are not addressed to someone in the user's "address book", so a conscious manual step would need to be taken to leak a public key that enables encryption in the reverse direction). Today's MUAs support End-to-End email encryption very poorly. Much usability work needs to happen before End-to-End email encryption is more than a curiosity. --=20 Viktor. From nobody Tue Apr 11 11:52:14 2017 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 78C8D12EC3C for ; Tue, 11 Apr 2017 11:52:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=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 7PK4UziCqVej for ; Tue, 11 Apr 2017 11:52:07 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AEAB312EC2F for ; Tue, 11 Apr 2017 11:52:07 -0700 (PDT) Received: from [172.31.31.193] (gzac12-mdf2-1.aoa.twosigma.com [208.77.215.155]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id E3FA77A32F1 for ; Tue, 11 Apr 2017 18:52:06 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Viktor Dukhovni In-Reply-To: <4BE233BA-D524-4D05-87C5-E898DD646E7C@dukhovni.org> Date: Tue, 11 Apr 2017 14:39:56 -0400 Content-Transfer-Encoding: quoted-printable Reply-To: IETF DANE Mailinglist Message-Id: <7AF2817A-1564-44C5-A049-4F210737760F@dukhovni.org> References: <4BE233BA-D524-4D05-87C5-E898DD646E7C@dukhovni.org> To: IETF DANE Mailinglist X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [dane] Improving DANE S/MIME Privacy X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.22 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, 11 Apr 2017 18:52:12 -0000 > On Apr 11, 2017, at 1:38 PM, Viktor Dukhovni = wrote: >=20 > If the design were up to me, I'd not have published per-user keys. > Instead a site-wide trust-anchor record scales better to large user > communities, and mostly addresses your concerns. I should note that one can of course implement one's SMIMEA deployment in exactly this way, something along the lines of: *._smimecert.example.net. IN SMIMEA 2 1 1 = e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855 would associate the same TA public key digest with every user, and would not enable user enumeration. --=20 Viktor. From nobody Tue Apr 11 12:15:13 2017 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 2977912EC8C for ; Tue, 11 Apr 2017 12:15:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 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.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l_P74AbApJJM for ; Tue, 11 Apr 2017 12:15:11 -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 45F5F12EC95 for ; Tue, 11 Apr 2017 12:15:04 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3w2cFL64X9z314; Tue, 11 Apr 2017 21:15:02 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1491938102; bh=LmC13GJ5T05Lc8UVNCsSFJfX/JhffC0IufAfbVBrQ9E=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=fvIXa8/We84fGbFNWSE58/dK9t+E+eT5qlbtRvzyhWtwgao9+nRzMAKfFkARV2Y4x /1H6kFI3EfwCNQ1E9bQ3umyIA83Drw1eLsDL4O4+6s40E1BNwPh+TiVpLD3Xueus96 64Vni74+iTVA5z/r8brvuuyvO7R2LfPlURJbg2iY= 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 TUCyE_8eISJ8; Tue, 11 Apr 2017 21:15:02 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Tue, 11 Apr 2017 21:15:02 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 30F8F418516; Tue, 11 Apr 2017 15:15:01 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 30F8F418516 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 199BF40D3585; Tue, 11 Apr 2017 15:15:01 -0400 (EDT) Date: Tue, 11 Apr 2017 15:15:00 -0400 (EDT) From: Paul Wouters To: Alice Wonder cc: dane@ietf.org In-Reply-To: Message-ID: References: User-Agent: Alpine 2.20.999 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [dane] Improving DANE S/MIME Privacy X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.22 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, 11 Apr 2017 19:15:12 -0000 On Tue, 11 Apr 2017, Alice Wonder wrote: > If the serial number for the x.509 certificate is a salt for the hash, then > spammers can not determine the validity of an e-mail address from DNS but > those who already have the certificate can use DNS to DANE validate the > certificate. Except the whole point of this record is to publish that certificate, so clearly the spammers have a copy of the serial number too :) Paul From nobody Tue Apr 11 13:02:18 2017 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 1D975131444 for ; Tue, 11 Apr 2017 13:02:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=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 SYYBlDHvptLt for ; Tue, 11 Apr 2017 13:02:16 -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 7F078130A93 for ; Tue, 11 Apr 2017 13:02:14 -0700 (PDT) Received: (qmail 7531 invoked from network); 11 Apr 2017 20:02:13 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 11 Apr 2017 20:02:13 -0000 Date: 11 Apr 2017 20:01:51 -0000 Message-ID: <20170411200151.72185.qmail@ary.lan> From: "John Levine" To: dane@ietf.org Cc: alice@domblogger.net In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dane] Improving DANE S/MIME Privacy X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.22 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, 11 Apr 2017 20:02:17 -0000 In article you write: >The obvious (and noted) privacy implications are that someone could >discover e-mail addresses by rainbow table DNS queries and/or zone walking. There are a lot easier ways to find e-mail addresses, and the problem of probing servers to see if addresses are valid has been around for 20 years. To the extent that we worry about it at all, the mail community has a lot of countermeasures that we needn't rehash here. >S/MIME makes use of x.509 certificates, so I suggest using the serial >number from the x.509 certificate as a salt with the username before >taking the hash. Uh, what? If you already have the cert, why do you need to do the lookup? And if you don't have the cert, where do you get the salt? >One of the things I worry about is spammers discovering valid e-mail >addresses through the DANE S/MIME and then using the public key of that >user to send encrypted malware that can not be filtered on the SMTP >servers because it is hidden. This is not a new or particularly interesting concern. Many people have noted that with encrypted mail, all of the spam body checks have to happen after it's decrypted. Malware signatures are just one example of that. R's, John From nobody Tue Apr 11 15:25:22 2017 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 7E7A0128796 for ; Tue, 11 Apr 2017 15:25:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 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.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=domblogger.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NpWBHTH9EJIP for ; Tue, 11 Apr 2017 15:25:18 -0700 (PDT) Received: from mail.domblogger.net (mail.domblogger.net [104.200.18.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33E001286B1 for ; Tue, 11 Apr 2017 15:25:18 -0700 (PDT) Received: from localhost.localdomain (68-189-44-253.dhcp.rdng.ca.charter.com [68.189.44.253]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.domblogger.net (Postfix) with ESMTPSA id 9FAD71A6; Tue, 11 Apr 2017 22:25:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=domblogger.net; s=default; t=1491949517; bh=JKbcsMizxT8RtQm/iprYa4niogbH3jE7YJdeQOF1oJI=; h=Subject:To:References:Cc:From:Date:In-Reply-To; b=Nv/WQ8W+FU6wcTlfFAj55faPuAfA+DeWsMrWvATAh+Smw4unhH5uYbpzJfs68DT2Q UACS5OUy4GpNGVVDbv0e+wfy34k7Lhw7u26MEuaZ6rYiTxOmS+jZbJnIGGO3alcky3 fRSs9cj/rMlv0io+znhbllQPE35TSgLlUiNN/qV4= To: Paul Wouters References: Cc: dane@ietf.org From: Alice Wonder Message-ID: <0d74ee85-fe33-f245-6702-ae0b67040cd8@domblogger.net> Date: Tue, 11 Apr 2017 15:25:15 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dane] Improving DANE S/MIME Privacy X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.22 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, 11 Apr 2017 22:25:19 -0000 On 04/11/2017 12:15 PM, Paul Wouters wrote: > On Tue, 11 Apr 2017, Alice Wonder wrote: > >> If the serial number for the x.509 certificate is a salt for the hash, >> then spammers can not determine the validity of an e-mail address from >> DNS but those who already have the certificate can use DNS to DANE >> validate the certificate. > > Except the whole point of this record is to publish that certificate, so > clearly the spammers have a copy of the serial number too :) > > Paul Okay I think my perspective on this is different. Due to epilepsy, I do not drive and require more sleep than most people and frequently must lie down. Not conductive to a good income, so I never used S/MIME simply because I did not want to pay for certs for my various e-mail addresses. I tried OpenPGP but found the web of trust to be too complex for most people I communicate with and found the procedure for revoking a private key that may have been compromised too awkward. I saw S/MIME with DANE as a way to use self-signed x.509 certs with confidence (more confidence than I personally have in the CA system where fraudulent certs are not uncommon, and where software like content filters and superfish often insert a root authority into user's trusted list) and saw S/MIME DANE as a way to validate those self-signed certificates, not as a way to distribute them. I am sorry, I misunderstood the purpose. That being said, the suggestion of using 2 1 1 or even 2 0 0 entries may give the privacy I seek. If a * wildcard works with DNSSEC (I've never tried personally tried them) then the e-mail domain could be the certificate authority for x.509 certificates on the domain and sign certificates for the users that could then be DANE validated without DNS giving positive confirmation to the existence of an address or revealing the public key needed for a spammer to bypass the content filtering when sending malware to random users. That is probably a better solution than using a serial number as a hash, and probably is easier to manage too as it only requires one DNS entry for every user on the system. From nobody Wed Apr 12 09:19:27 2017 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 90A04131752 for ; Wed, 12 Apr 2017 09:19:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.102 X-Spam-Level: X-Spam-Status: No, score=-0.102 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WHGTCEtnKlIK for ; Wed, 12 Apr 2017 09:19:23 -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 41586131774 for ; Wed, 12 Apr 2017 09:19:23 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3w38J875NCz3Nr; Wed, 12 Apr 2017 18:19:20 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1492013961; bh=qLzTVkqyrb7IHp4dKKTHVqFcsb8DXqlELWA8BexXtfM=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=EWjzLsX1sWDO905tHbcFYJR+BxzigWbnzpMxc0DP0E5KPYwoeVtFZwREoe8FnUvDn BPPoTzKmKMDs0BMoEwG7yJx2HKX34Jogynbsj9VCKYd8D98HuHGvAAwbRNlQz9L00q HmEkA57KtzrKqzmsToBkCuhnytq8UukjKb1zE3w8= 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 jtFp6dMUugP1; Wed, 12 Apr 2017 18:19:17 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Wed, 12 Apr 2017 18:19:17 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 8236D37019; Wed, 12 Apr 2017 12:19:16 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 8236D37019 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 703384161E1B; Wed, 12 Apr 2017 12:19:16 -0400 (EDT) Date: Wed, 12 Apr 2017 12:19:16 -0400 (EDT) From: Paul Wouters To: Alice Wonder cc: dane@ietf.org In-Reply-To: <0d74ee85-fe33-f245-6702-ae0b67040cd8@domblogger.net> Message-ID: References: <0d74ee85-fe33-f245-6702-ae0b67040cd8@domblogger.net> User-Agent: Alpine 2.20.999 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [dane] Improving DANE S/MIME Privacy X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.22 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, 12 Apr 2017 16:19:25 -0000 On Tue, 11 Apr 2017, Alice Wonder wrote: > That being said, the suggestion of using 2 1 1 or even 2 0 0 entries may give > the privacy I seek. It will, but you will then have to come up with a lookup system to find the SMIME cert for a given user. If I want to email you without having prior contact, how do I find your SMIME cert? Sure, if you email me you can attach it, but then the problem moves from me to you on the first email message. And when you create some other lookup mechanism to find my key, you can use that lookup mechanism to harvest email addresses. In the end, email addresses are a point of contact and hard to keep secret. Paul From nobody Wed Apr 12 09:29:27 2017 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 C2E4012EADE for ; Wed, 12 Apr 2017 09:29:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 2-MwTpC62fyW for ; Wed, 12 Apr 2017 09:29:09 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72F09131777 for ; Wed, 12 Apr 2017 09:29:06 -0700 (PDT) Received: from vpro.lan (cpe-74-71-8-253.nyc.res.rr.com [74.71.8.253]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id D13327A32F1 for ; Wed, 12 Apr 2017 16:29:05 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Viktor Dukhovni In-Reply-To: Date: Wed, 12 Apr 2017 12:29:04 -0400 Content-Transfer-Encoding: quoted-printable Reply-To: IETF DANE Mailinglist Message-Id: <6CBC1EB1-B87E-4CBE-B0D4-E7CC8B090165@dukhovni.org> References: <0d74ee85-fe33-f245-6702-ae0b67040cd8@domblogger.net> To: IETF DANE Mailinglist X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [dane] Improving DANE S/MIME Privacy X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.22 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, 12 Apr 2017 16:29:11 -0000 > On Apr 12, 2017, at 12:19 PM, Paul Wouters wrote: >=20 >> That being said, the suggestion of using 2 1 1 or even 2 0 0 entries = may give the privacy I seek. >=20 > It will, but you will then have to come up with a lookup system to = find > the SMIME cert for a given user. No lookup system required, the certificate comes along with any signed reply to the first contact message. If that message is signed, then the reply can also be encrypted. > If I want to email you without having prior contact, how do I find > your SMIME cert? You don't, and this is a feature, because Alice did not want S/MIME certificate publication to be an easy anti-spam/anti-virus filter bypass mechanism. With "SMIME 2 1 1 ..." first contact is in the clear. > Sure, if you email me you can attach it, but then the problem moves > from me to you on the first email message. 1. Alice sends Bob a signed mesage: - Bob can use the "SMIMEA 2 1 1" record of Alice's domain to verify the signature on Alice's message. Bob caches Alice's public key (certificate). - Bob can now use Alice's public key to encrypt replies. 2. Bob sends a signed (optionally encrypted) reply to Alice. - Alice can use the "SMIMEA 2 1 1" record of Bob's domain to verify the signature on Bob's message. Alice caches Bob's public key (certificate). - Alice can now use Bob's public key to encrypt replies. Lack of support for encryption on first contact can be seen as a feature, not a bug. --=20 Viktor. From nobody Wed Apr 12 09:49:02 2017 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 881A112EAAC for ; Wed, 12 Apr 2017 09:48:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 HEjKMpEQ5fxp for ; Wed, 12 Apr 2017 09:48:57 -0700 (PDT) Received: from mail-vk0-x22a.google.com (mail-vk0-x22a.google.com [IPv6:2607:f8b0:400c:c05::22a]) (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 34EE71314E3 for ; Wed, 12 Apr 2017 09:48:57 -0700 (PDT) Received: by mail-vk0-x22a.google.com with SMTP id j127so10204725vkh.0 for ; Wed, 12 Apr 2017 09:48:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=9QO/NlYLrrMjhdPS8vxWmnVsAawexflZTRzkpp53lb8=; b=fR2AUP0Cztdws1+jucFOw1JZvFm7Pyz9iE1hEhuzo9vlxaMYHfmYwf9A9TV3i4fnUx 0/XuZwghfxXBwaZdllfeRB+nor5HRPS/ChVGf4qn5IgZ7LJC7TiGOWAum18vQU0mKE0i g1fHrzv1w+9ActsYwFR/3EAP4BB7HN0+nSGGbqVptzribHU+tT6m/4Wht74/sX73vjmm NxZLl/HeoFia3qFtsnt7N6Ou7ZixevjMJnxOtON8Fmavl++bww2fbIe+mG+B2hdzoHpe aXy4hjOWZrwEYlMobgohXUpeQLxXZcees2g/u59PN6vfy4P3xamElcBc5prBfwMZM5qU A09Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=9QO/NlYLrrMjhdPS8vxWmnVsAawexflZTRzkpp53lb8=; b=uYci/kMkftOR63N2rxTAwWSHinbB2uW7XaTaxM78kj7HSn5GUsD+TQepsIPMJIqUyP bNolE8lkoQxSFHO/GEpqk83P2dGFPGfIu6N4yB8gy97G3OS48Y+RoVzdSYOMFs70wLKM rFLEoCNhOOvTDACQ7P32iBr5rgwRpklH+djAmsd6s4lRuOIuPF++7OZfKTQ7uaf/PEcO Lx3Ay99QpBzksT7PBlz/LT8Yb2uyH7PLzKOD+1bXiibXmv44h+anuV0xh4UYTFANdLIF 3brqkTxhihQzQKAxb/e60P8VaNKbqxMirnobl4jlftyddPRgNOaY3NdFuu/zYQvK7mW9 977Q== X-Gm-Message-State: AN3rC/7M2QUJ0D+fJxan1iohWk+3kwiK/MgKnJwoeGeL6RqULcvTBSXsIfgJ7+vovJ9D5QmbeL2cbxRUduIrkUKk X-Received: by 10.31.222.132 with SMTP id v126mr1421648vkg.128.1492015736027; Wed, 12 Apr 2017 09:48:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.0.22 with HTTP; Wed, 12 Apr 2017 09:48:55 -0700 (PDT) In-Reply-To: References: <455EC3FC-9140-40D3-88F8-77990B7C7DD0@vpnc.org> <1DA6DC8F-CA06-4453-96E6-D8D257555437@dukhovni.org> <9FC39E28-4285-40F8-8FE9-283FA83B1A0A@dukhovni.org> From: Wei Chuang Date: Wed, 12 Apr 2017 09:48:55 -0700 Message-ID: To: Viktor Dukhovni Cc: trans@ietf.org, IETF DANE Mailinglist Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="94eb2c07b1dcf825c7054cfafbb2" Archived-At: Subject: Re: [dane] [Trans] CT for DNSSEC X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.22 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, 12 Apr 2017 16:48:59 -0000 --94eb2c07b1dcf825c7054cfafbb2 Content-Type: multipart/alternative; boundary=94eb2c07b1dcf26945054cfafb85 --94eb2c07b1dcf26945054cfafb85 Content-Type: text/plain; charset=UTF-8 On Wed, Mar 29, 2017 at 8:11 AM, Viktor Dukhovni wrote: > > > On Mar 29, 2017, at 10:33 AM, Wei Chuang wrote: > > > > Why not create an explicit Non-existence of DS (NDS) RR that gets logged > along with DS and NS? > > This is not needed, the NSEC/NSEC3 RRs already serve that role. > > For NSEC records (RFC4034), an unsigned delegation looks like: > > example.com. IN NS ns1.example.com. > example.com. IN NSEC examplf.com NS > example.com. IN RRSIG NSEC ... > > this proves that NS (or other depending on the content of the type > bitmap of the NSEC record) records exist for example.com, but DS > records do not. > > With NSEC3 (rfc5155), and the "opt-out" bit the situation can be > more complex because the answer may not establish the existence of > example.com. Instead we may get an existence proof for the closest > encloser (ancestor domain) and proof that "example.com" is not signed, > but no proof of its existence. This means that to avoid spam, a log > might want to independently verify the existence of the insecure > delegation by repeating the query, so as to avoid storing data for > non-existent domains with the insecure NXDOMAIN modified to NOERROR > with made up NS records. > > Sorry this reply is coming late. Your response helped a lot (thanks!) but I had nagging concern that couldn't make concrete till now. When a DOE lookup occurs on DNSSEC, the authoritative nameserver services the request and determines to respond with what you describe above (the NSEC and its RRSIG). The complication occurs with CT. While we may log the NSEC or NSEC3 record and these records will be present for lookups in CT of existing records, there isn't an online server to assist with lookups in CT of non-existing records. I suppose it may be possible to replicate the state of the authoritative nameserver but consider that this likely doesn't scale as CT servers are servicing a scope potentially much larger than the authoritative nameservers. The approach I describe earlier with an explict Non-existence of DS (NDS) should allow for direct lookup of NDS entry. Also agreed with later comments suggesting that the entire key signing chain needs to be CT logged with its proofs and non-existance records for this to work. -Wei > -- > Viktor. > > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane > --94eb2c07b1dcf26945054cfafb85 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Mar 29, 2017 at 8:11 AM, Viktor Dukhovni <= ietf-dane@dukho= vni.org> wrote:

> On Mar 29, 2017, at 10:33 AM, Wei Chuang <weihaw@google.com> wrote:
>
> Why not create an explicit Non-existence of DS (NDS) RR that gets logg= ed along with DS and NS?

This is not needed, the NSEC/NSEC3 RRs already serve that role.

For NSEC records (RFC4034), an unsigned delegation looks like:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 example.com. IN NS ns1.example.com.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 example.com. IN NSEC examplf.com NS
=C2=A0 =C2=A0 =C2=A0 =C2=A0 example.com. IN RRSIG NSEC ...

this proves that NS (or other depending on the content of the type
bitmap of the NSEC record) records exist for example.com, but DS
records do not.

With NSEC3 (rfc5155), and the "opt-out" bit the situation can be<= br> more complex because the answer may not establish the existence of
example= .com.=C2=A0 Instead we may get an existence proof for the closest
encloser (ancestor domain) and proof that "example.com" is not signe= d,
but no proof of its existence.=C2=A0 This means that to avoid spam, a log might want to independently verify the existence of the insecure
delegation by repeating the query, so as to avoid storing data for
non-existent domains with the insecure NXDOMAIN modified to NOERROR
with made up NS records.


Sorry this reply is coming late.=C2=A0 Your re= sponse helped a lot (thanks!) but I had nagging concern that couldn't m= ake concrete till now.

When a DOE lookup occurs on= DNSSEC, the authoritative nameserver services the request and determines t= o respond with what you describe above (the NSEC and its RRSIG).=C2=A0 The = complication occurs with CT.=C2=A0 While we may log the NSEC or NSEC3 recor= d and these records will be present for lookups in CT of existing records, = there isn't an online server to assist with lookups in CT of non-existi= ng records.=C2=A0 I suppose it may be possible to replicate the state of th= e authoritative nameserver but consider that this likely doesn't scale = as CT servers are servicing a scope potentially much larger than the author= itative nameservers.=C2=A0 The approach I describe earlier with an explict= =C2=A0Non-existence of DS (NDS) should all= ow for direct lookup of NDS entry.=C2=A0

Also= agreed with later comments suggesting that the entire key signing chain ne= eds to be CT logged with its proofs and non-existance records for this to w= ork.

-Wei
=C2=A0
--
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Viktor.

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

--94eb2c07b1dcf26945054cfafb85-- --94eb2c07b1dcf825c7054cfafbb2 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIS5wYJKoZIhvcNAQcCoIIS2DCCEtQCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ghBNMIIEXDCCA0SgAwIBAgIOSBtqDm4P/739RPqw/wcwDQYJKoZIhvcNAQELBQAwZDELMAkGA1UE BhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVy c29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hBMjU2IC0gRzIwHhcNMTYwNjE1MDAwMDAwWhcNMjEw NjE1MDAwMDAwWjBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEiMCAG A1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBALR23lKtjlZW/17kthzYcMHHKFgywfc4vLIjfq42NmMWbXkNUabIgS8KX4PnIFsTlD6F GO2fqnsTygvYPFBSMX4OCFtJXoikP2CQlEvO7WooyE94tqmqD+w0YtyP2IB5j4KvOIeNv1Gbnnes BIUWLFxs1ERvYDhmk+OrvW7Vd8ZfpRJj71Rb+QQsUpkyTySaqALXnyztTDp1L5d1bABJN/bJbEU3 Hf5FLrANmognIu+Npty6GrA6p3yKELzTsilOFmYNWg7L838NS2JbFOndl+ce89gM36CW7vyhszi6 6LqqzJL8MsmkP53GGhf11YMP9EkmawYouMDP/PwQYhIiUO0CAwEAAaOCASIwggEeMA4GA1UdDwEB /wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIB ADAdBgNVHQ4EFgQUyzgSsMeZwHiSjLMhleb0JmLA4D8wHwYDVR0jBBgwFoAUJiSSix/TRK+xsBtt r+500ox4AAMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9ncy9n c3BlcnNvbmFsc2lnbnB0bnJzc2hhMmcyLmNybDBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG 9w0BAQsFAAOCAQEACskdySGYIOi63wgeTmljjA5BHHN9uLuAMHotXgbYeGVrz7+DkFNgWRQ/dNse Qa4e+FeHWq2fu73SamhAQyLigNKZF7ZzHPUkSpSTjQqVzbyDaFHtRBAwuACuymaOWOWPePZXOH9x t4HPwRQuur57RKiEm1F6/YJVQ5UTkzAyPoeND/y1GzXS4kjhVuoOQX3GfXDZdwoN8jMYBZTO0H5h isymlIl6aot0E5KIKqosW6mhupdkS1ZZPp4WXR4frybSkLejjmkTYCTUmh9DuvKEQ1Ge7siwsWgA NS1Ln+uvIuObpbNaeAyMZY0U5R/OyIDaq+m9KXPYvrCZ0TCLbcKuRzCCBB4wggMGoAMCAQICCwQA AAAAATGJxkCyMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAt IFIzMRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTExMDgwMjEw MDAwMFoXDTI5MDMyOTEwMDAwMFowZDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVyc29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hB MjU2IC0gRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCg/hRKosYAGP+P7mIdq5NB Kr3J0tg+8lPATlgp+F6W9CeIvnXRGUvdniO+BQnKxnX6RsC3AnE0hUUKRaM9/RDDWldYw35K+sge C8fWXvIbcYLXxWkXz+Hbxh0GXG61Evqux6i2sKeKvMr4s9BaN09cqJ/wF6KuP9jSyWcyY+IgL6u2 52my5UzYhnbf7D7IcC372bfhwM92n6r5hJx3r++rQEMHXlp/G9J3fftgsD1bzS7J/uHMFpr4MXua eoiMLV5gdmo0sQg23j4pihyFlAkkHHn4usPJ3EePw7ewQT6BUTFyvmEB+KDoi7T4RCAZDstgfpzD rR/TNwrK8/FXoqnFAgMBAAGjgegwgeUwDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8C AQEwHQYDVR0OBBYEFCYkkosf00SvsbAbba/udNKMeAADMEcGA1UdIARAMD4wPAYEVR0gADA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzA2BgNVHR8E LzAtMCugKaAnhiVodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L3Jvb3QtcjMuY3JsMB8GA1UdIwQY MBaAFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQACAFVjHihZCV/IqJYt 7Nig/xek+9g0dmv1oQNGYI1WWeqHcMAV1h7cheKNr4EOANNvJWtAkoQz+076Sqnq0Puxwymj0/+e oQJ8GRODG9pxlSn3kysh7f+kotX7pYX5moUa0xq3TCjjYsF3G17E27qvn8SJwDsgEImnhXVT5vb7 qBYKadFizPzKPmwsJQDPKX58XmPxMcZ1tG77xCQEXrtABhYC3NBhu8+c5UoinLpBQC1iBnNpNwXT Lmd4nQdf9HCijG1e8myt78VP+QSwsaDT7LVcLT2oDPVggjhVcwljw3ePDwfGP9kNrR+lc8XrfClk WbrdhC2o4Ui28dtIVHd3MIIDXzCCAkegAwIBAgILBAAAAAABIVhTCKIwDQYJKoZIhvcNAQELBQAw TDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24x EzARBgNVBAMTCkdsb2JhbFNpZ24wHhcNMDkwMzE4MTAwMDAwWhcNMjkwMzE4MTAwMDAwWjBMMSAw HgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEG A1UEAxMKR2xvYmFsU2lnbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMwldpB5Bngi FvXAg7aEyiie/QV2EcWtiHL8RgJDx7KKnQRfJMsuS+FggkbhUqsMgUdwbN1k0ev1LKMPgj0MK66X 17YUhhB5uzsTgHeMCOFJ0mpiLx9e+pZo34knlTifBtc+ycsmWQ1z3rDI6SYOgxXG71uL0gRgykmm KPZpO/bLyCiR5Z2KYVc3rHQU3HTgOu5yLy6c+9C7v/U9AOEGM+iCK65TpjoWc4zdQQ4gOsC0p6Hp sk+QLjJg6VfLuQSSaGjlOCZgdbKfd/+RFO+uIEn8rUAVSNECMWEZXriX7613t2Saer9fwRPvm2L7 DWzgVGkWqQPabumDk3F2xmmFghcCAwEAAaNCMEAwDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQF MAMBAf8wHQYDVR0OBBYEFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQBL QNvAUKr+yAzv95ZURUm7lgAJQayzE4aGKAczymvmdLm6AC2upArT9fHxD4q/c2dKg8dEe3jgr25s bwMpjjM5RcOO5LlXbKr8EpbsU8Yt5CRsuZRj+9xTaGdWPoO4zzUhw8lo/s7awlOqzJCK6fBdRoyV 3XpYKBovHd7NADdBj+1EbddTKJd+82cEHhXXipa0095MJ6RMG3NzdvQXmcIfeg7jLQitChws/zyr VQ4PkX4268NXSb7hLi18YIvDQVETI53O9zJrlAGomecsMx86OyXShkDOOyyGeMlhLxS67ttVb9+E 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEZDCCA0ygAwIBAgIMAQEwAHyjxWs8sJNjMA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE3MDMyNTE4NDI0N1oXDTE3MDky MTE4NDI0N1owIjEgMB4GCSqGSIb3DQEJAQwRd2VpaGF3QGdvb2dsZS5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDf/V6s9+sy7fHvy6Z2bKp63d5w85JpcZW9SebsKdycSAUATqgb Gvo6SYD4qMWY3mR+O3LHmJ6WoHqr9xEd7uZ5JxxpfjGhe3MqgS5JaXuKn34q4li1EdMk8F7MB0FD 6VFzmd2OYPpKF8f3d8oyqQUHPnZvoOqCVlO4+fHapq+Rz9++cSI1UbK7KX/kOsi1q+tNEVGP1oVC Cmy/1WK7EEGMOLo2K48AS9T3IP15I1hn/Sj4vVJrpW0rzvRpahOxWKo7SqLcwSRvDvKNue5di7iQ eVceAPcahROEy4P20dimQXpxTVyjQG8wz75b4hwykEgPruaXn1J1usP830/0Tet5AgMBAAGjggFu MIIBajAcBgNVHREEFTATgRF3ZWloYXdAZ29vZ2xlLmNvbTBQBggrBgEFBQcBAQREMEIwQAYIKwYB BQUHMAKGNGh0dHA6Ly9zZWN1cmUuZ2xvYmFsc2lnbi5jb20vY2FjZXJ0L2dzaHZzbWltZWNhMS5j cnQwHQYDVR0OBBYEFF4Fc4YKhOL19j17oEbz6tlaKO/DMB8GA1UdIwQYMBaAFMs4ErDHmcB4koyz IZXm9CZiwOA/MEwGA1UdIARFMEMwQQYJKwYBBAGgMgEoMDQwMgYIKwYBBQUHAgEWJmh0dHBzOi8v d3d3Lmdsb2JhbHNpZ24uY29tL3JlcG9zaXRvcnkvMDsGA1UdHwQ0MDIwMKAuoCyGKmh0dHA6Ly9j cmwuZ2xvYmFsc2lnbi5jb20vZ3NodnNtaW1lY2ExLmNybDAOBgNVHQ8BAf8EBAMCBaAwHQYDVR0l BBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4IBAQCPihhAVF7RDXtgpruF 0d7ukFX3Ki/I7JD6lTgEGdekylp4bPtLcnIZKM5+JhwalsTbInvGVI6e3VlIyVIOonCf+lIxwC0A enfp52lsFIy12dunCtSJckTlT9LYuxSK5sA4krofdq0ZtSxJ3y8CYHzzolTGaEPqf2BhIpboO4QI zEaRD8w652Rjfo/zP+yI+qYXzACs8erQN0B+8+hT/7Ir8NQcOztDBlNey/ynwE+p1/85y8IHPR8Y Ssm0jF6cpyP/WDat2BbKzT0O1XuZF24UCNxasGcYjYuz3a2+JwQEfSFyFVu/lslEsd8Ehcd9siGL t+pE4LJq0i8cDdnBhWcIMYICXjCCAloCAQEwXDBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xv YmFsU2lnbiBudi1zYTEiMCAGA1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMQIMAQEwAHyj xWs8sJNjMA0GCWCGSAFlAwQCAQUAoIHUMC8GCSqGSIb3DQEJBDEiBCC2PFhZAwdUCfUiLMrsQOCn XkC1dY8eJXROh3CGsB0bmDAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xNzA0MTIxNjQ4NTZaMGkGCSqGSIb3DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQB FjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEBBzALBglg hkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAEggEArizjkGPGaoSSjcriTPQgeq+VZI4Kcrac21iws+L7 ZD8nJb1V6voECRxUnxWUzZMLAl/ZhDedoKRA2Jbya7HYDO4y0JfEeS6eYxudYrR2iYfVa/Ld95H2 2zSS2vtM7poH2ypLirQZv22A8Ukc1pHPMmlWJLOjNQYtDkGVRuPGDnuYwIvuHfnZsD+z1Lqxne2z qMh6xft9UbItsWBBLfHWs2Rkyr4ys9F8w7GeTQuTpEmE4EN2w4MgrCEg4X1xy7tI+ucO067EVnsg 3bh1Sj7SsXm0fOqXCFDlve7q8DF6QFYBpi3GYdLgETuHbBqB35J5EVQpv8/wd+XKcHxyqxAkXQ== --94eb2c07b1dcf825c7054cfafbb2-- From nobody Wed Apr 12 11:50:42 2017 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 C1D9E127A91 for ; Wed, 12 Apr 2017 11:50:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 FIfPDQ5u0QIi for ; Wed, 12 Apr 2017 11:50:38 -0700 (PDT) Received: from mail-vk0-x22d.google.com (mail-vk0-x22d.google.com [IPv6:2607:f8b0:400c:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA2C412EB39 for ; Wed, 12 Apr 2017 11:50:37 -0700 (PDT) Received: by mail-vk0-x22d.google.com with SMTP id j127so11893013vkh.0 for ; Wed, 12 Apr 2017 11:50:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=VTzqVloyRzsgQk77UCW8E1H8R3GWrBQrMSRLuKSM4dg=; b=t6BWB8o5QGRShDnOCsJ7uGfpInv8NvsIjttXZL7Tk3n+aIbm/Ptlp7cmmekLZEXCFa EHSg5bN6hqtuyzzDmziayzUzlWeMSrnz3suEWtt5yyMJlBcSi3koKfIQSoKS6qb7ibvJ QYGWyTqHxcfhtyEveZuzhFOiWRGU/fAUePvwmuR9ROSt3Hrn8B45qjIFGBcZM+ZOcYPz lpMkvskMjm3woEA65W+JvJYYm4mrEcogfn13GjxguK+mQMIerd+13fEuwqYCkCdvClFm TBfXk5L0D1EAmD8ABFVMFoWCS101rZCbeP7pyT729n6492cflN6Gy+UFgjVG6TI6soHK aHxg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=VTzqVloyRzsgQk77UCW8E1H8R3GWrBQrMSRLuKSM4dg=; b=eNVVTo0pKYZeEaWF8znv7tP2E6d4A/s2ykRbuCb0v7EMb9BC+QWGqVC11WgN7NU844 hav5sLRPKtF549MGIiVAmRnp3RrzbcgiojdejvTidj5bub+gAirsG5IPwMmK/DnCF1wf quODXajfmPKpXHy6gWqP2r2tRVXXVudMMSUjcP3f+homoXqgsY6qzfUQDZ42U51+EKYJ pKuuO/1hxQ4T4mI78SVWZZ5Vj3Bp08NiWKA1qUEMx9CdTJIepMpNVkdulHyroCsWvs7l XJDLafXV6fVT1fbbYB0Ro7YJ3+DUJk3kRjPxn+h4c6jWdDBn2TlI8/NRMYhML8ONmFQ0 5DfQ== X-Gm-Message-State: AN3rC/6l1vKU8d0p5SrBADJLxRgj+TXwK45N9OLCq48Ixo+ii0xRVII1K9q00uoUATZbD/OOx7OFzsCI5vd+Ylgj X-Received: by 10.31.129.85 with SMTP id c82mr810133vkd.163.1492023036636; Wed, 12 Apr 2017 11:50:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.0.22 with HTTP; Wed, 12 Apr 2017 11:50:36 -0700 (PDT) From: Wei Chuang Date: Wed, 12 Apr 2017 11:50:36 -0700 Message-ID: To: IETF DANE Mailinglist Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="001a11459a401e7f81054cfcaf72" Archived-At: Subject: [dane] domain hijacking X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.22 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, 12 Apr 2017 18:50:40 -0000 --001a11459a401e7f81054cfcaf72 Content-Type: multipart/alternative; boundary=001a11459a4018dcba054cfcaf9e --001a11459a4018dcba054cfcaf9e Content-Type: text/plain; charset=UTF-8 Hi dane folks, There recently was an article in Wired about how a banking site was domain hijacked: https://www.wired.com/2017/04/hackers-hijacked-banks-entire-online-operation/ via a DNS registry account hijacking. I was wondering if DNSSEC can protect against such hijackings (and thereby protect DANE records). My suspicion is no, DNSSEC can't protect against an attack at the registry level since a hijacker could publish a new set of consistent records for the zone including at the parent. If my suspicion is correct, has there been thought of re-signing the DS record signed with the older private key in a way that proves ownership through the key change? This gets published at the parent so its visible even if the entire zone gets spoofed. This, put another way, would prove publicly continuity of ownership for the domain. thanks, -Wei --001a11459a4018dcba054cfcaf9e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi dane folks,

There recently was an ar= ticle in Wired about how a banking site was domain hijacked:
via a DNS registry account hijacking.=C2=A0= I was wondering if DNSSEC can protect against such hijackings (and thereby= protect DANE records).=C2=A0 My suspicion is no, DNSSEC can't protect = against an attack at the registry level since a hijacker could publish a ne= w set of consistent records for the zone including at the parent.=C2=A0 If = my suspicion is correct, has there been thought of re-signing the DS record= signed with the older private key in a way that proves ownership through t= he key change?=C2=A0 This gets published at the parent so its visible even = if the entire zone gets spoofed.=C2=A0 This, put another way, would prove p= ublicly continuity of ownership for the domain. =C2=A0

=
thanks,
-Wei=C2=A0
--001a11459a4018dcba054cfcaf9e-- --001a11459a401e7f81054cfcaf72 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIS5wYJKoZIhvcNAQcCoIIS2DCCEtQCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ghBNMIIEXDCCA0SgAwIBAgIOSBtqDm4P/739RPqw/wcwDQYJKoZIhvcNAQELBQAwZDELMAkGA1UE BhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVy c29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hBMjU2IC0gRzIwHhcNMTYwNjE1MDAwMDAwWhcNMjEw NjE1MDAwMDAwWjBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEiMCAG A1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBALR23lKtjlZW/17kthzYcMHHKFgywfc4vLIjfq42NmMWbXkNUabIgS8KX4PnIFsTlD6F GO2fqnsTygvYPFBSMX4OCFtJXoikP2CQlEvO7WooyE94tqmqD+w0YtyP2IB5j4KvOIeNv1Gbnnes BIUWLFxs1ERvYDhmk+OrvW7Vd8ZfpRJj71Rb+QQsUpkyTySaqALXnyztTDp1L5d1bABJN/bJbEU3 Hf5FLrANmognIu+Npty6GrA6p3yKELzTsilOFmYNWg7L838NS2JbFOndl+ce89gM36CW7vyhszi6 6LqqzJL8MsmkP53GGhf11YMP9EkmawYouMDP/PwQYhIiUO0CAwEAAaOCASIwggEeMA4GA1UdDwEB /wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIB ADAdBgNVHQ4EFgQUyzgSsMeZwHiSjLMhleb0JmLA4D8wHwYDVR0jBBgwFoAUJiSSix/TRK+xsBtt r+500ox4AAMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9ncy9n c3BlcnNvbmFsc2lnbnB0bnJzc2hhMmcyLmNybDBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG 9w0BAQsFAAOCAQEACskdySGYIOi63wgeTmljjA5BHHN9uLuAMHotXgbYeGVrz7+DkFNgWRQ/dNse Qa4e+FeHWq2fu73SamhAQyLigNKZF7ZzHPUkSpSTjQqVzbyDaFHtRBAwuACuymaOWOWPePZXOH9x t4HPwRQuur57RKiEm1F6/YJVQ5UTkzAyPoeND/y1GzXS4kjhVuoOQX3GfXDZdwoN8jMYBZTO0H5h isymlIl6aot0E5KIKqosW6mhupdkS1ZZPp4WXR4frybSkLejjmkTYCTUmh9DuvKEQ1Ge7siwsWgA NS1Ln+uvIuObpbNaeAyMZY0U5R/OyIDaq+m9KXPYvrCZ0TCLbcKuRzCCBB4wggMGoAMCAQICCwQA AAAAATGJxkCyMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAt IFIzMRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTExMDgwMjEw MDAwMFoXDTI5MDMyOTEwMDAwMFowZDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVyc29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hB MjU2IC0gRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCg/hRKosYAGP+P7mIdq5NB Kr3J0tg+8lPATlgp+F6W9CeIvnXRGUvdniO+BQnKxnX6RsC3AnE0hUUKRaM9/RDDWldYw35K+sge C8fWXvIbcYLXxWkXz+Hbxh0GXG61Evqux6i2sKeKvMr4s9BaN09cqJ/wF6KuP9jSyWcyY+IgL6u2 52my5UzYhnbf7D7IcC372bfhwM92n6r5hJx3r++rQEMHXlp/G9J3fftgsD1bzS7J/uHMFpr4MXua eoiMLV5gdmo0sQg23j4pihyFlAkkHHn4usPJ3EePw7ewQT6BUTFyvmEB+KDoi7T4RCAZDstgfpzD rR/TNwrK8/FXoqnFAgMBAAGjgegwgeUwDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8C AQEwHQYDVR0OBBYEFCYkkosf00SvsbAbba/udNKMeAADMEcGA1UdIARAMD4wPAYEVR0gADA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzA2BgNVHR8E LzAtMCugKaAnhiVodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L3Jvb3QtcjMuY3JsMB8GA1UdIwQY MBaAFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQACAFVjHihZCV/IqJYt 7Nig/xek+9g0dmv1oQNGYI1WWeqHcMAV1h7cheKNr4EOANNvJWtAkoQz+076Sqnq0Puxwymj0/+e oQJ8GRODG9pxlSn3kysh7f+kotX7pYX5moUa0xq3TCjjYsF3G17E27qvn8SJwDsgEImnhXVT5vb7 qBYKadFizPzKPmwsJQDPKX58XmPxMcZ1tG77xCQEXrtABhYC3NBhu8+c5UoinLpBQC1iBnNpNwXT Lmd4nQdf9HCijG1e8myt78VP+QSwsaDT7LVcLT2oDPVggjhVcwljw3ePDwfGP9kNrR+lc8XrfClk WbrdhC2o4Ui28dtIVHd3MIIDXzCCAkegAwIBAgILBAAAAAABIVhTCKIwDQYJKoZIhvcNAQELBQAw TDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24x EzARBgNVBAMTCkdsb2JhbFNpZ24wHhcNMDkwMzE4MTAwMDAwWhcNMjkwMzE4MTAwMDAwWjBMMSAw HgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEG A1UEAxMKR2xvYmFsU2lnbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMwldpB5Bngi FvXAg7aEyiie/QV2EcWtiHL8RgJDx7KKnQRfJMsuS+FggkbhUqsMgUdwbN1k0ev1LKMPgj0MK66X 17YUhhB5uzsTgHeMCOFJ0mpiLx9e+pZo34knlTifBtc+ycsmWQ1z3rDI6SYOgxXG71uL0gRgykmm KPZpO/bLyCiR5Z2KYVc3rHQU3HTgOu5yLy6c+9C7v/U9AOEGM+iCK65TpjoWc4zdQQ4gOsC0p6Hp sk+QLjJg6VfLuQSSaGjlOCZgdbKfd/+RFO+uIEn8rUAVSNECMWEZXriX7613t2Saer9fwRPvm2L7 DWzgVGkWqQPabumDk3F2xmmFghcCAwEAAaNCMEAwDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQF MAMBAf8wHQYDVR0OBBYEFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQBL QNvAUKr+yAzv95ZURUm7lgAJQayzE4aGKAczymvmdLm6AC2upArT9fHxD4q/c2dKg8dEe3jgr25s bwMpjjM5RcOO5LlXbKr8EpbsU8Yt5CRsuZRj+9xTaGdWPoO4zzUhw8lo/s7awlOqzJCK6fBdRoyV 3XpYKBovHd7NADdBj+1EbddTKJd+82cEHhXXipa0095MJ6RMG3NzdvQXmcIfeg7jLQitChws/zyr VQ4PkX4268NXSb7hLi18YIvDQVETI53O9zJrlAGomecsMx86OyXShkDOOyyGeMlhLxS67ttVb9+E 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEZDCCA0ygAwIBAgIMAQEwAHyjxWs8sJNjMA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE3MDMyNTE4NDI0N1oXDTE3MDky MTE4NDI0N1owIjEgMB4GCSqGSIb3DQEJAQwRd2VpaGF3QGdvb2dsZS5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDf/V6s9+sy7fHvy6Z2bKp63d5w85JpcZW9SebsKdycSAUATqgb Gvo6SYD4qMWY3mR+O3LHmJ6WoHqr9xEd7uZ5JxxpfjGhe3MqgS5JaXuKn34q4li1EdMk8F7MB0FD 6VFzmd2OYPpKF8f3d8oyqQUHPnZvoOqCVlO4+fHapq+Rz9++cSI1UbK7KX/kOsi1q+tNEVGP1oVC Cmy/1WK7EEGMOLo2K48AS9T3IP15I1hn/Sj4vVJrpW0rzvRpahOxWKo7SqLcwSRvDvKNue5di7iQ eVceAPcahROEy4P20dimQXpxTVyjQG8wz75b4hwykEgPruaXn1J1usP830/0Tet5AgMBAAGjggFu MIIBajAcBgNVHREEFTATgRF3ZWloYXdAZ29vZ2xlLmNvbTBQBggrBgEFBQcBAQREMEIwQAYIKwYB BQUHMAKGNGh0dHA6Ly9zZWN1cmUuZ2xvYmFsc2lnbi5jb20vY2FjZXJ0L2dzaHZzbWltZWNhMS5j cnQwHQYDVR0OBBYEFF4Fc4YKhOL19j17oEbz6tlaKO/DMB8GA1UdIwQYMBaAFMs4ErDHmcB4koyz IZXm9CZiwOA/MEwGA1UdIARFMEMwQQYJKwYBBAGgMgEoMDQwMgYIKwYBBQUHAgEWJmh0dHBzOi8v d3d3Lmdsb2JhbHNpZ24uY29tL3JlcG9zaXRvcnkvMDsGA1UdHwQ0MDIwMKAuoCyGKmh0dHA6Ly9j cmwuZ2xvYmFsc2lnbi5jb20vZ3NodnNtaW1lY2ExLmNybDAOBgNVHQ8BAf8EBAMCBaAwHQYDVR0l BBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4IBAQCPihhAVF7RDXtgpruF 0d7ukFX3Ki/I7JD6lTgEGdekylp4bPtLcnIZKM5+JhwalsTbInvGVI6e3VlIyVIOonCf+lIxwC0A enfp52lsFIy12dunCtSJckTlT9LYuxSK5sA4krofdq0ZtSxJ3y8CYHzzolTGaEPqf2BhIpboO4QI zEaRD8w652Rjfo/zP+yI+qYXzACs8erQN0B+8+hT/7Ir8NQcOztDBlNey/ynwE+p1/85y8IHPR8Y Ssm0jF6cpyP/WDat2BbKzT0O1XuZF24UCNxasGcYjYuz3a2+JwQEfSFyFVu/lslEsd8Ehcd9siGL t+pE4LJq0i8cDdnBhWcIMYICXjCCAloCAQEwXDBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xv YmFsU2lnbiBudi1zYTEiMCAGA1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMQIMAQEwAHyj xWs8sJNjMA0GCWCGSAFlAwQCAQUAoIHUMC8GCSqGSIb3DQEJBDEiBCDHnorcSj7C0PJvMju9dXNo Kb0+M6614HSR6kKW3QpT4DAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xNzA0MTIxODUwMzdaMGkGCSqGSIb3DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQB FjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEBBzALBglg hkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAEggEAGh0rQ8OOLUZhFegPMXJer4Q90K0ebAuaVI0BXNou TlhEmZROpIfIrftqPWNuF9IbUqOLpDI8BMxt0XOYYJIFo4vjk/xwDzdC0Q/+NUxrC0BkGJVJQf3n m5L5sxfPeJKh50eIa9TDiz771qY7jradNX/HNza3JZwR80k45sGJMn4r+Sw3ap9kAQkltWfQr375 03mrtjrp3v0nl7LsGCeQtR/aU4vvx6jdPNMXnTAdqmzpLOPAJB0nasskqgXkyklRtBMTDR73bPgs K9oq0iAuxDbh8RcwIu81dhv/PUdJxbDuuewaIjMOCHHB0lHc7LH8gfF8lVHlc3pQaTP2BKvsrw== --001a11459a401e7f81054cfcaf72-- From nobody Wed Apr 12 12:38:37 2017 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 0E160127843 for ; Wed, 12 Apr 2017 12:38:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.602 X-Spam-Level: X-Spam-Status: No, score=-0.602 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=domblogger.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PiOPclmxY70Y for ; Wed, 12 Apr 2017 12:38:34 -0700 (PDT) Received: from mail.domblogger.net (mail.domblogger.net [IPv6:2600:3c00::f03c:91ff:fe56:d6a2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80D291294EC for ; Wed, 12 Apr 2017 12:38:34 -0700 (PDT) Received: from localhost.localdomain (68-189-44-253.dhcp.rdng.ca.charter.com [68.189.44.253]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.domblogger.net (Postfix) with ESMTPSA id CB8A0495 for ; Wed, 12 Apr 2017 19:38:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=domblogger.net; s=default; t=1492025913; bh=l3E0iL4Dk4a2XeBpVafDjjRyeV9+z5A30AoN+i9Emss=; h=Subject:To:References:From:Date:In-Reply-To; b=2wAUIrh+KWmJJjtDP49FRS6LxAocXCOG9qC9mKfHu2TalGgi54AXmFHxsfWlw0T3p WZqKfp2nKsktaIhLkyviax2VXSqxO4MHgb5MARV/GSIga7M3XRIjnQ2jRFDDwkZ6To 3XX+IkOsqn8xj0m62KNCgur0FaBRBaV+DHAZvwI8= To: dane@ietf.org References: From: Alice Wonder Message-ID: <86ef0d97-990a-471a-c9a4-d677ba4da0d0@domblogger.net> Date: Wed, 12 Apr 2017 12:38:32 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dane] domain hijacking X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.22 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, 12 Apr 2017 19:38:36 -0000 On 04/12/2017 11:50 AM, Wei Chuang wrote: > Hi dane folks, > > There recently was an article in Wired about how a banking site was > domain hijacked: > https://www.wired.com/2017/04/hackers-hijacked-banks-entire-online-operation/ > via a DNS registry account hijacking. I was wondering if DNSSEC can > protect against such hijackings (and thereby protect DANE records). My > suspicion is no, DNSSEC can't protect against an attack at the registry > level since a hijacker could publish a new set of consistent records for > the zone including at the parent. If my suspicion is correct, has there > been thought of re-signing the DS record signed with the older private > key in a way that proves ownership through the key change? This gets > published at the parent so its visible even if the entire zone gets > spoofed. This, put another way, would prove publicly continuity of > ownership for the domain. > > thanks, > -Wei I had thought of this sort of scenario as well. You can script to watch your DS records and alert you if they ever are not suppose to be, but I hope there is a future where certificate authorities are replaced by trust anchors independent of the root DNS that can behave as a DS record 2FA. e.g. to create new KSK that DNSSEC would validate, the attacker would not only have to fool the registry into uploading new DS records but also fool the secondary trust anchor that duplicates the DS records. Unfortunately that also opens up DoS attack if an attacker is not able to change the actual DS records but is able to fool the secondary validator of the DS records. That's DNSSEC issue though, not DANE. Even if banks use DANE (and I wish they would) they also should have EV certificates to currently defend against that type thing. From nobody Wed Apr 12 12:53:06 2017 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 6467512778E for ; Wed, 12 Apr 2017 12:53:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.793 X-Spam-Level: X-Spam-Status: No, score=-1.793 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=wemonitoremail.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 RbLr7bL0ka4r for ; Wed, 12 Apr 2017 12:53:03 -0700 (PDT) Received: from mail.wemonitoremail.com (mail.wemonitoremail.com [78.47.26.204]) (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 1987E124B0A for ; Wed, 12 Apr 2017 12:53:02 -0700 (PDT) X-WeMonitorEmail-From: ken@wemonitoremail.com X-WeMonitorEmail-VirusCheck: Clean Received: from auth (localhost [127.0.0.1]) by mail.wemonitoremail.com (8.14.4/8.14.4/inbound) with ESMTP id v3CJqjG1027528 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Wed, 12 Apr 2017 20:52:47 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wemonitoremail.com; s=mail; t=1492026767; bh=OxhyUSK4pIaF2VAE7j/9BvnHiP7Sq0vFCZiaA27F0nY=; h=Subject:From:To:Date; b=jrtKtMKSnU2DHh2TqKL84UmcxCx9aPV/z5sFo+Mc2bbPM9UIzzhz1zPVJspnbzhDy b53QN5IGngG3QdQGlBeFHIsAaOSqtBIpDznuuZz6YtlMNiODxz9HCpYWscVNO0PLR2 nwU1jr+aulFGrauuf3n9QxQuCf5ippMQuSeusRGE= Message-ID: <1492026764.4157.21.camel@wemonitoremail.com> From: "Ken O'Driscoll" To: dane@ietf.org Date: Wed, 12 Apr 2017 20:52:44 +0100 In-Reply-To: References: Organization: We Monitor Email Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.20.5 (3.20.5-1.fc24) Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [dane] domain hijacking X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.22 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, 12 Apr 2017 19:53:04 -0000 On Wed, 2017-04-12 at 11:50 -0700, Wei Chuang wrote: > Hi dane folks, > > There recently was an article in Wired about how a banking site was > domain hijacked: > https://www.wired.com/2017/04/hackers-hijacked-banks-entire-online-operat > ion/ > via a DNS registry account hijacking.  I was wondering if DNSSEC can > protect against such hijackings (and thereby protect DANE records). [...snip...] Hi Wei, My first post to this list! My understanding of that incident is that the attackers compromised the .br registry and from there reassigned the nameservers, thus redirecting traffic to their rogue server. DANE or indeed DNSSEC isn't intended to prevent that type of attack, where the attacker has complete control of the domain name at a registry level, including the ability to change NS records and delete DS records. Essentially, in such cases the attacker follows the same procedure the legitimate registrant would follow to disable DNSSEC while changing nameservers. There are other technologies and strategies available to mitigate the risk of such attacks, but if the registry is compromised then DNSSEC etc. can just be disabled so any scheme involving re-signing DS records can be overcome. Ken. --  Ken O'Driscoll / We Monitor Email t: +353 1 254 9400 | w: www.wemonitoremail.com From nobody Wed Apr 12 13:06:56 2017 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 16EC712955F for ; Wed, 12 Apr 2017 13:06:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.903 X-Spam-Level: X-Spam-Status: No, score=-6.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, 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 FMNkOrEtPfDP for ; Wed, 12 Apr 2017 13:06:52 -0700 (PDT) Received: from clone.registro.br (clone.registro.br [IPv6:2001:12ff:0:2::4]) (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 A4B00126DED for ; Wed, 12 Apr 2017 13:06:52 -0700 (PDT) Received: by clone.registro.br (Postfix, from userid 1000) id 296E93D53D; Wed, 12 Apr 2017 17:06:49 -0300 (BRT) Date: Wed, 12 Apr 2017 17:06:49 -0300 From: Frederico A C Neves To: dane@ietf.org Message-ID: <20170412200649.GF74518@registro.br> References: <1492026764.4157.21.camel@wemonitoremail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1492026764.4157.21.camel@wemonitoremail.com> Archived-At: Subject: Re: [dane] domain hijacking X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.22 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, 12 Apr 2017 20:06:54 -0000 Ken, On Wed, Apr 12, 2017 at 08:52:44PM +0100, Ken O'Driscoll wrote: > On Wed, 2017-04-12 at 11:50 -0700, Wei Chuang wrote: > > Hi dane folks, > > > > There recently was an article in Wired about how a banking site was > > domain hijacked: > > https://www.wired.com/2017/04/hackers-hijacked-banks-entire-online-operat > > ion/ > > via a DNS registry account hijacking.  I was wondering if DNSSEC can > > protect against such hijackings (and thereby protect DANE records). > [...snip...] > > Hi Wei, > > My first post to this list! > > My understanding of that incident is that the attackers compromised the .br registry and from there reassigned the nameservers, thus redirecting traffic to their rogue server. > No, please read the article and the corrections we've provided. The domain contact account had their listed email account compromised, a free email provider. With email access and no 2FA configured for this account on our system the attacker did a password reset. With access to the system did a regular delegation change. > DANE or indeed DNSSEC isn't intended to prevent that type of attack, where the attacker has complete control of the domain name at a registry level, including the ability to change NS records and delete DS records. Essentially, in such cases the attacker follows the same procedure the legitimate registrant would follow to disable DNSSEC while changing nameservers. > Correct. If they had a DS the redelegation, done correctly, would be only a little bit harder but totally doable. Fred From nobody Wed Apr 12 13:26:04 2017 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 9C971129BD7 for ; Wed, 12 Apr 2017 13:26:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.106 X-Spam-Level: X-Spam-Status: No, score=0.106 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=wemonitoremail.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 8V7izVxXOYtE for ; Wed, 12 Apr 2017 13:26:02 -0700 (PDT) Received: from mail.wemonitoremail.com (mail.wemonitoremail.com [78.47.26.204]) (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 9E793129B50 for ; Wed, 12 Apr 2017 13:26:02 -0700 (PDT) X-WeMonitorEmail-From: ken@wemonitoremail.com X-WeMonitorEmail-VirusCheck: Clean Received: from auth (localhost [127.0.0.1]) by mail.wemonitoremail.com (8.14.4/8.14.4/inbound) with ESMTP id v3CKPSxH028078 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Wed, 12 Apr 2017 21:25:30 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wemonitoremail.com; s=mail; t=1492028731; bh=3X50Y3Y0NOuEyE+GkMuM0tGYLAsBhi2szIXQGOsREXc=; h=Subject:From:To:Date; b=YhbNVnv5eeaBykFMI9JJ1NG2fT9HxjyRsR04mTZdLZsuRG8kgwYY5ffrctazLjAgh 7M+R5ToolLTmADl/NoRg/0nRthpzXpkNb200j721/+fpPl0h382iVIQOAYJdfVdFpS QRaPQCsoRGxleyVAdIBZN+VUNZBw6IFmYUm3T87I= Message-ID: <1492028727.4157.25.camel@wemonitoremail.com> From: "Ken O'Driscoll" To: dane@ietf.org Date: Wed, 12 Apr 2017 21:25:27 +0100 In-Reply-To: <20170412200649.GF74518@registro.br> References: <1492026764.4157.21.camel@wemonitoremail.com> <20170412200649.GF74518@registro.br> Organization: We Monitor Email Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.20.5 (3.20.5-1.fc24) Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dane] domain hijacking X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.22 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, 12 Apr 2017 20:26:04 -0000 On Wed, 2017-04-12 at 17:06 -0300, Frederico A C Neves wrote: > No, please read the article and the corrections we've provided. The > domain contact account had their listed email account compromised, a > free email provider. With email access and no 2FA configured for this > account on our system the attacker did a password reset. With access > to the system did a regular delegation change. Apologies Frederico, didn't realise that the story had been updated. Ken. From nobody Wed Apr 12 20:12:07 2017 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 EC9AC128DF3 for ; Wed, 12 Apr 2017 20:11:51 -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, 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 gGopE0Wwx9fA for ; Wed, 12 Apr 2017 20:11:47 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 63A53126BF6 for ; Wed, 12 Apr 2017 20:11:47 -0700 (PDT) Received: (qmail 60597 invoked from network); 13 Apr 2017 03:11:46 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 13 Apr 2017 03:11:46 -0000 Date: 13 Apr 2017 03:11:24 -0000 Message-ID: <20170413031124.79969.qmail@ary.lan> From: "John Levine" To: dane@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dane] domain hijacking X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.22 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, 13 Apr 2017 03:11:52 -0000 > If my suspicion is correct, has there >been thought of re-signing the DS record signed with the older private key >in a way that proves ownership through the key change? This sounds to me like shutting the barn door after the horse is gone. If it's important to you that your domain isn't hijacked, we all know what to do, pick a registrar with good security and 2FA and so forth, and monitor your own DNS with alarms if there are unauthorized changes. Also, if we were to invent some sort of change signing, now you have the other problem where the guy with the private key quits and takes it with him, and you have to rebootstrap the zone somehow. R's, John From nobody Wed Apr 12 20:59:10 2017 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 8CDEB126C3D for ; Wed, 12 Apr 2017 20:59:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 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.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1248-bit key) header.d=spodhuis.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2nS6WNpDvTiW for ; Wed, 12 Apr 2017 20:59:07 -0700 (PDT) Received: from mx.spodhuis.org (smtp.spodhuis.org [IPv6:2a02:898:31:0:48:4558:736d:7470]) (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 288E3124D37 for ; Wed, 12 Apr 2017 20:59:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=spodhuis.org; s=d201702; h=In-Reply-To:Content-Type:MIME-Version:References :Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To:Content-Transfer-Encoding :Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=HvUHINjvvhanOIfosgNvhI15Yx1Yio9SGeWQOyU9TMo=; b=oQ4QjDFiKR9C5s9jxD33qHm1MS cd/sYu+hv/VkgrrESFT7q2ljbSCPSujLJFEJRjnF0x6CB1EapVA6o1RK5uTxCjdM8S6j3oQD+Z+vd yV18BXuaNZUyiY5+ztxzMom225L4AjH/0hTTuQvieW/AhTjpaShJNvy/2/oRh2Csr1DRJV+MwBiAl puZtuD7LCjRMd4qQ1RjlLWdcRn49; Received: from authenticated user by smtp.spodhuis.org with esmtpa id 1cyVuS-0006qR-4S; Thu, 13 Apr 2017 03:59:04 +0000 Date: Thu, 13 Apr 2017 03:59:03 +0000 From: Phil Pennock To: IETF DANE Mailinglist Message-ID: <20170413035903.GA9079@tower.spodhuis.org> Mail-Followup-To: IETF DANE Mailinglist , ietf-dane@dukhovni.org References: <4BE233BA-D524-4D05-87C5-E898DD646E7C@dukhovni.org> <7AF2817A-1564-44C5-A049-4F210737760F@dukhovni.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7AF2817A-1564-44C5-A049-4F210737760F@dukhovni.org> OpenPGP: url=https://www.security.spodhuis.org/PGP/keys/0x4D1E900E14C1CC04.asc Archived-At: Subject: Re: [dane] Improving DANE S/MIME Privacy X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.22 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, 13 Apr 2017 03:59:08 -0000 On 2017-04-11 at 14:39 -0400, Viktor Dukhovni wrote: > > On Apr 11, 2017, at 1:38 PM, Viktor Dukhovni wrote: > > > > If the design were up to me, I'd not have published per-user keys. > > Instead a site-wide trust-anchor record scales better to large user > > communities, and mostly addresses your concerns. > > I should note that one can of course implement one's SMIMEA deployment > in exactly this way, something along the lines of: > > *._smimecert.example.net. IN SMIMEA 2 1 1 e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855 > > would associate the same TA public key digest with every user, and would > not enable user enumeration. FWIW, I did something similar to this. Of course, there's a chicken/egg problem in _getting_ the CA cert for private CAs, unless you put the whole cert into DNS. And wildcards for something that large would be cache-unpleasant, but I did the same thing I do for TLSA records: define one SMIMEA record and CNAME to it elsewhere. Much more cache friendly. I never thought I'd see the day that I willingly chose to deploy a wildcard CNAME. :^D $ORIGIN spodhuis.org. *._smimecert CNAME _globnix-smimea _globnix-smimea SMIMEA ( ; GlobnixCA5 PKIX-less trust anchor 02 00 00 ; SKIP: binary blob for an ECDSA CA ; SMIMEA DANE-TA CERT FULL ) I can't attest that this _works_. As far as I know, it's entirely draft-spec compliant. If anyone has tooling which actually _uses_ SMIMEA, I'm happy to send you a test mail, or be given pointers to how to try it out. So far, I have an SMIME setup to theoretically let others verify mail I send, and that's it. -Phil From nobody Wed Apr 12 21:21:52 2017 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 E71D71293E3 for ; Wed, 12 Apr 2017 21:21:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=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 8IlOz6W8wlrd for ; Wed, 12 Apr 2017 21:21:49 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B00F6128CDB for ; Wed, 12 Apr 2017 21:21:48 -0700 (PDT) Received: from [172.31.31.193] (gzac12-mdf2-1.aoa.twosigma.com [208.77.215.155]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id 24CB07A32F1 for ; Thu, 13 Apr 2017 04:21:47 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Viktor Dukhovni In-Reply-To: <20170413035903.GA9079@tower.spodhuis.org> Date: Thu, 13 Apr 2017 00:21:46 -0400 Content-Transfer-Encoding: quoted-printable Reply-To: IETF DANE Mailinglist Message-Id: References: <4BE233BA-D524-4D05-87C5-E898DD646E7C@dukhovni.org> <7AF2817A-1564-44C5-A049-4F210737760F@dukhovni.org> <20170413035903.GA9079@tower.spodhuis.org> To: IETF DANE Mailinglist X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [dane] Improving DANE S/MIME Privacy X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.22 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, 13 Apr 2017 04:21:51 -0000 > On Apr 12, 2017, at 11:59 PM, Phil Pennock = wrote: >=20 >> I should note that one can of course implement one's SMIMEA = deployment >> in exactly this way, something along the lines of: >>=20 >> *._smimecert.example.net. IN SMIMEA 2 1 1 = e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855 >>=20 >> would associate the same TA public key digest with every user, and = would >> not enable user enumeration. >=20 > FWIW, I did something similar to this. Of course, there's a = chicken/egg > problem in _getting_ the CA cert for private CAs, unless you put the > whole cert into DNS. And wildcards for something that large would be > cache-unpleasant, but I did the same thing I do for TLSA records: = define > one SMIMEA record and CNAME to it elsewhere. Much more cache = friendly. >=20 > I never thought I'd see the day that I willingly chose to deploy a > wildcard CNAME. :^D >=20 > $ORIGIN spodhuis.org. > *._smimecert CNAME _globnix-smimea > _globnix-smimea SMIMEA ( ; GlobnixCA5 PKIX-less trust = anchor > 02 00 00 > ; SKIP: binary blob for an ECDSA CA > ; SMIMEA DANE-TA CERT FULL > ) >=20 > I can't attest that this _works_. As far as I know, it's entirely > draft-spec compliant. Note, that provided your MUA includes the issuing certificate in the signature block (you can always make it an intermediate CA issued by a throw-away root whose private key has been destroyed, and then the MUA should include at least all the intermediates), there's no need to use "SMIMEA 2 0 0" with the "large" DNS payloads that this entails. You get the same mileage from "SMIMEA 2 1 1". That said, ECDSA certificates are often considerably smaller than is the case with RSA, so "2 0 0" may be sufficient small to avoid issues with UDP MTUs. Still, I'd just go with "SMIMEA 2 1 1". --=20 Viktor. From nobody Wed Apr 12 22:02:27 2017 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 B33C11293E4 for ; Wed, 12 Apr 2017 22:02:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.103 X-Spam-Level: X-Spam-Status: No, score=-0.103 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=domblogger.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1v89UtOKu86y for ; Wed, 12 Apr 2017 22:02:19 -0700 (PDT) Received: from mail.domblogger.net (mail.domblogger.net [104.200.18.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBD93128B90 for ; Wed, 12 Apr 2017 22:02:19 -0700 (PDT) Received: from localhost.localdomain (68-189-44-253.dhcp.rdng.ca.charter.com [68.189.44.253]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.domblogger.net (Postfix) with ESMTPSA id 8445B601 for ; Thu, 13 Apr 2017 05:02:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=domblogger.net; s=default; t=1492059738; bh=2Kz4rrDsQgEGlA6YR5hDG4g0+0k6ODZj4r/Y0FlTaZM=; h=Subject:To:References:From:Date:In-Reply-To; b=qF19EJrI+U33+YA+0rrzwnb4j/fR7cEjsgknrg2hXroedfD2L/vLePZGE9de+KIWr VPbXroRyP0mbzY+WlusX5YTnstdzYme2FKGPtJHSB+IJihbrArFr062YC75CDrk43T 1r7c0yxyU3a9lney7+lkvN9UHa6YmLo1QM840oGE= To: dane@ietf.org References: <20170413031124.79969.qmail@ary.lan> From: Alice Wonder Message-ID: <5e781877-0c0c-5d11-2c64-3e66c0fd6f21@domblogger.net> Date: Wed, 12 Apr 2017 22:02:17 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <20170413031124.79969.qmail@ary.lan> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dane] domain hijacking X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.22 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, 13 Apr 2017 05:02:26 -0000 On 04/12/2017 08:11 PM, John Levine wrote: >> If my suspicion is correct, has there >> been thought of re-signing the DS record signed with the older private key >> in a way that proves ownership through the key change? > > This sounds to me like shutting the barn door after the horse is gone. > > If it's important to you that your domain isn't hijacked, we all know > what to do, pick a registrar with good security and 2FA and so forth, > and monitor your own DNS with alarms if there are unauthorized changes. > > Also, if we were to invent some sort of change signing, now you have > the other problem where the guy with the private key quits and takes > it with him, and you have to rebootstrap the zone somehow. > > R's, > John I wonder if the future DANE equivalent of EV type validation is DS records at a well known location at the root of the domain (e.g. /ds.signed) signed by a trusted third party that clients can use to validate what is in their TLD. The only commercial CA issued certificates I personally have any confidence in as an end user are EV and that would give even more confidence. Use DANE to secure to public x.509 and when more confidence than DANE is needed, expensive commercial CA to secure the DS records. Cheap commercial CA wouldn't be needed because DANE already provides far more than domain validation certs can, only DS record certs that involve human validation would make sense, for things like banking or commerce or major social network. To work with more than HTTPS third party DS records could be sent with a future version of TLS or some kind of blockchain technology. From nobody Wed Apr 12 22:04:39 2017 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 D659E1293E4 for ; Wed, 12 Apr 2017 22:04:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 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.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=domblogger.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lVBderWV_eCu for ; Wed, 12 Apr 2017 22:04:36 -0700 (PDT) Received: from mail.domblogger.net (mail.domblogger.net [IPv6:2600:3c00::f03c:91ff:fe56:d6a2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F1CBE1293E0 for ; Wed, 12 Apr 2017 22:04:29 -0700 (PDT) Received: from localhost.localdomain (68-189-44-253.dhcp.rdng.ca.charter.com [68.189.44.253]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.domblogger.net (Postfix) with ESMTPSA id 672FB601 for ; Thu, 13 Apr 2017 05:04:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=domblogger.net; s=default; t=1492059869; bh=0Rd5kUpeoEApPgZPTQ5dhA80W+8udybBXlJsnRN7/M4=; h=Subject:To:References:From:Date:In-Reply-To; b=R3FqwhDFGkKjHoAr7pIe2IvzQ9sLOLuXwmXvL+KE2BofytSvF2y5U8l0VzHcM7hel I1i2REeTeyhKpZtPwi+H7HaE6kcZgx8jeaxe78b/TRO29sqLAY2TN1cSHbW3EMqBts PwJUEDa04DhDk4m/HBgUkqhsqZV/sYYMABB9XAJs= To: dane@ietf.org References: <20170413031124.79969.qmail@ary.lan> <5e781877-0c0c-5d11-2c64-3e66c0fd6f21@domblogger.net> From: Alice Wonder Message-ID: <428eca20-a5b9-26e8-3f67-bc3ce770acf2@domblogger.net> Date: Wed, 12 Apr 2017 22:04:28 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <5e781877-0c0c-5d11-2c64-3e66c0fd6f21@domblogger.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dane] domain hijacking X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.22 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, 13 Apr 2017 05:04:39 -0000 On 04/12/2017 10:02 PM, Alice Wonder wrote: > On 04/12/2017 08:11 PM, John Levine wrote: >>> If my suspicion is correct, has there >>> been thought of re-signing the DS record signed with the older >>> private key >>> in a way that proves ownership through the key change? >> >> This sounds to me like shutting the barn door after the horse is gone. >> >> If it's important to you that your domain isn't hijacked, we all know >> what to do, pick a registrar with good security and 2FA and so forth, >> and monitor your own DNS with alarms if there are unauthorized changes. >> >> Also, if we were to invent some sort of change signing, now you have >> the other problem where the guy with the private key quits and takes >> it with him, and you have to rebootstrap the zone somehow. >> >> R's, >> John > > I wonder if the future DANE equivalent of EV type validation is DS > records at a well known location at the root of the domain (e.g. > /ds.signed) signed by a trusted third party that clients can use to > validate what is in their TLD. > > The only commercial CA issued certificates I personally have any > confidence in as an end user are EV and that would give even more > confidence. > > Use DANE to secure to public x.509 and when more confidence than DANE is > needed, expensive commercial CA to secure the DS records. Cheap > commercial CA wouldn't be needed because DANE already provides far more > than domain validation certs can, only DS record certs that involve > human validation would make sense, for things like banking or commerce > or major social network. > > To work with more than HTTPS third party DS records could be sent with a > future version of TLS or some kind of blockchain technology. Meant to type "third party *signed* DS records" From nobody Wed Apr 12 23:04:26 2017 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 BD388128D3E for ; Wed, 12 Apr 2017 23:04:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.103 X-Spam-Level: X-Spam-Status: No, score=-0.103 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=domblogger.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0E2ZBLOHjRXH for ; Wed, 12 Apr 2017 23:04:23 -0700 (PDT) Received: from mail.domblogger.net (mail.domblogger.net [104.200.18.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F4F61293E9 for ; Wed, 12 Apr 2017 23:04:22 -0700 (PDT) Received: from localhost.localdomain (68-189-44-253.dhcp.rdng.ca.charter.com [68.189.44.253]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.domblogger.net (Postfix) with ESMTPSA id DE82611F1 for ; Thu, 13 Apr 2017 06:04:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=domblogger.net; s=default; t=1492063462; bh=T7QxIRQ61t5S8CXvoRm9t/KRk2FTyPJBXs5SI6Y27Cs=; h=Subject:To:References:From:Date:In-Reply-To; b=juxyNEXgwtxKLHfRiE1cemHwoBhgU5JmpeLnWbtxaBt1PwqF9I+eRVA1a9bQoxPNo 03FbYGqvv9r7xq1z7Z2oOKjD+2u2hIl+qKVzQHoMGqPsQM+lf4tCBmjXApj7Hu7Q7r 0ZedUONJLcVOMITGCHhW2OcnAE0PpcrE46APJ/fw= To: dane@ietf.org References: <20170413031124.79969.qmail@ary.lan> <5e781877-0c0c-5d11-2c64-3e66c0fd6f21@domblogger.net> <428eca20-a5b9-26e8-3f67-bc3ce770acf2@domblogger.net> From: Alice Wonder Message-ID: <6a605bbc-6c19-94de-b0fc-dcd49c946f67@domblogger.net> Date: Wed, 12 Apr 2017 23:04:20 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <428eca20-a5b9-26e8-3f67-bc3ce770acf2@domblogger.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dane] domain hijacking X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.22 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, 13 Apr 2017 06:04:25 -0000 On 04/12/2017 10:04 PM, Alice Wonder wrote: *snip* > > Meant to type "third party *signed* DS records" Okay this is how I would do it. I'm new to list and kind of a nobody but... DANE is used to secure the long-term private key as an alternate to commercial DV certificates. For OV and EV level of confidence - a company can get an x.509 certificate using their zone as the CN and extensions specifying the DS records that is signed by a trusted third party commercial CA. This x.509 is only used as verification that the DNSSEC validated DS records are genuine and to give the consumer confidence the zone has been validated using OV or EV standards. It does not replace DS records secured by DNSSEC, only adds a second validation in addition to DNSSEC. Only OV and EV make sense for this type of x.509. To compromise a zone protected by this second x.509 a bad actor would need to both obtain a fraudulently signed x.509 from a trusted authority *and* get fraudulent DS records into the zone's parent zone. I'm not an expert on TLS but I think this would even work with existing TLS, just send this x.509 along with the DANE protected x.509 as part of the TLS handshake. Would that work and solve the problem? From nobody Thu Apr 13 05:28:06 2017 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 6E14E129416 for ; Thu, 13 Apr 2017 05:28:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.793 X-Spam-Level: X-Spam-Status: No, score=-1.793 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=wemonitoremail.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 oHqpfY9XO8AH for ; Thu, 13 Apr 2017 05:28:03 -0700 (PDT) Received: from mail.wemonitoremail.com (mail.wemonitoremail.com [78.47.26.204]) (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 379CD126DD9 for ; Thu, 13 Apr 2017 05:28:03 -0700 (PDT) X-WeMonitorEmail-From: ken@wemonitoremail.com X-WeMonitorEmail-VirusCheck: Clean Received: from auth (localhost [127.0.0.1]) by mail.wemonitoremail.com (8.14.4/8.14.4/inbound) with ESMTP id v3DCRLvm011410 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 13 Apr 2017 13:27:24 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wemonitoremail.com; s=mail; t=1492086444; bh=zqIrLB5aVAWi1YBAna5SYO77XbVa2qHzpRI7C5qdmyk=; h=Subject:From:To:Date; b=RpPjKxrqxgL5gX2h49NalS+LPp9xjiXjxSPgNXyL7N9ABqDxkZc6Eqq/BA6FMoaXG 6Tg7csl8qgJOI8e1xjXNzn/BmapOnVzRTkANxu4rEh28nM3b67zHNgxkyo2FB//q9t Vy/wwxrycszh5/YU6bO7qnVMXU0GVgspIlhNggQo= Message-ID: <1492086441.2469.30.camel@wemonitoremail.com> From: "Ken O'Driscoll" To: dane@ietf.org Date: Thu, 13 Apr 2017 13:27:21 +0100 In-Reply-To: <6a605bbc-6c19-94de-b0fc-dcd49c946f67@domblogger.net> References: <20170413031124.79969.qmail@ary.lan> <5e781877-0c0c-5d11-2c64-3e66c0fd6f21@domblogger.net> <428eca20-a5b9-26e8-3f67-bc3ce770acf2@domblogger.net> <6a605bbc-6c19-94de-b0fc-dcd49c946f67@domblogger.net> Organization: We Monitor Email Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.20.5 (3.20.5-1.fc24) Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [dane] domain hijacking X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.22 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, 13 Apr 2017 12:28:04 -0000 On Wed, 2017-04-12 at 23:04 -0700, Alice Wonder wrote: > To compromise a zone protected by this second x.509 a bad actor would  > need to both obtain a fraudulently signed x.509 from a trusted authority  > *and* get fraudulent DS records into the zone's parent zone. Or, an attacker could (as in the case we're discussing) just gain access to the domain registry and re-assign NS records, disabling any DNSSEC type security in the process. Resolvers have no expectation to be dealing with DNSSEC signed zones so removing the protection would not be challenged. Any mechanism that relies on anything that the registrant controls which they (or an imposter with their credentials) can disable does not address this risk. As John already pointed out, organisations can mitigate against these attacks by choosing registries (and registrars) who offer robust authentication options along with employing monitoring solutions. I'm not seeing how any type of protocol can do away with normal operational level security. Ken. From nobody Thu Apr 13 05:38:52 2017 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 45B8613159A for ; Thu, 13 Apr 2017 05:38:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 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.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=domblogger.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M0sBG7p_BjX7 for ; Thu, 13 Apr 2017 05:38:50 -0700 (PDT) Received: from mail.domblogger.net (mail.domblogger.net [104.200.18.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B1CE129423 for ; Thu, 13 Apr 2017 05:38:50 -0700 (PDT) Received: from localhost.localdomain (68-189-44-253.dhcp.rdng.ca.charter.com [68.189.44.253]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.domblogger.net (Postfix) with ESMTPSA id 9CDB61E67 for ; Thu, 13 Apr 2017 12:38:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=domblogger.net; s=default; t=1492087129; bh=fqFiuDX/a1zqn8/fMPc8LKZHLW2GK7yAjtpFefN1Dn0=; h=Subject:To:References:From:Date:In-Reply-To; b=q2zTrmaacjAsKx4zypJKwouV4x+96QkjdtM0fODnn9cRNcmbOgDG7KokOIpKoVRVV a4pzg2eH5slxPexV4u0OmEwnXiMbKZ2QSlahItr46snKfdm4fcoM9cwQ09nEOEF8k+ bkXBVn8oGa658P6pZao3KX4YQYwMfTPZ8twXs3Ko= To: dane@ietf.org References: <20170413031124.79969.qmail@ary.lan> <5e781877-0c0c-5d11-2c64-3e66c0fd6f21@domblogger.net> <428eca20-a5b9-26e8-3f67-bc3ce770acf2@domblogger.net> <6a605bbc-6c19-94de-b0fc-dcd49c946f67@domblogger.net> <1492086441.2469.30.camel@wemonitoremail.com> From: Alice Wonder Message-ID: Date: Thu, 13 Apr 2017 05:38:48 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <1492086441.2469.30.camel@wemonitoremail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dane] domain hijacking X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.22 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, 13 Apr 2017 12:38:51 -0000 On 04/13/2017 05:27 AM, Ken O'Driscoll wrote: > > On Wed, 2017-04-12 at 23:04 -0700, Alice Wonder wrote: >> To compromise a zone protected by this second x.509 a bad actor would >> need to both obtain a fraudulently signed x.509 from a trusted authority >> *and* get fraudulent DS records into the zone's parent zone. > > Or, an attacker could (as in the case we're discussing) just gain access to > the domain registry and re-assign NS records, disabling any DNSSEC type > security in the process. Resolvers have no expectation to be dealing with > DNSSEC signed zones so removing the protection would not be challenged. > > Any mechanism that relies on anything that the registrant controls which > they (or an imposter with their credentials) can disable does not address > this risk. > > As John already pointed out, organisations can mitigate against these > attacks by choosing registries (and registrars) who offer robust > authentication options along with employing monitoring solutions. > > I'm not seeing how any type of protocol can do away with normal operational > level security. What I am suggesting is that a CSR be produced from the KSK. That CSR gets signed by a third party - either OV or EV (no point in DV) The resulting x.509 cert is sent as part of the TLS handshake. If it doesn't match the DS record in zone's parent the client refuses. If it matches the DS record in zone's parent then the client shows the pretty OV or EV information in the URL bar. That won't stop someone who takes over a zone but it will prevent them from doing so with the extra EV validation users like me always look for when going to our bank or twitter or whatever. So if Chase has their zone hijacked in the registry, the attacker could make a DNSSEC validating phishing site, but it wouldn't have the other visual indications of EV because the attacker wouldn't be able to send a signed X.509 from the KSK that matches the fraudulent DS records they created. Wouldn't stop MITM from being attempted but it would give at least some users a visual indication that things are not what they are suppose to be. From nobody Thu Apr 13 06:15:45 2017 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 158CD129465 for ; Thu, 13 Apr 2017 06:15:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, 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 tPBhOu_d88e4 for ; Thu, 13 Apr 2017 06:15:42 -0700 (PDT) Received: from mail.nic.cl (mail.nic.cl [IPv6:2001:1398:1::6008]) (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 08E34129473 for ; Thu, 13 Apr 2017 06:15:33 -0700 (PDT) Received: from mail.nic.cl (localhost [127.0.0.1]) by mail.nic.cl (Postfix) with ESMTP id 82A148003CF for ; Thu, 13 Apr 2017 10:15:31 -0300 (CLST) Received: from vulcano.intra.nic.cl (unknown [IPv6:2001:1398:4:6:a986:59d3:cbbf:59e5]) (using TLSv1.2 with cipher AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.nic.cl (Postfix) with ESMTPS id 75E978002A6 for ; Thu, 13 Apr 2017 10:15:31 -0300 (CLST) Date: Thu, 13 Apr 2017 10:15:29 -0300 From: Hugo =?iso-8859-1?Q?Salgado-Hern=E1ndez?= To: dane@ietf.org Message-ID: <20170413131529.GA2423@vulcano.intra.nic.cl> References: <20170413031124.79969.qmail@ary.lan> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="oyUTqETQ0mS9luUI" Content-Disposition: inline In-Reply-To: <20170413031124.79969.qmail@ary.lan> User-Agent: Mutt/1.8.0 (2017-02-23) X-Virus-Scanned: ClamAV using ClamSMTP on Thu Apr 13 10:15:31 2017 -0300 (CLST) Archived-At: Subject: Re: [dane] domain hijacking X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.22 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, 13 Apr 2017 13:15:44 -0000 --oyUTqETQ0mS9luUI Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 03:11 13/04, John Levine wrote: > > If my suspicion is correct, has there > >been thought of re-signing the DS record signed with the older private k= ey > >in a way that proves ownership through the key change? >=20 > This sounds to me like shutting the barn door after the horse is gone. >=20 > If it's important to you that your domain isn't hijacked, we all know > what to do, pick a registrar with good security and 2FA and so forth, > and monitor your own DNS with alarms if there are unauthorized changes. >=20 > Also, if we were to invent some sort of change signing, now you have > the other problem where the guy with the private key quits and takes > it with him, and you have to rebootstrap the zone somehow. Agree. But anyway, we have two indicators of something is wrong, from DNSSEC perspective. Even the hijacker deletes the DS and the zone goes insecure, or change it for a new one and the zone goes bogus for some hours, just like a bad made rollover. Maybe the bank could indicate somehow that it's zone should never go insecure/bogus, just like a website owner can signal with HSTS that it'll never go plain. Hugo --oyUTqETQ0mS9luUI Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBAgAGBQJY73nxAAoJELDuRLDm9Omt6IIP/3SrXJNv0N8V76vZ6H3FOsHc m6a/VG/tesma4SADWDxQYRukJ7rHLA66vjWNBFjqJtcZgUYPgoxf5pLykg9arRUG HpyKi3e7A24e/B3NX2QWkran+7i3jelgoSc5JjlVfc3qhk2EybMeriDyB78q8Pu1 l0Dej1UPDkUQ036hTd+kfIaUYwb4LwJtaS6xAogp7cdL8QttbJjcEWuvOw4Xm5aj /XYt3dc0hbL6Jf+MPDB3KD4FbZcfXHq68iKWx2mNCxWHxbxkNF5Hhnu+F4xV4eaw 3Lnm2kB8X+HuGQMzZgZUlg0qozX1eDEf/dsvsmh51R2LMYjxuIsdLsw/nmTaXERH RGQHTBmKDfwHcAiyq2XZA97JrmCRhjuWGuwlXBW0geoleOhRDzc338n2/EX8thkZ 8Vl2Ait68x5ndn68mfGPlH3xQNCqsPEtrPnBhCqa/D0vjOPYJCm0rFblAtsKEXy5 1K4Z8TCBJRCCdmfMQG9y+PsC1J1pWIqC1ys+ee9A25FvLZnTaCw8cGui2EKIo7Vk 0S6T9M/PEWRlJ5I+OM/s7Ng2yv2rfZLSVRdXc9BEAE3iCfwPmKAgH51EByzjZ8FQ Q/hVDWfeIm5iLWj+Sjt4NIs+wsELa2FtS4ZX80qFZTdKwJu0A7SlGeTLv0vTRFV9 CVRpBpciYi9jo8hKPTox =Bqw2 -----END PGP SIGNATURE----- --oyUTqETQ0mS9luUI-- From nobody Thu Apr 13 07:06:56 2017 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 8C12B124D68 for ; Thu, 13 Apr 2017 07:06:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 5JO0QpGZPDwm for ; Thu, 13 Apr 2017 07:06:52 -0700 (PDT) Received: from mail-vk0-x22b.google.com (mail-vk0-x22b.google.com [IPv6:2607:f8b0:400c:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8D8D126FDC for ; Thu, 13 Apr 2017 07:06:51 -0700 (PDT) Received: by mail-vk0-x22b.google.com with SMTP id z204so28516402vkd.1 for ; Thu, 13 Apr 2017 07:06:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=iXQO3mJ2iHtl5+ppkc+EnpSnK08ckUbrE46VWfw45zU=; b=VMEQmhKhC/KfQDQavV7f7mm2hBEYGtssFLJR64XwX9Rlbv7cfCUHThEQbPTxkTNAXL m5DcvRiF+Y23sIkaQY0S4FJoeifoyxoWsaJ8voOFcZf5bEX5il4+TO9YsKK/PbfqmaZP aqTNF2aqhmRsPXhdfU0bO+Ok7XE63q3SoYGTi/96lDXJc2+Ofteg0KdXqHe1j6SLgEe8 jTIEZ+LbdxyV1ek0MbK6MOHjxP2i8yJfBm31pHX4cP9Mi2TcSwMpQvJQ8c8Q3KBU8wa/ wFgwYthhnJ5XYMsePwKLMDn/pyuwCcsX5ziaOGJCcrPSxARgk5Sq0tQg/c6w8CLwUGkj 8p/g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=iXQO3mJ2iHtl5+ppkc+EnpSnK08ckUbrE46VWfw45zU=; b=hmjalMa5+gq+UuSX29c5qc7v58dkdwZ+5hGMHwzd8RTLnQldSJDdC3/tw4qaXFrPY4 YWq92kUKOCQhoLoK5YbLbEY8AYquX2aUSzyjDq3+eK/X3qcyczXKtKHXcre7NetnyJDz xPmjIEWnscR7TEieYGqJ2M+z9fqaDIdh+YjL+EYEjyhPaM6fN0w1Cp0WJkKeq6CeFZg5 FHZYJ6iwDdLyTNHbjwW+Q9J9N2ZMsoRYwxHKIyUOZofOaVbB5L5IiFw2RGR9r9KHBKL4 mEm1NjzoMjdLsVeE/SnBIm75tDqk6npNhEWBiEq9atMaJHyBsDrzl3DfL0qQRTRX/Ufh YK5A== X-Gm-Message-State: AN3rC/6r+qzD8vDo8dCs8vhA4JIxiWvbqh5hG13kH0AXhZcdSfgVR7ac XvtSvAB/W6ueLKbpx9QQKjqMQmD9ausAnJ9isQ== X-Received: by 10.31.153.74 with SMTP id b71mr1313531vke.73.1492092410511; Thu, 13 Apr 2017 07:06:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.51.200 with HTTP; Thu, 13 Apr 2017 07:06:49 -0700 (PDT) In-Reply-To: <20170413031124.79969.qmail@ary.lan> References: <20170413031124.79969.qmail@ary.lan> From: Wei Chuang Date: Thu, 13 Apr 2017 07:06:49 -0700 Message-ID: To: John Levine Cc: IETF DANE Mailinglist Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="001a1141dd30215f3a054d0cd6aa" Archived-At: Subject: Re: [dane] domain hijacking X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.22 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, 13 Apr 2017 14:06:55 -0000 --001a1141dd30215f3a054d0cd6aa Content-Type: multipart/alternative; boundary=001a1141dd301a3d90054d0cd670 --001a1141dd301a3d90054d0cd670 Content-Type: text/plain; charset=UTF-8 On Wed, Apr 12, 2017 at 8:11 PM, John Levine wrote: > > If my suspicion is correct, has there > >been thought of re-signing the DS record signed with the older private key > >in a way that proves ownership through the key change? > > This sounds to me like shutting the barn door after the horse is gone. > > If it's important to you that your domain isn't hijacked, we all know > what to do, pick a registrar with good security and 2FA and so forth, and monitor your own DNS with alarms if there are unauthorized changes. > Even with a good registrar there might be some reason for this. Consider that 2FA might not be a permanent solution to zone admin account hijacking. For example, RSA 2FA products which are very popular, were reportedly bypassed back in 2012 . Further such a solution might better detect/prevent spoofing by a adversarial parent zone or registrar. Agreed that monitoring is a good idea. One issue it that it may be difficult for you/your script to be always vigilant. Perhaps by making a domain hijacking more visible to everyone, and having a whistleblowing (i.e. reporting mechanism such as used in Coniks) protocol then you could distribute the problem of monitoring. > > Also, if we were to invent some sort of change signing, now you have > the other problem where the guy with the private key quits and takes > it with him, and you have to rebootstrap the zone somehow. > Agreed this is pertinent issue and I don't have a fully baked scheme to work out this scenario. But perhaps a solution might involve checking the cached but stale result to see if that historic state is consistent with a newly published state up to 1 TTL period. Errors condition would then existing for a finite time (1 TTL). -Wei --001a1141dd301a3d90054d0cd670 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Apr 12, 2017 at 8:11 PM, John Levine <johnl@taugh.com> wrote:
> If my suspicion is correct, has there
>been thought of re-signing the DS record signed with the older private = key
>in a way that proves ownership through the key change?

This sounds to me like shutting the barn door after the horse is gon= e.

If it's important to you that your domain isn't hijacked, we all kn= ow
what to do, pick a registrar with good security and 2FA and so forth,=C2=A0=
and monitor your own DNS with alarms if there are unauthorized changes.
=

Even with a good registrar there might be = some reason for this.=C2=A0 Consider that 2FA might not =C2=A0be a permanen= t solution to zone admin account hijacking.=C2=A0 For example, RSA 2FA prod= ucts which are very popular, were reportedly bypassed=C2=A0back in 2012.=C2=A0 Further such a solution might better detect/pr= event spoofing by a adversarial parent zone or registrar.=C2=A0 Agreed that= monitoring is a good idea.=C2=A0 One issue it that it may be difficult for= you/your script to be always vigilant.=C2=A0 Perhaps by making a domain hi= jacking more visible to everyone, and having a whistleblowing (i.e. reporti= ng mechanism such as used in Coniks) protocol then you could distribute the= problem of monitoring.
=C2=A0

Also, if we were to invent some sort of change signing, now you have
the other problem where the guy with the private key quits and takes
it with him, and you have to rebootstrap the zone somehow.
=

Agreed this is pertinent issue and I don't have a f= ully baked scheme to work out this scenario.=C2=A0 But perhaps a solution m= ight involve checking the cached but stale result to see if that historic s= tate is consistent with a newly published state up to 1 TTL period.=C2=A0 E= rrors condition would then existing for a finite time (1 TTL). =C2=A0
=
=C2=A0
-Wei

--001a1141dd301a3d90054d0cd670-- --001a1141dd30215f3a054d0cd6aa Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIS5wYJKoZIhvcNAQcCoIIS2DCCEtQCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ghBNMIIEXDCCA0SgAwIBAgIOSBtqDm4P/739RPqw/wcwDQYJKoZIhvcNAQELBQAwZDELMAkGA1UE BhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVy c29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hBMjU2IC0gRzIwHhcNMTYwNjE1MDAwMDAwWhcNMjEw NjE1MDAwMDAwWjBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEiMCAG A1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBALR23lKtjlZW/17kthzYcMHHKFgywfc4vLIjfq42NmMWbXkNUabIgS8KX4PnIFsTlD6F GO2fqnsTygvYPFBSMX4OCFtJXoikP2CQlEvO7WooyE94tqmqD+w0YtyP2IB5j4KvOIeNv1Gbnnes BIUWLFxs1ERvYDhmk+OrvW7Vd8ZfpRJj71Rb+QQsUpkyTySaqALXnyztTDp1L5d1bABJN/bJbEU3 Hf5FLrANmognIu+Npty6GrA6p3yKELzTsilOFmYNWg7L838NS2JbFOndl+ce89gM36CW7vyhszi6 6LqqzJL8MsmkP53GGhf11YMP9EkmawYouMDP/PwQYhIiUO0CAwEAAaOCASIwggEeMA4GA1UdDwEB /wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIB ADAdBgNVHQ4EFgQUyzgSsMeZwHiSjLMhleb0JmLA4D8wHwYDVR0jBBgwFoAUJiSSix/TRK+xsBtt r+500ox4AAMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9ncy9n c3BlcnNvbmFsc2lnbnB0bnJzc2hhMmcyLmNybDBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG 9w0BAQsFAAOCAQEACskdySGYIOi63wgeTmljjA5BHHN9uLuAMHotXgbYeGVrz7+DkFNgWRQ/dNse Qa4e+FeHWq2fu73SamhAQyLigNKZF7ZzHPUkSpSTjQqVzbyDaFHtRBAwuACuymaOWOWPePZXOH9x t4HPwRQuur57RKiEm1F6/YJVQ5UTkzAyPoeND/y1GzXS4kjhVuoOQX3GfXDZdwoN8jMYBZTO0H5h isymlIl6aot0E5KIKqosW6mhupdkS1ZZPp4WXR4frybSkLejjmkTYCTUmh9DuvKEQ1Ge7siwsWgA NS1Ln+uvIuObpbNaeAyMZY0U5R/OyIDaq+m9KXPYvrCZ0TCLbcKuRzCCBB4wggMGoAMCAQICCwQA AAAAATGJxkCyMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAt IFIzMRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTExMDgwMjEw MDAwMFoXDTI5MDMyOTEwMDAwMFowZDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVyc29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hB MjU2IC0gRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCg/hRKosYAGP+P7mIdq5NB Kr3J0tg+8lPATlgp+F6W9CeIvnXRGUvdniO+BQnKxnX6RsC3AnE0hUUKRaM9/RDDWldYw35K+sge C8fWXvIbcYLXxWkXz+Hbxh0GXG61Evqux6i2sKeKvMr4s9BaN09cqJ/wF6KuP9jSyWcyY+IgL6u2 52my5UzYhnbf7D7IcC372bfhwM92n6r5hJx3r++rQEMHXlp/G9J3fftgsD1bzS7J/uHMFpr4MXua eoiMLV5gdmo0sQg23j4pihyFlAkkHHn4usPJ3EePw7ewQT6BUTFyvmEB+KDoi7T4RCAZDstgfpzD rR/TNwrK8/FXoqnFAgMBAAGjgegwgeUwDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8C AQEwHQYDVR0OBBYEFCYkkosf00SvsbAbba/udNKMeAADMEcGA1UdIARAMD4wPAYEVR0gADA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzA2BgNVHR8E LzAtMCugKaAnhiVodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L3Jvb3QtcjMuY3JsMB8GA1UdIwQY MBaAFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQACAFVjHihZCV/IqJYt 7Nig/xek+9g0dmv1oQNGYI1WWeqHcMAV1h7cheKNr4EOANNvJWtAkoQz+076Sqnq0Puxwymj0/+e oQJ8GRODG9pxlSn3kysh7f+kotX7pYX5moUa0xq3TCjjYsF3G17E27qvn8SJwDsgEImnhXVT5vb7 qBYKadFizPzKPmwsJQDPKX58XmPxMcZ1tG77xCQEXrtABhYC3NBhu8+c5UoinLpBQC1iBnNpNwXT Lmd4nQdf9HCijG1e8myt78VP+QSwsaDT7LVcLT2oDPVggjhVcwljw3ePDwfGP9kNrR+lc8XrfClk WbrdhC2o4Ui28dtIVHd3MIIDXzCCAkegAwIBAgILBAAAAAABIVhTCKIwDQYJKoZIhvcNAQELBQAw TDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24x EzARBgNVBAMTCkdsb2JhbFNpZ24wHhcNMDkwMzE4MTAwMDAwWhcNMjkwMzE4MTAwMDAwWjBMMSAw HgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEG A1UEAxMKR2xvYmFsU2lnbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMwldpB5Bngi FvXAg7aEyiie/QV2EcWtiHL8RgJDx7KKnQRfJMsuS+FggkbhUqsMgUdwbN1k0ev1LKMPgj0MK66X 17YUhhB5uzsTgHeMCOFJ0mpiLx9e+pZo34knlTifBtc+ycsmWQ1z3rDI6SYOgxXG71uL0gRgykmm KPZpO/bLyCiR5Z2KYVc3rHQU3HTgOu5yLy6c+9C7v/U9AOEGM+iCK65TpjoWc4zdQQ4gOsC0p6Hp sk+QLjJg6VfLuQSSaGjlOCZgdbKfd/+RFO+uIEn8rUAVSNECMWEZXriX7613t2Saer9fwRPvm2L7 DWzgVGkWqQPabumDk3F2xmmFghcCAwEAAaNCMEAwDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQF MAMBAf8wHQYDVR0OBBYEFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQBL QNvAUKr+yAzv95ZURUm7lgAJQayzE4aGKAczymvmdLm6AC2upArT9fHxD4q/c2dKg8dEe3jgr25s bwMpjjM5RcOO5LlXbKr8EpbsU8Yt5CRsuZRj+9xTaGdWPoO4zzUhw8lo/s7awlOqzJCK6fBdRoyV 3XpYKBovHd7NADdBj+1EbddTKJd+82cEHhXXipa0095MJ6RMG3NzdvQXmcIfeg7jLQitChws/zyr VQ4PkX4268NXSb7hLi18YIvDQVETI53O9zJrlAGomecsMx86OyXShkDOOyyGeMlhLxS67ttVb9+E 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEZDCCA0ygAwIBAgIMAQEwAHyjxWs8sJNjMA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE3MDMyNTE4NDI0N1oXDTE3MDky MTE4NDI0N1owIjEgMB4GCSqGSIb3DQEJAQwRd2VpaGF3QGdvb2dsZS5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDf/V6s9+sy7fHvy6Z2bKp63d5w85JpcZW9SebsKdycSAUATqgb Gvo6SYD4qMWY3mR+O3LHmJ6WoHqr9xEd7uZ5JxxpfjGhe3MqgS5JaXuKn34q4li1EdMk8F7MB0FD 6VFzmd2OYPpKF8f3d8oyqQUHPnZvoOqCVlO4+fHapq+Rz9++cSI1UbK7KX/kOsi1q+tNEVGP1oVC Cmy/1WK7EEGMOLo2K48AS9T3IP15I1hn/Sj4vVJrpW0rzvRpahOxWKo7SqLcwSRvDvKNue5di7iQ eVceAPcahROEy4P20dimQXpxTVyjQG8wz75b4hwykEgPruaXn1J1usP830/0Tet5AgMBAAGjggFu MIIBajAcBgNVHREEFTATgRF3ZWloYXdAZ29vZ2xlLmNvbTBQBggrBgEFBQcBAQREMEIwQAYIKwYB BQUHMAKGNGh0dHA6Ly9zZWN1cmUuZ2xvYmFsc2lnbi5jb20vY2FjZXJ0L2dzaHZzbWltZWNhMS5j cnQwHQYDVR0OBBYEFF4Fc4YKhOL19j17oEbz6tlaKO/DMB8GA1UdIwQYMBaAFMs4ErDHmcB4koyz IZXm9CZiwOA/MEwGA1UdIARFMEMwQQYJKwYBBAGgMgEoMDQwMgYIKwYBBQUHAgEWJmh0dHBzOi8v d3d3Lmdsb2JhbHNpZ24uY29tL3JlcG9zaXRvcnkvMDsGA1UdHwQ0MDIwMKAuoCyGKmh0dHA6Ly9j cmwuZ2xvYmFsc2lnbi5jb20vZ3NodnNtaW1lY2ExLmNybDAOBgNVHQ8BAf8EBAMCBaAwHQYDVR0l BBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4IBAQCPihhAVF7RDXtgpruF 0d7ukFX3Ki/I7JD6lTgEGdekylp4bPtLcnIZKM5+JhwalsTbInvGVI6e3VlIyVIOonCf+lIxwC0A enfp52lsFIy12dunCtSJckTlT9LYuxSK5sA4krofdq0ZtSxJ3y8CYHzzolTGaEPqf2BhIpboO4QI zEaRD8w652Rjfo/zP+yI+qYXzACs8erQN0B+8+hT/7Ir8NQcOztDBlNey/ynwE+p1/85y8IHPR8Y Ssm0jF6cpyP/WDat2BbKzT0O1XuZF24UCNxasGcYjYuz3a2+JwQEfSFyFVu/lslEsd8Ehcd9siGL t+pE4LJq0i8cDdnBhWcIMYICXjCCAloCAQEwXDBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xv YmFsU2lnbiBudi1zYTEiMCAGA1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMQIMAQEwAHyj xWs8sJNjMA0GCWCGSAFlAwQCAQUAoIHUMC8GCSqGSIb3DQEJBDEiBCAEnj7nfz1fHLibouRlTEEw 9Dy/gcyQAgs3msB5EFXJSzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xNzA0MTMxNDA2NTFaMGkGCSqGSIb3DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQB FjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEBBzALBglg hkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAEggEAuSbvDuC7hs0mdGDI/FYG15p6M97zVPIl6SmqasF2 DQ6N9G6cf0/aAUpW07GHf+yQUxebSFcH9Sc3by//6crYhceRs1XxJOsm0eI89jQ8exwjIq5lY9Ap Es6oi17zmnXkQNzdnotZ9ea/9ER2uHkPl4lMrVT3sA3LafRJLF+TYGhgw03uUpiZQ7WhS8/pCi6u tU8hAtCYJ1miKGmdtzTecX9JwixtA2c0vMu6Xyf/yARL/F4aVfXYTcA6ue1EeSjI1UcNBdab6TRO yXwa2xcLF+fIMg87BDEx83vk0iR9TixlOXo3YE6t0YiDBtk6aPcKNKKmqScWq3phpA1/yQE1Cg== --001a1141dd30215f3a054d0cd6aa-- From nobody Thu Apr 13 09:38:09 2017 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 A0E8D1294F9 for ; Thu, 13 Apr 2017 09:38:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.221 X-Spam-Level: X-Spam-Status: No, score=-1.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=PJpyMGcd; dkim=pass (1536-bit key) header.d=taugh.com header.b=IkgWjJ/4 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k8ypMLKLyXIv for ; Thu, 13 Apr 2017 09:38:06 -0700 (PDT) Received: from miucha.iecc.com (www.iecc.com [IPv6:2001:470:1f07:1126::4945:4343]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A99831294C8 for ; Thu, 13 Apr 2017 09:38:05 -0700 (PDT) Received: (qmail 38031 invoked from network); 13 Apr 2017 16:38:04 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=948d.58efa96c.k1704; bh=ED3vXg+REE/FBfCjAVkCveVpcyq+DXukbrLZwde2HDA=; b=PJpyMGcdIqLeItwNDBzOlcB8vvI2P2OfzYjzCgz9QCxjLqayKIea1SMfASX/01hG9k0xTrujEiou/jF7fcMjLvBEtDEG0Jh9Q9mONnBPTQkIQdY/Y47k6iH1FInfGvdfeFdWUdSqFwgdiTE308j91IMgsD69XAOqGwcSwr2w5eonLn/127fquuRQILLv4GCPF7QrgVGT4vhpzAGQRcADHbIEducTDMf5wff69N3XjlcLYRTTKS9YtIsd1eJbnKK8 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=948d.58efa96c.k1704; bh=ED3vXg+REE/FBfCjAVkCveVpcyq+DXukbrLZwde2HDA=; b=IkgWjJ/4pv6mP6JJNzYLV4W9030RBOV1EraZF9jclONJSyhfUHZDdYU/P9vN8/rXct7Ne1ssZz9aLImlcJIi6sCvCFWQzGq77tmo1GJPbUexWO6MAaKR9Yz3355lTgd0yR5GFGDUTssX9yRAQVZmguYPezFlmZWdaR3sdG0KCc616fpS5r3Wc08irVmH3PBtTABldKB0j2Gz59lrdhz9ZqwamIj+9BVr2lv40XhiNzrRyq+lueWjG8bgTj+h35d6 Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2/X.509/AEAD) via TCP6; 13 Apr 2017 16:38:04 -0000 Date: 13 Apr 2017 12:38:03 -0400 Message-ID: From: "John R Levine" To: "Wei Chuang" Cc: "IETF DANE Mailinglist" In-Reply-To: References: <20170413031124.79969.qmail@ary.lan> User-Agent: Alpine 2.20 (OSX 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII Archived-At: Subject: Re: [dane] domain hijacking X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.22 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, 13 Apr 2017 16:38:08 -0000 > Perhaps by making a domain hijacking more visible to everyone, and > having a whistleblowing (i.e. reporting mechanism such as used in > Coniks) protocol then you could distribute the problem of monitoring. That's just what I *don't* want to do. I do not want to be volunteered to be an unpaid security officer for everyone else's DNS. It's fine to think about ways that a domain can secure its DNS and detect and fix unauthorized change, but I don't think it's fair to expect the rest of the world to do it for you. R's, John From nobody Sat Apr 15 09:01:15 2017 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 AE9C01293FF for ; Sat, 15 Apr 2017 09:01:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.698 X-Spam-Level: X-Spam-Status: No, score=0.698 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=domblogger.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 25K46qOFvRSY for ; Sat, 15 Apr 2017 09:01:13 -0700 (PDT) Received: from mail.domblogger.net (mail.domblogger.net [IPv6:2600:3c00::f03c:91ff:fe56:d6a2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 63718127873 for ; Sat, 15 Apr 2017 09:01:13 -0700 (PDT) Received: from localhost.localdomain (68-189-44-253.dhcp.rdng.ca.charter.com [68.189.44.253]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.domblogger.net (Postfix) with ESMTPSA id 71E89D6E for ; Sat, 15 Apr 2017 16:01:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=domblogger.net; s=default; t=1492272071; bh=OCbq7jze1j6lZdafXCHoxh/W46BSkt3aAk2CS0TaHZk=; h=To:From:Subject:Date; b=W4S4sAw/wusWohnbuY6uXQwcUX40DGpiCXuKfl9UB/4yI+tOnFTZH9XqYmbsz9vOt kMSDM0U5/T8E1ASFqg27NMfueWvuQ5Ec/D4xMMrIgVH1y1EmfRoz8frQFFhMu4ZBrF VF+K6zP+swMO9SYHgkxJS/nVQC7+1OdlNP4XLPc4= To: IETF DANE Mailinglist From: Alice Wonder Message-ID: <9bb60f83-84cb-0e26-a6ac-3e65e57ef7bb@domblogger.net> Date: Sat, 15 Apr 2017 09:01:10 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [dane] Quick question regarding DANE and S/MIME X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.22 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, 15 Apr 2017 16:01:15 -0000 When using a 2 x x DANE record for S/MIME - Do I need to then include the intermediary (and root?) certificate with the actual user's certificate, or is it possible to use something like authorityInfoAccess when generating the cert to specify where the intermediary certificate that matches the DANE record resides? -- Sorry for the n00b like question, I'm probably still months away from implementing, I have the scripts needed for the root and intermediaries set up, but I need to finish carefully inspecting them find a good open source OCSP responder because I believe that is necessary if an intermediary fingerprint is put in DANE record instead of a self-signed. This does however really excite me, wish we had DANE validation of S/MIME when I first got into computing. Thank you for your time, Alice Wonder From nobody Sat Apr 15 10:31:29 2017 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 15C9C12940B for ; Sat, 15 Apr 2017 10:31:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=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 14qT5TOYpQe3 for ; Sat, 15 Apr 2017 10:31:26 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9787A12422F for ; Sat, 15 Apr 2017 10:31:26 -0700 (PDT) Received: from dhcp-gs-2002.eduroam.cornell.edu (nat-128-84-124-0-978.cit.cornell.edu [128.84.127.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id 9E5D17A32F1 for ; Sat, 15 Apr 2017 17:31:25 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Viktor Dukhovni In-Reply-To: <9bb60f83-84cb-0e26-a6ac-3e65e57ef7bb@domblogger.net> Date: Sat, 15 Apr 2017 13:31:25 -0400 Content-Transfer-Encoding: quoted-printable Reply-To: IETF DANE Mailinglist Message-Id: References: <9bb60f83-84cb-0e26-a6ac-3e65e57ef7bb@domblogger.net> To: IETF DANE Mailinglist X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [dane] Quick question regarding DANE and S/MIME X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.22 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, 15 Apr 2017 17:31:28 -0000 > On Apr 15, 2017, at 12:01 PM, Alice Wonder = wrote: >=20 > When using a 2 x x DANE record for S/MIME - Do I need to then include > the intermediary (and root?) certificate with the actual user's = certificate, > or is it possible to use something like authorityInfoAccess when = generating > the cert to specify where the intermediary certificate that matches = the DANE > record resides? The user's signature needs to (and generally will) include all the = certificates up to and including the "2 x x" trust-anchor. To maximize the chance = that this will happen publish a "2 x x" for an intermediate, rather than a root = (self-signed) CA. --=20 Viktor.