Re: [TLS] DNS-based Encrypted SNI

Ben Schwartz <bemasc@google.com> Tue, 03 July 2018 15:21 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 360F7130E50 for <tls@ietfa.amsl.com>; Tue, 3 Jul 2018 08:21:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.51
X-Spam-Level:
X-Spam-Status: No, score=-17.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, 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 SyLTudw21Ixj for <tls@ietfa.amsl.com>; Tue, 3 Jul 2018 08:21:03 -0700 (PDT)
Received: from mail-io0-x22b.google.com (mail-io0-x22b.google.com [IPv6:2607:f8b0:4001:c06::22b]) (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 05DFC130E6D for <tls@ietf.org>; Tue, 3 Jul 2018 08:20:36 -0700 (PDT)
Received: by mail-io0-x22b.google.com with SMTP id t135-v6so2057538iof.7 for <tls@ietf.org>; Tue, 03 Jul 2018 08:20:35 -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=OCwaTDHW3hQDiNCcGNiml7/pZQi2jvxfVZRUb9RB8A8=; b=XibhJCIANy49GcvLNpLs5jY5RzD2kktN6JkoE4v6gCJT0cir+4XWUoo+S4TveYozlX QE4H0Iqkuvx6jtqet+A9a1/e4PWRmBCK/5wZY2FZqOrU1ViSKsKXe06R9VM6mp9548HE ycpvm5Y2bqYdaWoQMDqSa/a90UC7Er6DibgPig5tJVSwnsIaFQzKgqiK/wv0rHC/X97c mAKb+eoVexD9wgda1Iarw0N5qviedD7zvXJwk6Iz7Glnef4oUhwVpFuHnuFEaE7OzOP9 5L03hC3+ywCcdOgJMEmlf6/WZ7vwzfGYBb9kGeor22l4Bhwwkj7V+/dbhU/8AZQ6Nqp8 jRoA==
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=OCwaTDHW3hQDiNCcGNiml7/pZQi2jvxfVZRUb9RB8A8=; b=XrGqp48uhowDMC2hQL3tr9ftmRSqMT9tK8wpbj820uPt7npBxzBDkxEWUp3XUXJcsd n7j6IoX6LTtcPQX28zx11ytjeA2shYE94wdvVYZdjgJikSvdlJgt8EOPubEOZTqADctP 8w/6FJjjU+dXftBrGHQyoSFvARwSEuwQN+2ptlpxlIZiCoMDyuXJWwkCAUZK70Jgftbr RCRIG6KBOrCOqjZgniRlEX/F67T4LQfOat7dQZwsuDkG1zQeO/cj3cVD1SMhwggLN6sr EAXCklh7r8SNQ8e7R10kRIRYLnpNjMAgL11ooT4TKNuIObgjIY/FHjUm736cBZibSOHM RqCQ==
X-Gm-Message-State: APt69E1583kE8xPU1CPjHsjsLRYTD5wPV9z2Ekopw5RUOCT44qTI+XnV pQysR2MO4IoHswXvVs8VVWrUCZQU1TNTpsZF0W8f2Q==
X-Google-Smtp-Source: AAOMgpeq6eJgLLFBZ42NaxJPZ8ewCV/zVE2tceIGk1ml9T7+oDBfuVHThWcGOU50BOiXPYclL+T4XWQCHVu9JMNm4So=
X-Received: by 2002:a6b:f812:: with SMTP id o18-v6mr23636860ioh.235.1530631234713; Tue, 03 Jul 2018 08:20:34 -0700 (PDT)
MIME-Version: 1.0
References: <CABcZeBMR=5QQjSS68H2mQoyG1cHVa5+Z_5SH0Md07kTBVSr3Sw@mail.gmail.com>
In-Reply-To: <CABcZeBMR=5QQjSS68H2mQoyG1cHVa5+Z_5SH0Md07kTBVSr3Sw@mail.gmail.com>
From: Ben Schwartz <bemasc@google.com>
Date: Tue, 3 Jul 2018 11:20:22 -0400
Message-ID: <CAHbrMsCaYHgoBX6__m9qCPqJ1pbZ0JDPehHdvc8p51_gS7o8Yw@mail.gmail.com>
To: Eric Rescorla <ekr@rtfm.com>
Cc: "<tls@ietf.org>" <tls@ietf.org>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="000000000000129580057019dbb5"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/G71ff9zXykEWPPJDLLwtBIqk1kw>
Subject: Re: [TLS] DNS-based Encrypted SNI
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.26
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, 03 Jul 2018 15:21:11 -0000

On Mon, Jul 2, 2018 at 7:41 PM Eric Rescorla <ekr@rtfm.com>; wrote:

> Hi folks,
>
> I just submitted:
>
>   https://tools.ietf.org/html/draft-rescorla-tls-esni-00
>
> This draft describes a DNS-based approach to doing encrypted SNI.
>

Thanks for this proposal, Eric.  I fully support this line of work.

This proposal obviously bears some relevance to the SNI Alt-Svc + DNS
ALTSVC drafts in HTTPBIS [1][2].  That's OK; we'll sort it out eventually.
I hope people interested in this draft will also check out those.  In my
view, ESNI and those drafts are two complementary approaches to this
problem.  I can see reasons to pick one, or both, or a combination.

[1] https://tools.ietf.org/html/draft-bishop-httpbis-sni-altsvc-02
[2] https://tools.ietf.org/html/draft-schwartz-httpbis-dns-alt-svc-02

On Mon, Jul 2, 2018 at 11:59 PM Eric Rescorla <ekr@rtfm.com>; wrote:

> On Mon, Jul 2, 2018 at 8:53 PM, Paul Wouters <paul@nohats.ca>; wrote:
>
...

> It is strongly recommended not to use TXT records. Why not use a new
>> RRTYPE? Everything these days knows how to serve unknown record types
>> (see RFC 3597). The only possibly exception is provisioning tools of
>> small players, but this document starts of saying you basically need
>> to be on a bulk hosting provider anyway. They can properly provision.
>>
>
> See:
>
> https://github.com/ekr/draft-rescorla-tls-esni/issues/7#issuecomment-388531906
> <https://github..com/ekr/draft-rescorla-tls-esni/issues/7#issuecomment-388531906>
>

That logic (CNAME compatibility) requires not placing this information at
the apex, i.e. using a prefix, as you've done.  It doesn't preclude using a
new record type.  The DNS ALTSVC draft, for example, does both.

Some other thoughts:

I expect much nitpicking of the exact DNS syntax.  You may end up wanting
to describe that separately, especially since these "introduction tokens"
may well be useful to acquire over non-DNS channels (e.g. Alt-Svc) and may
be useful for non-SNI purposes (like 0-RTT, as you've noted).

I wonder how well this scales to a "large key" future (e.g. post-quantum).

As described, this approach seems hard to use with a domain load-balanced
across two CDNs.  (I don't know how important that use case is.)

One concern I've heard many times is that we can't add non-A/AAAA queries
to a browser's critical path because there are middleboxes and buggy
recursives that will just drop them, leading to a DNS timeout delay on
every new socket.  However, for encrypted SNI I think we can ignore this by
focusing on clients with DPRIVE or DOH enabled, which should avoid these
kinds of problems.