Re: [TLS] WGLC: draft-ietf-tls-tls13-19

Olivier Levillain <olivier.levillain@ssi.gouv.fr> Fri, 31 March 2017 11:57 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 81BA01296BB for <tls@ietfa.amsl.com>; Fri, 31 Mar 2017 04:57:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 r5RcNAyFFVBa for <tls@ietfa.amsl.com>; Fri, 31 Mar 2017 04:57:18 -0700 (PDT)
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 567C71296A7 for <tls@ietf.org>; Fri, 31 Mar 2017 04:57:17 -0700 (PDT)
Received: from smtp-switch.internet.local (smtp-switch [192.168.3.9]) by smtp.ssi.gouv.fr (Postfix) with ESMTP id 779F590B914 for <tls@ietf.org>; Fri, 31 Mar 2017 13:55:59 +0200 (CEST)
To: tls@ietf.org
References: <025D3ABD-199F-421A-9265-6F960135A3B7@sn3rd.com> <58D8C395.8090707@ssi.gouv.fr>
From: Olivier Levillain <olivier.levillain@ssi.gouv.fr>
X-Enigmail-Draft-Status: N1110
Message-ID: <58DE441B.7010203@ssi.gouv.fr>
Date: Fri, 31 Mar 2017 13:57:15 +0200
User-Agent:
MIME-Version: 1.0
In-Reply-To: <58D8C395.8090707@ssi.gouv.fr>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/DU6n7cjuymyjr3yqDktLgUgul4M>
Subject: Re: [TLS] WGLC: draft-ietf-tls-tls13-19
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
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: Fri, 31 Mar 2017 11:57:23 -0000

Hi,

> I think there is at least another issue that still needs to be
> discussed: how to properly handle post-handshake handshake messages.
> 
> The subject has also been raised several times on GitHub
> (https://github.com/tlswg/tls13-spec/pull/680,
> https://github.com/tlswg/tls13-spec/pull/676,
> https://github.com/tlswg/tls13-spec/issues/572) and on the mailing list
> (https://www.ietf.org/mail-archive/web/tls/current/msg22038.html).
> 
> Bottom line is:
> - handling client late authentication requires a lot of state in the
> client stack
> - currently, handling client late authentication is mandatory

[...]

> Thus, I believe the current text is inadequate. Different solutions are
> possible :
> - remove client late authentication entirely (this would have my
> preference, since it introduces other issues*)
> - make client late authentication optional (compatible clients would
> signal it as an extension)
> - rethink the client late authentication, as was done with KeyUpdate,
> to limit the state required on the client side.


Martin Thomson proposed a PR (thank you) corresponding to the second
point, using a simple extension in the ClientHello :
https://github.com/tlswg/tls13-spec/pull/921/

I believe this proposal is a good trade-off allowing simpler
implementation designs when late client authentication is not needed.


Best regards,
Olivier Levillain