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

Erik Nygren <erik+ietf@nygren.org> Sat, 18 February 2017 02:09 UTC

Return-Path: <nygren@gmail.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 01DA0126B6D for <dnsop@ietfa.amsl.com>; Fri, 17 Feb 2017 18:09:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 Tfz4Z0WZgC0F for <dnsop@ietfa.amsl.com>; Fri, 17 Feb 2017 18:09:41 -0800 (PST)
Received: from mail-ua0-x244.google.com (mail-ua0-x244.google.com [IPv6:2607:f8b0:400c:c08::244]) (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 90A7E128BA2 for <dnsop@ietf.org>; Fri, 17 Feb 2017 18:02:15 -0800 (PST)
Received: by mail-ua0-x244.google.com with SMTP id k3so5152576uak.3 for <dnsop@ietf.org>; Fri, 17 Feb 2017 18:02:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=QnKl5rBPNd+rbyEXODbpengGiLnyKEdiH0z1bF63b3Y=; b=rvTZUwKUaAWjf+XgucpK4NbGjVSQBI8YFHXgHF0h25W2X3F+L6F9mwycH3aZ8AESpU romYttIHI+8NqmUm3yarojtE8L3XkLymOQfDBl03YVu3H7Od+aPfMpEoyxd5auer5Zho UWX1d2WUJQz4F2wnexhGCqwA5tgaJE/rvSPQetk59k+ujSdWq8U1AO5Z21ngeLlzmvyE c8Vh7LSn27TgDvfTUrLufpt4gkku9LihhkHqGSVbsVXq/LFLdAqLdJW2C9OPfejpyAQ0 YViIlo9lFRbmh4EQSWRbj0ZgCdyQlYX3zlEwdeNF9jsNdZxy2jXfgK2oq6wmB4aNg9mn k+eg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=QnKl5rBPNd+rbyEXODbpengGiLnyKEdiH0z1bF63b3Y=; b=kniGK4xpAq6u5po1j4xi2xAWUc4jUhJl/lpgDGSO3eTg6SXCWUNivjb2nnVyt0tBVf av2ymWJvj8MLCygypvB1GQwBfCw1tbPaNw7mIXiwAtnhG76sm29Yy3HdqvNZyZztHEvI kixrIjn1q7+Wyj8Tz7+pwemhBNcgc32JAgylDWp4/c25inCYcjQgyErRHvmbuUChZTQt CG1JTZw5vNAm5dx/wh0sh2PqpFCH90pYzZHzSowL+inLDcXYN5Di4+4u2o1cwqV/1mup O/d6tHH0BzYdpiVBl+5CNHJtp+ZbZuGyKTrX7mZynftFrkf2kWiMhL9PfyMU93BtF+7O Iatw==
X-Gm-Message-State: AMke39kEBBr4fajtphK6PJOQpFGbDLKal7IapISspe6vnna1effa8RKMjATrbl3Nhc2mImQEYLsHGORFalW2GQ==
X-Received: by 10.176.74.30 with SMTP id q30mr1922273uae.4.1487383334631; Fri, 17 Feb 2017 18:02:14 -0800 (PST)
MIME-Version: 1.0
Sender: nygren@gmail.com
Received: by 10.103.146.79 with HTTP; Fri, 17 Feb 2017 18:02:14 -0800 (PST)
In-Reply-To: <CAHbrMsA278usgFNzxhrsLS6_EfXPeMoAKN65ec0YhCW93oKNYg@mail.gmail.com>
References: <CAHbrMsAJ5JRtdjZRkCq4qC3dS_Fx96WBu8DPnJ1sSf=9HErKrw@mail.gmail.com> <CAHbrMsA278usgFNzxhrsLS6_EfXPeMoAKN65ec0YhCW93oKNYg@mail.gmail.com>
From: Erik Nygren <erik+ietf@nygren.org>
Date: Fri, 17 Feb 2017 21:02:14 -0500
X-Google-Sender-Auth: -qwCd63tnAckZMh81Vu9Ill9k5U
Message-ID: <CAKC-DJh_+fGdJL1dyOqyGtoeppXtp=ajC_BDUESN76Jinw10Sw@mail.gmail.com>
To: Ben Schwartz <bemasc@google.com>
Content-Type: multipart/alternative; boundary=f403045f87164e416b0548c46bde
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/WB-VU6iha85nWk9WmlXTt7_YIGM>
Cc: dnsop@ietf.org, dkg@fifthhorseman.net
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: Sat, 18 Feb 2017 02:09:43 -0000

I wrote a similar draft a few years ago which I've been considering
resurrecting if there is interest:

    https://tools.ietf.org/html/draft-nygren-service-bindings-00

One of the big challenges that at least in the web context, browsers want
to make as few DNS lookups as possible prior to making HTTP requests.
(For example, some home gateways choke if too many requests are
outstanding.)
Having to lookup both A and AAAA is already a problem.  So if we're going
to add
something, ideally we'd add something that was extensible that could be
used
for multiple purposes.

For this case, the result could be something like:

_https._b.www.example.com IN B 2 0 www.example.com. { "alpn": "h2",
"tls-sni": "SOME_TOKEN", "hsts": true }
_https._b.www.example.com IN B 1 0 www-alt.example.com. { "alpn":
"quic352", "tp": 443, "tls-sni": "SOME_OTHER_TOKEN", "hsts": true }

By adding this one single lookup, you both get to specify an alternate SNI,
be able to force HTTPS-only, and specify Alternative Services (ala rfc7838
but allowing it to be done in DNS).  Having an extensible model here also
increases
the value of a client doing the lookup as once the records exist other
optional
attributes can be added in.

(Ignore the specific key/value pair examples in that expired I-D.  They
made more
sense when some other things were being considered.)

Based on our extensive discussions in the TLS WG over the past few years,
introducing something like this into the DNS to indicate an alternate SNI
value
(which might be one shared with many other hostnames) or telling the client
not to send an SNI value seemed to be one of the best ways to help with
the SNI privacy problems, at least once there is a DNS privacy path.

For example, for a cert like *.example.com (perhaps with lots of other SANs
as well)
there is no reason the client needs to send "
something-potentially-private.example.com" when sending
an SNI value of "wildcard.example.com" would do just fine.  The TLS
handshake
is too late to learn this, but if we could move it into the DNS then clients
could learn it (and potentially other useful info) before connecting.

[I added DKG as he was a strong advocate of doing something in this space
for signalling TLS SNI omission, alteration, or aliasing in DNS records.]

             Erik




On Fri, Feb 17, 2017 at 3:49 PM, Ben Schwartz <bemasc@google.com> wrote:

> Thanks for the input everyone!  Here's an updated version with some
> clarifications based on your feedback:
> https://tools.ietf.org/html/draft-schwartz-dns-sni-02
>
> Diff:
> https://www.ietf.org/rfcdiff?url1=draft-schwartz-dns-sni-
> 01&url2=draft-schwartz-dns-sni-02
>
> I know this approach is controversial, so I'm also very curious to hear
> any suggestions of other ways that we could fix this privacy leak without
> slowing down everyone's connections.  As a friend put it: if everyone can
> see you're reading justinbieber.tumblr.com, "that defeats the whole point
> of HTTPS".
>
> On Tue, Feb 14, 2017 at 1:02 PM, Ben Schwartz <bemasc@google.com> 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
>>
>
>
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
>