[TLS] HTTPSSVC record draft - ESNI alternative for HTTPS

Erik Nygren <erik+ietf@nygren.org> Mon, 08 July 2019 21:27 UTC

Return-Path: <nygren@gmail.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id A75C812031C for <tls@ietfa.amsl.com>; Mon, 8 Jul 2019 14:27:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.106
X-Spam-Status: No, score=-0.106 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.247, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, PDS_NO_HELO_DNS=1.295, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id N41Ve76745JK for <tls@ietfa.amsl.com>; Mon, 8 Jul 2019 14:27:42 -0700 (PDT)
Received: from mail-wm1-f48.google.com (mail-wm1-f48.google.com []) (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 303981202A3 for <tls@ietf.org>; Mon, 8 Jul 2019 14:27:42 -0700 (PDT)
Received: by mail-wm1-f48.google.com with SMTP id w9so908897wmd.1 for <tls@ietf.org>; Mon, 08 Jul 2019 14:27:42 -0700 (PDT)
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; bh=JHszSawOh1OhLxFerjlxVACRI8h4l2i9RkY5MWFFkpU=; b=Mu+B77FhME07Di5Z6kcdd0emxqBVt/1GGcaxeZyEocVsnVjaiNBShUeEONv0jlbQKe W7yBVvbrfuWfMocsIGXyZQnIqthHiYh/F//7yW5g8CqmiWYz6OGt/HVO/kNN9okU718m zne0ZSpAFSjj9saSFhd++KKL5dpZbTrYrjBYmfmmB+b5SQQdFRJqsvII3q4VGIPdXyl3 f9VQgkXQet00W2Ar4z+ZH3vERjLCVzv3WB+Hial2Ph9ODXsIDNj/5AYYaWVA5eaHzn50 Udqk9MzRkuVGazZ/GN+mYqs9B8FumYXv3h+6Pm33smKdqRxwKBOP4sUz88+DJdMFaq5Q SqYw==
X-Gm-Message-State: APjAAAWEOC7wG4qULHQrN3FdTo2YVdiH2VVv1PdhbtC6w6ikeRSYsknZ d7IU6tzMqj0fIPpdn7h4l493g9YL2MUigmQHWdryeiBl
X-Google-Smtp-Source: APXvYqwsrQXdui6n5IOHV2cznUozAb0sara+Xxy1h78oRLSm49vEG99DjM3xEd8BcZFCnuWsmj4bkRvY8AJ5gl6Mpb0=
X-Received: by 2002:a1c:f914:: with SMTP id x20mr19027510wmh.142.1562621259845; Mon, 08 Jul 2019 14:27:39 -0700 (PDT)
MIME-Version: 1.0
References: <CAKC-DJikByP+wX-GoD6ntpUWTbr6ioJzB4i8nGQL4NtPWePL3g@mail.gmail.com>
In-Reply-To: <CAKC-DJikByP+wX-GoD6ntpUWTbr6ioJzB4i8nGQL4NtPWePL3g@mail.gmail.com>
From: Erik Nygren <erik+ietf@nygren.org>
Date: Mon, 8 Jul 2019 17:27:28 -0400
Message-ID: <CAKC-DJg7dioWSWhMC+yq4jxX+xGkxT-g7aPEGtjk8UHEL63WJw@mail.gmail.com>
To: tls@ietf.org, Ben Schwartz <bemasc@google.com>, Mike Bishop <mbishop@evequefou.be>
Content-Type: multipart/alternative; boundary="0000000000001c943d058d321d81"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/Tu4ycbyypyr4UbEVXZJgMFWlry8>
Subject: [TLS] HTTPSSVC record draft - ESNI alternative for HTTPS
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: Mon, 08 Jul 2019 21:27:52 -0000

For those not on the HTTP-WG or DNSOP lists, Ben Mike and I have
a draft for an "HTTPSSVC" DNS record.  There's a -03 that incorporates
some feedback from the first version:


This attempts to address a number of problems (ESNI, QUIC bootstrapping,
HTTP-to-HTTPS redirection via DNS, SRV-equivalent for HTTP, etc) in a
holistic manner through a new extensible DNS record, rather than in a
piecemeal fashion.  It is based on some previous proposals such as "Alt-Svc
in the DNS" and "Service Bindings" but takes into account feedback received
in DNSOP and elsewhere.

In particular for the TLS WG, we'd be interested in hearing if this would
solve enough of the ESNI-key-delivery-via-DNS needs for the HTTPS use-case.

Feedback is most welcome and we're looking forward to discussing with
people in Montreal.

While this is still an individual draft, we have been tracking it here:
but as always, commentary on the IETF lists is generally preferable.
There is even a preliminary private type implementation in BIND
of the -01 version (with the -02 wire format supported by ifdefs)
from Mark Andrews:

>From the abstract:

This document specifies an "HTTPSSVC" DNS resource record type to
facilitate the lookup of information needed to make connections for HTTPS
URIs.  The HTTPSSVC DNS RR mechanism allows an HTTPS origin hostname to be
served from multiple network services, each with associated parameters
(such as transport protocol and keying material for encrypting TLS SNI).
It also provides a solution for the inability of the DNS to allow a CNAME
to be placed at the apex of a domain name.  Finally, it provides a way to
indicate that the origin supports HTTPS without having to resort to
redirects, allowing clients to remove HTTP from the bootstrapping process.

By allowing this information to be bootstrapped in the DNS, it allows for
clients to learn of alternative services before their first contact with
the origin.  This arrangement offers potential benefits to both performance
and privacy.

This proposal is inspired by and based on recent DNS usage proposals such
as ALTSVC, ANAME, and ESNIKEYS (as well as long standing desires to have
SRV or a functional equivalent implemented for HTTP).  These proposals each
provide an important function but are potentially incompatible with each
other, such as when an origin is load-balanced across multiple hosting
providers (multi-CDN). Furthermore, these each add potential cases for
adding additional record lookups in-addition to AAAA/A lookups.  This
design attempts to provide a unified framework that encompasses the key
functionality of these proposals, as well as providing some extensibility
for addressing similar future challenges.


Some likely FAQs (with some others listed in an appendix):

Q: Why this is HTTP-specific?
A: This is because every protocol has different bootstrap requirements.
This draft is concerned with improving the efficiency and security of
bootstrapping HTTPS connections.  This proposal does offer room for
non-HTTPS protocols, but the nature of DNS requires underscore prefixing to
support protocol-keyed answers within a single RRTYPE.  It's also unlikely
that a single RR format would be the ideal bootstrap mechanism for every
protocol, and there's no reason that multiple protocols should have to
share an RRTYPE.

Q: Why is ESNI addressed directly?
A: This helps make a major motivation of this draft more clear.  Splitting
out those sections to a separate-but-associated "alt-svc attribute for ESNI
keys" draft might make sense, but keeping it here helps work through some
of the issues together.

Q: Why does this try to address the HSTS case?
A: This is a unique opportunity to fix HTTPS bootstrap and avoid providing
insecure defaults.  We'd originally proposed a separate Alt-Svc attribute
to indicate hsts-style behavior, but then realized that it would make sense
to push on that as the default here.

Best, Erik