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

Ben Schwartz <bemasc@google.com> Tue, 07 February 2017 16:12 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 604B7127076 for <tls@ietfa.amsl.com>; Tue, 7 Feb 2017 08:12:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 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, URIBL_BLOCKED=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 zEZsyBkGnLzx for <tls@ietfa.amsl.com>; Tue, 7 Feb 2017 08:12:14 -0800 (PST)
Received: from mail-it0-x235.google.com (mail-it0-x235.google.com [IPv6:2607:f8b0:4001:c0b::235]) (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 0B333129CFE for <tls@ietf.org>; Tue, 7 Feb 2017 08:12:14 -0800 (PST)
Received: by mail-it0-x235.google.com with SMTP id c7so80123022itd.1 for <tls@ietf.org>; Tue, 07 Feb 2017 08:12:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=hMPHl/WKffRdAtEPMV68QA4fZl4QATiWdHcUkbdlFgw=; b=kJ4x3h/j98HzrS8b2+HFL9qgWIj4STBXsbcN7JUs+I4iWyPmdoiAnamscb5kxaXU+1 BxYrYzExj7+GdHIGB0qyAWeThuKDtbznQlaJSnTMe7Fyzc10wP3TWQXA3zmvx1JAWwUg 1OtXJGH6kzgf/wI8BsyMiThUORk6qMybm17PgqSNGzvCYvOnfezWyq2LC5i9xbc1ua/O WOaUEfp1K3b4OGK8n7Qae5PIsE3BIy/7UuqzRq3/WLnwAbipaIJAjc3F7olUea/8klyp 2G++gvSCWHOedlukSz/QhH9QUDek7jIE8MYLRU112nQ4zakrNlPEIroZLleboRUnBlcY Zscw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=hMPHl/WKffRdAtEPMV68QA4fZl4QATiWdHcUkbdlFgw=; b=TAQtoOThXuU/MZBRCpAyhX0r5asniAEgCkFSBGiBx90XObEJ9KS748lm9tID5jFOE7 3DbWTtUfdMxyVgEiCS8kvQm4fCID0TncNKQ6B7C90bfZB+8RuENy62EM5ScttMIbbRSK m9a4XfKm445JnFeu7ZwmPokKGkP3hsUUqw8n4d93qA3vtx+8j5P7gXfz7qb2U79TEkMe Pn7UvlAX3S+9SIbEZlLcv9aCgoveEtd7H4f+vMPr1iqUBZLc/MUT6qgtc3svHsd7iLbt 9oIWM18wEP4oJqcvgFa3EZwuWS2xlf+19gTca7wJVEcprdnIor29izXyeraT3J5fVi8T nafA==
X-Gm-Message-State: AIkVDXKsDjUGb7gwcYAoArgWA78gfA56cgC3ep4OZYZsEQO5sy789+YNGbQDOoRDyUz4X0MNEpqv89YdAS9aqP0C
X-Received: by 10.36.71.207 with SMTP id t198mr12543363itb.98.1486483933040; Tue, 07 Feb 2017 08:12:13 -0800 (PST)
MIME-Version: 1.0
Received: by 10.107.135.164 with HTTP; Tue, 7 Feb 2017 08:12:12 -0800 (PST)
From: Ben Schwartz <bemasc@google.com>
Date: Tue, 07 Feb 2017 11:12:12 -0500
Message-ID: <CAHbrMsCpCH2qSG=cZjMMuWbpzCn8dQhvaTDaRc1riwnYiKGjsg@mail.gmail.com>
To: tls@ietf.org
Content-Type: multipart/alternative; boundary="001a1145b664cb83d20547f302a1"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/PAuBZELrZ_DiNgz-vbW8C-VfWJY>
Subject: [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: Tue, 07 Feb 2017 16:12:15 -0000

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

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.

Thanks,
Ben Schwartz