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

David Benjamin <davidben@chromium.org> Tue, 07 March 2017 18:05 UTC

Return-Path: <davidben@google.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 171001294B1 for <tls@ietfa.amsl.com>; Tue, 7 Mar 2017 10:05:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org
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 Y-Xu3E5Drd_7 for <tls@ietfa.amsl.com>; Tue, 7 Mar 2017 10:05:40 -0800 (PST)
Received: from mail-pf0-x235.google.com (mail-pf0-x235.google.com [IPv6:2607:f8b0:400e:c00::235]) (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 A1B28129494 for <tls@ietf.org>; Tue, 7 Mar 2017 10:05:40 -0800 (PST)
Received: by mail-pf0-x235.google.com with SMTP id w189so3488864pfb.0 for <tls@ietf.org>; Tue, 07 Mar 2017 10:05:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=1TsFiIyE0p1YBQsid1QKZA+917t+zkxEMKNtEHXb9r0=; b=d2l2PCUaxmc1Iup8+uvL0bANnkEDvThd50grgVymktxO7J0mRfZ6OZ9GN+5nIMI9wQ 0xCr1ZNTod+AoP9L6/LzYOT2LxeGRlv65gcSoinmst4lrXZ4FenfhykilKMzr+y4/COe Ju1vS8TzMq9M82MAroNeCuQSZ0C/6NBPZ/vLo=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=1TsFiIyE0p1YBQsid1QKZA+917t+zkxEMKNtEHXb9r0=; b=mAbMMejuzCsDFRsW5V9Iv+/irn1//vC20nn6VlpeYKKqFseAPJgW6sD44hnjc+CoN0 feVZgX7Ws8uj7Gnne+bqM/NI+1KcJsyIQg2QzV1E+TZRmjE24f4V7CTXyngHHOpfeDIv C0fpAMtq4wtJKExFFPTVxSpc6mrvvnxnbm0NK16dlU0Roj5pWIaYp8gfrXTywIjxJaaI nzLBAkPUQWc/t3k8I12BfsJEcJ5F0r9zc+KLDt4KuXPvVxZIeKwSNjLTBTue32XUfo2s iC5asN+v5fHpuwhIOOStbz/KOIGM/wf7T98LtUlAzBtramyzzI2Kz9vl8kO5hR3v7usP USJw==
X-Gm-Message-State: AMke39nvhtOeu0b+H7B3hibZ26qTLosYiOxXK/UdqhvmOrpEROHcPRHK8mJkYmAt4u0TqqVllMWs2SCtDW7f4ADD
X-Received: by 10.84.234.8 with SMTP id m8mr2213496plk.25.1488909939995; Tue, 07 Mar 2017 10:05:39 -0800 (PST)
MIME-Version: 1.0
References: <B6B302EF-6836-4E50-B916-D9260C16D25B@symantec.com> <CABcZeBPT7W=hY5KZVW=A-3FpzpY_c_Gj4Tfh+YzYBgNqrVcHfw@mail.gmail.com>
In-Reply-To: <CABcZeBPT7W=hY5KZVW=A-3FpzpY_c_Gj4Tfh+YzYBgNqrVcHfw@mail.gmail.com>
From: David Benjamin <davidben@chromium.org>
Date: Tue, 07 Mar 2017 18:05:29 +0000
Message-ID: <CAF8qwaA+yU3=wjonBV6Ru+x+ffCLazjSKnwjvzRqg=RwUnCHXQ@mail.gmail.com>
To: Eric Rescorla <ekr@rtfm.com>, Roelof Du Toit <Roelof_Dutoit@symantec.com>
Content-Type: multipart/alternative; boundary="f4030436081013c4a5054a27dc5b"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/B950-ClB4DcDGIlkdVD-1sjUAJU>
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 18:05:42 -0000

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