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

"Adrien de Croy" <adrien@qbik.com> Wed, 15 February 2017 00:51 UTC

Return-Path: <adrien@qbik.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 9B85A12945D for <dnsop@ietfa.amsl.com>; Tue, 14 Feb 2017 16:51:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 eKIXfl8btAJ4 for <dnsop@ietfa.amsl.com>; Tue, 14 Feb 2017 16:51:03 -0800 (PST)
Received: from smtp.qbik.com (smtp.qbik.com [122.56.26.1]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E272612706D for <dnsop@ietf.org>; Tue, 14 Feb 2017 16:51:02 -0800 (PST)
Received: From [192.168.1.146] (unverified [192.168.1.146]) by SMTP Server [192.168.1.3] (WinGate SMTP Receiver v9.0.4 (Build 5915)) with SMTP id <0000964626@smtp.qbik.com>; Wed, 15 Feb 2017 13:51:00 +1300
From: "Adrien de Croy" <adrien@qbik.com>
To: "Ben Schwartz" <bemasc@google.com>, "Robert Edmonds" <edmonds@mycre.ws>
Date: Wed, 15 Feb 2017 00:51:00 +0000
Message-Id: <em7c413932-28f0-4bd0-814e-c8450c0a8182@bodybag>
In-Reply-To: <CAHbrMsCOMrRzDLC+xXFnXr_vC=0pwpOdL+_Y87QjrB563XxTCg@mail.gmail.com>
References: <CAHbrMsAJ5JRtdjZRkCq4qC3dS_Fx96WBu8DPnJ1sSf=9HErKrw@mail.gmail.com> <20170214191615.rwawyluf6nf4lfnm@mycre.ws> <CAHbrMsCOMrRzDLC+xXFnXr_vC=0pwpOdL+_Y87QjrB563XxTCg@mail.gmail.com>
User-Agent: eM_Client/7.0.27943.0
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="------=_MB18CF7FD7-3BF0-403F-B801-54CF9AEEDC36"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/v9JOc2TL4NGjrTPLcIzXvLBQf_s>
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
Reply-To: Adrien de Croy <adrien@qbik.com>
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: Wed, 15 Feb 2017 00:51:05 -0000


presuming that the client will have to look up the hostname of the 
destination at some stage, and presuming that a passive network attacker 
may see DNS requests as well as TCP connections, how does this help?

Or does this require the use of DNS over TLS.

And also there will be leakage of certificate IDs in OCSP lookups which 
cannot be secured due to the paradox that would create.  An attacker 
could mine sites for cert IDs and do a reverse mapping from that.

Adrien

------ Original Message ------
From: "Ben Schwartz" <bemasc@google.com>
To: "Robert Edmonds" <edmonds@mycre.ws>
Cc: "dnsop@ietf.org" <dnsop@ietf.org>
Sent: 15/02/2017 9:03:09 AM
Subject: Re: [DNSOP] Proposal for a new record type: SNI

>
>
>On Tue, Feb 14, 2017 at 2:16 PM, Robert Edmonds <edmonds@mycre.ws> 
>wrote:
>>Ben Schwartz 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.
>> >
>> > https://tools.ietf.org/html/draft-schwartz-dns-sni-01 
>><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.
>> >
>> > One particular issue that I could use advice on: should this be a 
>>new
>> > record type, or should it reuse/repurpose an existing type like SRV 
>>or PTR?
>> >
>> > Thanks,
>> > Ben
>> >
>> > [1] https://www.ietf.org/mail-archive/web/tls/current/msg22353.html 
>><https://www.ietf.org/mail-archive/web/tls/current/msg22353.html>
>>
>>Hi, Ben:
>>
>>I'm kind of curious: your examples are pretty HTTP-centric, and HTTP
>>already has some pretty strong features for origins to persistently
>>modify how clients perform TLS, i.e., HTTP Strict Transport Security 
>>and
>>HTTP Public Key Pinning, along with preloading of those settings by 
>>the
>>browser vendors. Why not follow that same model for the functionality 
>>in
>>your draft?
>>
>>--
>>Robert Edmonds
>
>Hi Robert,
>
>While this technique would apply to any use of TLS, you're right that 
>I'm mainly motivated by improvements for HTTPS.
>
>It's true, we could accomplish something like this by preloading a data 
>file into browsers.  In some sense, this is also true for any aspect of 
>DNS!  Obviously, preloading fares very badly when the data in question 
>is valid for short times, or applies to many thousands or millions of 
>domains, and I think both problems apply here.
>
>For example, a CDN that operates DNS on behalf of its customers could 
>apply SNI records to all of their domains.  Preloading all of those 
>domains into every browser seems impractical, and the list will quickly 
>become outdated.
>
>Without preloading, we cannot solve the problem of revealing the 
>destination in the initial connection.
>
>I would also note that HSTS and HPKP could not have been implemented 
>using insecure DNS, given their adversary model.  The SNI record is 
>very different, and does not require DNSSEC.
>
>--Ben