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.