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

Olivier Levillain <olivier.levillain@ssi.gouv.fr> Wed, 23 November 2016 13:25 UTC

Return-Path: <olivier.levillain@ssi.gouv.fr>
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 7BCAC129DB7 for <tls@ietfa.amsl.com>; Wed, 23 Nov 2016 05:25:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.398
X-Spam-Level:
X-Spam-Status: No, score=-3.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 thxFkmg6CeKv for <tls@ietfa.amsl.com>; Wed, 23 Nov 2016 05:25:22 -0800 (PST)
Received: from smtp.ssi.gouv.fr (smtp.ssi.gouv.fr [86.65.182.16]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4EAD129DB4 for <tls@ietf.org>; Wed, 23 Nov 2016 05:25:22 -0800 (PST)
Received: from smtp-switch.internet.local (smtp-switch [192.168.3.9]) by smtp.ssi.gouv.fr (Postfix) with ESMTP id 1776190B930; Wed, 23 Nov 2016 14:25:21 +0100 (CET)
To: Eric Rescorla <ekr@rtfm.com>
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>
From: Olivier Levillain <olivier.levillain@ssi.gouv.fr>
Message-ID: <583598C1.5090601@ssi.gouv.fr>
Date: Wed, 23 Nov 2016 14:25:21 +0100
User-Agent:
MIME-Version: 1.0
In-Reply-To: <CABcZeBO7t6gG-EKXTZgUUZQJQD77q=iM+AZB0ginu8+zA-dxmg@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/cxCgs_uh1hS56rkloOHK7JXCh-k>
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:25:24 -0000

>> 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.

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

olivier