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

"John Levine" <> Wed, 15 February 2017 23:10 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 84D9E129721 for <>; Wed, 15 Feb 2017 15:10:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Z9q--fxDkT36 for <>; Wed, 15 Feb 2017 15:10:30 -0800 (PST)
Received: from ( [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B4912129952 for <>; Wed, 15 Feb 2017 15:10:29 -0800 (PST)
Received: (qmail 19880 invoked from network); 15 Feb 2017 23:10:28 -0000
Received: from unknown ( by with QMQP; 15 Feb 2017 23:10:28 -0000
Date: 15 Feb 2017 23:10:06 -0000
Message-ID: <20170215231006.19946.qmail@ary.lan>
From: "John Levine" <>
In-Reply-To: <>
X-Headerized: yes
Mime-Version: 1.0
Content-type: text/plain; charset=utf-8
Content-transfer-encoding: 8bit
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:10:31 -0000

>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:
>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?

"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.