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

Paul Wouters <paul@nohats.ca> Tue, 14 February 2017 19:25 UTC

Return-Path: <paul@nohats.ca>
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 97E161294C2 for <dnsop@ietfa.amsl.com>; Tue, 14 Feb 2017 11:25:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 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] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca
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 6O1yRDE6SKDW for <dnsop@ietfa.amsl.com>; Tue, 14 Feb 2017 11:25:00 -0800 (PST)
Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9BA67129555 for <dnsop@ietf.org>; Tue, 14 Feb 2017 11:25:00 -0800 (PST)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3vNC6d2ZdLz378; Tue, 14 Feb 2017 20:24:57 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1487100297; bh=IQ81KCT+2HcZDfQmpvdnCEBoi53lOWlI7pJdiQ8ZqDg=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=eqtBDffDyeXchmgoZ6MN0a+xisaM/TkQABup4axqTUa4a2EvNVF3ohOTJgDODghgm glU8F9NV7bW+ApNBZ3PpM6voET6L2DvVY6Oc/unD6tNRlZnSudCOIjg27mYW9auMrG xDHEn9YYkfugn8csPmH9YHPsrxTLyl01oT5NcvmM=
X-Virus-Scanned: amavisd-new at mx.nohats.ca
Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id m720gyT_LUFw; Tue, 14 Feb 2017 20:24:54 +0100 (CET)
Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Tue, 14 Feb 2017 20:24:54 +0100 (CET)
Received: by bofh.nohats.ca (Postfix, from userid 1000) id 1F03E2DEFFF; Tue, 14 Feb 2017 14:24:53 -0500 (EST)
DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 1F03E2DEFFF
Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 0A15641DA42F; Tue, 14 Feb 2017 14:24:52 -0500 (EST)
Date: Tue, 14 Feb 2017 14:24:52 -0500 (EST)
From: Paul Wouters <paul@nohats.ca>
To: Ben Schwartz <bemasc@google.com>
In-Reply-To: <CAHbrMsAJ5JRtdjZRkCq4qC3dS_Fx96WBu8DPnJ1sSf=9HErKrw@mail.gmail.com>
Message-ID: <alpine.LRH.2.20.1702141415360.31528@bofh.nohats.ca>
References: <CAHbrMsAJ5JRtdjZRkCq4qC3dS_Fx96WBu8DPnJ1sSf=9HErKrw@mail.gmail.com>
User-Agent: Alpine 2.20 (LRH 67 2015-01-07)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII; format=flowed
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/YcZognNBVLShhWb1colfZFNQshQ>
Cc: 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:25:02 -0000

On Tue, 14 Feb 2017, Ben Schwartz wrote:

> 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.
> 
> https://tools.ietf.org/html/draft-schwartz-dns-sni-01
> I've incorporated some helpful feedback [1] from the TLS WG, but now I could use your help analyzing the DNS side. All comments
> welcome; this draft will change based on your feedback.

This seems like a bandaid to TLS that I think just needs
fixing in the TLS protocol.

If I was a passive attacker logging lots of traffic, I would just
query the SNI's of all major sites (and/or any other A/AAAA records
I encounter while monitoring the traffic streams) so the protection
this offers is lost very quickly.

I don't think the additional TLS to DNS "ephemeral SNI" synchronisation
is worth the trouble. It would make more sense to have the TLS
client take the hit of some additional roundtrip to the server to
convey this privately after the EDH.

Also, it would make more sense to actually use the TLS server PUBKEY
for this, if the server uses the same pubkey for a lot of certificates
or SubjectAltNames. It is just as meaningless to the observer as an
ephemeral SNI, but now the TLS server can select the proper key if
it is configured with multiple different keypairs.

Paul