Re: [TLS] I-D Action: draft-ietf-tls-ticketrequests-02.txt
Hubert Kario <hkario@redhat.com> Tue, 01 October 2019 12:18 UTC
Return-Path: <hkario@redhat.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 E44AA120154 for <tls@ietfa.amsl.com>; Tue, 1 Oct 2019 05:18:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Level:
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 HX-SxbnKjQ0Y for <tls@ietfa.amsl.com>; Tue, 1 Oct 2019 05:18:13 -0700 (PDT)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 12E08120142 for <tls@ietf.org>; Tue, 1 Oct 2019 05:18:12 -0700 (PDT)
Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 87DBE30842A8; Tue, 1 Oct 2019 12:18:12 +0000 (UTC)
Received: from pintsize.usersys.redhat.com (unknown [10.43.21.184]) by smtp.corp.redhat.com (Postfix) with ESMTP id B61DC5D713; Tue, 1 Oct 2019 12:18:11 +0000 (UTC)
From: Hubert Kario <hkario@redhat.com>
To: Christopher Wood <caw@heapingbits.net>
Cc: "TLS@ietf.org" <tls@ietf.org>
Date: Tue, 01 Oct 2019 14:18:10 +0200
Message-ID: <1971068.D9yiD15FoS@pintsize.usersys.redhat.com>
In-Reply-To: <62ee0774-5667-43a3-b5fa-144d52c04c4d@www.fastmail.com>
References: <156962803631.24993.3421537129925787732@ietfa.amsl.com> <1765606.IRqicVgrGs@pintsize.usersys.redhat.com> <62ee0774-5667-43a3-b5fa-144d52c04c4d@www.fastmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart1795895.jXyq4bQGy8"; micalg="pgp-sha512"; protocol="application/pgp-signature"
X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.40]); Tue, 01 Oct 2019 12:18:12 +0000 (UTC)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/dCmHHgX5EJUDfKUX_uJ0FrDztvo>
Subject: Re: [TLS] I-D Action: draft-ietf-tls-ticketrequests-02.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.29
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, 01 Oct 2019 12:18:15 -0000
On Monday, 30 September 2019 15:36:36 CEST Christopher Wood wrote: > On Mon, Sep 30, 2019, at 6:28 AM, Hubert Kario wrote: > > On Saturday, 28 September 2019 01:59:42 CEST Christopher Wood wrote: > > > This version addresses some of the comments we received from Hubert a > > > while > > > back. We think it's ready to go for WGLC, modulo whatever nits folks > > > find. > > > > > > :-) > > > > I still see the "vend" instead of "send" typos... Same for "vended" > > It's not a typo! We chose to use vend. then you're not consistent: As per [RFC5077], and as described in [RFC8446], TLS servers send :) > > ``` > > > > Clients must therefore > > bound the number of parallel connections they initiate by the > > number of tickets in their possession, or risk ticket re-use. > > > > ``` > > > > I'm not a native speaker, but shouldn't it be "...therefore bind the > > number..."? > > Yes, we can fix it in the next version. > > > ``` > > Servers MUST NOT send more than 255 tickets to clients. > > ``` > > > > per what? session? at a time? connection? > > This is all per session. We can state it explicitly in the next version. so this count needs to be kept as part of session and impacts connections that perform resumption? > > what's the expected behaviour with tickets and post-handshake > > authentication? Are tickets sent after PHA also bound by this limit? > > As mentioned earlier, there is no effect, so we left it out. We're happy to > accept text should you think it's needed. If the I-D states that servers should not send more tickets than the client asked for, and then send exactly that amount, then they won't be able to send new tickets after PHA and remain compliant. Yes, it's completely up to the server to decide if to send tickets after PHA or not, and I'm not suggesting that the client should request for tickets in one of its PHA messages, much less expect or require them, but sending tickets after PHA is reasonable and explicitly stated behaviour: RFC 8446 Section 4.6.1: For instance, the server might send a new ticket after post-handshake authentication in order to encapsulate the additional client authentication state. so the I-D should explicitly state what's the expected behaviour in that case. IMHO, the extension should be used for the tickets sent right after the handshake, it should not put an upper bound for the tickets that a server can send in a single connection. For a very long lived connection (especially if the connection uses KeyUpdate messages regularly), the initial tickets may expire. Server may notice that and send a new group of tickets then. > > ``` > > > > Clients MUST NOT change the value of TicketRequestContents.count in > > second ClientHello messages sent in response to a HelloRetryRequest. > > > > ``` > > > > 'A server MUST abort the connection with an "illegal_parameter" if the > > value of the extension changed, it was added or removed in second > > ClientHello.' ? > I don't think this is necessary. given past discussions on this mailing list, I don't think this is entirely obvious.... Then what about the addition or removal of extension being forbidden? Can we add something like this?: ``` The presence or absence of the extension MUST be maintained in second ClientHello message when compared to first ClientHello in connection. ``` -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 115, 612 00 Brno, Czech Republic
- [TLS] I-D Action: draft-ietf-tls-ticketrequests-0… internet-drafts
- Re: [TLS] I-D Action: draft-ietf-tls-ticketreques… Christopher Wood
- Re: [TLS] I-D Action: draft-ietf-tls-ticketreques… Hubert Kario
- Re: [TLS] I-D Action: draft-ietf-tls-ticketreques… Christopher Wood
- Re: [TLS] I-D Action: draft-ietf-tls-ticketreques… Jeremy Harris
- Re: [TLS] I-D Action: draft-ietf-tls-ticketreques… Hubert Kario
- Re: [TLS] I-D Action: draft-ietf-tls-ticketreques… Hubert Kario
- Re: [TLS] I-D Action: draft-ietf-tls-ticketreques… Christopher Wood
- Re: [TLS] I-D Action: draft-ietf-tls-ticketreques… Viktor Dukhovni
- Re: [TLS] I-D Action: draft-ietf-tls-ticketreques… Hubert Kario
- Re: [TLS] I-D Action: draft-ietf-tls-ticketreques… Viktor Dukhovni
- Re: [TLS] I-D Action: draft-ietf-tls-ticketreques… Christopher Wood
- Re: [TLS] I-D Action: draft-ietf-tls-ticketreques… Daniel Migault
- Re: [TLS] I-D Action: draft-ietf-tls-ticketreques… Christopher Wood
- Re: [TLS] I-D Action: draft-ietf-tls-ticketreques… Daniel Migault
- Re: [TLS] I-D Action: draft-ietf-tls-ticketreques… Nico Williams
- Re: [TLS] I-D Action: draft-ietf-tls-ticketreques… Rob Sayre
- Re: [TLS] I-D Action: draft-ietf-tls-ticketreques… Christopher Wood
- Re: [TLS] I-D Action: draft-ietf-tls-ticketreques… Christopher Wood
- Re: [TLS] I-D Action: draft-ietf-tls-ticketreques… Viktor Dukhovni
- Re: [TLS] I-D Action: draft-ietf-tls-ticketreques… Rob Sayre
- Re: [TLS] I-D Action: draft-ietf-tls-ticketreques… Hubert Kario
- Re: [TLS] I-D Action: draft-ietf-tls-ticketreques… Robert Relyea
- Re: [TLS] I-D Action: draft-ietf-tls-ticketreques… Daniel Migault
- Re: [TLS] I-D Action: draft-ietf-tls-ticketreques… Hubert Kario
- Re: [TLS] I-D Action: draft-ietf-tls-ticketreques… Daniel Migault
- Re: [TLS] I-D Action: draft-ietf-tls-ticketreques… Hubert Kario
- Re: [TLS] I-D Action: draft-ietf-tls-ticketreques… Christopher Wood
- Re: [TLS] I-D Action: draft-ietf-tls-ticketreques… Christopher Wood
- Re: [TLS] I-D Action: draft-ietf-tls-ticketreques… Viktor Dukhovni
- Re: [TLS] I-D Action: draft-ietf-tls-ticketreques… Hubert Kario
- Re: [TLS] I-D Action: draft-ietf-tls-ticketreques… Daniel Migault
- Re: [TLS] I-D Action: draft-ietf-tls-ticketreques… Hubert Kario
- Re: [TLS] I-D Action: draft-ietf-tls-ticketreques… Martin Thomson
- Re: [TLS] I-D Action: draft-ietf-tls-ticketreques… Viktor Dukhovni
- Re: [TLS] I-D Action: draft-ietf-tls-ticketreques… Martin Thomson
- Re: [TLS] I-D Action: draft-ietf-tls-ticketreques… Viktor Dukhovni