[TLS] 'Type B' Extensions (was Re: Pull request for 1RTT Handshake)
Tom Ritter <tom@ritter.vg> Sat, 05 July 2014 12:47 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 791FB1A0505 for <tls@ietfa.amsl.com>; Sat, 5 Jul 2014 05:47:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.379
X-Spam-Level:
X-Spam-Status: No, score=-1.379 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, 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 CjB38MQFSOvQ for <tls@ietfa.amsl.com>; Sat, 5 Jul 2014 05:47:50 -0700 (PDT)
Received: from mail-vc0-x22c.google.com (mail-vc0-x22c.google.com [IPv6:2607:f8b0:400c:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90F141A04F1 for <tls@ietf.org>; Sat, 5 Jul 2014 05:47:50 -0700 (PDT)
Received: by mail-vc0-f172.google.com with SMTP id hy10so2365121vcb.17 for <tls@ietf.org>; Sat, 05 Jul 2014 05:47:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ritter.vg; s=vg; h=mime-version:from:date:message-id:subject:to:cc:content-type; bh=IZxo+4cdpMSC2+Vn0AJGLjBWtNbY8Sq+u7iWlRaIqAw=; b=KuJXwcfKWRP5uafD0++sDELvMb9bK0mmrmEqe2VPJtXfUO14NR71089OCJ+vVKayFr 30x7v9bizYjUYh5jmjP7WINwP48g/mu+qUsXLFgAcDWXUDTEfMoijFRySkHopG6DV39R M1xY2XEMgspVKmHJteIX8Y5qvbTyT9339iCJQ=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc :content-type; bh=IZxo+4cdpMSC2+Vn0AJGLjBWtNbY8Sq+u7iWlRaIqAw=; b=F65tbOjwz3pCoHTP60JUeoKZ055nl7Vq9uOz697zghRD/E6LpJaviNDgLnLku20O/9 1wvvrEPvxJ2txDfzfCIez9upYoHZ2BJnQkSKg8QrjJ0lMezYefG+9khkrqy387/wWPu9 NC5ac4uSmzEhu+PYn8ifcqavh21AntPfKJFvUaFSmUh/quIhTggx2wExUGFLNT27d9Nm NW/GdCaxACdt+1cuoLfyvjIbq+3LWXxvd5bDzPb7FHbqWDYti2pyQE8bV6bw1d9eaGCg /qzEMbWVsDec0cFsuZz86pqh1c8qyEKoFgfzjXqSLae6V/hzhm+16ueBZHhxHFP1yzYo 2pgQ==
X-Gm-Message-State: ALoCoQl2ygCsIMN4V746HBhWkeexnSbSLZE8+fLYzBBro1VRM57IDBcZNtR3I+ppsPYVkuQiDjLo
X-Received: by 10.58.153.4 with SMTP id vc4mr14558367veb.19.1404564469642; Sat, 05 Jul 2014 05:47:49 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.58.108.164 with HTTP; Sat, 5 Jul 2014 05:47:29 -0700 (PDT)
From: Tom Ritter <tom@ritter.vg>
Date: Sat, 05 Jul 2014 08:47:29 -0400
Message-ID: <CA+cU71=3pdFh6bQq5y3MfRWE_bNyR2mSCMTg3yKDRfMwJJ2GWA@mail.gmail.com>
To: Watson Ladd <watsonbladd@gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/uOvyjruM2ISNWaPdihmR4nzSPnw
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: [TLS] 'Type B' Extensions (was Re: Pull request for 1RTT Handshake)
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: Sat, 05 Jul 2014 12:47:51 -0000
On 4 July 2014 23:30, Watson Ladd <watsonbladd@gmail.com> wrote: > Also, I don't recall having seen > 'type B extensions': what was the rationale? How was the answer going > to come back?) They've not been mentioned before because they haven't really been presented for discussion. They're buried in here: http://www.ietf.org/proceedings/interim/2014/05/15/tls/slides/slides-interim-2014-tls-1-4.pdf and they're not that important right now, in comparison to other changes like 1RTT and eSNI. The idea was that since we're going to be encrypting half the handshake starting with a Server-> Client message, we could make extensions that are protected entirely against a passive adversary by making them 'Server Offers, Client Accepts'. Some of the extensions we have could work that way, some could not. -tom