Re: [TLS] Draft 18 review : Message order
Olivier Levillain <olivier.levillain@ssi.gouv.fr> Wed, 23 November 2016 17:03 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 57CE712A04F for <tls@ietfa.amsl.com>; Wed, 23 Nov 2016 09:03:00 -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 341XajmPrfkX for <tls@ietfa.amsl.com>; Wed, 23 Nov 2016 09:02:56 -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 1B5D512A059 for <tls@ietf.org>; Wed, 23 Nov 2016 09:02:55 -0800 (PST)
Received: from smtp-switch.internet.local (smtp-switch [192.168.3.9]) by smtp.ssi.gouv.fr (Postfix) with ESMTP id 9FF8090B949; Wed, 23 Nov 2016 18:02:54 +0100 (CET)
References: <20161122190758.GG19978@neoplankton.picty.org> <CABcZeBNC_KepTUUMABU7YAN29UWpwBOp5XW6pCkFhhN82+hGjQ@mail.gmail.com>
From: Olivier Levillain <olivier.levillain@ssi.gouv.fr>
X-Enigmail-Draft-Status: N1110
To: Eric Rescorla <ekr@rtfm.com>
Message-ID: <5835CBBE.9070202@ssi.gouv.fr>
Date: Wed, 23 Nov 2016 18:02:54 +0100
User-Agent:
MIME-Version: 1.0
In-Reply-To: <CABcZeBNC_KepTUUMABU7YAN29UWpwBOp5XW6pCkFhhN82+hGjQ@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/VILlQWp3Dz_kJIWAuCRlsWcVnMo>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Draft 18 review : Message order
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 17:03:00 -0000
Hi, > On Tue, Nov 22, 2016 at 11:08 AM, Olivier Levillain < > olivier.levillain@ssi.gouv.fr> wrote: > >> = Message order = >> >> I believe the message P.27 section 4 is important, but not >> sufficient. As already expressed on the list, a formal automaton >> should be provided in the spec. >> >> I think Ekr said there was some work in progress in this area. Is >> this a goal for the final specification? >> > Yes, I will put some sort of more complete state machine in the final spec > (probably in -19) I have been working on my black board on the simplest case (pure TLS, no PSK support), and I stumble upon the late client authentication issue that was presented in the thread starting with https://www.ietf.org/mail-archive/web/tls/current/msg21500.html. I agree with the thread that NST and KU are easy to deal with. As stated in the thread, as it is currently specified, the mechanism is kind of a pandora's box : - the client must keep the handshake transcript (or its running / forkable hash) because of the Finished message that must eventually be sent - the server can send multiple CertificateRequest, and the client must, for each, keep the content of the message (for the label, and also for the hash context required for the Finished message) => the unboundedness problem - there is no way to reject the request gracefully. As I understand the thread, one idea was to say that the mechanism is forbidden by default, unless it is activated by some profile. However, as stated in https://www.ietf.org/mail-archive/web/tls/current/msg21561.html, since there are voices to allow it in the HTTP profile, this is problematic because HTTPS can be used in constrained environments where we would like to avoid late client auth. I believe the late client auth mechanism should explicitly be negotiated, either at the TLS level with an extension, or at the application level via an API callback (not a profile) and an upper layer nego. Sorry to dig this up (and sorry for the re-discovery explained at length), but where does the WG stand on this issue? PR 680 is currently parked, but I believe the current situation is not acceptable from the client's point of view, and I fail to see whether unbounded parallel certificate requests would be used in practice or not. Best regards, olivier
- [TLS] Draft 18 review : Message order Olivier Levillain
- Re: [TLS] Draft 18 review : Message order Eric Rescorla
- Re: [TLS] Draft 18 review : Message order Olivier Levillain