[TLS] Negotiating with known_configuration

Eric Rescorla <ekr@rtfm.com> Tue, 21 July 2015 11:04 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 C7B181A0087 for <tls@ietfa.amsl.com>; Tue, 21 Jul 2015 04:04:56 -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 R7TNtTKab7pr for <tls@ietfa.amsl.com>; Tue, 21 Jul 2015 04:04:55 -0700 (PDT)
Received: from mail-wg0-f48.google.com (mail-wg0-f48.google.com [74.125.82.48]) (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 D996B1A0078 for <tls@ietf.org>; Tue, 21 Jul 2015 04:04:54 -0700 (PDT)
Received: by wgbcc4 with SMTP id cc4so59993672wgb.3 for <tls@ietf.org>; Tue, 21 Jul 2015 04:04:53 -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:from:date:message-id:subject:to :content-type; bh=qKYwz1ZV4j9vI82egDX1zRtHGyf+HO/0lCr63H3AAbY=; b=eI1bNMxKan3W3G3SjNMjKeOljp/1REYsPIESgWdZNKdYMkBAYcGwJR3AOsKExKOO/v 0pDaNF/ESlF4m6S/9QsVk3qZSV2oHdDv7e9MsZ2LF+5Sxt8fl5JBXCJ+MpGDIOOBijFc rKedJwyAHt0xjIkvUawaGmKLsvPLb/WzUe/vO7SMcDmrM/JQEZ4xp959IDCtzLnlhztg Tn4m2CJM5QX6bLfJdTDOLy2NR2A//7o/xhO4TjxDEI0a/SYkFJ1HJ1HXnW9ljKW94vEx BPloWkJiR1aai0JLLmbj1PmyOsiL2Q9GwjOf0NPvuJPE8Ut0Kdqy7+o9bmhRcsKORSXV GWRw==
X-Gm-Message-State: ALoCoQnMCsRWKIOBdv3R3SD5WuyfcwK6VO9fpVA7D52Bwv4HnoPgTd8yYME65dqnsAyquxCm0weO
X-Received: by 10.194.79.225 with SMTP id m1mr66966375wjx.8.1437476693557; Tue, 21 Jul 2015 04:04:53 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.27.85.75 with HTTP; Tue, 21 Jul 2015 04:04:14 -0700 (PDT)
From: Eric Rescorla <ekr@rtfm.com>
Date: Tue, 21 Jul 2015 13:04:14 +0200
Message-ID: <CABcZeBOEUuVKHYRs5+DY6h8vcQ9uLWW9SXzN=VH=ovHbnEK0AA@mail.gmail.com>
To: "tls@ietf.org" <tls@ietf.org>
Content-Type: multipart/alternative; boundary=047d7b10c903b160f2051b609f4f
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/dPJCTZn3WrZXJkz3aDVCiRE272A>
Subject: [TLS] Negotiating with known_configuration
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: Tue, 21 Jul 2015 11:04:56 -0000

The known_configuration mechanism in the current draft allows the
client to resurrect the handshake parameters (though not the keys)
which were negotiated in a previous handshake, but this is done
implicitly, i.e., the server provides a label and the client returns
it on the next connection. This has the advantage of keeping things
short but the disadvantage the it means that you can't have a static
configuration ID for everyone (instead, the server has to somehow
embed the properties in the configuration ID). After some thought,
I think this is a bad plan.

Here's what I propose (and what's in my slides for today):

- The client indicates configuration ID and cryptographic configuration,
  including the cipher suites and cryptographic extensions. This
  MUST replicate the server's selection from a previous handshake

- The server verifies the client's ClientHello and
  (a) Checks that configuration ID is valid
  (b) Verifies that client's parameters are what it would negotiate


Accordingly, this would change the extension to something like:

         struct {
           select (Role) {
             case client:
               opaque identifier<0..2^16-1>;
               CipherSuite cipher_suite;            // NEW
               Extension extensions<0..2^16-1>;     // NEW

             case server:
               struct {};
           }
         } KnownConfigurationExtension


The server would just need one configuration for each public key and
woudldn't need to have any client-specific state. It also has the
benefit that it makes PSK work with 0-RTT.

Thoughts? Improvements?

-Ekr