[TLS] Offline configurations

Martin Thomson <martin.thomson@gmail.com> Mon, 19 October 2015 23:01 UTC

Return-Path: <martin.thomson@gmail.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 9E0D11B2E52 for <tls@ietfa.amsl.com>; Mon, 19 Oct 2015 16:01:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 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, 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 RkAztANq4Nnq for <tls@ietfa.amsl.com>; Mon, 19 Oct 2015 16:01:54 -0700 (PDT)
Received: from mail-yk0-x22f.google.com (mail-yk0-x22f.google.com [IPv6:2607:f8b0:4002:c07::22f]) (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 29DEF1B2E66 for <tls@ietf.org>; Mon, 19 Oct 2015 16:01:54 -0700 (PDT)
Received: by ykdr3 with SMTP id r3so227261ykd.1 for <tls@ietf.org>; Mon, 19 Oct 2015 16:01:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=IBUV/Z3egp46/py2eXKNYdaBrkEUlZzmDCFUuUxiWcE=; b=HF1d96P1rDeTbLQKhIDINzHG3vnaoh8s6Swp5L9ANtansMIJzSHSwTelto4UOuRusl Cciw6hF5bULyVD67N4Q12BLLinidJA8BsPNqk1BrllDUTufu7gFhdInSPQtsWSTrtXCs F4DU+6AVFXk5s8t4M9SPv3suFwyxN2hbrtmDNdamGdlRkBCd+ESYYzmEsRyX7qNA4A5Q YCXZStbSqi3JhsTh0W54EzCOByen6pKoz8ZXILgaWaIvXANYUo6+c04yxeHBzr+347mw qiS0fav5FGT8LwGgN/k1MHtbaf8hQ5h3JaO1haNNbb3h8rWDMLTIQVEcY3UJR8d2um8I Qp0A==
MIME-Version: 1.0
X-Received: by 10.129.79.129 with SMTP id d123mr21805840ywb.159.1445295713384; Mon, 19 Oct 2015 16:01:53 -0700 (PDT)
Received: by 10.129.132.145 with HTTP; Mon, 19 Oct 2015 16:01:53 -0700 (PDT)
Date: Mon, 19 Oct 2015 16:01:53 -0700
Message-ID: <CABkgnnVP6cV=sjUWpOzFBbOqYU+iWaDptOEssHqdz15POgQq=Q@mail.gmail.com>
From: Martin Thomson <martin.thomson@gmail.com>
To: "tls@ietf.org" <tls@ietf.org>
Content-Type: text/plain; charset=UTF-8
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/rnVY52rF5n9R9DxxVdkoroqCub0>
Subject: [TLS] Offline configurations
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: <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: Mon, 19 Oct 2015 23:01:55 -0000

This is an exploration of what it might take to bootstrap 0RTT without
a prior TLS connection.

https://tools.ietf.org/html/draft-thomson-tls-offline-config-00

There are two important lessons I've learned from this:
  1. authentication is important (and hard to get right)
  2. TLS implicitly includes a bunch of stuff in the server
configuration, these are explicitly manifest here as extensions to the
server configuration

On this latter point, I believe that this identifies the additional
state that needs to be considered as part of a server configuration by
clients.  These are implicitly included in the regular 0RTT setup and
don't get entered into the 0RTT handshake hash.  I don't think that's
a problem, but it might be worth thinking about some.

For instance, if a CertificateRequest alters how the client behaves
for a second connection, should that be covered by the handshake hash
for that connection?  Similar concerns might apply to cipher suite
selection and supported groups.

For an offline configuration, the entire configuration is included
both under a signature and as part of the handshake transcript for the
new connection.  That means that the certificate is covered twice.