From nobody Wed Oct 5 23:32:14 2016 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E5E41200DF for ; Wed, 5 Oct 2016 23:32:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.196 X-Spam-Level: X-Spam-Status: No, score=-7.196 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.996] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B5Vwakxd0mvH for ; Wed, 5 Oct 2016 23:32:09 -0700 (PDT) Received: from office.denic.de (office.denic.de [81.91.160.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B895A12946E for ; Wed, 5 Oct 2016 23:32:09 -0700 (PDT) Received: from office.denic.de (mailout-6.osl.denic.de [10.122.34.32]) by office.denic.de (Postfix) with ESMTP id 96B4D1FEAA for ; Thu, 6 Oct 2016 08:32:05 +0200 (CEST) Received: from notes1.fra2.osl.denic.de (notes1.fra2.osl.denic.de [10.122.50.48]) by office.denic.de with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) id 1bs2Dt-0003bm-J7; Thu, 06 Oct 2016 08:32:05 +0200 To: dane@ietf.org MIME-Version: 1.0 X-KeepSent: 3260F3E2:2BFFC454-C1258044:0021F733; type=4; name=$KeepSent X-Mailer: IBM Notes Release 9.0.1FP5 Octobe4, 2013 From: Marcos Sanz Message-ID: Date: Thu, 6 Oct 2016 08:32:04 +0200 X-MIMETrack: Serialize by Router on notes/Denic at 06.10.2016 08:32:05, Serialize complete at 06.10.2016 08:32:05 Content-Type: text/plain; charset="US-ASCII" Archived-At: Subject: [dane] Comment on draft-ietf-dane-smime-12 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Oct 2016 06:32:12 -0000 Hello all, I just got through the dane-smime document and have one ammendment to make to section 7, specifically "applications SHOULD use TCP - not UDP". My impression is that that specific recommendation (and its rationale in the next paragraph) was mimicked from the OPENPGPKEY spec, where it makes sense because the whole armored key gets into the DNS. But since SMIMEA is very much like TLSA, I don't see the need for that TCP preference (nor does 7671 - check section 10.1.1). One might argue that QNAMES for SMIMEA will be bigger than for TLSA, since they routinely include a 28-octect hash, however, I don't buy that as a powerful enough reason. I would just delete the text and, if at all, refer to 7671 for transport considerations. Paul already reminded me that the wg last call for the document is over, but I think it still would be time to make some change, if the chairs haven't passed the doc to the IESG. Best regards, Marcos From nobody Thu Oct 6 13:08:44 2016 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32A6912977C for ; Thu, 6 Oct 2016 13:08:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.996 X-Spam-Level: X-Spam-Status: No, score=-4.996 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=-2.996] 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 b-9v92qyKb73 for ; Thu, 6 Oct 2016 13:08:42 -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 3C58B12970A for ; Thu, 6 Oct 2016 13:08:42 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3sqkHW3z2lzD09; Thu, 6 Oct 2016 22:08:39 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1475784519; bh=hXmVLRfsUCGU9xmRj1asJa+7tsoDSh3HKL4wHX7A9T8=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=RQMf6U6etGp7Y0LCM9Fp7O34zho2PcrNoETTVDxxVFwzLQHxopspCEnfXd89gBvdT IboE8STGeoNubOr1nMo9jhCH3rXgBJ3Z0I/JzUwBEipIk3tBNpHDtgcycR4YLohUCh cqKXZJ+4aNy3f56TvjJvTF7ST7wSI+D6UDx+1QOE= 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 891jsgzkj1LZ; Thu, 6 Oct 2016 22:08:38 +0200 (CEST) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Thu, 6 Oct 2016 22:08:38 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 67B315C83A; Thu, 6 Oct 2016 16:08:35 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.10.3 bofh.nohats.ca 67B315C83A Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 640B140D358A; Thu, 6 Oct 2016 16:08:35 -0400 (EDT) Date: Thu, 6 Oct 2016 16:08:35 -0400 (EDT) From: Paul Wouters To: Marcos Sanz In-Reply-To: Message-ID: References: User-Agent: Alpine 2.20 (LRH 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Cc: dane@ietf.org Subject: Re: [dane] Comment on draft-ietf-dane-smime-12 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Oct 2016 20:08:43 -0000 On Thu, 6 Oct 2016, Marcos Sanz wrote: > I just got through the dane-smime document and have one ammendment to make > to section 7, specifically "applications SHOULD use TCP - not UDP". > > My impression is that that specific recommendation (and its rationale in > the next paragraph) was mimicked from the OPENPGPKEY spec, where it makes > sense because the whole armored key gets into the DNS. But since SMIMEA is > very much like TLSA, I don't see the need for that TCP preference (nor > does 7671 - check section 10.1.1). If you do not have the s/mime cert and you pull it from the DNS, it is still a pretty big blob that would not be nice to get spoofed to the wrong IP address. So I do think the same security consideration applies. For 7671, which really mostly talks about DANE use with TLS, getting the whole certificate from DNS is less likely, because the TLS handshake already provides you with the certificate. Paul From nobody Sun Oct 9 21:12:32 2016 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 423F31295D3 for ; Sun, 9 Oct 2016 21:12:31 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fzx3Ar3vmRhp for ; Sun, 9 Oct 2016 21:12:29 -0700 (PDT) Received: from mail-qt0-x235.google.com (mail-qt0-x235.google.com [IPv6:2607:f8b0:400d:c0d::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF184129475 for ; Sun, 9 Oct 2016 21:12:29 -0700 (PDT) Received: by mail-qt0-x235.google.com with SMTP id q7so44361246qtq.1 for ; Sun, 09 Oct 2016 21:12:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=6hrhvwprOjAYQqZrboGbZiL8J7ellfFBhpcHrBXj3uA=; b=rt6BUZeyy5vLOVlmTwFgf24r6s6Acp5WIx1H+Hl6Gu+ZZB47einCCWo4ys9xKHtQgE LSv9h1yFTyn2IdoQ/jKajjk7Awh00dIybtTTQ2CoWHgW/PQk21xL0occh1W20+FkAejX zC3swlzHrdJxAu+QNOy0G32rQyed0Zm5KRwvVLts2NF1+IS/AhC/hkbBWKMmLpXkre6s pGQoyVpx9v1Q3r5LXFkCXC9Ct7buIZRnNi2oS09Y6Qnd93tHHTn+G+q+EvoTUKhA0yVr RhMgYWFKvNdo4a7OM+CTUD+/G9afMgDObKfIHGIH+837kfqAreEYLE5TD4fP/HBwZJ6Z JCGA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=6hrhvwprOjAYQqZrboGbZiL8J7ellfFBhpcHrBXj3uA=; b=LVPnmz6Y9HcU743wYSpatakB0SrOHFH0Iut3iwX1BwQS/yxLm5jKmjmsf9QeKm4Qxg lCs3W1r6FcIPtfW6W/f6/e7m9yrthcnnQVxcvxvW1QZ++AxfeIlhx4LeudLp5LtPVWYY qhTDLvIjQrO9cRqyLBu8kgg/54sPw9e29cZgnr4tqv5fN4x/zHF1bCmL1TR5OyKbQXgF flvhd5NjAopHlXDZ1iZQ35rtFgLMiomNyE/tuuk/vrZORwo138IzIglQIAfxOEThYvB9 cWQw3nOTGiFp8Ena3fAYrgRrPcaK5/kS2WkdBfQL3m9VLgh0UR9ydKuehVeM2jqZWKiD Altw== X-Gm-Message-State: AA6/9RnCxmGZafBuEW75C3k2lGt7q9672YXDsPDAVIbArxOdU9UC4+vIvuTnmi42woUVMPg4ImM/H7VTSNABQA== X-Received: by 10.200.36.202 with SMTP id t10mr30592500qtt.85.1476072748861; Sun, 09 Oct 2016 21:12:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.85.7 with HTTP; Sun, 9 Oct 2016 21:12:28 -0700 (PDT) From: Martin Thomson Date: Mon, 10 Oct 2016 15:12:28 +1100 Message-ID: To: IETF DANE Mailinglist Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [dane] UKS attacks on DANE X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Oct 2016 04:12:31 -0000 Richard, ekr and I have submitted a draft describing UKS attacks on certain DANE usages: https://datatracker.ietf.org/doc/draft-barnes-dane-uks/ The draft contains the details, but the short version is that usages 2 and 3 are potentially vulnerable to an unknown key share attack if the client fails to verify the identity of the server. Since Section 5.1 of RFC RFC 7671 explicitly states that client's should NOT verify the identity of the server in these cases. The draft describes how this attack can be used to circumvent cross-origin safeguards on the web. It also explains how to properly avoid the attack. As I understand it, email is believed to be unaffected since the mail security model explicitly permits UKS attacks (MX). Thanks to Karthik Bhargavan for pointing out this problem and in helping to analyze it. --Martin From nobody Sun Oct 9 21:35:25 2016 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 333EE129467 for ; Sun, 9 Oct 2016 21:35:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uQoiiRo0d2Nn for ; Sun, 9 Oct 2016 21:35:21 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B2A3129423 for ; Sun, 9 Oct 2016 21:35:20 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id C9ED7284E5A; Mon, 10 Oct 2016 04:35:19 +0000 (UTC) Date: Mon, 10 Oct 2016 04:35:19 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20161010043519.GS4670@mournblade.imrryr.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [dane] UKS attacks on DANE X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Oct 2016 04:35:23 -0000 On Mon, Oct 10, 2016 at 03:12:28PM +1100, Martin Thomson wrote: > Richard, ekr and I have submitted a draft describing UKS attacks on > certain DANE usages: > > https://datatracker.ietf.org/doc/draft-barnes-dane-uks/ > > The draft contains the details, but the short version is that usages 2 > and 3 are potentially vulnerable to an unknown key share attack if the > client fails to verify the identity of the server. Since Section 5.1 > of RFC RFC 7671 explicitly states that client's should NOT verify the > identity of the server in these cases. Thanks for the advance notice on this back in June. As a result, the DANE implementation in the OpenSSL 1.1.0 release by default enforces name checks for all DANE certificate usages. The documentation mentions that for specific applications, that are not at risk of cross-origin attacks, may disable name checks for DANE-EE(3), e.g. SMTP. For the record, in RFC7671, only DANE-EE(3) was in scope for skipping identity checks, no similar language is present for DANE-TA(2). Indeed RFC7671 clearly states that name checks are required for DANE-TA(2). https://tools.ietf.org/html/rfc7671#section-5.2 With usage DANE-TA(2), the server certificates will need to have names that match one of the client's reference identifiers (see [RFC6125]). When hosting multiple unrelated Customer Domains (that can't all appear in a single certificate), such a server SHOULD employ SNI to select the appropriate certificate to present to the client. https://tools.ietf.org/html/rfc7671#section-10.2 With the exception of TLSA certificate usage DANE-EE(3), where name checks are not applicable (see Section 5.1), DANE clients MUST verify that the client has reached the correct server by checking that the server name is listed in the server certificate's SAN or CN (when still supported). The primary server name used for this comparison MUST be the TLSA base domain; however, additional acceptable names may be specified by protocol-specific DANE standards. For example, with SMTP, both the destination domain name and the MX hostname are acceptable names to be found in the server certificate (see [RFC7672]). > As I understand it, email is believed to be unaffected since the mail > security model explicitly permits UKS attacks (MX). And I think the same analysis applies to XMPP as a result of SRV records, and lack of cross-origin exposure. https://www.openssl.org/docs/man1.1.0/ssl/SSL_CTX_dane_enable.html SSL_CTX_dane_set_flags() and SSL_dane_set_flags() can be used to enable optional DANE verification features. SSL_CTX_dane_clear_flags() and SSL_dane_clear_flags() can be used to disable the same features. The flags argument is a bitmask of the features to enable or disable. The flags set for an SSL_CTX context are copied to each SSL handle associated with that context at the time the handle is created. Subsequent changes in the context's flags have no effect on the flags set for the handle. At present, the only available option is DANE_FLAG_NO_DANE_EE_NAMECHECKS which can be used to disable server name checks when authenticating via DANE-EE(3) TLSA records. For some applications, primarily web browsers, it is not safe to disable name checks due to "unknown key share" attacks, in which a malicious server can convince a client that a connection to a victim server is instead a secure connection to the malicious server. The malicious server may then be able to violate cross-origin scripting restrictions. Thus, despite the text of RFC7671, name checks are by default enabled for DANE-EE(3) TLSA records, and can be disabled in applications where it is safe to do so. In particular, SMTP and XMPP clients should set this option as SRV and MX records already make it possible for a remote domain to redirect client connections to any server of its choice, and in any case SMTP and XMPP clients do not execute scripts downloaded from remote servers. -- Viktor. From nobody Sun Oct 9 21:42:09 2016 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70ADF129467 for ; Sun, 9 Oct 2016 21:42:08 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ghc8JIyyW5L6 for ; Sun, 9 Oct 2016 21:42:07 -0700 (PDT) Received: from mail-qt0-x230.google.com (mail-qt0-x230.google.com [IPv6:2607:f8b0:400d:c0d::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2914129423 for ; Sun, 9 Oct 2016 21:42:06 -0700 (PDT) Received: by mail-qt0-x230.google.com with SMTP id s49so44521256qta.0 for ; Sun, 09 Oct 2016 21:42:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=A8/kIFCzbBGhS4+XwR5VniSqGZ2B5oZaKnztex5GlZc=; b=ZheCOtNELUt+DWxbiaO5b/9CX+jeJIN6XpobQG5kTbrVhsSkeD+wIA0q8BbakUTSCW umE2h2gn4L8yNAWDOAplIvpcpxyloaiq5CnjdsxkMBccBanxT6mB31X+ase4zPh5ztVg VyHIek47NCpad712tuflOYDKfAzLAtAL1+De0X4Ds9Q2HtDoZEpaHZLVM09tdYnJaVPe TI25fY0GnnDZB0ybUKSERWJGpBgMgVV4pQswd04YI5EEYAmmBiaGybP9h5pzvxfeQBeH xYZgQ0wU9u/DUiHtHibtBe/Ra5KYM8cgjinazj6AQtvxRR+LuTq+kis95yGqGQX7vMVQ 7rMw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=A8/kIFCzbBGhS4+XwR5VniSqGZ2B5oZaKnztex5GlZc=; b=X0bS9xqZ5Z+IQTZd6KOJqYtJj8Oq7VyR5tJeptunh88EWpbYNheGnmAhCeHJcQdFpF zoqmnync/NPKtZYvXWx4HARHL0s2yhGctmn5t62dr9X3HvttXAg7EXgO7qOYKmOJl+UB anLIrIOzpY9/le+Gfzj9A0ck6y8nryPqnjnxK3D5Dyw3ELRX9UaZrBHpZZO0mzDhakE4 oO21ygnv6y+0uJPuPdiOAEeWSXyzMIkfljJDkCF//SHfyzLSy/aKJQtvNo9HTYoNfXD6 eKequcvLqIYe42sxIBnTyQ/wqQtoEkYxPpZuy6CCpBYBpIGtZxF91UF7cKld2YGs2TNM L9Vg== X-Gm-Message-State: AA6/9RnJkb4yTwKDsIkyCn3+t4zJaVmfjkga4pAvVYBke1Eba9FlM2FG2iSMGmYhKqozwbIr4pj0nXhKiB38gA== X-Received: by 10.200.36.202 with SMTP id t10mr30658838qtt.85.1476074525424; Sun, 09 Oct 2016 21:42:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.85.7 with HTTP; Sun, 9 Oct 2016 21:42:05 -0700 (PDT) In-Reply-To: <20161010043519.GS4670@mournblade.imrryr.org> References: <20161010043519.GS4670@mournblade.imrryr.org> From: Martin Thomson Date: Mon, 10 Oct 2016 15:42:05 +1100 Message-ID: To: IETF DANE Mailinglist Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [dane] UKS attacks on DANE X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Oct 2016 04:42:08 -0000 On 10 October 2016 at 15:35, Viktor Dukhovni wrote: > For the record, in RFC7671, only DANE-EE(3) was in scope for skipping > identity checks, no similar language is present for DANE-TA(2). This is correct. The draft goes into this in more detail, and is more correct than my short announcement writeup. Usage 2 is only a problem if implemented incorrectly (and we have no evidence that this is the case anywhere). From nobody Mon Oct 10 02:24:44 2016 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38AEE1294C6 for ; Mon, 10 Oct 2016 02:24:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.922 X-Spam-Level: X-Spam-Status: No, score=-6.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id niuqPYMSaYER for ; Mon, 10 Oct 2016 02:24:41 -0700 (PDT) Received: from smtpde01.smtp.sap-ag.de (smtpde01.smtp.sap-ag.de [155.56.68.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C3961294BE for ; Mon, 10 Oct 2016 02:24:41 -0700 (PDT) Received: from mail06.wdf.sap.corp (mail06.sap.corp [194.39.131.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde01.smtp.sap-ag.de (Postfix) with ESMTPS id 3ssvpZ6zVNz1HwM; Mon, 10 Oct 2016 11:24:38 +0200 (CEST) X-purgate-ID: 152705::1476091479-00002B31-02B58833/0/0 X-purgate-size: 661 X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate-type: clean X-SAP-SPAM-Status: clean Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail06.wdf.sap.corp (Postfix) with ESMTP id 3ssvpZ5T1vzkp7D; Mon, 10 Oct 2016 11:24:38 +0200 (CEST) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id B0A181A559; Mon, 10 Oct 2016 11:24:38 +0200 (CEST) In-Reply-To: To: Martin Thomson Date: Mon, 10 Oct 2016 11:24:38 +0200 (CEST) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20161010092438.B0A181A559@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: Cc: IETF DANE Mailinglist Subject: Re: [dane] UKS attacks on DANE X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: mrex@sap.com List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Oct 2016 09:24:43 -0000 Martin Thomson wrote: > Richard, ekr and I have submitted a draft describing UKS attacks on > certain DANE usages: > > https://datatracker.ietf.org/doc/draft-barnes-dane-uks/ > > The draft contains the details, but the short version is that usages 2 > and 3 are potentially vulnerable to an unknown key share attack if the > client fails to verify the identity of the server. Since Section 5.1 > of RFC RFC 7671 explicitly states that client's should NOT verify the > identity of the server in these cases. The description of the problem sounds vaguely familiar. https://www.ietf.org/mail-archive/web/dane/current/msg03737.html -Martin From nobody Tue Oct 11 03:11:58 2016 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 076861294C8 for ; Tue, 11 Oct 2016 03:11:57 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v0i91_fnf8CT for ; Tue, 11 Oct 2016 03:11:55 -0700 (PDT) Received: from mail-qk0-x22c.google.com (mail-qk0-x22c.google.com [IPv6:2607:f8b0:400d:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 26DD9129469 for ; Tue, 11 Oct 2016 03:11:55 -0700 (PDT) Received: by mail-qk0-x22c.google.com with SMTP id o68so24303479qkf.3 for ; Tue, 11 Oct 2016 03:11:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=zSYBbhbwM9riSeG5Z3OHXVWjEHbqrDqB914R9JM1iP4=; b=vF9Fw+HA1W5qoH3TprCcAQI/IrXrBKuCLTTv4MXzcwWqyavJv0G9KnV/TlcNfN7RsQ 0ByIK77qm7BaEKFf2PFi1OEXCN1uuE1ju39zq7CrnXmCYURfHxCKbC4/i/FWQ0NivHjV EZrSzimat3EBJxjCXXJPAv1DRhd3bPa7I1J2iKqqIOpnb47j6s3USyr1CBkfbxFafOG0 lCiI5C/Q9J/J3FH7WzMesd8c4USDqgz3N67Y9gAsTe+UUNt6L4hA6iPm4+0a9kr+iV5x b4XZJ87CPyan4VHgzHztvBH8b8tk+/QAj8NiobKGBaJoYnIr6xPUQpU5BMiaqwgAJ7yH p1rg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=zSYBbhbwM9riSeG5Z3OHXVWjEHbqrDqB914R9JM1iP4=; b=A7df415UsJinsBhrf6xMw6MnrOED6wZGbhYVFTU5fl8zZxYKYvirfdWhQD7Yrsi28u 04ahMuFpvVEK5IJWqdnVL5wKZKxcox9RJR276vPH3vXcZjE9JVHCNaBUwSNuHOj3fbPj G6NDRsw7xlSB6Br572ZNx3WG//amo2nNodqeyilpOeyMUHrdmg9PIKJi/gkuiTz4srBa S8wX/oiE+EUwTODUtvw5UxRiteWRml+m/fE7aLd3UGmQ0mCWxelWgdYVXqWEJOCYEbQd H691N/vL8j0ZBGtdy8QDssn2VhM6j38dKe6GrIpFfrhVcmobHH/Q6zMv5oI/miil75La VDqw== X-Gm-Message-State: AA6/9Rk+VKifKPEgu/ltmoPR1Tt0YfJlYUqJplKgf+YnCQNyrh73VuRJaO/hEfviKoDW/ThTm0LH+rUQ5w4/rw== X-Received: by 10.55.158.139 with SMTP id h133mr2874644qke.202.1476180714281; Tue, 11 Oct 2016 03:11:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.85.7 with HTTP; Tue, 11 Oct 2016 03:11:53 -0700 (PDT) In-Reply-To: <20161010092438.B0A181A559@ld9781.wdf.sap.corp> References: <20161010092438.B0A181A559@ld9781.wdf.sap.corp> From: Martin Thomson Date: Tue, 11 Oct 2016 21:11:53 +1100 Message-ID: To: "mrex@sap.com" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: IETF DANE Mailinglist Subject: Re: [dane] UKS attacks on DANE X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2016 10:11:57 -0000 On 10 October 2016 at 20:24, Martin Rex wrote: > The description of the problem sounds vaguely familiar. > > https://www.ietf.org/mail-archive/web/dane/current/msg03737.html If only they had listened eh? And they went ahead and published anyway. I didn't do a complete search of mailing list archives when writing this. Unsurprisingly, your concerns turned out to be well-founded. From nobody Tue Oct 11 07:03:40 2016 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD05C12954B for ; Tue, 11 Oct 2016 07:03:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G7SaNOcqQteP for ; Tue, 11 Oct 2016 07:03:36 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A06D129478 for ; Tue, 11 Oct 2016 07:03:36 -0700 (PDT) Received: from vpro.lan (cpe-74-71-8-253.nyc.res.rr.com [74.71.8.253]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id 02984284B0A for ; Tue, 11 Oct 2016 14:03:35 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Viktor Dukhovni In-Reply-To: Date: Tue, 11 Oct 2016 10:04:21 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <0B6AF381-7312-400F-B38B-78F16B48470A@dukhovni.org> References: <20161010092438.B0A181A559@ld9781.wdf.sap.corp> To: dane@ietf.org X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [dane] UKS attacks on DANE X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2016 14:03:39 -0000 > On Oct 11, 2016, at 6:11 AM, Martin Thomson = wrote: >=20 > On 10 October 2016 at 20:24, Martin Rex wrote: >> The description of the problem sounds vaguely familiar. >>=20 >> https://www.ietf.org/mail-archive/web/dane/current/msg03737.html >=20 > If only they had listened eh? And they went ahead and published = anyway. I am confused as to what "they went ahead anyway" this references. The linked message from 2011, was part of the discussion of RFC6698. RFC6698 makes no mention of eliding hostname checks. The UKS issue that is the subject of this thread pertains to RFC7671, work on which did not begin until May of 2013, and which was published in Oct 2015. > I didn't do a complete search of mailing list archives when writing > this. Unsurprisingly, your concerns turned out to be well-founded. Well, the UKS issue is rather narrowly applicable to special TLS applications in which cross-origin concerns apply. That's basically just browsers, and browsers are not doing DANE, and certainly not DANE-EE(3). No browsers support DANE at this time. One of the recommendations of RFC7671 is that in each DANE application a decision be made whether to support PKIX-TA(0)/PKIX-EE(1) or alternatively DANE-TA(2)/DANE-EE(3). One might expect DANE in browsers to only support the PKIX-?? TLSA variants... Also, as the draft notes, DNSSEC record discovery for DANE with HTTPS will likely be server-mediated (via TLS extensions), which entirely addresses the issue, since the TLSA record is then signed by the EE key. In any case, the suggested remediation in the UKS draft is too broad. It needlessly requires name checks across the board, even in applications where none UKS is not a concern. It consequently substantially limits the applicability of RFC7250 raw public keys. While I support the publication of the draft, I'd like to see the recommendations changed from MUST check names to SHOULD check names. Or, if you prefer, MUST unless UKS is not a concern. As I mentioned, OpenSSL 1.1.0 performs name checks for all DANE certificate usages by default, but provides a flag to disable them for usage DANE-EE(3). The documentation of the flag notes the UKS issue. --=20 --=20 Viktor. --=20 Viktor. From nobody Tue Oct 11 07:45:19 2016 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 728DF12955A for ; Tue, 11 Oct 2016 07:45:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.922 X-Spam-Level: X-Spam-Status: No, score=-6.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JZmhmsY35k9w for ; Tue, 11 Oct 2016 07:45:15 -0700 (PDT) Received: from smtpde01.smtp.sap-ag.de (smtpde01.smtp.sap-ag.de [155.56.68.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D80781295A1 for ; Tue, 11 Oct 2016 07:45:14 -0700 (PDT) Received: from mail06.wdf.sap.corp (mail06.sap.corp [194.39.131.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde01.smtp.sap-ag.de (Postfix) with ESMTPS id 3stft022KRz1Hr4 for ; Tue, 11 Oct 2016 16:45:12 +0200 (CEST) X-purgate-ID: 152705::1476197112-0000521C-F4C80A26/0/0 X-purgate-size: 922 X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate-type: clean X-SAP-SPAM-Status: clean Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail06.wdf.sap.corp (Postfix) with ESMTP id 3stft00NqDzkqgK for ; Tue, 11 Oct 2016 16:45:12 +0200 (CEST) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 01F391A55F; Tue, 11 Oct 2016 16:45:11 +0200 (CEST) In-Reply-To: <0B6AF381-7312-400F-B38B-78F16B48470A@dukhovni.org> To: dane@ietf.org Date: Tue, 11 Oct 2016 16:45:11 +0200 (CEST) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20161011144512.01F391A55F@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: Subject: Re: [dane] UKS attacks on DANE X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: mrex@sap.com List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2016 14:45:17 -0000 Viktor Dukhovni wrote: > > Well, the UKS issue is rather narrowly applicable to special TLS > applications in which cross-origin concerns apply. That's > basically just browsers, and browsers are not doing DANE, and > certainly not DANE-EE(3). I believe your concept is much to narrow. The issue affects *EVERY* TLS client that will in at least one usage scenario perform rfc2818 section 3.1 endpoint identification for a TLS server certificate issued from a public CA. Every such client, when adopting an alternative TLS server certificate validation through DANE, probably ought to check the end-entity certificate for appearance of the Certificate Policy with the OID 2.23.140.1.2.2 and for any TLS server certificate that carries this OID, enforce the rfc2818 section 3.1 endpoint identification for the hostname, no matter what kind of TLSA record/usage exists for that server. -Martin From nobody Tue Oct 11 08:18:56 2016 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C62D129610 for ; Tue, 11 Oct 2016 08:18:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NDADm6-dze4v for ; Tue, 11 Oct 2016 08:18:53 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3EEFC129602 for ; Tue, 11 Oct 2016 08:18:53 -0700 (PDT) Received: from vpro.lan (cpe-74-71-8-253.nyc.res.rr.com [74.71.8.253]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id B1A3C284B67 for ; Tue, 11 Oct 2016 15:18:50 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Viktor Dukhovni In-Reply-To: <20161011144512.01F391A55F@ld9781.wdf.sap.corp> Date: Tue, 11 Oct 2016 11:19:35 -0400 Content-Transfer-Encoding: 7bit Message-Id: <22430AD9-9662-4CB0-9CE2-E659435076FC@dukhovni.org> References: <20161011144512.01F391A55F@ld9781.wdf.sap.corp> To: dane@ietf.org X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [dane] UKS attacks on DANE X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2016 15:18:55 -0000 > On Oct 11, 2016, at 10:45 AM, Martin Rex wrote: > > Viktor Dukhovni wrote: >> >> Well, the UKS issue is rather narrowly applicable to special TLS >> applications in which cross-origin concerns apply. That's >> basically just browsers, and browsers are not doing DANE, and >> certainly not DANE-EE(3). > > I believe your concept is much to narrow. > > The issue affects *EVERY* TLS client that will in at least one usage > scenario perform rfc2818 section 3.1 endpoint identification for > a TLS server certificate issued from a public CA. I am not going to quibble over which HTTPS use-case are in scope. The relevant application-specific decisions can and will be made. > Every such client, when adopting an alternative TLS server certificate > validation through DANE, probably ought to check the end-entity certificate > for appearance of the Certificate Policy with the OID 2.23.140.1.2.2 > and for any TLS server certificate that carries this OID, enforce > the rfc2818 section 3.1 endpoint identification for the hostname, > no matter what kind of TLSA record/usage exists for that server. Likely not all HTTPS use-cases are beholden to the policies of the CA/B Forum. One thing I should point out, that the authors of the UKS draft may not have noticed, is that RFC7671 not only says that name checks are optional for DANE-EE(3), but also specifies that DANE clients accept certificate hostnames derived from DNSSEC-validated CNAME records, when the TLSA records are associated with the target of the CNAME. Thus, given DNSSEC-validated records as below: www.impostor.example. IN CNAME www.victim.example. www.victim.example. IN A 192.0.2.1 _443._tcp.www.victim.example. IN TLSA ... a client would accept a certificate for "www.victim.example" when establishing a DANE-authenticated connection to www.impostor.example". This is probably an issue for browsers in the same way as directly binding the EE key of "www.victim.example" at "_443._tcp.impostor.example. IN TLSA ?". So likely the same applications that SHOULD perform name checks for all certificate usages, SHOULD also not include expanded CNAMEs in the set of reference identifiers acceptable from the server or use such expansions in SNI. By which point, in such applications, it probably makes no sense to look for TLSA records at the CNAME target. -- -- Viktor. From nobody Tue Oct 11 12:22:09 2016 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04DEC12957E for ; Tue, 11 Oct 2016 12:22:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uBqscZLvLago for ; Tue, 11 Oct 2016 12:22:05 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5637129400 for ; Tue, 11 Oct 2016 12:22:05 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id CBE77284E5B; Tue, 11 Oct 2016 19:22:04 +0000 (UTC) Date: Tue, 11 Oct 2016 19:22:04 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20161011192204.GV4670@mournblade.imrryr.org> References: <20160826013552.GR4670@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160826013552.GR4670@mournblade.imrryr.org> User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [dane] Nudge DANE SMTP adoption at DNSSEC-signed MX hosting providers X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2016 19:22:08 -0000 On Fri, Aug 26, 2016 at 01:35:52AM +0000, Viktor Dukhovni wrote: > Many domain hosting providers that also host the email for the > customer domains. For a bunch of these providers the MX hosts are > in a DNSSEC-signed zone, and a non-trivial number of customer MX > RRsets are also in signed zones. Consequently, they can easily > enable DANE SMTP for all the domains in question, just by publishing > a small set of TLSA records. > > I've reached out to a couple of the providers with the largest > count of DNSSEC-signed customer domains, but don't have the cycles > to reach out to the rest. Two of the MX providers from the original "nudge" list are now live: domeneshop.no -- ~42000 domains uvt.nl -- ~290 domains The first hosts domains for paying customers, the second hosts a handful of their own domains. The total number of domains with TLSA records for SMTP is now greater than 102,000. These are served by ~2200 MX hosts (distinct DANE-validated server certificates). The number of DANE-validated domains that have appeared in Google's email transparency report (which it seems exludes domains that don't send a sufficiently high volume of email) was 24 when I reported that number at M3AAWG last October, it is now 81. Of these 43 appear in today's (not just some past) report: gmx.at mail.de otvi.nl conjur.com.br posteo.de overheid.nl nic.br ruhr-uni-bochum.de xs4all.nl registro.br tum.de domeneshop.no gmx.ch uni-erlangen.de webcruitermail.no open.ch web.de debian.org gmx.com octopuce.fr freebsd.org mail.com comcast.net gentoo.org xfinity.com dd24.net ietf.org bund.de gmx.net netbsd.org fau.de hr-manager.net openssl.org gmx.de t-2.net samba.org jpberlin.de xs4all.net torproject.org kabelmail.de asp4all.nl lrz.de bhosted.nl Which leaves the below for ongoing nudging: protonmail.ch 1024degres.com gransy.com intility.com networking4all.com procolix.com senta.com shoptrader.com tornado-mail.com aerohosting.cz banan.cz dc3.cz globe.cz ignum.cz onebit.cz seolight.cz smtp.cz webcloud.cz hosting.eu mail-scanner.eu mailplatform.eu anonymail.hu dns1.hu integrity.hu microware.hu webtar.hu servicios-nic.com.mx netvibeshosting.net networking4all.net ubm-us.net 2is.nl argewebhosting.nl atention.nl bit.nl box.nl datacon.nl flexfilter.nl greenhost.nl hostingdiscounter.nl hostplan.nl iaf.nl is.nl jouwweb.nl mach3builders.nl openprovider.nl pcextreme.nl prolocation.nl spamservice.nl swathosting.nl webguru.nl fastname.no uniweb.no entos.se paranormal.se ine.co.th -- Viktor. From nobody Tue Oct 11 17:31:51 2016 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60F701295C4 for ; Tue, 11 Oct 2016 17:31:50 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mOTPFE3OyYyg for ; Tue, 11 Oct 2016 17:31:48 -0700 (PDT) Received: from mail-qk0-x22e.google.com (mail-qk0-x22e.google.com [IPv6:2607:f8b0:400d:c09::22e]) (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 A9DFF129416 for ; Tue, 11 Oct 2016 17:31:48 -0700 (PDT) Received: by mail-qk0-x22e.google.com with SMTP id o68so57510307qkf.3 for ; Tue, 11 Oct 2016 17:31:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=XJII4nqrRgWnMD3ePkHrSczym6Odmid1VzpqrxH6Az0=; b=YtbcuC21o3Z+ucx8vNRO2yBgaM9TXsMDxXMqBNw1SEDV/Im/+dmPLy46bQtuax30NI dfdiKJH+iOA7TAwX1DV/9DrtM5w8zymUkPSqPt6ZmfKRQSHKqmodVZ8EwBHxQsltJjq2 4vNwFD0ZH81Xwfp3kKoL9nU5+y3bFJpk0HteKVr8HD0V+gTZTc4GypNoWeeFVm6KRvd9 dODgcTLyhGMC2rtKSzkQw9WBdwJei5+JS5IJzLm/1pHKhUWmNN/yPrTl6a3Ajcp+HTyz XnYv2cU4xmYtMOw/RPjIQ2DEtOl9nfCubDRTegJi5l29qSGiXfGvfwDnBwyiDMx53uNb ewhg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=XJII4nqrRgWnMD3ePkHrSczym6Odmid1VzpqrxH6Az0=; b=kb3EVunTRR7NYF+9VZd0lq9vCCBIqLIAkuYS0de0VgeGoNMLw9y6kmoeJqIjoOcR3V 3P9AdT33YF1DBaWIfWgrQrI/9Z2zBEs+GNR0duilE4KPtTLRXp6QvyWZCxWcIEd82D6F Agpx7/yXoqDoDhIur7l86+06vjJbWfusbFb32AweKhRV45uEq9xvY/GMLJW34IZqmb9m iN9ydZfagE0id1YkBBx1rs6uN77PmQWsemhuvL2deE6CoISjLgfhft5x/NFkUH2hgKko QLL8d7x3xHPpjSWQmpgJ91kUxK2dP3U1ulLLkzn1UHciSodp6ZyvWVHl76Gn7rlxFDkE K/WQ== X-Gm-Message-State: AA6/9RnFvSEfg/o4SL7pjwK9Jrka8uRkBTT4bfxFjTNvKu+wci+Q8KenWAsHecs8Y1Ji4huCEfvrHD/4Dw4MYw== X-Received: by 10.55.163.214 with SMTP id m205mr5746812qke.68.1476232307838; Tue, 11 Oct 2016 17:31:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.85.7 with HTTP; Tue, 11 Oct 2016 17:31:47 -0700 (PDT) In-Reply-To: <20161011144512.01F391A55F@ld9781.wdf.sap.corp> References: <0B6AF381-7312-400F-B38B-78F16B48470A@dukhovni.org> <20161011144512.01F391A55F@ld9781.wdf.sap.corp> From: Martin Thomson Date: Wed, 12 Oct 2016 11:31:47 +1100 Message-ID: To: "mrex@sap.com" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: IETF DANE Mailinglist Subject: Re: [dane] UKS attacks on DANE X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2016 00:31:50 -0000 On 12 October 2016 at 01:45, Martin Rex wrote: >> Well, the UKS issue is rather narrowly applicable to special TLS >> applications in which cross-origin concerns apply. That's >> basically just browsers, and browsers are not doing DANE, and >> certainly not DANE-EE(3). > > I believe your concept is much to narrow. I tend to agree, though that hinges on your definition of "cross-origin". In the web world, that has a very specific meaning. What you could say that "if the client doesn't care who it is talking to, or it has some secondary means of validating the identity of a server, then this isn't a concern". In the mail case, I continue to be astonished that this isn't a material problem, but I guess that there really must be these secondary mechanisms. From nobody Tue Oct 11 19:54:09 2016 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06E9B12953E for ; Tue, 11 Oct 2016 19:54:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id br9ZQ4uObKcI for ; Tue, 11 Oct 2016 19:54:07 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 58350129436 for ; Tue, 11 Oct 2016 19:54:07 -0700 (PDT) Received: from [172.31.24.203] (gzac12-mdf2-1.aoa.twosigma.com [208.77.215.155]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id 1A294284B67 for ; Wed, 12 Oct 2016 02:54:06 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Viktor Dukhovni In-Reply-To: Date: Tue, 11 Oct 2016 22:54:52 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <52A68D3C-434C-4047-9C16-C7A5DB277301@dukhovni.org> References: <0B6AF381-7312-400F-B38B-78F16B48470A@dukhovni.org> <20161011144512.01F391A55F@ld9781.wdf.sap.corp> To: IETF DANE Mailinglist X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [dane] UKS attacks on DANE X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: IETF DANE Mailinglist List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2016 02:54:09 -0000 > On Oct 11, 2016, at 8:31 PM, Martin Thomson = wrote: >=20 >> I believe your concept is much to narrow. >=20 > I tend to agree, though that hinges on your definition of > "cross-origin". In the web world, that has a very specific meaning. > What you could say that "if the client doesn't care who it is talking > to, or it has some secondary means of validating the identity of a > server, then this isn't a concern". No, it is not "don't care". It is rather that it is quite sufficient to know that mail is being delivered to whichever server the next-hop domain designates as its mailhost. If some domain wants to publish (DNSSEC-signed) records: example.com. MX 0 mail.ietf.org. or _xmpp-server._tcp.example.com. SRV 0 100 5222 jabber.ietf.org. to the effect that its email or XMPP servers are running on some outsourced host, it is free to do so. The target host may not offer the service, and may turn away clients trying to send email or instant messages to user@example.com, but there is no security impact on either the client or ietf.org beyond any extra load. And of course extra load be imposed much more effectively by other means. > In the mail case, I continue to be astonished that this isn't a > material problem, but I guess that there really must be these > secondary mechanisms. No secondary mechanisms are present or needed. The issue is simply moot. The attacker gains no advantage by redirecting his own domain's SMTP, XMPP, ... traffic to an unwitting target server. What's odd is not that SMTP and XMPP are immune, but rather the astonishing subtlety of the Web security model, which makes web applications vulnerable. --=20 Viktor.= From nobody Wed Oct 12 01:29:52 2016 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E7FB1294B3 for ; Wed, 12 Oct 2016 01:29:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.896 X-Spam-Level: X-Spam-Status: No, score=-4.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-2.996] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nqfqWm8ccrzJ for ; Wed, 12 Oct 2016 01:29:48 -0700 (PDT) Received: from welho-filter2.welho.com (welho-filter2.welho.com [83.102.41.24]) by ietfa.amsl.com (Postfix) with ESMTP id 162E912948A for ; Wed, 12 Oct 2016 01:29:47 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter2.welho.com (Postfix) with ESMTP id D7F2E13CCD for ; Wed, 12 Oct 2016 11:29:46 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp2.welho.com ([IPv6:::ffff:83.102.41.85]) by localhost (welho-filter2.welho.com [::ffff:83.102.41.24]) (amavisd-new, port 10024) with ESMTP id tUiwq3jEdTwv for ; Wed, 12 Oct 2016 11:29:46 +0300 (EEST) Received: from LK-Perkele-V2 (87-100-237-87.bb.dnainternet.fi [87.100.237.87]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id 97DF921C for ; Wed, 12 Oct 2016 11:29:46 +0300 (EEST) Date: Wed, 12 Oct 2016 11:29:40 +0300 From: Ilari Liusvaara To: IETF DANE Mailinglist Message-ID: <20161012082940.GC16436@LK-Perkele-V2.elisa-laajakaista.fi> References: <0B6AF381-7312-400F-B38B-78F16B48470A@dukhovni.org> <20161011144512.01F391A55F@ld9781.wdf.sap.corp> <52A68D3C-434C-4047-9C16-C7A5DB277301@dukhovni.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <52A68D3C-434C-4047-9C16-C7A5DB277301@dukhovni.org> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [dane] UKS attacks on DANE X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2016 08:29:50 -0000 On Tue, Oct 11, 2016 at 10:54:52PM -0400, Viktor Dukhovni wrote: > > What's odd is not that SMTP and XMPP are immune, but rather > the astonishing subtlety of the Web security model, which > makes web applications vulnerable. It is combination of HTTP servers being pretty widely misconfig'd in a manner that results in bogus responses to requests (pretty much nobody has similarly misconfig'd SMTP server (as it would be a major problem in other ways), and AFAICT XMPP servers can't even configured that way), combined with the very brittle nature of the same-origin policy. -Ilari From nobody Thu Oct 13 17:15:22 2016 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B43A129458 for ; Thu, 13 Oct 2016 17:15:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.073 X-Spam-Level: X-Spam-Status: No, score=-3.073 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_BRBL_LASTEXT=1.449, RCVD_IN_XBL=0.375, RP_MATCHES_RCVD=-2.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Izg1CBWPgzPK for ; Thu, 13 Oct 2016 17:15:17 -0700 (PDT) Received: from new.toad.com (new.toad.com [209.237.225.253]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (112/168 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2E84127A90 for ; Thu, 13 Oct 2016 17:15:17 -0700 (PDT) Received: from new.toad.com (localhost.localdomain [127.0.0.1]) by new.toad.com (8.12.9/8.12.9) with ESMTP id u9E0FDY9032675; Thu, 13 Oct 2016 17:15:13 -0700 Message-Id: <201610140015.u9E0FDY9032675@new.toad.com> To: Martin Thomson In-reply-to: References: Comments: In-reply-to Martin Thomson message dated "Mon, 10 Oct 2016 15:12:28 +1100." Date: Thu, 13 Oct 2016 17:15:13 -0700 From: John Gilmore Archived-At: Cc: IETF DANE Mailinglist Subject: Re: [dane] UKS attacks on DANE X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2016 00:15:20 -0000 I'm a bit puzzled by this "UKS" (Unknown Key Share) attack concept. The attack scenario, presented in section 2 of https://www.ietf.org/id/draft-barnes-dane-uks-00.txt is that a user connects to the "attacker" site (say google.com) but actually google.com has published Facebook.com's public key and is a man-in-the-middle (MITM) forwarding all the traffic to facebook.com. Now this MITM can't actually read or modify any of the traffic, they are just a passive conduit. The most they can see is the timing of the traffic and the number of bytes involved. The user sees Facebook's site, secured with Facebook's key, even though they connected to google.com. (How or why the user was somehow convinced to connect to google.com while seeking facebook.com is unexplained.) So the threat is... uh... ? ... something about some cross-origin scripting firewall policy elsewhere in the system? Why do we care? John From nobody Thu Oct 13 18:05:05 2016 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5481C129440 for ; Thu, 13 Oct 2016 18:05:04 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6N-ZEaDphMZ8 for ; Thu, 13 Oct 2016 18:05:02 -0700 (PDT) Received: from mail-qt0-x235.google.com (mail-qt0-x235.google.com [IPv6:2607:f8b0:400d:c0d::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 42FEE120726 for ; Thu, 13 Oct 2016 18:05:02 -0700 (PDT) Received: by mail-qt0-x235.google.com with SMTP id f6so65392924qtd.2 for ; Thu, 13 Oct 2016 18:05:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=12XKsOmiXZSJ+42nJndcd5GcPp79fSpyjO3MGuq9isY=; b=MaIbXDyfl6DjMyEEgBp7OFRIUGBshjbBsrUARKuqrxCpbWCFRurE09iwq8xX2jMNYv jGHECybsOqMbGko6Wx8PcybVwEVASjw0lhER4msb1oVw+Bfk8sTCmabg4Yz2aL5iufI8 yZlu/mqYSjKT/1PQLHaF2AwealwGLiT703hw+43wkCPre9IWAyTMaTozRJtPweYu78a/ 6QSVPS1YxxC2xJnTxrsPYnqTCXgjw9MLBUDT5Y1H8YhkU1KBzWnVivEysZLHCVEV1mLj nV39XekmMbc1E/m/ssslMVpp0snj0dRHEU5YO1j8gsNvm3eo7tGIn47BRiM8P9u4ryjw 2v+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=12XKsOmiXZSJ+42nJndcd5GcPp79fSpyjO3MGuq9isY=; b=UAbVrmYgCISCiHCafq2R3k6ZF9e+DAkbwvVNLC7/tyCRBs6ejSMwDX1V8/JldWTBDP y9cT9zkAo0oKrPWvnYSFehdaRYyakyELCraTYicoU9VVSxiE1PSULKLJZkRMeffZUGgE InJJKiT84EXwGuZ8tS47dKt8h1ByNt0DIwfPQtk2DRte3VSolkcHbXfrtmBV5ArCfqux rb3L51/GWwRzGhk4OCF7Bt9YQlPZBHxfJH+vVr56E3Kl0xuZa8tR+4CPfxd41qxoUeDb oIGlg4G6nJv/H/HYC41YcYKZBpsumEkCy+NSHi60LNYTfreIrczwF9Q0Oh04wAdj0efw 4wwA== X-Gm-Message-State: AA6/9RmLxosbLvh06kvZxlcbjVtdiebGgkYndoHksxjDu2Lti3JtfEBkRxjdOHqsU1opZYdeg65ZSSE2+w8MMw== X-Received: by 10.200.34.66 with SMTP id p2mr10002153qtp.107.1476407101329; Thu, 13 Oct 2016 18:05:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.85.7 with HTTP; Thu, 13 Oct 2016 18:05:00 -0700 (PDT) In-Reply-To: <201610140015.u9E0FDY9032675@new.toad.com> References: <201610140015.u9E0FDY9032675@new.toad.com> From: Martin Thomson Date: Fri, 14 Oct 2016 12:05:00 +1100 Message-ID: To: John Gilmore Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: IETF DANE Mailinglist Subject: Re: [dane] UKS attacks on DANE X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2016 01:05:04 -0000 The draft explains this in more detail. To use your example, there is now confusion over the identity of the server. The client thinks that they have connected to google.com, when in fact they have connected to facebook.com. That's where the attacks start. Requests made to facebook.com over that connection will be treated as *same-origin* to google.com. That violates the SOP and could allow google.com to read confidential data from facebook.com. On 14 October 2016 at 11:15, John Gilmore wrote: > I'm a bit puzzled by this "UKS" (Unknown Key Share) attack concept. > > The attack scenario, presented in section 2 of > > https://www.ietf.org/id/draft-barnes-dane-uks-00.txt > > is that a user connects to the "attacker" site (say google.com) but > actually google.com has published Facebook.com's public key and is a > man-in-the-middle (MITM) forwarding all the traffic to facebook.com. > > Now this MITM can't actually read or modify any of the traffic, they > are just a passive conduit. The most they can see is the timing of > the traffic and the number of bytes involved. The user sees > Facebook's site, secured with Facebook's key, even though they > connected to google.com. (How or why the user was somehow convinced > to connect to google.com while seeking facebook.com is unexplained.) > > So the threat is... uh... ? > > ... something about some cross-origin scripting firewall policy > elsewhere in the system? > > Why do we care? > > John