Re: [DNSOP] New Version Notification for draft-rebs-dnsop-svcb-dane-00.txt

Ben Schwartz <bemasc@google.com> Wed, 22 December 2021 20:52 UTC

Return-Path: <bemasc@google.com>
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 269703A0C0A for <dnsop@ietfa.amsl.com>; Wed, 22 Dec 2021 12:52:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.599
X-Spam-Level:
X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] 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 WIqM6mxaVGgF for <dnsop@ietfa.amsl.com>; Wed, 22 Dec 2021 12:52:36 -0800 (PST)
Received: from mail-ua1-x92c.google.com (mail-ua1-x92c.google.com [IPv6:2607:f8b0:4864:20::92c]) (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 82A6F3A0C09 for <dnsop@ietf.org>; Wed, 22 Dec 2021 12:52:36 -0800 (PST)
Received: by mail-ua1-x92c.google.com with SMTP id i6so6342167uae.6 for <dnsop@ietf.org>; Wed, 22 Dec 2021 12:52:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=L8Xc4wSPEU1V/DFhUWAPuSZ6aPVnv4V/L8/EKWOhr2Q=; b=N6If8XhOps4PwNZ0heBMW9cwW1OnTHUmkWOoWrFaA5jTAyjbyJvhhjb5imbz8O2648 W2SOtdZLHTWlkFOYh8wFW3BafPy0d07U0r1J2KXFm1okUuPloH4VQoXwWvC/WAuhTM8S lg+ChFtj34tKXX49QhjjD110mevu9jCW/qbI/2N47fW+EHOW6aF2bauXedeFgJIgk+d7 Qp/hdUjTrYFm80z7xoLIxzedbAIaf7f4QMBL1nobywI6aaWZCVVcipZ4y3ODsPrbYb2x IXfaRIhRyQouy/wb6ajJDHEAob5UWbdZ5YJMVRrSv/XdSariyOkbnAVpXx1/AhqymAo8 6MJA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=L8Xc4wSPEU1V/DFhUWAPuSZ6aPVnv4V/L8/EKWOhr2Q=; b=4zjV6dQ+i+PwPilyRdpvNdpxsB7LzFb8ZBqorec9GxPlTfzWRSQ4f4VoWpS/WLc600 RU1UeaoOEau9pgz7HzbeINjtRdcoyHazAYAlhOk8nPjpb4Y6RPsMLVfzA1oJP8GZF/1O cNu7deRSnkHa28lNu8aeSiN6dYRHFv1xsNBia8KWcxl3LmzE3ujrgcGCY/ohV16eqOzS 6j2um6adiRDJ2UbOX1vQKSCpmzCtcIBh4SxnLqJVMleiFZrwGb4pUvvTXo3/Dk8OT6dt tXJeUYE5GFC2rkPBONCPwzvQYNEvllId2I0n9TJhktKbZNlzeOGosbonfObQFFF9RJrX yEhQ==
X-Gm-Message-State: AOAM531evfT7MzLtsglddv9rFhaMDY+b6aiGqDD/9OLOrryA16nVMGja bQpM/0j11Kqvbzth3y/hjlgt1Kdf9pAEHw4EyZ2dPzsBggY0cA==
X-Google-Smtp-Source: ABdhPJx88fCRTiD1Vz2mXPOYlP4nWrXlWIvqCaJCDKfpPWvR8aTtwwNXGLwYufyUEnN9iGIO2shQPptFBxywaBAR9Rc=
X-Received: by 2002:ab0:20ad:: with SMTP id y13mr1562510ual.15.1640206353751; Wed, 22 Dec 2021 12:52:33 -0800 (PST)
MIME-Version: 1.0
References: <163908832760.8339.4135304026578566025@ietfa.amsl.com> <CAHbrMsCbN8+2UCQLCYKvp5RZ_v+srMha5xU25A9Q9F=ASna9xA@mail.gmail.com> <F9919030-4B37-42DE-BE7B-73BAAFDC5433@dukhovni.org> <CAHbrMsDT5-u6n1tJnSjd9X1vMyyp5HcNrvL4NB3Quzi_p5nWfQ@mail.gmail.com> <YbeZyhZXAuLT250e@straasha.imrryr.org>
In-Reply-To: <YbeZyhZXAuLT250e@straasha.imrryr.org>
From: Ben Schwartz <bemasc@google.com>
Date: Wed, 22 Dec 2021 15:52:22 -0500
Message-ID: <CAHbrMsATmtSapSWL4Ocr3F50x2xaLSmsi_XyAHHPRTUzrtnrVg@mail.gmail.com>
To: dnsop <dnsop@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000013628205d3c24dc6"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/ikTilxpTOVQQ32Vx4dk2nndO94Y>
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: Wed, 22 Dec 2021 20:52:42 -0000

On Mon, Dec 13, 2021 at 2:07 PM Viktor Dukhovni <ietf-dane@dukhovni.org>
wrote:

> On Mon, Dec 13, 2021 at 10:04:55AM -0500, Ben Schwartz wrote:
>
> > >
> > > 1.  While DANE certificate validation as described in RFCs 7671,7672
> and 7673
> > >     is fine in SMTP, IMAP, XMPP, ... for HTTP (and perhaps some other
> applications)
> > >     skipping validation of the target name with DANE-EE(3) records
> introduces a "UKS"
> > >     (i.e. "Unknown Key Share") issue, that would definitely be a
> concern for "h3".
> > >
> > >     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).
> > >
> >
> > This is interesting, but I think it's orthogonal.  That vulnerability
> > analysis applies equally before and after this draft.
>
> Correct, but since draft post-dates the UKS I-D, it is worth keepin the
> latter in mind.  And an update to 767[123] may be warranted (based on
> the "UKS" I-D).
>

