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

Ben Schwartz <bemasc@google.com> Sat, 18 February 2017 02:23 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 60B1C1295F7 for <dnsop@ietfa.amsl.com>; Fri, 17 Feb 2017 18:23:47 -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 E5BxAeEMFhId for <dnsop@ietfa.amsl.com>; Fri, 17 Feb 2017 18:23:45 -0800 (PST)
Received: from mail-io0-x232.google.com (mail-io0-x232.google.com [IPv6:2607:f8b0:4001:c06::232]) (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 5A1CA129584 for <dnsop@ietf.org>; Fri, 17 Feb 2017 18:23:45 -0800 (PST)
Received: by mail-io0-x232.google.com with SMTP id j13so4398674iod.3 for <dnsop@ietf.org>; Fri, 17 Feb 2017 18:23:45 -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=rE5KTCnizQDLmgAF0y3W4i94bOFFt5ViOO5e/YMIdOw=; b=FEosVjGhccqp6rQA4KCY26pVG3IZhZmSZ+w7Jd+h1JZkq+GYAOzwiNLWPLIq7N/FCW nz8E/rSIsvHAqRNVBchjoVIq5ZU5CEm3klM/AmjXX0JvBh3/oW3Z69/Ycss+7RAEBziE sOk0IynJgl+WYCKAvagQC9HFInkzsF3honERb1bHHLc1JzCHzBWPg12WWbK7iLyyJmfi m3OxEtCPDCznV25I+uZ3TQOOMAAvHuThsmxQGvRWkFRp9qSAGbqUSxOOsvIcoC8gXup4 8c+YGUInpQ0oAljOtRN8++NLSCWhwU7FAk1DUXoD3OiKcJ0Nqt+Py+4WL8/IWqAPGEw8 QddA==
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=rE5KTCnizQDLmgAF0y3W4i94bOFFt5ViOO5e/YMIdOw=; b=RR8ssDZN+RbTy6n14oDEA05GPlB4amUFqXpgU5qC8Yx2ebWfMJMSja9BXX4WSv0JRq zG+hea3bqBe3juE01rllW8Roqmzc4ZQtr7QW2WrVXRSSVxD7sXcUEfKwmF6nzCOQPouD ywjl/p+0KgIestQ50I0j2CccrRDn6/ySSsn2Nh5u1tdMkU5mmnyDbQ+L7GQUrQgzJcG1 dhNRfumIgki9xteuvyZbACa4rdm4goL26JRvl++qVHGFM0DiOFjKrYuF43adgnlYSy+m ln6TDgu0bFe8gDaFdqR0zpXZ0DRhsncIPh2Z7019As2cA3L1TjkCRGs2gVxx9G4EFS4K iKrQ==
X-Gm-Message-State: AMke39nmG601wfbsU+PqNc5hZDQnzSd6l6pRZVm9oU7uOVZimrH1WGKXLdX3d/LLjmx3QZc8m84Nz/B3dXfdJUVs
X-Received: by 10.107.34.10 with SMTP id i10mr9005631ioi.41.1487384624464; Fri, 17 Feb 2017 18:23:44 -0800 (PST)
MIME-Version: 1.0
Received: by 10.107.135.164 with HTTP; Fri, 17 Feb 2017 18:23:43 -0800 (PST)
In-Reply-To: <20170217220309.9637.qmail@ary.lan>
References: <CAHbrMsA278usgFNzxhrsLS6_EfXPeMoAKN65ec0YhCW93oKNYg@mail.gmail.com> <20170217220309.9637.qmail@ary.lan>
From: Ben Schwartz <bemasc@google.com>
Date: Fri, 17 Feb 2017 21:23:43 -0500
Message-ID: <CAHbrMsAdgRU6g4E6wCCA0zs6p=yTU4VJE3UWzvsuU5JAtnxaWQ@mail.gmail.com>
To: John Levine <johnl@taugh.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="001a1140ec6834b3380548c4b85c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/mCdAsguEY-7PJDIZUVn3Yva7nt4>
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: Sat, 18 Feb 2017 02:23:47 -0000

On Fri, Feb 17, 2017 at 5:03 PM, John Levine <johnl@taugh.com> wrote:

> In article <CAHbrMsA278usgFNzxhrsLS6_EfXPeMoAKN65ec0YhCW93oKNYg@
> mail.gmail.com> you write:
> >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.
>
> I have problems with the word "other".  This approach depends for its
> security on the assumption that it is hard to reverse SNI record
> lookups, that is, to find the qname(s) that have SNI records with
> given contents.
>

That was not my intent, and I don't think it's accurate.  We can consider
two cases

1. Multiple domains on the same host set the same SNI record.  Possession
of a global DNS database is no help to the adversary.  The adversary still
cannot distinguish the domains.  This is the intended use.

2. A domain sets an SNI record that is unique to that domain.  This is not
the intended use.

Case 1 is achievable whenever there are multiple domains in a certificate
(Subject Alternative Name or wildcard), with greater privacy protection as
a wider range of domains shares a certificate.

Case 2 is the only option if the domain is alone in its certificate.  In
this scenario, with current TLS, this is unavoidable.

We can certainly imagine solutions to Case 2.  For example, the SNI record
could include a public key that can be used to encrypt the SNI, e.g. RDATA
= "pubkey=<base64 encoded key>".  I would strongly support such a proposal.

Implementation of such a proposal would require changes to TLS, but would
be compatible with this draft's extensibility model.  I view this draft as
a modest step toward such solutions, allowing us to separate the question
of a new DNS record from possible TLS changes.


> That is a poor assumption.  There are many large passive DNS
> databases, and a lot of people have access to them.  My working
> assumption is that anyone sophisticated enough to peek at TLS
> handshake packets is sophisticated enough to find a passive DNS
> source.
>
> So to me the question is whether the small speculative incremental
> increase in user security is worth the investment to define a new
> record type, add it to DNS servers and provisioning systems, add it to
> web server configuration languages, and set up whatever infrastructure
> is needed to coordinate the published SNI records and what the web
> servers expect.
>
> I'd also note that if the assumption is that people will publish SNI
> records through the usual registrar and dns hosting operators managed
> through web consoles, there is no chance that the webware will support
> SNI records.  We know this because they don't support any other
> RRTYPEs defined in the past decade, either.
>
> R's,
> John
>
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>