IETF Logo Mail Archive

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

Ben Schwartz <bemasc@google.com> Sat, 18 February 2017 03:41 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 EB977129463 for <dnsop@ietfa.amsl.com>; Fri, 17 Feb 2017 19:41:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level:
X-Spam-Status: No, score=-2.701 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] 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 v9xtJqrbMNy2 for <dnsop@ietfa.amsl.com>; Fri, 17 Feb 2017 19:41:31 -0800 (PST)
Received: from mail-it0-x22a.google.com (mail-it0-x22a.google.com [IPv6:2607:f8b0:4001:c0b::22a]) (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 11D3C120727 for <dnsop@ietf.org>; Fri, 17 Feb 2017 19:41:31 -0800 (PST)
Received: by mail-it0-x22a.google.com with SMTP id g67so29747378itb.1 for <dnsop@ietf.org>; Fri, 17 Feb 2017 19:41:31 -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=D5hGo+M/RFk3l2C5kUWjcKpGf5H4OYNdf2mt4yGGV/k=; b=Qo+irajc3sB8y03rjSJv6Ei1my2VZU7O2aFEs4Sk0viUjYIhUdMpDkBeNQ6Iwl8gJa r4k63BwvBiK4RsSEDRvsmrdACJmh9bLwolo0FmIJHbyzCEseGnoGRMRtH6sr/4YInZTZ mSNhN70pwhl92XNhPJUXlXBoZye8gVV8RLRCQshbp3KXjOX++Tw0RXOHQ8Q34dV1poE5 jPQ1dsUdzmmDkmvn5KtloB6sOnsSYa+6aG8ZmhIrT/02fUvy1Kng9QhXAhMuBu/d1Anc yNJu4nNdbxUQaEKiLgqfq2PmiKVDzBRC52zvUxoVz4SAm00PZe9457lCnpev3QGmkCMU uHTQ==
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=D5hGo+M/RFk3l2C5kUWjcKpGf5H4OYNdf2mt4yGGV/k=; b=EjHWu7EdP6/E0IVteiRr4QtUpKH688iznFbHgYODNN4tgfzA2Tmp5cj/1IG35b8rWp ha1RiS+nw9HCSx6Psc+GErR1WJ07aKsbTFBEc1gsjKVCGG9gHR7bmiqVTQ6skdUYENBM tb0BdqS2P6dTR5mOttGKAo+Cg12LgYa/8nsW0yJOV1WF83YS4DDyJxjUNTP4QHr7L6wX jp43+x0q+vLCSIGMWCn1CRAncZBv0tsGpn/evI1EjvyXpMqGEjOIJGgdEG6ogQyWhyT5 DVjKMARyMO4NaZjrz77AWj7cT23HkB5kVvQH5VmoLAZyKhL+w+2Od4UcRhf42WfQ/jxq HYLA==
X-Gm-Message-State: AMke39mOlzj23U6OUGfdgj2FRPo1QU2vo6OvFB5XsLuDLXaj4hZGCWGd2eyJG6jbG4757HAYseni4o43ldhu8Vz8
X-Received: by 10.36.25.83 with SMTP id b80mr4767221itb.98.1487389290208; Fri, 17 Feb 2017 19:41:30 -0800 (PST)
MIME-Version: 1.0
Received: by 10.107.135.164 with HTTP; Fri, 17 Feb 2017 19:41:29 -0800 (PST)
In-Reply-To: <alpine.OSX.2.20.1702172143530.94448@ary.qy>
References: <CAHbrMsA278usgFNzxhrsLS6_EfXPeMoAKN65ec0YhCW93oKNYg@mail.gmail.com> <20170217220309.9637.qmail@ary.lan> <CAHbrMsAdgRU6g4E6wCCA0zs6p=yTU4VJE3UWzvsuU5JAtnxaWQ@mail.gmail.com> <alpine.OSX.2.20.1702172143530.94448@ary.qy>
From: Ben Schwartz <bemasc@google.com>
Date: Fri, 17 Feb 2017 22:41:29 -0500
Message-ID: <CAHbrMsApypey9WRvFMzAPupjmts-sdG9N=zuwtP=PZ1cxV=rvg@mail.gmail.com>
To: John R Levine <johnl@taugh.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="001a114401824e292b0548c5ce5e"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/9xW1h9kVmvB9n-q6TX_9Jihcltc>
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: Sat, 18 Feb 2017 03:41:33 -0000

On Fri, Feb 17, 2017 at 9:47 PM, John R Levine <johnl@taugh.com> wrote:

> 1. Multiple domains on the same host set the same SNI record.  Possession
>> of a global DNS database is no help to the adversary.  The adversary still
>> cannot distinguish the domains.  This is the intended use.
>>
>
> Now I'm really confused.  If the SNI value is just a cover name, and the
> client's going to send the real name later, why not just pick a fixed
> impossible cover name like SNI.INVALID and skip the SNI lookup?
>

In that case, one would simply omit the SNI, since it is optional.  The
draft specifies that an empty RDATA instructs the client to omit the SNI.
Currently, most TLS servers do not require SNI at all, so this will often
work ... but there's no way for the client to know ahead of time if it's
safe to omit, so the clients always include it.

The reason to allow non-empty RDATA is to support servers that serve
multiple multi-domain certificates from a single IP address, dispatched by
SNI.  This is common on CDNs and other large internet serving systems.


> Presumably if this became at all popular, everyone will send SNI.INVALID
> so it wouldn't leak anything interesting.
>
> Regards,
> John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY
> Please consider the environment before reading this e-mail. https://jl.ly
>

v2.35.0 | Report a Bug | By Email | System Status