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

Ben Schwartz <> Wed, 15 February 2017 23:48 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9D6B7129BEB for <>; Wed, 15 Feb 2017 15:48:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.7
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 221fXCQwhF0N for <>; Wed, 15 Feb 2017 15:48:43 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4001:c0b::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0EB12129BEA for <>; Wed, 15 Feb 2017 15:48:43 -0800 (PST)
Received: by with SMTP id d9so29169550itc.0 for <>; Wed, 15 Feb 2017 15:48:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=NgRZExdn2/1H0a888Mt52RUPMGmqghF81b8sQOKSgMI=; b=vK5uyYu3o0oqG1pl3WVSeJwe8oVDYHuXO0C/Q6/sgb++pqprLN4Ep9uRTBZ7U4Xm7k ey15x2+Pr+O8mMo0Ch4JozvIhA/uwnObiPq6XIZ+SvqDVvIgz9CWasIRh7RpQIxgtTuP nFhM2lJz617a6e0oEqpVJYx6kiRwoSXWM3DDN69oiRrv5jZSBwfrFsp/gJjDG92Vocft PRUhn497N0yKacCxK5r5B4ZF8xbT5kanPigTU/efYpvm1+immEgAcM2vlySf9Kumg2bh +UXyDXU2N4WthnTIRYOqfwx1yrAbFuWbfsQKHKup5lvof783HwSi8vK/9QH/e373mJmy Cylw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=NgRZExdn2/1H0a888Mt52RUPMGmqghF81b8sQOKSgMI=; b=DXtY+I4gEWCbnZ9qw351BRKFMaGpSbMA5Jb0KPEReHjjqnuZ5nFcAaLcC/foqEmiPZ dRZBBBnHF3m274TUFcVo8vCZjdK+/dWzPNJ2NoRUNKfT9W8clsXoiTIBbVEq4XDSZq7d 8LJ/gpbVSv9Uq+qV1PWHdCRm6BZ5VYOivdIzWQwkl/K7oenE2l+UG+6+WHFlj5qPiAsH YpdPL7QvdRY3kfn2PfhcenkfcecuxzOjLd35PYZG4Z3OcUwpV2nbXN6Uu3zsD8c+wNGR JnDQx2sJ4u/oI1K8s3whSoJIj2hituS//PfD6DJBGW665kupogWPzM6kVT9Tq6c3z+hR 06hg==
X-Gm-Message-State: AMke39nrMsfdVh6Q7t2ZFMcEBe1UdwXmi3ko8pcv9rFqeKvUsa4ePTbCoDo+6xk166l8UX4TsHrfdTMkMGqNpPf5
X-Received: by with SMTP id p70mr11364113itc.115.1487202522109; Wed, 15 Feb 2017 15:48:42 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Wed, 15 Feb 2017 15:48:41 -0800 (PST)
In-Reply-To: <20170215231006.19946.qmail@ary.lan>
References: <> <20170215231006.19946.qmail@ary.lan>
From: Ben Schwartz <>
Date: Wed, 15 Feb 2017 18:48:41 -0500
Message-ID: <>
To: John Levine <>
Content-Type: multipart/alternative; boundary=001a114a9de80a982605489a52cc
Archived-At: <>
Subject: Re: [DNSOP] Proposal for a new record type: SNI
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 15 Feb 2017 23:48:44 -0000

On Wed, Feb 15, 2017 at 6:10 PM, John Levine <> wrote:

> >I'm /soooo/ not a TLS person, but I think that this was discussed in
> >the TLS WG and didn't make it into the final spec -- it requires (at
> >least) an additional RTT. You do get SNI encryption with Zero-RTT, but
> >it's too later by then...
> >Some slideware:
> 94-tls-8.pdf
> >The DNS SNI lookup could at least be done in parallel with the
> >"normal" DNS one (and, possibly returned in a
> >draft-wkumari-dnsop-multiple-responses answer :-))
> To put it baldly, if it is a problem that SNI leaks, the solution is
> to fix SNI.  This is not a solution, it is at most a band-aid that
> will deter a subset of unsophisticated snoops while adding useless
> complexity to https.  For example, what are users supposed to do when
> the SNI DNS records and the SNI mapping in the servers inevitably get
> out of sync?

FWIW, the draft recommends users retry with whatever their behavior would
have been otherwise, effectively imposing a one roundtrip penalty in this
failure case.

> "But fixing SNI is hard" isn't a good reason to do this.  I understand
> that adding an extra round trip to the handshake would be a problem,
> but I am a long way from believing that's the only way to fix SNI.

Removing SNI without adding an extra roundtrip to every SSL connection
logically requires the client to learn an additional piece of information
about the server before it contacts the server.  In a typical situation
(e.g. hyperlink following), the client's only initial piece of information
about the server is its domain name.

Mapping a domain name to information about the thing that lives at that
domain name is the defining characteristic of the DNS.  It seems to me,
therefore, that any solution to the SNI problem must either use DNS or
reinvent DNS.  I'd prefer the former.

There are certainly alternative ways that we could use DNS (e.g. publishing
a public key).  Of the available options, I felt this was the simplest.  I
think it could reasonably be extended to a more sophisticated solution if
one were developed.

> R's,
> John
> _______________________________________________
> DNSOP mailing list