Re: [DNSOP] Proposal for a new record type: SNI

Ben Schwartz <bemasc@google.com> Tue, 14 February 2017 20:03 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 8A5CE129559 for <dnsop@ietfa.amsl.com>; Tue, 14 Feb 2017 12:03:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level:
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] 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 sBvJvPXbbRMV for <dnsop@ietfa.amsl.com>; Tue, 14 Feb 2017 12:03:19 -0800 (PST)
Received: from mail-it0-x234.google.com (mail-it0-x234.google.com [IPv6:2607:f8b0:4001:c0b::234]) (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 B347B1297E7 for <dnsop@ietf.org>; Tue, 14 Feb 2017 12:03:10 -0800 (PST)
Received: by mail-it0-x234.google.com with SMTP id c7so48092458itd.1 for <dnsop@ietf.org>; Tue, 14 Feb 2017 12:03:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=yG37EAi3P4tCew5O/8jmq89hn6p2C59M1sO275M/zDg=; b=n7O7wx5AmtA61O9nVMhPtxUc1+kJaGEiV+qbsiFVAFj2Lu+Q8IYTv1cSIU6Twtz5Ze RXxw8T9tA6H1bgrGbNl81dAbCK2/m61HY8OolrqxCVD19jtCx6E+K8GwqVe94CiiFytZ omu1Sbsj4Ho3wI/h7d+f4lYev7wKyVbQLJHbvQq8bCRvkuXHrnfi/DFKEWm7ipMugjri 2kbxoQGP2qLss9UD34kuM7NF5ehrIHhRrY/baUhvXy5WtUfnUTfJWFtyeQbOVeIK4RLP IEzreFEswCUjeFMl49ny0brjp4JdST8w/dotypHen3pPXsjdLH1N3KcjAeazcxMm6ryO URdg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=yG37EAi3P4tCew5O/8jmq89hn6p2C59M1sO275M/zDg=; b=fZfSE+QtaOrV7gOUUzVc9DoAv4b21mqrvjWEEyHYr+mmWymm8pXgJxh1GG03ckmcGI yVT8YT27GQRucwn21oQFjxWWsg3A8oHQchCy+PFtBAJwUStaf5Pxx2dZgBOS2QUKPvQS SrpDE5XUCN0IE0eL0uq2ixRo53hLQfONV35pW4WuDA7pmVBND/bHfxlHObv5bjIdktRq nL1gv3qZcOcsu3/T8bHThsPcKyWRcs9t08xNQHbuvHaaq6GsTJ0fcO6TzWx45A5VLh8i BYSWrNRegS0hQnHsnykgUX0eYFKLwAnl3vhH5ABq3shbc506WRiYGEZzYyv9xO0MBHKa GrtA==
X-Gm-Message-State: AMke39mLuqxcznkfyUtMGG+rbZa7elKRjKJD7lSzGoGIHNHpxwq0ld+UQeeZOjmpQiinxIVXQ2jmWOegt7ZBcOsh
X-Received: by 10.107.34.10 with SMTP id i10mr26990814ioi.41.1487102589822; Tue, 14 Feb 2017 12:03:09 -0800 (PST)
MIME-Version: 1.0
Received: by 10.107.135.164 with HTTP; Tue, 14 Feb 2017 12:03:09 -0800 (PST)
In-Reply-To: <20170214191615.rwawyluf6nf4lfnm@mycre.ws>
References: <CAHbrMsAJ5JRtdjZRkCq4qC3dS_Fx96WBu8DPnJ1sSf=9HErKrw@mail.gmail.com> <20170214191615.rwawyluf6nf4lfnm@mycre.ws>
From: Ben Schwartz <bemasc@google.com>
Date: Tue, 14 Feb 2017 15:03:09 -0500
Message-ID: <CAHbrMsCOMrRzDLC+xXFnXr_vC=0pwpOdL+_Y87QjrB563XxTCg@mail.gmail.com>
To: Robert Edmonds <edmonds@mycre.ws>
Content-Type: multipart/alternative; boundary=001a1140ec689cbd1f0548830d24
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/qk16CkifJi1FxWKlGYm8VUFyVRE>
Cc: dnsop@ietf.org
Subject: Re: [DNSOP] Proposal for a new record type: SNI
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.17
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: Tue, 14 Feb 2017 20:03:21 -0000

On Tue, Feb 14, 2017 at 2:16 PM, Robert Edmonds <edmonds@mycre.ws> wrote:

> Ben Schwartz wrote:
> > Hi dnsop,
> >
> > I've written a draft proposal to improve the privacy of TLS connections,
> by
> > letting servers use the DNS to tell clients what SNI to send.
> >
> > https://tools.ietf.org/html/draft-schwartz-dns-sni-01
> >
> > I've incorporated some helpful feedback [1] from the TLS WG, but now I
> > could use your help analyzing the DNS side. All comments welcome; this
> > draft will change based on your feedback.
> >
> > One particular issue that I could use advice on: should this be a new
> > record type, or should it reuse/repurpose an existing type like SRV or
> PTR?
> >
> > Thanks,
> > Ben
> >
> > [1] https://www.ietf.org/mail-archive/web/tls/current/msg22353.html
>
> Hi, Ben:
>
> I'm kind of curious: your examples are pretty HTTP-centric, and HTTP
> already has some pretty strong features for origins to persistently
> modify how clients perform TLS, i.e., HTTP Strict Transport Security and
> HTTP Public Key Pinning, along with preloading of those settings by the
> browser vendors. Why not follow that same model for the functionality in
> your draft?
>
> --
> Robert Edmonds
>

Hi Robert,

While this technique would apply to any use of TLS, you're right that I'm
mainly motivated by improvements for HTTPS.

It's true, we could accomplish something like this by preloading a data
file into browsers.  In some sense, this is also true for any aspect of
DNS!  Obviously, preloading fares very badly when the data in question is
valid for short times, or applies to many thousands or millions of domains,
and I think both problems apply here.

For example, a CDN that operates DNS on behalf of its customers could apply
SNI records to all of their domains.  Preloading all of those domains into
every browser seems impractical, and the list will quickly become outdated.

Without preloading, we cannot solve the problem of revealing the
destination in the initial connection.

I would also note that HSTS and HPKP could not have been implemented using
insecure DNS, given their adversary model.  The SNI record is very
different, and does not require DNSSEC.

--Ben