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
- [TLS] About encrypting SNI Salz, Rich
- Re: [TLS] About encrypting SNI Martin Thomson
- Re: [TLS] About encrypting SNI Salz, Rich
- Re: [TLS] About encrypting SNI Watson Ladd
- Re: [TLS] About encrypting SNI Russ Housley
- Re: [TLS] About encrypting SNI Eric Rescorla
- Re: [TLS] About encrypting SNI Brian Sniffen
- Re: [TLS] About encrypting SNI Alyssa Rowan
- Re: [TLS] About encrypting SNI Nick Mathewson
- Re: [TLS] About encrypting SNI Daniel Kahn Gillmor
- Re: [TLS] About encrypting SNI Sniffen, Brian
- Re: [TLS] About encrypting SNI Yoav Nir
- Re: [TLS] About encrypting SNI Salz, Rich
- Re: [TLS] About encrypting SNI Seth David Schoen
- Re: [TLS] About encrypting SNI Nico Williams
- Re: [TLS] About encrypting SNI Watson Ladd
- Re: [TLS] About encrypting SNI Salz, Rich
- Re: [TLS] About encrypting SNI Yoav Nir
- Re: [TLS] About encrypting SNI Salz, Rich
- Re: [TLS] About encrypting SNI Watson Ladd
- Re: [TLS] About encrypting SNI Salz, Rich
- Re: [TLS] About encrypting SNI Eric Rescorla
- Re: [TLS] About encrypting SNI Alyssa Rowan
- Re: [TLS] About encrypting SNI Salz, Rich
- Re: [TLS] About encrypting SNI Martin Rex
- Re: [TLS] About encrypting SNI Eric Rescorla
- Re: [TLS] About encrypting SNI Eric Rescorla
- Re: [TLS] About encrypting SNI Andy Lutomirski
- Re: [TLS] About encrypting SNI Eric Rescorla
- Re: [TLS] About encrypting SNI Tom Ritter
- Re: [TLS] About encrypting SNI Brian Sniffen
- Re: [TLS] About encrypting SNI Andy Lutomirski
- Re: [TLS] About encrypting SNI Andy Lutomirski
- Re: [TLS] About encrypting SNI Salz, Rich
- Re: [TLS] About encrypting SNI Eric Rescorla
- Re: [TLS] About encrypting SNI Watson Ladd
- Re: [TLS] About encrypting SNI Brian Sniffen
- Re: [TLS] About encrypting SNI Andy Lutomirski
- Re: [TLS] About encrypting SNI Andy Lutomirski
- Re: [TLS] About encrypting SNI Sniffen, Brian
- Re: [TLS] About encrypting SNI Andy Lutomirski
- Re: [TLS] About encrypting SNI Alyssa Rowan
- Re: [TLS] About encrypting SNI Michael D'Errico
- Re: [TLS] About encrypting SNI James Cloos
- Re: [TLS] About encrypting SNI Jacob Appelbaum
- Re: [TLS] About encrypting SNI Andy Lutomirski
- Re: [TLS] About encrypting SNI Erik Nygren
- Re: [TLS] About encrypting SNI Andy Lutomirski
- Re: [TLS] About encrypting SNI Jacob Appelbaum
- [TLS] Forged RST (was: About encrypting SNI) Alyssa Rowan
- Re: [TLS] Forged RST (was: About encrypting SNI) Eric Rescorla
- Re: [TLS] About encrypting SNI Paul Lambert
- Re: [TLS] About encrypting SNI Andy Lutomirski
- Re: [TLS] About encrypting SNI Erik Nygren
- Re: [TLS] About encrypting SNI Andy Lutomirski
- Re: [TLS] Forged RST (was: About encrypting SNI) Yoav Nir
- Re: [TLS] About encrypting SNI Sniffen, Brian
- Re: [TLS] Forged RST (was: About encrypting SNI) Erik Nygren
- Re: [TLS] About encrypting SNI James Cloos
- Re: [TLS] Forged RST Stephen Farrell
- Re: [TLS] About encrypting SNI Andy Lutomirski
- Re: [TLS] Forged RST (was: About encrypting SNI) Nico Williams
- Re: [TLS] About encrypting SNI Erik Nygren
- Re: [TLS] About encrypting SNI Sniffen, Brian
- Re: [TLS] About encrypting SNI Andy Lutomirski
- Re: [TLS] About encrypting SNI Martin Thomson
- Re: [TLS] About encrypting SNI Brian Sniffen
- Re: [TLS] About encrypting SNI Eric Rescorla
- Re: [TLS] About encrypting SNI Sniffen, Brian
- Re: [TLS] About encrypting SNI Erik Nygren
- Re: [TLS] Forged RST (was: About encrypting SNI) Bill Frantz
- Re: [TLS] Forged RST (was: About encrypting SNI) Yoav Nir
- Re: [TLS] Forged RST (was: About encrypting SNI) Bill Frantz
- Re: [TLS] Forged RST (was: About encrypting SNI) Eric Rescorla
- Re: [TLS] Forged RST (was: About encrypting SNI) Watson Ladd
- Re: [TLS] Forged RST (was: About encrypting SNI) Eric Rescorla
- Re: [TLS] About encrypting SNI Marsh Ray
- Re: [TLS] About encrypting SNI Martin Rex
- Re: [TLS] About encrypting SNI David Holmes
- Re: [TLS] About encrypting SNI Brian Sniffen
- Re: [TLS] About encrypting SNI Marsh Ray
- Re: [TLS] About encrypting SNI Marsh Ray
- Re: [TLS] About encrypting SNI Nico Williams
- Re: [TLS] About encrypting SNI Andy Lutomirski
- Re: [TLS] About encrypting SNI Michael D'Errico
- Re: [TLS] About encrypting SNI Watson Ladd
- Re: [TLS] About encrypting SNI Erik Nygren
- Re: [TLS] About encrypting SNI Salz, Rich
- Re: [TLS] About encrypting SNI Daniel Kahn Gillmor
- Re: [TLS] About encrypting SNI Salz, Rich
- Re: [TLS] About encrypting SNI - Traffic Analysis… Michael StJohns
- Re: [TLS] About encrypting SNI - Traffic Analysis… Nico Williams
- Re: [TLS] About encrypting SNI - Traffic Analysis… Stephen Farrell
- Re: [TLS] About encrypting SNI - Traffic Analysis… Martin Rex
- Re: [TLS] About encrypting SNI Nikos Mavrogiannopoulos
- Re: [TLS] About encrypting SNI Salz, Rich
- Re: [TLS] About encrypting SNI Stephen Farrell
- Re: [TLS] About encrypting SNI Andy Lutomirski
- Re: [TLS] About encrypting SNI - Traffic Analysis… Martin Thomson
- Re: [TLS] About encrypting SNI - Traffic Analysis… Tom Ritter
- Re: [TLS] About encrypting SNI Brian Sniffen
- Re: [TLS] About encrypting SNI Fabrice
- Re: [TLS] About encrypting SNI Jacob Appelbaum
- Re: [TLS] About encrypting SNI Paul Lambert
- Re: [TLS] About encrypting SNI Yoav Nir
- Re: [TLS] About encrypting SNI Daniel Kahn Gillmor
- Re: [TLS] About encrypting SNI Tim Bray
- Re: [TLS] About encrypting SNI Jacob Appelbaum
- Re: [TLS] About encrypting SNI Paul Hoffman
- Re: [TLS] About encrypting SNI Viktor Dukhovni
- Re: [TLS] About encrypting SNI Brian Sniffen
- Re: [TLS] About encrypting SNI Yoav Nir