Re: [TLS] About encrypting SNI

Andy Lutomirski <luto@amacapital.net> Thu, 17 April 2014 14:52 UTC

Return-Path: <luto@amacapital.net>
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 2B9F31A0179 for <tls@ietfa.amsl.com>; Thu, 17 Apr 2014 07:52:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.979
X-Spam-Level:
X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] 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 1gz8hjq2WCGC for <tls@ietfa.amsl.com>; Thu, 17 Apr 2014 07:52:41 -0700 (PDT)
Received: from mail-la0-f54.google.com (mail-la0-f54.google.com [209.85.215.54]) by ietfa.amsl.com (Postfix) with ESMTP id 0341C1A0240 for <tls@ietf.org>; Thu, 17 Apr 2014 07:52:40 -0700 (PDT)
Received: by mail-la0-f54.google.com with SMTP id mc6so460190lab.41 for <tls@ietf.org>; Thu, 17 Apr 2014 07:52:36 -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=nXO9c9CjVVz3vKxBGKv03TRna7I28i8JGFOgPlDv+4Q=; b=nLo3hOHw5q26CAouSt+vqd0LTtRFmT7pImhmkHqClk0buTelM6sCpzlGFls+MygMrx DVR9ve4+XiNTzLHotgA7DZXXmquYEXmhKwdbe8rRgfjVYoLZkxTer8TeBuOgsAgEAOtV zAJmKm3gcX6pmuxVT94vbTZDovDrCKPA0k58rCy4/MLeh9G+/63uj114AaV84ROffYQT Qqbt6XHSLyLjV7J5HAUIlRvNF0NWeESnOkgKIb/vDkgIHQ5mGqMmYiFjcZOV9ncq3+FP DJC0suMmT0IYZg1/Vy8FbNfoTJcm8vV9fgkfgSiZKzIjnVh6A5U3fRTxjlNmuDf0hmFH 1tEg==
X-Gm-Message-State: ALoCoQkIwNvnITHoxnM2tn8UZ7E+Mbsrug4lAwnnXY6cQlaWoN/kyrVQImp1Dcd/ej+WWOhY3nsj
X-Received: by 10.112.150.162 with SMTP id uj2mr1581632lbb.52.1397746356797; Thu, 17 Apr 2014 07:52:36 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.152.21.7 with HTTP; Thu, 17 Apr 2014 07:52:16 -0700 (PDT)
In-Reply-To: <566E6D8E-ACD5-4B21-9586-84C149F6A1B9@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>
From: Andy Lutomirski <luto@amacapital.net>
Date: Thu, 17 Apr 2014 07:52:16 -0700
Message-ID: <CALCETrUi+fc9LW1iqx0bFuAsgygmeorR9AnzLN+abGx08y152A@mail.gmail.com>
To: "Sniffen, Brian" <bsniffen@akamai.com>
Content-Type: text/plain; charset="UTF-8"
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/L3kW90YiSKLY6SLrb_YGEIO7jHc
Cc: "tls@ietf.org" <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: Thu, 17 Apr 2014 14:52:45 -0000

On Thu, Apr 17, 2014 at 6:16 AM, Sniffen, Brian <bsniffen@akamai.com> wrote:
> On Apr 16, 2014, at 10:08 PM, "Andy Lutomirski" <luto@amacapital.net> wrote:
>>
>> You still only need four.  Remember that my ClientHello key is
>> completely independent of the key associated with the server
>> certificate, and that it can be stripped.
>
> Do I understand that you intend one for normal operation, one more during rotations---and then for my example that different people want different crypto, another operation/rotation pair?

Yes.

>
> I can imagine that working well in 2015.  I think in 2020 we'll surely find it too tight and chafing. Maybe that is enough.
>

I'd much rather allow an unlimited number of keys, but it's not
obvious to me that it's possible to do that.

I think that we need a protocol in which Bob knows N private keys,
Alice knows one of those keys, Alice can encrypt a message to Bob
using that key, Bob can decrypt it in time t(N), and an eavesdropper
who does not know any of the private keys can't distinguish the
message from random?

My protocol has t(N) linear in N -- Bob does tries decrypting with
each key.  Does anyone know of a protocol that scales better?

If we're willing to lose a bunch of the nice properties, we could just
include a short has of the public key.  To me, that seems like a
tradeoff that we'd be better off without.

--Andy