Re: [TLS] Fwd: SVCB and HTTPSSVC records: draft-nygren-dnsop-svcb-httpssvc-00

Ben Schwartz <bemasc@google.com> Tue, 24 September 2019 16:24 UTC

Return-Path: <bemasc@google.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D2E21200D7 for <tls@ietfa.amsl.com>; Tue, 24 Sep 2019 09:24:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.499
X-Spam-Level:
X-Spam-Status: No, score=-17.499 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, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 SMdl4S4lkyhl for <tls@ietfa.amsl.com>; Tue, 24 Sep 2019 09:24:30 -0700 (PDT)
Received: from mail-io1-xd2f.google.com (mail-io1-xd2f.google.com [IPv6:2607:f8b0:4864:20::d2f]) (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 303241200C1 for <tls@ietf.org>; Tue, 24 Sep 2019 09:24:30 -0700 (PDT)
Received: by mail-io1-xd2f.google.com with SMTP id n197so5884511iod.9 for <tls@ietf.org>; Tue, 24 Sep 2019 09:24:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=2+R6bae8qmlR0xxCEpPLQb9iipwvzlezq5W17yIv4l4=; b=K/z100JcWnNWJqYNP3BKD1tSEv5Kbn19Iue/VgWJnLRuDmEW5Akf+EKbRn9kkgNUQB 8hh1EVCw/BPJDPA7hIfvlHN3hAIhUJhsd49BkwirnrxajRo4ffzouYuM2w/IXM95uyzf nqJGgncAeR4I3CmuC3fhH2N1vDAHuCwTPwVCIK8pWVTd5bAxBs71jYzLPP3tEU54bUmW e38VZCg/K2FQBhcGQBZ/KJOpzcYcMktai30TAK4GiCZ+E4zJ7tjVsPnIGcxry2T1H63z MmMfxOiX6CWAgYTFuev5DJghbc0cG4dLJqEir0K1/WCo6ll1eIKuuAolIo+agybSskH1 gI8A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=2+R6bae8qmlR0xxCEpPLQb9iipwvzlezq5W17yIv4l4=; b=ij1S4/+vUIc027W/VtiYMKabwLsUtExkQtzlLu2wg8MJ4jwq/D0ri11UbpkjkGCRhJ NIY1exvXM1CP39MS5wJk3K2vB07Pg8o3gcgeWE/PCNkTH1HSK7RsEA472gZtXdaaTtF2 qXcUSRDbp9d8Ul4sLdXIEXtDZ4KSgkKsmkfz/ujtJU8kyW/VOT9Lx/nP5HTdj7+q3YJK AoFUwpJUiUIN6fyze/js4M9ZXkbieQw8/14G2ep1OpawHP06lljC6SCPzfdXFXyLl0mi jq7HXi6Q8Hmq7aOuV428QrHHnBL+UcBZ3F4SOItPmyd6gG1/nkpPmErlUVVZ2UA7Nd3N FlDQ==
X-Gm-Message-State: APjAAAWZDogh0uPW59BfjhIRwvk+H0aHkLR8Mt0YSs0PmFwiwf3AHZka IF8nVdwS7kXq/ugfVao1H4TI6N+gUHq1XF/M+j4Ovg==
X-Google-Smtp-Source: APXvYqznFp2EJw1W+LCVlv6RjVaKwGJ3ScA4EAhxHbgwpYmIivKUYY/PKI2P7Ir0OG1p9MkFw35PUwKVetkzqaCHfsI=
X-Received: by 2002:a6b:916:: with SMTP id t22mr4262623ioi.193.1569342268979; Tue, 24 Sep 2019 09:24:28 -0700 (PDT)
MIME-Version: 1.0
References: <156927967091.17209.1946223190141713793.idtracker@ietfa.amsl.com> <CAKC-DJi4EHz5CCAqRj_cYTVygiuo0s2QGaPLCct6e9Bh1mXaXQ@mail.gmail.com> <CAKC-DJgUt-H4-EQ3pvBL8_-UEUty3kQwTyh_Adtp3ORtiZOySg@mail.gmail.com> <20190924153148.GA2027159@LK-Perkele-VII>
In-Reply-To: <20190924153148.GA2027159@LK-Perkele-VII>
From: Ben Schwartz <bemasc@google.com>
Date: Tue, 24 Sep 2019 12:24:15 -0400
Message-ID: <CAHbrMsBmikuLD10evSgH2z59cPT43D=ha=POLAdz+v7ZgM8nLg@mail.gmail.com>
To: Ilari Liusvaara <ilariliusvaara@welho.com>
Cc: Erik Nygren <erik+ietf@nygren.org>, "<tls@ietf.org>" <tls@ietf.org>, Mike Bishop <mbishop@evequefou.be>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="000000000000828acc05934ef823"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/OCYdOyNpsnrZp9WCuth8TNaHlgQ>
Subject: Re: [TLS] Fwd: SVCB and HTTPSSVC records: draft-nygren-dnsop-svcb-httpssvc-00
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 24 Sep 2019 16:24:34 -0000

On Tue, Sep 24, 2019 at 11:31 AM Ilari Liusvaara <ilariliusvaara@welho.com>;
wrote:

> On Tue, Sep 24, 2019 at 09:21:25AM -0400, Erik Nygren wrote:
> > Following the discussions in Montreal (as well as with some of the ESNI
> > authors),
> > we refactored the HTTPSSVC draft to make it more general.  The hope is
> that
> > it could be an alternative (or replace the need) for a distinct ESNI
> record.
> > The draft generalizes to a protocol-agnostic SVCB record, but also
> specifies
> > an HTTPSSVC record for the HTTP(S) use-case.
> >
> > Based on discussions with various chairs, the plan is to call for
> adoption
> > in the DNSOP WG.
> >
> > Comments/feedback are most welcome.
> >
> > From: <internet-drafts@ietf.org>;
> > Date: Mon, Sep 23, 2019 at 7:01 PM
> > Subject: New Version Notification for
> > draft-nygren-dnsop-svcb-httpssvc-00.txt
> > To: Mike Bishop <mbishop@evequefou.be>;, Erik Nygren <
> erik+ietf@nygren.org>;,
> > Benjamin Schwartz <bemasc@google.com>;
> >
> > Name:           draft-nygren-dnsop-svcb-httpssvc
> > Revision:       00
> > Title:          Service binding and parameter specification via the DNS
> > (DNS SVCB and HTTPSSVC)
>
> Couple comments:
>
> - Is there need for two resource records? It seems like the two uses
>   could be distinguished by starting point.
>

I believe you're right that a single RR type would suffice, but that RR
type specification would have to contain special-case logic for HTTP and
HTTPS.  We felt it was more elegant to have one purely generic RR type, and
one specialized.  Also, if any other protocol wants an SVCB-compatible type
without prefixing, we'll end up with multiple RR types anyway.

If the WG would prefer a single RR type with a special-case for HTTP(S), I
think we would be able to make that change.

- What about starting point of protocols that have defined name for
>   SRV records? That thing is of form _foo._tcp.domain.example
>   (or _foo.udp.domain.example).
>

Do you mean to ask about how this would coexist with SRV?  Broadly, I view
this as a successor to SRV, but I think the details of how they interact
would have to be defined by the protocol mapping document for a specific
protocol that currently uses SRV.  The correct logic might be different for
different protocols; I'm not sure.

If you think there's a universal rule, that would be good to know.


> - One possible use for AliasForm with '.' would be to signal that
>   this service does not exist (IIRC, some other rrtype had special
>   "this does not exist" value).
>

Currently, that's effectively indicated by NXDOMAIN/NODATA.  Do you see a
need for a specific flag?


> - It seems like ALPN and port are fundamential and would be better
>   being their own fields, instead of attributes.
>

ALPN only applies to TLS-based protocols, and even many TLS-based protocols
don't use it.  For example, a hypothetical mapping of SVCB for SSH would
have no use for ALPN.

I agree that ports are nearly universal, but they're often redundant.  For
example, in HTTPSSVC, the port can be omitted if it is the default port.
Since the port doesn't apply in the AliasForm, making it a parameter seemed
like the most convenient representation.


> - This could be defined to carry out TLS upgrade for any protocol
>   that uses it. However, one would need to allow ALPN to override the
>   behavior (e.g., HTTP/3 needs to change transport from TCP to UDP).
>

Yes, SVCB is well-suited for pre-connection "upgrades" of all sorts, and
hopefully it will be useful for TLS upgrades beyond HTTP.  As you note,
this can be nontrivial, as in the case of HTTP, where the ALPN can signal a
transport change!  For that reason, the details of client behavior are left
to the protocol mappings.


> - To me, ipv4hint/ipv6hint seem very bad ideas, as they break
>   normalization and ownership, drastically increasing odds for errors.
>

I admit that these hints are fragile, but they have been a very strong
request from some browser vendors, and similar hints are also present in
the ESNI RR proposal.  The concern is that, when the origin is using
HTTPSSVC delegation, and the client's recursive is not HTTPSSVC-aware, the
client will have to perform a followup A+AAAA query before it can start
connecting.  The IP hints allow connection start right away.

The draft contains a number of mitigations against fragility.  For example,
the client is still required to perform the A+AAAA queries, and switch to
one of those "official" IP addresses as soon as they are available.
Hopefully this limits the amount of mischief that can be made by bad IP
hints.


> - I would not speculate about records for DNS authorities looking
>   anything like this. That RRtype will be very special snowflake.
>

I agree, we should probably remove that.  Hopefully many of the SVCB
conventions will be reusable, but it's too soon to say.


>
>
> -Ilari
>