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

"Wessels, Duane" <dwessels@verisign.com> Tue, 14 February 2017 19:33 UTC

Return-Path: <dwessels@verisign.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 9F0101296FA for <dnsop@ietfa.amsl.com>; Tue, 14 Feb 2017 11:33:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.002
X-Spam-Level:
X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=verisign.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 y-oxdCP1PwGG for <dnsop@ietfa.amsl.com>; Tue, 14 Feb 2017 11:33:54 -0800 (PST)
Received: from mail2.verisign.com (mail2.verisign.com [72.13.63.31]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 594A4129559 for <dnsop@ietf.org>; Tue, 14 Feb 2017 11:33:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verisign.com; l=2954; q=dns/txt; s=VRSN; t=1487100835; h=from:to:cc:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=eF8fE1NHpxJtjC31XZ1SwPeixwAkB2rordxeEocV/Xo=; b=IWfzQs3SspOlZDttdujZmd43gzQww3uRud2cW8NqHfFdjRipoE/v3aq1 1bNdZcjcxW9eMNnBaHXtWvPv7bgL0PoTRYbpMjndHECyPbZZAARMBz3oo +cZJz+A2eUdYAeqTAYiP9y0MNitXpDd+QXExxlxzYK8T/FpUs2MkKrK0Y SBiXITNkhMAn10QiJ5qqx6eN3ski1yZmrW19JMe/P/UNTVskUglyoka5j qVU2coKu1IcuUouePlLO0kl0ik55UKY9+SoNxBso2Tt1NcTqdZREVcV+9 Bc8LPbQZa5NptrwJDmIHxlcUo7qdmGNGtfyf0ZHnoZ9IV2optLN7r9Z9v w==;
X-IronPort-AV: E=Sophos;i="5.35,162,1484006400"; d="scan'208";a="1503439"
IronPort-PHdr: =?us-ascii?q?9a23=3AgB4Dkx9ilC8k1/9uRHKM819IXTAuvvDOBiVQ1KB3?= =?us-ascii?q?2+scTK2v8tzYMVDF4r011RmSDNids6oP0rKM+4nbGkU4qa6bt34DdJEeHzQksu?= =?us-ascii?q?4x2zIaPcieFEfgJ+TrZSFpVO5LVVti4m3peRMNQJW2aFLduGC94iAPERvjKwV1?= =?us-ascii?q?Ov71GonPhMiryuy+4ZPebgFIiTanfb9+MBq6oRjNusUInIBvNrs/xhzVr3VSZu?= =?us-ascii?q?9Y33loJVWdnxb94se/4ptu+DlOtvwi6sBNT7z0c7w3QrJEAjsmNXs15NDwuhnY?= =?us-ascii?q?UQSP/HocXX4InRdOHgPI8Qv1Xpb1siv9q+p9xCyXNtD4QLwoRTiv6bpgRRn1gy?= =?us-ascii?q?kFKjE56nnahMxugqxGvBKvqR9xw4DWb4GUKPVwcazScMgGRWpYW8ZdSzBNDp+i?= =?us-ascii?q?Y4YJEuEPPfxYr474p1YWoxexBRejBPj0yjBWgn/2xrU22PkvHwHbxgMgGcwBvH?= =?us-ascii?q?rJp9jyKagTX/66zLLTzTrda/NWwizw6JbWfRA7oPGMRrNwccXXyUU1CwzFiVCQ?= =?us-ascii?q?pJXjMjiI2OoNtG2b4PBhVeKpk2MotQ5wrSKqxsc0jonGmJgZxUzD9SV8xos+ON?= =?us-ascii?q?62SFZjbNK5DJdcrTyWOol4T884Xm1luCg3xqcYtZO0cyUG0IkrywLFZ/CacYWF?= =?us-ascii?q?7AjvWPuRLDtmnn5od7SyjAuo/0e60O3zTMy03U5PripCj9bDqGgA1wfW6sibUv?= =?us-ascii?q?t9+Vqh2SqX2wDT9O5EJUc0mLLAJJ47xL48i54TsEvGHiDsmUX2iKiWdlg4+uS0?= =?us-ascii?q?9ujreKvmqYGGN491kQH+M6sumsqlDeskNQgOWnCX+eW61LL94U30WKhGguEsnq?= =?us-ascii?q?XEsp3XK94XqrO5DgJbyIov9RmyAji+3NQdh3YHLVZFeBydj4juPlHDOO33DPmh?= =?us-ascii?q?jFS3izdk2fTGPqb6D5XTMHfDirbhfa18605Tzgo/18xQ55VRCr0ZOvL8RlfxtM?= =?us-ascii?q?DEDh8+KwG73uDnCM561oMGQm+PA7GWML/csVOS4eIvOeaMbpcPuDnhM/gl++Lu?= =?us-ascii?q?jXghlFAGY6ap2IEYaGukEfl9LEWZZn3sgtgFEWgUpAYxUOvqiFjRGQJUMly/We?= =?us-ascii?q?oH7TEkAZi6H8+XTI2oiaeK9Ci8GZJSayZNDVXaQlnycIDREcgBczmfJtQl2hAZ?= =?us-ascii?q?XL6sAcd12Q6jrxT3z6FPMOfO+zYZupSl399wsb6A3Sou/CB5WpzOm1qGSHt5yz?= =?us-ascii?q?sF?=
X-IPAS-Result: =?us-ascii?q?A2HTAAB8W6NY//SZrQpeGgEBAQECAQEBAQgBAQEBFgEBAQM?= =?us-ascii?q?BAQEJAQEBhAiBCQefSx+TJ4IPgS0FWiaFfAKCPhcBAQEBAQEBAQEBAQKBB4IzG?= =?us-ascii?q?Q89PAEBAQEBASMCOjABAQEBAgE6PwULAgEIDQEKHhAyJQIEDgWJY7IUi2cBAQE?= =?us-ascii?q?BAQEEAQEBAQEBAQEBAQEdhk2CBAiCYoQ+FoM0gjEFj0OMKQYBhm6NIFOIFIYjk?= =?us-ascii?q?xUgAYEAN1EVTgGEMx2BYXWHZiuBA4EMAQEB?=
Received: from brn1wnexcas01.vcorp.ad.vrsn.com (brn1wnexcas01 [10.173.152.205]) by brn1lxmailout01.verisign.com (8.13.8/8.13.8) with ESMTP id v1EJXdw9009100 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 14 Feb 2017 14:33:39 -0500
Received: from BRN1WNEXMBX02.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0301.000; Tue, 14 Feb 2017 14:33:39 -0500
From: "Wessels, Duane" <dwessels@verisign.com>
To: Ben Schwartz <bemasc@google.com>
Thread-Topic: [EXTERNAL] [DNSOP] Proposal for a new record type: SNI
Thread-Index: AQHShuyb/6dMJIvc3kmOxocjw/jhBqFpOHIA
Date: Tue, 14 Feb 2017 19:33:38 +0000
Message-ID: <16A41EBF-8B43-4806-B548-345A1BEA7E96@verisign.com>
References: <CAHbrMsAJ5JRtdjZRkCq4qC3dS_Fx96WBu8DPnJ1sSf=9HErKrw@mail.gmail.com>
In-Reply-To: <CAHbrMsAJ5JRtdjZRkCq4qC3dS_Fx96WBu8DPnJ1sSf=9HErKrw@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.173.152.4]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <E27092FC39E25E459A42702B0B0F495B@verisign.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/nLDMrjbfRkyHF_5VpFt7ZQi33Lw>
Cc: "dnsop@ietf.org" <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 19:33:55 -0000

