Re: [TLS] Interaction between session resumption and negotiated protocol version

Brian Smith <brian@briansmith.org> Fri, 03 April 2015 23:52 UTC

Return-Path: <brian@briansmith.org>
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 51A6C1A87A7 for <tls@ietfa.amsl.com>; Fri, 3 Apr 2015 16:52:56 -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 DtXGFKEQBB_T for <tls@ietfa.amsl.com>; Fri, 3 Apr 2015 16:52:55 -0700 (PDT)
Received: from mail-ob0-f178.google.com (mail-ob0-f178.google.com [209.85.214.178]) (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 234681A877F for <tls@ietf.org>; Fri, 3 Apr 2015 16:52:55 -0700 (PDT)
Received: by obvd1 with SMTP id d1so188353797obv.0 for <tls@ietf.org>; Fri, 03 Apr 2015 16:52:54 -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:date :message-id:subject:from:to:cc:content-type; bh=3mIKjybpOtETRVySFa4lTkKVjz4HTQXuVPbwCbDCXzY=; b=jleSiuKlgeErsy7+yop1o+kdMmfRLf7Kx99iLUhUz3Se2RvoHLRWjAC4YPCSRAcjRy FzbHwICXKM1B5AuHV1isuwie34CuOQ/1e6D9CUp+7mv/WkZqQn31gu5Sw4yax+SQPzXW PnkRD18dLI3pGnEhJ/QJC0GtJ3BDx0C7/GMIjSfhbm+ewfQgMqqhyj6CKjIsceNRJfQu LKLtiUYV/bMDS+qlQ1tnR9smLgfZZG6/tWltPHE3E82pkRX7BKHMLuNXnt8XBY2C7se1 5c8weQTYZMQtO6c0sLhVI5hsi3jOwy2Zb/GKjD1tb0KNB5JmJ05tmsW99Rly9EGOTzWx UcGg==
X-Gm-Message-State: ALoCoQmmfNNGcMlEd9DdAYDiPAqzpykgy6c46U0y8MNxarU96d32Ynn+W+oM63gJJR/PrpnaXN10
MIME-Version: 1.0
X-Received: by 10.182.230.132 with SMTP id sy4mr5640854obc.29.1428105174618; Fri, 03 Apr 2015 16:52:54 -0700 (PDT)
Received: by 10.76.20.146 with HTTP; Fri, 3 Apr 2015 16:52:54 -0700 (PDT)
In-Reply-To: <201504031933.31280.davemgarrett@gmail.com>
References: <CANOyrg9BSVAtVC4y34jMi-OAbK5OHMFsTUOhxRJqgGKGzO41xQ@mail.gmail.com> <BLU177-W41FFC60C00F3D8BAFDC57DC3F10@phx.gbl> <CAF8qwaAqn8mYVP8E95HC_s9jK8dshm-PWALJLO76tBeA1qvZXQ@mail.gmail.com> <201504031933.31280.davemgarrett@gmail.com>
Date: Fri, 03 Apr 2015 13:52:54 -1000
Message-ID: <CAFewVt5tDXHQjQgQ6a5_rfkyCwnckSoLHmPgvB9ZUFdywTk+Nw@mail.gmail.com>
From: Brian Smith <brian@briansmith.org>
To: Dave Garrett <davemgarrett@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/W0Hqs-lqldbD4Gts6kgJxVi5TD4>
Cc: "<tls@ietf.org>" <tls@ietf.org>
Subject: Re: [TLS] Interaction between session resumption and negotiated protocol version
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: Fri, 03 Apr 2015 23:52:56 -0000

Dave Garrett <davemgarrett@gmail.com> wrote:
> TLS 1.2 has:
>
> Whenever a client already knows the highest protocol version known to
> a server (for example, when resuming a session), it SHOULD initiate
> the connection in that native protocol.
>
> TLS 1.3 currently has:
>
> A client resuming a session SHOULD initiate the connection using the
> version that was previously negotiated.

These are both bad. The best way for the client to behave is to
calculate ClientHello.client_version independently of the session
cache.

For any full handshake, the client_version should be the best version
the client supports. Since the server is allowed to respond to any
ClientHello by initiating a full handshake (e.g. because it blew away
its session cache), ClientHello.client_version shouldn't be different
for ClientHellos that include a session ID or session ticket.

Cheers,
Brian