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

Ben Schwartz <bemasc@google.com> Wed, 15 February 2017 02:09 UTC

Return-Path: <bemasc@google.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 9513C129478 for <dnsop@ietfa.amsl.com>; Tue, 14 Feb 2017 18:09:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 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_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 JnC7uI3-OZK5 for <dnsop@ietfa.amsl.com>; Tue, 14 Feb 2017 18:09:07 -0800 (PST)
Received: from mail-it0-x22b.google.com (mail-it0-x22b.google.com [IPv6:2607:f8b0:4001:c0b::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45A6D12944A for <dnsop@ietf.org>; Tue, 14 Feb 2017 18:09:07 -0800 (PST)
Received: by mail-it0-x22b.google.com with SMTP id c7so57473543itd.1 for <dnsop@ietf.org>; Tue, 14 Feb 2017 18:09:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=LpgFbPjrBJub0MEtUz5m+2B+SbuIcz9oOd1Wc9ad5ms=; b=ZrT8YzK27rIoiAH0kaW9FCYiQclT4xDMx+NgPCoG574ZqCztzvkcqnCbD0aTBZDNdr 6ZelyrMPfwiGqT9yEO2OwY+fg+U4qL3K1kWqpB3VsRz2BGp+X2zOE79dS/jynkIewjE/ JqSQZ2U0ERmqnUgIIMfXoic4Du/Uuh/qi7aTOzpitW+JDzaxzKPONLEYT8kjm13pLI0o iNPr7Y2C1aseMvNqhjCSz1KiHol/EKUcpmfmP1U2nTJWyG6HWkr682c9O1LJgp2EMEvw dIELegpwT2509KyZJpMqQNqEBnGkkcNYYpEGOR0pw2qPQ3eu8nSaixt3n9fKuURGy6kN s+Qg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=LpgFbPjrBJub0MEtUz5m+2B+SbuIcz9oOd1Wc9ad5ms=; b=XIVHIjNkTwyCCNz0k27yk+qMOwyJW0SOHvb/Equs9oS1H7/LZovs+C3+/9Fohgzxyt YwGFd2Wyn0wE+PF81p4rmmHin+ETYHbm8YIuBbwICnoSLaIcRwvQvE2SBcYQqFx8KzcE OdMMaC2C8i/2Smb9MIIr/ff57zPA/VPDuKshGrwBRthVJfArWFb1YlTBQtwH1Wx8prdi N5h+MS7fIRGJlq2XRb8MdrYf8ewc29O10ASiGNyK0DrhYarxKcuFMJdrAn3+cwpC5aCu ahfSb7fvVqKgBrGGJ7EA5xzOeacAdj8oyx4Idm4McyefJOqisat+ukJpYqMYmCDKjMm1 llng==
X-Gm-Message-State: AMke39m9krLVxKkOkRmpFe2M+IgoQhCL/6U9MZItbhCjrWA9ViRfqjWTosiY2/2B1YAanP/K1bVAIJaWOzqpEc2z
X-Received: by 10.36.120.73 with SMTP id p70mr6645820itc.115.1487124546359; Tue, 14 Feb 2017 18:09:06 -0800 (PST)
MIME-Version: 1.0
Received: by 10.107.135.164 with HTTP; Tue, 14 Feb 2017 18:09:05 -0800 (PST)
In-Reply-To: <em7c413932-28f0-4bd0-814e-c8450c0a8182@bodybag>
References: <CAHbrMsAJ5JRtdjZRkCq4qC3dS_Fx96WBu8DPnJ1sSf=9HErKrw@mail.gmail.com> <20170214191615.rwawyluf6nf4lfnm@mycre.ws> <CAHbrMsCOMrRzDLC+xXFnXr_vC=0pwpOdL+_Y87QjrB563XxTCg@mail.gmail.com> <em7c413932-28f0-4bd0-814e-c8450c0a8182@bodybag>
From: Ben Schwartz <bemasc@google.com>
Date: Tue, 14 Feb 2017 21:09:05 -0500
Message-ID: <CAHbrMsAiUokXmQnWq2j_AF7pyVm+8NrQ6jUz83gEJMV_oqNMgw@mail.gmail.com>
To: Adrien de Croy <adrien@qbik.com>
Content-Type: multipart/alternative; boundary=001a114a9de8532f5d0548882ab2
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/aO7gK6pHPxoeiellzZ6jwq_dWEM>
Cc: Robert Edmonds <edmonds@mycre.ws>, "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: Wed, 15 Feb 2017 02:09:09 -0000

On Tue, Feb 14, 2017 at 7:51 PM, Adrien de Croy <adrien@qbik.com> wrote:

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

The draft says:


   A passive adversary who monitors the client's DNS queries could learn
   which domain the client is accessing, defeating the confidentiality
   benefits of this record type.  Therefore, clients wishing to conceal
   browsing history from a passive adversary SHOULD also use DNS over
   TLS [RFC7858 <https://tools.ietf.org/html/rfc7858>].  However,
clients MAY use SNI records with standard
   DNS, in order to provide protection against a weak passive adversary
   who can monitor only the link between the client and the TLS server,
   not the link between the client and the DNS server.


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

Interesting observation!  I'll add a note.  However, I don't think this is
a big problem.  The goal is not to hide which certificate is being used.
The goal is to hide which domain is being accessed within a multi-domain
(SAN/UCC or wildcard) certificate.


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