Re: [TLS] About encrypting SNI

Tom Ritter <tom@ritter.vg> Wed, 16 April 2014 13:54 UTC

Return-Path: <tom@ritter.vg>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70D6E1A01A7 for <tls@ietfa.amsl.com>; Wed, 16 Apr 2014 06:54:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.321
X-Spam-Level: *
X-Spam-Status: No, score=1.321 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, SPF_PASS=-0.001] autolearn=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 hwLIqCinUvV3 for <tls@ietfa.amsl.com>; Wed, 16 Apr 2014 06:54:16 -0700 (PDT)
Received: from mail-pa0-x22d.google.com (mail-pa0-x22d.google.com [IPv6:2607:f8b0:400e:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id E41EE1A019B for <tls@ietf.org>; Wed, 16 Apr 2014 06:54:15 -0700 (PDT)
Received: by mail-pa0-f45.google.com with SMTP id kl14so10947919pab.4 for <tls@ietf.org>; Wed, 16 Apr 2014 06:54:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ritter.vg; s=vg; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=P+/tJ5VSTFsOoBrKfHOemFUJkLg08Ne3O6jcgy8QnYY=; b=Eey4ZPNzmYR2ina3+rE2VBIoKnT4x0yh76R9uX29woHArOeiRh1i4Od1iWKwHn/7kE oABJcVC/iP8mPzj34vWi713qps3YmNzvszJ2/j9A5x2N4tYSGYPTa/+wVlJCHeI9tw0G No0AnR2GxaVOf6xra04Tg/gpCgAvvV/ntVDFI=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=P+/tJ5VSTFsOoBrKfHOemFUJkLg08Ne3O6jcgy8QnYY=; b=RtqlxuV6bWqfVJmOf3CoSZK5Kqh+9JvKDy4Bt0gGLtxWdVg7/agJibnVF8inYnyjcA juWNB4/WsPNr7TAa44C0+dSjReYqp5IHPxhadqgVUVaCrM7FqM8RGmrRiMHtNJt6T/29 mUf2/KmrrloDX9leOJPjFZ4dqYgbQgBv52mrxi1794gfdH+sFrDZsFBLwHeOZ/mYr6Wn lF+LyWiclGtBh+K/AiwEDFxCFF537RAFbDzquArQoCOTGJUhK3xqFSCiMoe8mgX51lau iqqURfR5ZuAsATr8D6HhS6RB3Z1QJAhDrf9patS4QsMP4D/9+whRM+XpXplYW12QD7DU zTzw==
X-Gm-Message-State: ALoCoQkXaFyuz98Dw6Ll5o+sCZx/s9YiA7dRyA2Wnr0E8cfbqRVoDFSsSaaZA8GzFDlMci/GjVwb
X-Received: by 10.66.140.104 with SMTP id rf8mr8626852pab.107.1397656452581; Wed, 16 Apr 2014 06:54:12 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.68.198.68 with HTTP; Wed, 16 Apr 2014 06:53:51 -0700 (PDT)
In-Reply-To: <CABcZeBOJ7k8Hb9QqCAxJ_uev9g_cb4j361dp7ANvnhOOKsT7NA@mail.gmail.com>
References: <2A0EFB9C05D0164E98F19BB0AF3708C7120A04ED40@USMBX1.msg.corp.akamai.com> <534C3D5A.3020406@fifthhorseman.net> <474FAE5F-DE7D-4140-931E-409325168487@akamai.com> <D2CB0B72-A548-414C-A926-A9AA45B962DA@gmail.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120B490162@USMBX1.msg.corp.akamai.com> <CACsn0cmusUc3Rsb2Wof+dn0PEg3P0bPC3ZdJ75b9kkZ5LDGu_A@mail.gmail.com> <534DB18A.4060408@mit.edu> <CABcZeBOJ7k8Hb9QqCAxJ_uev9g_cb4j361dp7ANvnhOOKsT7NA@mail.gmail.com>
From: Tom Ritter <tom@ritter.vg>
Date: Wed, 16 Apr 2014 09:53:51 -0400
Message-ID: <CA+cU71kFo6EihTVUrRRtBYEHbZwCa9nZo-awt4Sub2qXcKHC7g@mail.gmail.com>
To: Eric Rescorla <ekr@rtfm.com>
Content-Type: text/plain; charset="ISO-8859-1"
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/ovuTzETENRYVe3WV5fUhRnrblaw
Cc: "tls@ietf.org" <tls@ietf.org>, Andy Lutomirski <luto@amacapital.net>
Subject: Re: [TLS] About encrypting SNI
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 16 Apr 2014 13:54:20 -0000

On 15 April 2014 23:50, Eric Rescorla <ekr@rtfm.com> wrote:
> However, it's worth considering
> and I'd love to hear from people who want encrypted SNI what they
> think of this tradeoff.


I don't much like opt-in security or privacy mechanisms. I feel that
over time, people's opinion of their usefulness dwindles, they're
removed in favour of simplicity or performance, and then later on we
realise we wished we had them and wind up having to work around
things.  But the status quo has become to do without, and thus
re-proposing it is a non-starter.  (An example could be OCSP-nonce
requests.)

Furthermore, no offence to Rich, but I suspect if you told him "We'll
build the DNS subdomain forwarding, and you can use that or just not
encrypted SNI", he will choose not to use it. Maybe I'm wrong, but
since he argued against it initially, I'll make the leap.  So making
it opt-in seems to be as equivalent to building an optional feature
that almost no one will use from the beginning.

No matter what we do, we will be defining a new protocol that requires
network operators do a test deployment, change configurations, and
move some inter-operating pieces into play. While I'm sympathetic to
keeping that effort as low as possible, I feel optimising for that
goal is the incorrect optimisation.  Rather, optimising for the best
protocol on the wire, with 0-RTT and 1-RTT, a protected handshake, and
the like is more important.

There are a couple options that can try to address the technical
problems Rich has raised.

The wildcard approach is one way to solve this, and I don't have any
immediate concerns about beyond it's heavy requirement on DNS
integrity. While it's my sincere hope we will have it at least
deployed, I suspect not all clients will have validating resolvers
such that we're willing to bank what will be significant amounts of
dependence on it.

....But... There once was a thing called DNSSEC Stapled Certs
(https://www.imperialviolet.org/2011/06/16/dnssecchrome.html) where a
SSL certificate had a chain of DNSSEC signatures in it, validating it
via DANE (or at that time, a DANE-like mechanism.)  It violates a
layering principal that people hold dearly, shoving DNS information in
other corners it shouldn't be.  But I think it would be necessary for
the wildcard approach to be reliable for clients like browsers.

This DNSSEC chain (from root, to TLD, to the record that
xxx.privacy.org TLSNAMEs to privacy.cdn.com) could be provided by
privacy.org in an HTTP Header, HTML META tag, or other mechanism. The
browser sees this, and then doesn't even need to perform a DNS lookup
for the subdomain when it encounters it.  The application server for
privacy.org only needs a DNSSEC-capable client to retrieve these
records periodically.



Another approach I think can be made to work is the idea of per-IP
shared parameters. A static key, valid for a week, for an IP that
servers 10,000 domains does not seem less secure to me than 10,000 RSA
keys on a server serving 10,000 domains. If you can steal one RSA key,
I don't understand why you could not so target the other 9,999.

CDNs are probably in the _best_ position to rotate these keys quickly,
as a client who is on the internet is more likely to talk to a CDN
every day than any individual domain name.



The idea of the handshake being indistinguishable from random using
Elligator is very very attractive.  Several people in internet
censorship research have lamented that if you build a protocol that is
indistinguishable from random bytes on the wire - you are the _only_
protocol to do so, and thus are distinguishable.  I would love for TLS
1.3/1.4/2.0/whatever to lay out that goal, as I feel we would be
giving the notion of Net Neutrality a powerful gift: Outside
intranets, on the internet itself, all traffic is equal, and you
cannot distinguish between the most popular protocol or
MyFirstRandomProtocol.

-tom