Re: [TLS] About encrypting SNI

Eric Rescorla <ekr@rtfm.com> Mon, 14 April 2014 17:14 UTC

Return-Path: <ekr@rtfm.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 B877E1A0663 for <tls@ietfa.amsl.com>; Mon, 14 Apr 2014 10:14:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level:
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
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 14fDi2E8tFPa for <tls@ietfa.amsl.com>; Mon, 14 Apr 2014 10:14:20 -0700 (PDT)
Received: from mail-wi0-f169.google.com (mail-wi0-f169.google.com [209.85.212.169]) by ietfa.amsl.com (Postfix) with ESMTP id F378C1A0564 for <tls@ietf.org>; Mon, 14 Apr 2014 10:14:19 -0700 (PDT)
Received: by mail-wi0-f169.google.com with SMTP id hm4so5683211wib.0 for <tls@ietf.org>; Mon, 14 Apr 2014 10:14:17 -0700 (PDT)
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=BlbRDU4/mPWwDU8e60df9T/iQmtbDav3bMkmlCUYSuc=; b=C19n/Z5TVz1DIO+2+7ydtL798YMQyZS4hhGTCe1lZVxHfyud3R+HopQ/PEC+P3Ik3M YJxYuGjC3ioWG48t38iIWElzT3H1ptzyE4iGbgnBXfFzO/9UBndKrdhT5G4LRALrgih+ vFYoDyagThKyle1gIOZEmSU3Dhv0VafdPGvfXrTHMpksDABDc6oGsnsvsXdh1RJbVvLy +RPCd/Ti1nqs56WUW/g3+RuuErWJfraY4n6Q9qeYqgMRkXMxBrYuFTcfYVPpAY2QoHQy 7Rv3FNuvQ7WCvUkERMeVySBZ+y10DKZMkm6jugsGEuf5yTi9S/VVWb+Zj9amJsEcabW1 zF/g==
X-Gm-Message-State: ALoCoQlE7xyTQqCFC6a2u9B8Uzv32kCdvZUa/mibf8brrkC6vsCpHBT1jYBoQhOxINojpd2f1Ghu
X-Received: by 10.180.94.226 with SMTP id df2mr10411953wib.1.1397495656999; Mon, 14 Apr 2014 10:14:16 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.216.218.198 with HTTP; Mon, 14 Apr 2014 10:13:36 -0700 (PDT)
X-Originating-IP: [63.245.221.34]
In-Reply-To: <0B76075A-D9F1-4780-8834-7FF0A1C82999@vigilsec.com>
References: <2A0EFB9C05D0164E98F19BB0AF3708C7120A04ED40@USMBX1.msg.corp.akamai.com> <CACsn0cksJP-cxLKam=r_LGYG5_psL-ecxVxV=pCERn8rbHaGsw@mail.gmail.com> <0B76075A-D9F1-4780-8834-7FF0A1C82999@vigilsec.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Mon, 14 Apr 2014 10:13:36 -0700
Message-ID: <CABcZeBM4putSnhE7_kCVF9hOsUTW9-nc8-TXj-zfhaZcnkrL5Q@mail.gmail.com>
To: Russ Housley <housley@vigilsec.com>
Content-Type: multipart/alternative; boundary="f46d04447e6136086f04f703d03a"
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/58cr_ujFYahUrmHUtIG81sZjBf4
Cc: IETF TLS <tls@ietf.org>
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: Mon, 14 Apr 2014 17:14:24 -0000

On Mon, Apr 14, 2014 at 7:51 AM, Russ Housley <housley@vigilsec.com> wrote:

>
> > I think Rich Salz has outlined very compelling reasons not to support
> SNI.
>
> While I might quibble with a detail here or there, I do agree with the
> conclusion.  If you need to protect SNI, then TOR or to a lesser extent
> TLS-in-TLS can be used.
>

I'm not sure that this addresses the requests I have heard for SNI
encryption which is to conceal the sites people are going to by default
rather than as a special case for the privacy conscious. Hopefully
some of the people who have asked for this (e.g., dkg) will weigh in
but as I understand it, the concern is that if the only people who
attempt to conceal the site being connected to are the privacy
conscious, then that's a signal that those connections are worth
monitoring.

It's certainly the case that there are some additional changes that
would be required to make concealing SNI worth doing
(principally encrypted name resolution, but also a clear model
for how to do traffic padding and other things), but conversely
if we don't change TLS to permit concealing the SNI, then we
won't get as much value from encrypted DNS.

I'm not saying that either of these are slam dunk arguments, but
I wanted to make sure they were on the table.

-Ekr