Re: [TLS] I-D Action: draft-ietf-tls-ticketrequests-02.txt

Hubert Kario <hkario@redhat.com> Tue, 01 October 2019 16:15 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 C1B8E120A41 for <tls@ietfa.amsl.com>; Tue, 1 Oct 2019 09:15:41 -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 wvyffCEdJM4z for <tls@ietfa.amsl.com>; Tue, 1 Oct 2019 09:15:38 -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 8E9AC120A1D for <tls@ietf.org>; Tue, 1 Oct 2019 09:15:38 -0700 (PDT)
Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 22EDCC010C19; Tue, 1 Oct 2019 16:15:38 +0000 (UTC)
Received: from pintsize.usersys.redhat.com (unknown [10.43.21.184]) by smtp.corp.redhat.com (Postfix) with ESMTP id 53C22614C3; Tue, 1 Oct 2019 16:15:37 +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 18:15:31 +0200
Message-ID: <1708345.JU3unZtj4k@pintsize.usersys.redhat.com>
In-Reply-To: <851aded9-70a7-4a9a-abd5-b75f98f86baf@www.fastmail.com>
References: <156962803631.24993.3421537129925787732@ietfa.amsl.com> <1971068.D9yiD15FoS@pintsize.usersys.redhat.com> <851aded9-70a7-4a9a-abd5-b75f98f86baf@www.fastmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart2099791.1yBVDje6zj"; micalg="pgp-sha512"; protocol="application/pgp-signature"
X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.32]); Tue, 01 Oct 2019 16:15:38 +0000 (UTC)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/5R_0oq_lp-M4UKXc9JJV5hSCf28>
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 16:15:42 -0000

On Tuesday, 1 October 2019 16:01:32 CEST Christopher Wood wrote:
> On Tue, Oct 1, 2019, at 5:18 AM, Hubert Kario wrote:
> > > > ```
> > > > 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?
> 
> Sorry, I meant connection:
> 
>    "Clients may indicate to servers their desired number of tickets for *a
> single connection* via the following "ticket_request" extension"
> 
> This is a simple hint for servers. Nothing more. No state needs to be stored
> past connection establishment.

sounds good

> > > > 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.
> Since these hints are not mandatory to honor I don't think we need to
> describe this case. In particular, this is a valid case where ignoring the
> SHOULD is fine, in my opinion.
> 
> If the draft required that servers MUST NOT send more tickets than what's
> requested, then yes, I think these details would be important.

huh? I see the following in the draft-02:

   Servers MUST NOT
   send more than 255 tickets to clients.


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