Re: [DNSOP] New Version Notification for draft-rebs-dnsop-svcb-dane-00.txt
Viktor Dukhovni <ietf-dane@dukhovni.org> Sun, 12 December 2021 04:27 UTC
Return-Path: <ietf-dane@dukhovni.org>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9A143A0863 for <dnsop@ietfa.amsl.com>; Sat, 11 Dec 2021 20:27:30 -0800 (PST)
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, SPF_HELO_NONE=0.001, 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 LnJ7hJrM-Rqe for <dnsop@ietfa.amsl.com>; Sat, 11 Dec 2021 20:27:26 -0800 (PST)
Received: from straasha.imrryr.org (straasha.imrryr.org [100.2.39.101]) (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 A00423A085E for <dnsop@ietf.org>; Sat, 11 Dec 2021 20:27:26 -0800 (PST)
Received: by straasha.imrryr.org (Postfix, from userid 1001) id A0F89F41BC; Sat, 11 Dec 2021 23:27:24 -0500 (EST)
Date: Sat, 11 Dec 2021 23:27:24 -0500
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: dnsop@ietf.org
Message-ID: <YbV6LCozgx3GhGE7@straasha.imrryr.org>
Reply-To: dnsop@ietf.org
References: <163908832760.8339.4135304026578566025@ietfa.amsl.com> <CAHbrMsCbN8+2UCQLCYKvp5RZ_v+srMha5xU25A9Q9F=ASna9xA@mail.gmail.com> <F9919030-4B37-42DE-BE7B-73BAAFDC5433@dukhovni.org> <m1mw0U9-0000IMC@stereo.hq.phicoh.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <m1mw0U9-0000IMC@stereo.hq.phicoh.net>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/e_-R7RGdJV9drEdIpy5q348a7Z0>
Subject: Re: [DNSOP] New Version Notification for draft-rebs-dnsop-svcb-dane-00.txt
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 12 Dec 2021 04:27:31 -0000
On Sat, Dec 11, 2021 at 12:24:13PM +0100, Philip Homburg wrote: > > https://datatracker.ietf.org/doc/html/draft-barnes-dane-uks-00 > > > > Thus, unless "UKS" is known to not be a concern, applications > > should also validate the target name against the server > > certificate even with DANE-EE(3). > > There is something I don't understand about this draft. The main thing to understand is that complex applications like browsers allow data retrieved from one endpoint to script interaction with a *different* endpoint, and possibly see the retrieved content, subject to various CORS (Cross-origin resource sharing) controls. If the client uses the same (client) certificate to identify itself to both the attacker and victim servers, then if it believes that the victim server is the same origin as the attacker's server, it may allow cross-origin requests between them. > Suppose an attacker creates attack[1-3].example.com with 3 different setups: > > 1) attack1.example.com has a regular PKI cert and the attacker runs a > reverse proxy there that relays traffic to victim.example.com This does not achieve client cert authentication to victim server. > 2) attack2.example.com has a self signed cert and DANE with both > attack2.example.com and victim.example.com in the DNS names of the cert. > Again the attacker has a reverse proxy and relays to victim.example.com This does not achieve client cert authentication to victim server. > 3) attack3.example.com has a DANE record that refers to the cert of > victim.example.com. There the attacker directly relays traffic to > victim.example.com. This does would achieve client cert authentication to victim server, if the client does not perform certificate name checks. > In my experience, a hard part of PKI certs is to make sure that every name > that can be used to reach the cert is infact listed in the certificate. > It would be way better if for DANE, no name checks are done at all. For applications other than browsers, sure. Browsers go out of their to run code served by the remote server, and then try to make that somehow safe. It's a miracle they sometimes succeed. -- Viktor.
- [DNSOP] Fwd: New Version Notification for draft-r… Ben Schwartz
- Re: [DNSOP] New Version Notification for draft-re… Viktor Dukhovni
- Re: [DNSOP] New Version Notification for draft-re… Philip Homburg
- Re: [DNSOP] New Version Notification for draft-re… Viktor Dukhovni
- Re: [DNSOP] New Version Notification for draft-re… Philip Homburg
- Re: [DNSOP] New Version Notification for draft-re… Viktor Dukhovni
- Re: [DNSOP] New Version Notification for draft-re… Ben Schwartz
- Re: [DNSOP] New Version Notification for draft-re… Viktor Dukhovni
- Re: [DNSOP] [Ext] New Version Notification for dr… Paul Hoffman
- Re: [DNSOP] [Ext] New Version Notification for dr… Paul Wouters
- Re: [DNSOP] New Version Notification for draft-re… Ben Schwartz
- Re: [DNSOP] New Version Notification for draft-re… Viktor Dukhovni