> On Feb 14, 2017, at 10:02 AM, 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.
> 


Hi Ben,


>    _443._tcp.subdomain1.example.com.  IN SNI subdomain2.example.com

As I read this part I was assuming that the RDATA of the SNI record is an RFC 1035 <domain-name> and the lack of a trailing dot made me twitch a little bit.

It seems to me that you need to decide what the format of the RDATA will be.  Throughout most of the doc it looks like a <domain-name>, but in other places it sounds like an opaque string (particularly the paragraph about extensibility).



>    When initiating a TLS connection to a domain and port, a client
>    application SHOULD query the SNI record for the prefixed domain at
>    the same time as the A or AAAA query, and wait for a response before
>    initiating TLS. 

In the Introduction you said "Clients can make use of this record without adding delay to their connection process" but here the instruction is to wait.  How long should a client wait for a response to its SNI query?

Oh, I see later you wrote: A client application SHOULD NOT delay initiating a TCP connection while waiting for the SNI DNS response.



>    The application MUST discard or ignore any SNI
>    record whose RDATA is not a well-formed domain name or an empty
>    string. 

This might need more clarification.  Here's a place where the RDATA sounds very much like <domain-name>.  But then the empty label "." becomes particularly tricky here because, arguably, a <domain-name> can never be an empty string.


>    If
>    the selected SNI record is present with an empty RDATA (RLENGTH = 0),
>    then the client SHOULD omit the Server Name Indication.

Again, advice here will depend on what you choose for the RDATA format.  If its <domain-name> then you can't really have RDLEN=0.

>    Client applications MUST NOT allow the contents of the SNI record to
>    influence their certificate validation behavior.  The client's
>    certificate validation MUST be based on the user's specified
>    destination, not the RDATA of the SNI DNS record.  

Given this, it sounds like there is no real reason that the SNI value needs to be a domain name.  It could be something else, like an opaque string or an RFC4122 UUID?


I think this doc also needs a privacy considerations that talks about ways it could be abused by server operators.  For example, I think it could be used as a component of a so-called super cookie.  Each client could get a unique SNI from the DNS server, allowing the web site to track individuals.  While you may be improving privacy with respect to passive attackers, it can reduce privacy between web clients and servers.

DW