Re: [TLS] About encrypting SNI

Nico Williams <nico@cryptonector.com> Tue, 13 May 2014 00:39 UTC

Return-Path: <nico@cryptonector.com>
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 B77561A07B8 for <tls@ietfa.amsl.com>; Mon, 12 May 2014 17:39:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.044
X-Spam-Level:
X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] 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 DGMhEVzn2Mnt for <tls@ietfa.amsl.com>; Mon, 12 May 2014 17:39:01 -0700 (PDT)
Received: from homiemail-a104.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 5EE8E1A07B3 for <tls@ietf.org>; Mon, 12 May 2014 17:39:01 -0700 (PDT)
Received: from homiemail-a104.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a104.g.dreamhost.com (Postfix) with ESMTP id 021562007F227 for <tls@ietf.org>; Mon, 12 May 2014 17:38:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=5+0o2+keullUilSu6z9h aMHy9vY=; b=jprf2VL9IapL/I5BIjP4sDFpOda5t5bxMX7w2gQvGt6fLekRH3AD IoMKMGexDprpLVGIs+zusHJ5Eb2QDecm5pLad9jPbSq+t9XdkudQG1s3d3XTftyM 1l+UhaRlj2L4J0hyFRbG/clIf1L3OOuNFXzJ7VJQOn9QC5OkmhnkUsc=
Received: from mail-wi0-f177.google.com (mail-wi0-f177.google.com [209.85.212.177]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a104.g.dreamhost.com (Postfix) with ESMTPSA id ABB9F2007F226 for <tls@ietf.org>; Mon, 12 May 2014 17:38:54 -0700 (PDT)
Received: by mail-wi0-f177.google.com with SMTP id f8so5403813wiw.16 for <tls@ietf.org>; Mon, 12 May 2014 17:38:53 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.180.77.225 with SMTP id v1mr17940190wiw.5.1399941533290; Mon, 12 May 2014 17:38:53 -0700 (PDT)
Received: by 10.216.29.200 with HTTP; Mon, 12 May 2014 17:38:53 -0700 (PDT)
In-Reply-To: <CA+cU71kFo6EihTVUrRRtBYEHbZwCa9nZo-awt4Sub2qXcKHC7g@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> <CA+cU71kFo6EihTVUrRRtBYEHbZwCa9nZo-awt4Sub2qXcKHC7g@mail.gmail.com>
Date: Mon, 12 May 2014 19:38:53 -0500
Message-ID: <CAK3OfOi1x9huaazwcO=d72mfOFuV_RyXnfHmFRduhhbJE2miYw@mail.gmail.com>
From: Nico Williams <nico@cryptonector.com>
To: Tom Ritter <tom@ritter.vg>
Content-Type: text/plain; charset="UTF-8"
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/bpW2rOvEoQxFV7XqhmsQYQLN_ns
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: Tue, 13 May 2014 00:39:02 -0000

On Wed, Apr 16, 2014 at 8:53 AM, Tom Ritter <tom@ritter.vg> wrote:
> ....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

I've been thinking of this for a while...

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

Layers aren't pure though.  Some things show through the various
layers' interfaces, sometimes several layers through.

For example, many apps have to deal with all of DNS and TCP/IP, with
IP addresses and TCP port numbers used together in socket APIs.  It
might have been a lot better if the sockets APIs had deal with
hostnames from the start, but here we are.  Abstractions are leaky.

Now in this case I think saving a client a number of DNSSEC lookups
could be convenient.  We should -of course- make sure that this works
out securely -- we don't want to end up with a cache poisoning attack
here.

Nico
--