[TLS] Remove EncryptedExtensions from 0-RTT

Martin Thomson <martin.thomson@gmail.com> Thu, 23 June 2016 03:37 UTC

Return-Path: <martin.thomson@gmail.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8208912DEFB for <tls@ietfa.amsl.com>; Wed, 22 Jun 2016 20:37:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 IigO_a8QzaH4 for <tls@ietfa.amsl.com>; Wed, 22 Jun 2016 20:37:16 -0700 (PDT)
Received: from mail-qk0-x234.google.com (mail-qk0-x234.google.com [IPv6:2607:f8b0:400d:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3333912DEFA for <tls@ietf.org>; Wed, 22 Jun 2016 20:37:16 -0700 (PDT)
Received: by mail-qk0-x234.google.com with SMTP id c73so92153392qkg.2 for <tls@ietf.org>; Wed, 22 Jun 2016 20:37:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=OVI0wVRy8u9SSYUlOrq5Wo0yH2eXqroanC+LxxLLnDs=; b=Gocqwr0OC1vkk9CDCs5sdfm3U4YjzlIiHencfiN/Ys4tV9eHjZuxy8/QxJ/Aiald3b BdG6uBW3UFl+WRpc5r4AszC91yIm+OZMNo2T6OLfXb2VxPtj7eO7n+ysFhjoDo+JgswX Ijwr/Qnfj5X5UciQyCBh8c1OksilXfuSNfhvJpssuXDf5LqcJwnmx6Rd4DH9UoOeYVaJ c/hVZy/iVniRH4jaH0nioz67/mRhSMXYzE4H28syDm2k8NYuhtUI+e2/pexavJ9WYmMl LyqvPcyband+1YDuGkUQuyC6eUUnObqLKQ6PJWb31+veKnKCC2ZAqg7/mmW7wbZaSGHq w8sw==
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; bh=OVI0wVRy8u9SSYUlOrq5Wo0yH2eXqroanC+LxxLLnDs=; b=aZ9F4/cRI2rQyhyg9l+RBwpjcj7Dmu5y1sG47DPIIco4VpzUpihUaMMuYwDa8Dy0tT Q9v5heCEPneSYLr4r676mbTwtuNVbEdfNLwLpvY9ps2PYDIvxObof+3SF2IJ8tUsKYg7 GvhF6wbe2Cwo2SWUOYzazFX2Q1NVdwFNQAOa35v3teZrxBcPd8Z1JUXimpvFzl9alsD9 4EtHviQ6VagL+ozeWRoiiiPMnch5QaUHlPk8QEkt1O99AdBTYbMR5VtKHgYjMzKu4/Gd gR2vSqCF+DeWpLx4pUEcVU8RaWNdBsLzhf0eLTXlEgSAo9xyOTUKqWhN+wgduW+s/QH1 tYwQ==
X-Gm-Message-State: ALyK8tL59tjnxnPy4z/2RHyzTdWzxDUkkPJtXXCiBPasYJavcMQhfz01dXkfwj0m82XdtvbRfMZGVknDDsD04g==
X-Received: by 10.55.18.194 with SMTP id 63mr8477445qks.199.1466653034973; Wed, 22 Jun 2016 20:37:14 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.140.22.38 with HTTP; Wed, 22 Jun 2016 20:37:14 -0700 (PDT)
From: Martin Thomson <martin.thomson@gmail.com>
Date: Thu, 23 Jun 2016 13:37:14 +1000
Message-ID: <CABkgnnVFg2iCc8eWX40+25ATE=dAw3WmndReO0ky2j1K_soLPQ@mail.gmail.com>
To: "tls@ietf.org" <tls@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/IcU6__8a8QVSPdy2Shg8fP42Pkw>
Subject: [TLS] Remove EncryptedExtensions from 0-RTT
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
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: <https://mailarchive.ietf.org/arch/browse/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, 23 Jun 2016 03:37:18 -0000

When implementing 0-RTT, an in particular the ticket_age extension, we
discovered that this greatly increases the complexity of the server
state machine.  The problem is that the server is making decisions
about what to send in the ServerHello based on the content of messages
that appear after the ClientHello.  Worse, this means that the server
is making decisions based on material that is not hashed into the
session transcript [1].

David Benjamin rather flippantly described a solution to this problem:
XOR the ticket age value with something that is either derived from
the old session keys or was included in the NewSessionTicket message.

I propose we take David's solution.  After all, simple is better:

  https://github.com/tlswg/tls13-spec/pull/503

To be clear, this means we lose the generality provided by having
encrypted extensions in the client's first flight.  I can't find a
reason to be sad about that; the only other possible use for this was
encrypted SNI, but I think we can find better ways to solve that
particular problem.


[1] This lead to ugly patches like what
https://github.com/tlswg/tls13-spec/issues/501 suggests.