Re: [TLS] New Draft: Using DNS to set the SNI explicitly

Yoav Nir <ynir.ietf@gmail.com> Wed, 08 February 2017 07:13 UTC

Return-Path: <ynir.ietf@gmail.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 9E8CD129572 for <tls@ietfa.amsl.com>; Tue, 7 Feb 2017 23:13:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=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=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 9CCwaO0L4meK for <tls@ietfa.amsl.com>; Tue, 7 Feb 2017 23:13:20 -0800 (PST)
Received: from mail-wr0-x236.google.com (mail-wr0-x236.google.com [IPv6:2a00:1450:400c:c0c::236]) (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 89C491294F3 for <tls@ietf.org>; Tue, 7 Feb 2017 23:13:19 -0800 (PST)
Received: by mail-wr0-x236.google.com with SMTP id o16so54942443wra.1 for <tls@ietf.org>; Tue, 07 Feb 2017 23:13:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=KNmR42103SHRHU+fXCAHw623Q9IXEK0fCoNixq1MaY0=; b=E1rczImvRwO2xN4c0ffqM7GUWJYOvoLxX4TFp6GM6ExKyBlple7+edC7qpVXcWoY1N 8JHsHGxKZpwuzsnnhy3dyy5p6IApcJtznBCzmk4l0qeq6dJ5TUhehKv32/t6lL9hry3S TyHC0zFUZB4iuBuF9K/cb+7ivRd2Ciq0pgGAcf350Rn6tiJ8648IOirDjcQognFq4yZ/ SSHql8Sz/rgnI+bc+LSAN5pjOHRtgFhmmpJxe4eKqIlQ2Sqf+dE/qxxjVP6exabR9dDI TFMpnn0A15QscIBpuSk+Sp+TwbdQfGwquJIQ2XUF/cudCml/VAHhePpX01IOkRDF7kND YTgA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=KNmR42103SHRHU+fXCAHw623Q9IXEK0fCoNixq1MaY0=; b=rjTIHt/ouvl4eNL5cj0BaQHWFAO5f1rm/6u0GGxOjBlJJyixXh/zAooat3MZb5i4yz RmVMOn99CLd4BpJQRlUkUxpDgV5WPN4eaBmJ2cnQXTgzopgTdQdIDXUaLI2wZxX+d1Xk otpVwHj97co1X5YFAiU5/VzC952dqXjhY5img6U5eYYqbbySIMFP0YbiCZ4vPB2GtNBq Qm0p3wUNkYeiho5aJeK0kVrUhx5dYvRKd8VCNHrM/y7gBBTKxWN1VrYDQ+lpV6elBlfg JBSMhEX1aYx2gyVL0jQdq1Yhfg0QLD4I5IVauaGjOioPIkQ6Mpqve5Q5szhiI1dfdTr4 m/4Q==
X-Gm-Message-State: AMke39kcbOQqMGof+7cjYzBl7BEPDLYfc8H+pDAiqmeb0Sm3xD9UR8O5g9A3O72oPQB1rg==
X-Received: by 10.223.130.204 with SMTP id 70mr17043999wrc.128.1486537997968; Tue, 07 Feb 2017 23:13:17 -0800 (PST)
Received: from users-mbp.mshome.net ([109.253.228.86]) by smtp.gmail.com with ESMTPSA id c9sm1662474wmf.18.2017.02.07.23.13.15 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 07 Feb 2017 23:13:16 -0800 (PST)
From: Yoav Nir <ynir.ietf@gmail.com>
Message-Id: <DB1DB8DB-F33A-4435-986E-69628C67C63B@gmail.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_7FAF0DBF-62A6-4FA4-9C24-F6BB04195294"; protocol="application/pgp-signature"; micalg="pgp-sha512"
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
Date: Wed, 08 Feb 2017 09:12:59 +0200
In-Reply-To: <CAHbrMsCpCH2qSG=cZjMMuWbpzCn8dQhvaTDaRc1riwnYiKGjsg@mail.gmail.com>
To: Ben Schwartz <bemasc@google.com>
References: <CAHbrMsCpCH2qSG=cZjMMuWbpzCn8dQhvaTDaRc1riwnYiKGjsg@mail.gmail.com>
X-Mailer: Apple Mail (2.3259)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/u3QWXbgWHRlAHWFsl3BxBd5b2zo>
Cc: tls@ietf.org
Subject: Re: [TLS] New Draft: Using DNS to set the SNI explicitly
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
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: Wed, 08 Feb 2017 07:13:21 -0000

On 7 Feb 2017, at 18:12, Ben Schwartz <bemasc@google.com> wrote:

> Hi TLS,
> 
> Like a lot of people here, I'm very interested in ways to reduce the leakage of users' destinations in the ClientHello's cleartext SNI.  It seems like the past and current proposals to fix the leak are pretty difficult, involving a lot of careful cryptography and changes to clients and servers.
> 
> While we're trying to figure that out, I think there's a simple trick that could help a lot: just let domain owners tell users an alternate SNI in a DNS entry.
> 
> Here's the full draft:
> https://tools.ietf.org/html/draft-schwartz-dns-sni-00 <https://tools.ietf.org/html/draft-schwartz-dns-sni-00>
> 
> If you just want to glance at it, I recommend Figure 2.
> 
> Please read and critique!  This is a starting point; the contents will change based on your input.

Hi, Ben

I’m a little surprised that you depend on RFC 7858 (DNS over TLS), which is fairly new and lightly deployed, but do not depend on DNSSEC, which is (slowly) getting traction.

If you assign a one fake SNI to each real name, then a determined adversary (especially the police state) can map the fake SNIs for all domains of interest and you lose the privacy.

If you assign one fake SNI for a bunch of real names, then the best an adversary can do is to associate a visible SNI with a group of names, some of which may be innocuous. But I’m thinking, why do we need SNI at all in the TLS handshake?  Obvious answer is to select the right certificate, but under this scenario the certificate already has to have the names of all domains possibly hosted on the server.

So why not instead use secure delegation using signed CNAME records and a new record (which perhaps should be called “noSNI”). Then the diagram looks like this:

  DNS Server                      Client                      TLS Server
     |                               |                                 |
     |<===example.com AAAA?==========|                                 |
     |<=_443._tcp.example.com NOSNI?=|                                 |
     |=example.com CNAME a7.cdn.net=>|                                 |
     |==a7.cdn.net AAAA 2001:db8::1=>|                                 |
     |==example.com NOSNI cdn.net===>|                                 |
     |                               |--------------TCP SYN----------->|
     |                               |<------------TCP SYN+ACK---------|
     |                               |--------------TCP ACK----------->|
     |                               |------ClientHello SNI:none------>|
     |                               |<--------- ServerHello ----------|
     |                               |<-- Certificate name:cdn.net ----|

And the server works it out using the HOST header as Rich said.  Of course this depends heavily on DNSSEC validation, but it would work with any version of TLS.

Yoav