Re: [TLS] About encrypting SNI

Eric Rescorla <ekr@rtfm.com> Thu, 17 April 2014 20:20 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 89F831A00B9 for <tls@ietfa.amsl.com>; Thu, 17 Apr 2014 13:20:25 -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 ltimYvAprzEv for <tls@ietfa.amsl.com>; Thu, 17 Apr 2014 13:20:20 -0700 (PDT)
Received: from mail-we0-f175.google.com (mail-we0-f175.google.com [74.125.82.175]) by ietfa.amsl.com (Postfix) with ESMTP id 695AB1A0088 for <tls@ietf.org>; Thu, 17 Apr 2014 13:20:20 -0700 (PDT)
Received: by mail-we0-f175.google.com with SMTP id q58so902812wes.34 for <tls@ietf.org>; Thu, 17 Apr 2014 13:20:16 -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=8d5dcZLnl1quIVy9yuGSg+sJ4yh7M0HxfKcOHdL3QX8=; b=YXxo48nCozrhvVfK/+y+N9CAUd7ny4d+i64cxynD72UxEYdKs+yH8zEIzIBGVh365E 3VMp0Y9gyexqio4pmCip9l7iLVGSpRUfHYVJv8+K6ta6JXtFMcfcRGZET6otMGGKNgUf sQfUwf/p9LpOZRqUaKwngMzaUYtYxa8zGPef4MqzzEVsjLoGP5iyR0Vd7jTG9PLTZ76e +TAKhePPDyW+RqylrnW2RaULiAg3ECkbZJM9AMyngnhjOm6myoJx7Z0zXNURjqWDaUss UptKcK4Z9R4bHnvMHDWR+sCjqiX0yavvx5DM/mPPFEvc9gygLFCQ8JZu3od88kuwvelz J/+Q==
X-Gm-Message-State: ALoCoQnJCGWPeJRFpPgYj7Yw7nxK2Bp9JBzlLwMXbsWHeIYR3p29KtLSUtvd8pBd0Mo/iTMcW+lO
X-Received: by 10.180.94.226 with SMTP id df2mr25343198wib.1.1397766016124; Thu, 17 Apr 2014 13:20:16 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.216.218.198 with HTTP; Thu, 17 Apr 2014 13:19:36 -0700 (PDT)
X-Originating-IP: [63.245.221.34]
In-Reply-To: <m238hblob1.fsf@usma1mc-0csx92.kendall.corp.akamai.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> <m2k3apmjk2.fsf@usma1mc-0csx92.kendall.corp.akamai.com> <CALCETrU6zn52yX=Q-_h4epR6W9+f2oTr3yfyK1sxiwGa2dvWGw@mail.gmail.com> <CAKC-DJgNvF=hhwoyRNkJ3vKz9EZ_JpoM84bCip6eProLwsQsEg@mail.gmail.com> <CALCETrWY_-N+nM9N0_gbeffkX5Jo8vn7XKeFCezGiwq2A74Wjw@mail.gmail.com> <CAKC-DJg6kRLezM+Q60VLY=dBU9C_Q9hb_0u7WD-HHWVJ5Y6tRQ@mail.gmail.com> <CALCETrX7Dv9_+uM7VqotHGurS+k6K5wKzeXEj7zuekd8+0qOJQ@mail.gmail.com> <566E6D8E-ACD5-4B21-9586-84C149F6A1B9@akamai.com> <CALCETrUi+fc9LW1iqx0bFuAsgygmeorR9AnzLN+abGx08y152A@mail.gmail.com> <5204AB60-0B32-4953-9D3D-C2756883D39D@akamai.com> <CALCETrXOaNihRRNQ3RQsctbipAGq67cSUofOm0AOb-YWENFFwQ@mail.gmail.com> <m238hblob1.fsf@usma1mc-0csx92.kendall.corp.akamai.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Thu, 17 Apr 2014 13:19:36 -0700
Message-ID: <CABcZeBN0i9Su1SuY6AZE7MBbPEPXRKAVQ1k7b+vOJKfpPEw3Ww@mail.gmail.com>
To: Brian Sniffen <bsniffen@akamai.com>
Content-Type: multipart/alternative; boundary="f46d04447e61dee40504f742c2e8"
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/wLrYUksxC8ooI_TJ1eVHd0r7Nxc
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: Thu, 17 Apr 2014 20:20:25 -0000

On Thu, Apr 17, 2014 at 12:59 PM, Brian Sniffen <bsniffen@akamai.com> wrote:
>
> I hesitate to ask, but: is it plausible to re-open the proof-of-work
> conversation, so a server under load can, in the initial opportunistic
> encryption phase, push back to a client and ask for a puzzle to be
> solved?


I don't think it's implausible (though I'm not completely sold yet).

One concern I would have is whether we understand the problem well
enough to actually specify this. I'm not an expert in this area, but weren't
there a bunch of concerns about designing puzzles that were effective
without being prohibitively expensive for mobile devices? How would
we design a new kind of puzzle (As opposed to messing with the puzzle
work factor) and then roll it out?

-Ekr

 > I wonder if there's a way to test a large number of private keys at
> > once.  If so, then the cost drops to O(log N).  Off the top of my
> > head, I can't think of a cryptosystem with that property.
>
> I certainly don't expect to find any *pair* of cryptosystems with that
> property, and continue to maintain that in 3 years we won't find two big
> organizations willing to use exactly the same crypto.
>
> -Brian
>
> --
> Brian Sniffen
> Information Security
> Akamai Technologies
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>