I don't want this draft to become an omnibus update to RFC 7671.  My goal
is to produce a short draft that is basically parallel to RFC 7673.

If you want to pursue a broader revamp of DANE, I think that could be
valuable, but I don't think it needs to be connected to this.

> I'd be happy to add a reference to draft-barnes-dane-uks to the text, but
> > since that draft expired several years ago, I think we would need a new
> or
> > updated draft first.
>
> Likely so, or it can be incorporated into a separate update document, if
> that's deemed more efficient.  With DANE working group no longer around,
> would "dnsop" be an appropriate home for such work?
>

I'm not a relevant chair, but perhaps the DANISH charter could be expanded
to include "any corrections and deprecations needed to simplify correct
usage of DANE".  After all, DANISH clients would likely also be DANE
clients, and overcomplicated client logic would be unwelcome in an IoT
context.


> So this is different from the situation with MX (and IIRC SRV) records,
> so perhaps CNAMEs will be much more common in this context?


I think it's too early to predict the popular deployment strategies here.
Also, SVCB + TLSA is "green field" territory, so it's up to us what we want
to allow.

> There are also some nontrivial privacy implications due to the effect
> > on SNI.
>
> Can you be more explicit about this?  Which is the better privacy
> outcome, using the initial or expanded name in SNI?


Generally the expanded name, as it is likely to reveal less information
(when combined with the destination IP address, which is necessarily
public).  However, in practice the TargetName is expected to already be
generic, and CNAME-after-SVCB should be rare, so this is likely not a major
issue when SVCB is actually in use.  It's more relevant in the case of
fallback to non-SVCB connection.


>   The SNI name is
> IIRC encrypted in TLS 1.3, so perhaps this is not a long-term issue?
>

TLS 1.3 doesn't encrypt the SNI by itself.  TLS 1.3 "Encrypted ClientHello"
(now in interop testing) does, but it is not final, and is far from trivial
to deploy.


> > > 4.  If there are opportunistic applications in scope for this draft,
> they may
> > >     want to follow the advice of 7672 to only check for TLSA records
> if the
> > >     target zone is determined to be signed after first performing the
> IP (v4/v6)
> > >     address lookup.
> >
> > This doesn't seem like a very good optimization.  For optimal latency,
> the
> > client would issue any queries as soon as it can.
>
> It is very much *NOT* an optimisation.  Rather it is an essential
> element of robustness of the protocol in the face of the reality
> of the DNS ecosystem:
>
>     - For DANE to be useful it must not be trivially subject to
>       downgrade by not responding to TLSA records, returning REFUSED,
>       NOTIMP, SERFVAIL or bogus replies.
>
>     - However, many unsigned zones are served by functionally limited
>       to mostly-broken load-balancers that just know how to return
>       A/AAAA records and not much else.
>
>     - When you send a TLSA query to such a nameserver, you often end
>       up with a lookup failure, rather than a valid "insecure" denial
>       of existence (proof of an insecure delegation at some parent
>       node + insecure NODATA or NXDOMAIN).
>
>     - For DANE to avoid downgrades, TLSA query SERVFAIL needs to lead
>       to connection failure.
>
> This is why the "optimisation" in question is in fact an essential
> element of 7671.
>

If it's an essential element of 7671, maybe it should be mentioned in 7671!

I think this is an interesting workaround, but I'm not sure it will be
necessary here.  SVCB is to a large extent a "green field" territory, which
may exclude a lot of buggy legacy systems.  Also, SVCB specifically renders
this kind of misbehavior into a hard-fail condition already [1], and
large-scale experiments have confirmed that this does not result in a
significant error rate.

[1]
https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-svcb-https-08#section-3.1

I should also mention that "opportunistic" here is a much broader class
> of applications that one might think.  It covers applications that
> strictly perform peer authentication, but whose use of DANE is "when
> published", rather than as an exclusive authentication mechanism.
>
> So any application that has a fallback to some other way of establishing
> trust when the peer does not have TLSA records is one where the above is
> applicable.  This is perhaps something we should discuss off-list on a
> voice call to make sure we're on the same page...
>
> > > Therefore, if HTTPS/SVCB targets are allowed to be aliased, the
> > > client would have to issue an explicit "CNAME query" in the address
> > > lookup comes back as an "insecure" answer via CNAME/DNAME expansion.
> > > This assumes that the client is delegating DNSSEC-validation to a
> > > local recursive resolver and trusting its "AD" bit.
>
...

> No, I am talking about a situation where AD=0 despite the fact that the
> original name is in a signed zone, because the target of the CNAME
> lookup is not in a signed zone:
>
>     ; signed zone
>     www.secure.example. IN CNAME www.insecure.example.
>     www.secure.example. IN RRSIG CNAME 13 3 ...
>     _443._tcp.www.secure.example. IN TLSA 2 1 1 ...
>     _443._tcp.www.secure.example. IN RRSIG TLSA 13 5 ...
>
>     ; unsigned zone
>     www.insecure.example. IN A 192.0.2.1
>
> An "A" record query for "www.secure.example" via recursive resolver will
> return an insecure answer" with AD=0:
>
>     www.secure.example. IN CNAME www.insecure.example.
>     www.insecure.example. IN A 192.0.2.1
>
> but there are in fact signed TLSA records for the qname.


Yes, so the client issues a query for TLSA at
_443._tcp.www.secure.example.  This seems like the standard RFC 7671 CNAME
handling.  There is no need for the client to issue a query with
QTYPE="CNAME".