Re: [TLS] Draft 18 review : Hello Retry Request and supported groups cache

Eric Rescorla <ekr@rtfm.com> Wed, 23 November 2016 13:36 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 6B117129DCC for <tls@ietfa.amsl.com>; Wed, 23 Nov 2016 05:36:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 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_LOW=-0.7] 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 yEVj3IFZ62WN for <tls@ietfa.amsl.com>; Wed, 23 Nov 2016 05:36:01 -0800 (PST)
Received: from mail-yw0-x233.google.com (mail-yw0-x233.google.com [IPv6:2607:f8b0:4002:c05::233]) (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 D8E42129DC9 for <tls@ietf.org>; Wed, 23 Nov 2016 05:36:00 -0800 (PST)
Received: by mail-yw0-x233.google.com with SMTP id r204so11356039ywb.0 for <tls@ietf.org>; Wed, 23 Nov 2016 05:36:00 -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=wb/0FIoRNAUexm951jJzOMP9DijRQAyCcc3k+c9h6PU=; b=erdOqxBQaj5Y14pKIygxj4pD/aRRkE5x/4C5PPtmp7I482d08vSYo0gyGdKUZrcSpf Hdvr0bzDmdous2A5syIQGK/xosrmbwMG3g+U1wpBsOuxX+o5W8W/ibsyxPze5RxZ7VEG l3lPe3Nt7RVLkqyo/n/KSfjBwLejSRFfRkEQenHRWWkv03xIpsVtmoMHAXw/bDn0EPcf 3fy4vHFTcmcYYSOSQqLDZbCIk1bmMuLqh5/tXgzTPmVsc07UD3adp5IO0JWZRm/wMdPm dIRtW8H/aeVGUjGO9xD3LrWOOFcUrX2NVzwHIyc1Uv5K4m4KfMNrPKkiib+jXggG/4za MbdQ==
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:from:date :message-id:subject:to:cc; bh=wb/0FIoRNAUexm951jJzOMP9DijRQAyCcc3k+c9h6PU=; b=gbpYenLqPNDhNypDls0VJ2pArnSLJcKtv6rb0C5ohz8Op7qkAagdqWLqH6k3GMvktr WWnRseaPNgYtvqoWC3L6tji2QYaXE52yKY+dmSfiCxM6Z57jHVXhWmLdstovHHJmgUl7 ROfGxsWSqE2s2CUMB3FAkUXRqKB4ys7aaACvapG8ilIMVQq6oCUBXnGRek2U/Qir2/O3 XVHrUhr4htvf06oqQJ/GNifE6WUewwG7O0BipDGMU8w/8zmbwf79QkdUDmXRyXe8XoKb bjDeZwWOt81tG0yWVm7f7N80R2+CP1jrOJXXs8jpgFAEYTFobh39UUzStUlsP7PPXXtK 8AlA==
X-Gm-Message-State: AKaTC00+HDxmKCJbhcUHQmPylQT6MYX0kPHtiieyO/wpRTf6TFFi57/+bNz6EwLXXyWIwoGK9n3oIvNT0zqGYA==
X-Received: by 10.129.53.194 with SMTP id c185mr3235882ywa.205.1479908160131; Wed, 23 Nov 2016 05:36:00 -0800 (PST)
MIME-Version: 1.0
Received: by 10.129.159.141 with HTTP; Wed, 23 Nov 2016 05:35:19 -0800 (PST)
In-Reply-To: <583598C1.5090601@ssi.gouv.fr>
References: <20161122190344.GC19978@neoplankton.picty.org> <CANduzxB1+Vw8-uWfbmGauCiK6OMZxO5VogV7e-oB0Ms5uHst8A@mail.gmail.com> <CABcZeBMqBCo9Bc7LXaRTTN0bOhXqku0txLFor+zQ3Zg-7C=E3g@mail.gmail.com> <58355120.5030800@ssi.gouv.fr> <CABcZeBO7t6gG-EKXTZgUUZQJQD77q=iM+AZB0ginu8+zA-dxmg@mail.gmail.com> <583598C1.5090601@ssi.gouv.fr>
From: Eric Rescorla <ekr@rtfm.com>
Date: Wed, 23 Nov 2016 05:35:19 -0800
Message-ID: <CABcZeBM6fJEsWK3eX7miESN_x9pVVS=2uTu4-r08z=VSU_9Nag@mail.gmail.com>
To: Olivier Levillain <olivier.levillain@ssi.gouv.fr>
Content-Type: multipart/alternative; boundary="001a114214782f79f90541f7f866"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/7aqM_Bk7YzrYgJHFmN5HyUkAEac>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Draft 18 review : Hello Retry Request and supported groups cache
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: Wed, 23 Nov 2016 13:36:02 -0000

On Wed, Nov 23, 2016 at 5:25 AM, Olivier Levillain <
olivier.levillain@ssi.gouv.fr> wrote:

> >> There were actually two points in my message:
> >>  - I was not convinced by this way of signalling a preference without
> >> enforcing it, but I understand that, if we keep supported_groups, it
> >> does not cost much and the client can safely ignore the server sent
> >> extension;
> >>  - however, I found strange that the specification stated that the
> >> client could update its view when seeing this extension, but that it was
> >> not stated in the case of an HRR where updating its views of the
> >> servers' preference would clearly be useful for the future. I only
> >> proposed to add the same text "The client MAY update its view of the
> >> server's preference when receiving an HRR, to avoid the extra round trip
> >> in future encounters".
> >>
> > This is is unsafe, because the HRR is unauthenticated. We could update it
> > after the handshake completes, but I think this is obvious enough that it
> > doesn't
> > need to be stated.
>
> Unless I am mistaken, EncryptedExtensions is not authenticated either
> (even if it is sent in the same flight as the authentication messages),
> so updating the client cache can not be done immediately after
> interpreting the supported_groups extension.
>

That is intended to be covered by the following text:

   by the client.  Clients MUST NOT act upon any information found in
   "supported_groups" prior to successful completion of the handshake,
   but MAY use the information learned from a successfully completed
   handshake to change what groups they use in their "key_share"
   extension in subsequent connections.

My point about HRR is that the client can generally update its opinion
based on what it successfully completed the handshake with. This can
happen either with HRR or when it offered >1 shares and the server
took one. The special case is when supported_versions indicates a
key type you didn't use. So I think if we wanted text around this it would
go somewhere that covered the general case. I'm not sure it's needed
but if the WG feels like we should add some text, I can...

-Ekr


> However, if you believe this does not need to be stated, I am fine with
> that.
>
> olivier
>