Re: [TLS] Allow KeyShare in HelloRetry if not advertised in ClientHello?

Eric Rescorla <ekr@rtfm.com> Tue, 07 March 2017 19:50 UTC

Return-Path: <ekr@rtfm.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 B6D8812948D for <tls@ietfa.amsl.com>; Tue, 7 Mar 2017 11:50:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 TOyNfb7v7AcG for <tls@ietfa.amsl.com>; Tue, 7 Mar 2017 11:50:57 -0800 (PST)
Received: from mail-ot0-x22f.google.com (mail-ot0-x22f.google.com [IPv6:2607:f8b0:4003:c0f::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 13860129426 for <tls@ietf.org>; Tue, 7 Mar 2017 11:50:57 -0800 (PST)
Received: by mail-ot0-x22f.google.com with SMTP id o24so15233024otb.1 for <tls@ietf.org>; Tue, 07 Mar 2017 11:50:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=QS1walGLVWqAyhiyXpnkPgzXILQybx+I9qHT0tZ3GU4=; b=KaQ0QazxSnh/T+NQXdswZRVAdtAmceeYyJ2dFW+utt1RgFbJZyyrZXXDxY6ymq2f4h Jx5iPGT1Ve30Ar7EYBmMnNUWx/dxFZM28XT44Wo8kRCIwFUkMlQw0/tkEto/1FZPxYe/ AhCaCefi/xCMDGiG3vp3J/cnTqsKMphdh7m4cB/GqaAFNogTGPHB2swjnQH8lDJ4tf9Y 3YRgUtHzCHJ1ZE29+Mz86v1J4Lo+mTPY45I40j08AnAekRMo/96Y2uC5DY3U16ZZB5R3 oX2QwLKck5Hh7WFPikUNcvNSPi4y94IiUpl0C83k4EM/aDp8R0kHssALqnytiTfEQKAV da3w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=QS1walGLVWqAyhiyXpnkPgzXILQybx+I9qHT0tZ3GU4=; b=ZBCvjNEs7cFJ/y4a2rMBdxpUG2oqY8FpQFl/iylRXQ5gIO2St5PWa46sA02wn8qIkH 8CWXr9xmSzWXcBGqxrUlyHnYe9yK1gkFyv3gQ7Y02qkFJlx5pSl35b6f0S8psL5q1NRR 13z7hOQ0k92ln572T9rSUlwsLCgsbdEbwpgCZoS7HUa+AMcxwqSVOJCKN6DoSgf77wDI oG2+PJht/7n+ZuDiUDkDkN4whrP4jbxA0HUJ4KJGbnqpE4AEGzDR0XuNj0hwBRp76Idm tiq1d+JNSrU4zQcaRxwzWbShannMQ4GTSvLKIP6dFcgbOIDVa0e2x82NdMbaznNBAuPZ 8Cag==
X-Gm-Message-State: AMke39lMBSOiLSLbn3FEBvIdnayk8QNYLcK+zOKYyjpR/W1XBM6gqiGiP10Oga/j8UjAMkMIJpEimJca7nCsow==
X-Received: by 10.13.240.196 with SMTP id z187mr558662ywe.337.1488916256355; Tue, 07 Mar 2017 11:50:56 -0800 (PST)
MIME-Version: 1.0
Received: by 10.129.154.210 with HTTP; Tue, 7 Mar 2017 11:50:15 -0800 (PST)
In-Reply-To: <D06DC120-231A-4349-9C69-51FAB0B1C77E@symantec.com>
References: <B6B302EF-6836-4E50-B916-D9260C16D25B@symantec.com> <CABcZeBPT7W=hY5KZVW=A-3FpzpY_c_Gj4Tfh+YzYBgNqrVcHfw@mail.gmail.com> <CAF8qwaA+yU3=wjonBV6Ru+x+ffCLazjSKnwjvzRqg=RwUnCHXQ@mail.gmail.com> <D06DC120-231A-4349-9C69-51FAB0B1C77E@symantec.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Tue, 7 Mar 2017 11:50:15 -0800
Message-ID: <CABcZeBNgjhJ6xgxDCXUYJkE9DaXvEAk6f-u8=LO3wVYgO4uERQ@mail.gmail.com>
To: Roelof Du Toit <Roelof_Dutoit@symantec.com>
Content-Type: multipart/alternative; boundary=94eb2c034eb08f8db9054a295447
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/Ft6okgQNVpqaaCYlMU-urfDYbXY>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Allow KeyShare in HelloRetry if not advertised in ClientHello?
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: Tue, 07 Mar 2017 19:50:58 -0000

This appears in https://tlswg.github.io/tls13-spec/#resumption-and-psk

"As the server is authenticating via a PSK, it does not send a Certificate
or a CertificateVerify message. When a client offers resumption via PSK, it
SHOULD also supply a “key_share” extension to the server to allow the
server to decline resumption and fall back to a full handshake, if needed. "

-Ekr




On Tue, Mar 7, 2017 at 11:35 AM, Roelof Du Toit <Roelof_Dutoit@symantec.com>
wrote:

> Thank you.
>
>
>
> The following text in 4.2.7 prompted my scenario:
>
> ""
>
> A server which receives an “early_data” extension MUST behave in one of
> three ways:"
>
> ..
>
> - Request that the client send another ClientHello by responding with a
> HelloRetryRequest. A client MUST NOT include the “early_data” extension in
> its followup ClientHello.
>
> ""
>
>
>
> My conclusion from your replies is that the burden is on the client to
> avoid the scenario by including an empty key_share (with corresponding
> sigalgs and supported_groups) when sending early_data with psk_ke mode (vs
> psk_dhe_ke).  It might be worth warning implementers about that in the spec.
>
>
>
> --Roelof
>
>
>
> *From: *David Benjamin <davidben@chromium.org>
> *Date: *Tuesday, March 7, 2017 at 1:05 PM
> *To: *Eric Rescorla <ekr@rtfm.com>om>, Roelof Du Toit <
> Roelof_Dutoit@symantec.com>
> *Cc: *"tls@ietf.org" <tls@ietf.org>
> *Subject: *Re: [TLS] Allow KeyShare in HelloRetry if not advertised in
> ClientHello?
>
>
>
> On Tue, Mar 7, 2017 at 12:49 PM Eric Rescorla <ekr@rtfm.com> wrote:
>
> On Tue, Mar 7, 2017 at 9:44 AM, Roelof Du Toit <Roelof_Dutoit@symantec.com
> > wrote:
>
> All,
>
>
>
> The current language in https://tlswg.github.io/tls13-
> spec/#rfc.section.4.1.4 states:
>
> As with ServerHello, a HelloRetryRequest MUST NOT contain any extensions
> that were not first offered by the client in its ClientHello, with the
> exception of optionally the “cookie” (see Section 4.2.2
> <https://tlswg.github.io/tls13-spec/#cookie>) extension.
>
>
>
> I am analyzing the following message flow:
>
> ClientHello
>
> + early_data
>
> + psk_key_exchange_modes = psk_ke
>
> + pre_shared_key --------->
>
> (Early Data) ---------> *reject*
>
> <--------- HelloRetryRequest (not allowed to add key_share)
>
> ClientHello
>
> + supported_groups
>
> + key_share ---------> *not supported*
>
>
>
> At that point in the flow the server is not allowed to send another
> HelloRetryRequest.  To avoid that the client would need some hints in the
> HelloRetryRequest.
>
> Would it be possible to allow an exception to send key_share and/or
> supported_groups in a HelloRetryRequest if not offered in ClientHello?
>
>
>
> I would prefer not. If the client is willing to do DH, it should offer
> KeyShare in its initial ClientHello.
>
>
>
>  In particular, per 4.2.5:
>
>
>
> "Clients MAY send an empty client_shares vector in order to request group
> selection from the server at the cost of an additional round trip."
>
>
>
> David
>