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

"Christopher Wood" <caw@heapingbits.net> Tue, 01 October 2019 14:01 UTC

Return-Path: <caw@heapingbits.net>
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 13CB3120824 for <tls@ietfa.amsl.com>; Tue, 1 Oct 2019 07:01:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level:
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=heapingbits.net header.b=fM5+btKn; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=0GAaqNjT
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 ayvUUoIFZBaO for <tls@ietfa.amsl.com>; Tue, 1 Oct 2019 07:01:54 -0700 (PDT)
Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFF4F120251 for <tls@ietf.org>; Tue, 1 Oct 2019 07:01:53 -0700 (PDT)
Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 2CD3220C69; Tue, 1 Oct 2019 10:01:53 -0400 (EDT)
Received: from imap4 ([10.202.2.54]) by compute6.internal (MEProxy); Tue, 01 Oct 2019 10:01:53 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heapingbits.net; h=mime-version:message-id:in-reply-to:references:date:from:to :cc:subject:content-type; s=fm2; bh=RsEWahNArKCgIJHYFsOIyUVKxgTR xebjuL2Eq9cMurc=; b=fM5+btKn00gKBCf8ps66ZN8/tCgz0q/IHhsw5kGD1awN wCrOBWfzHsPYjIiXXChBDrsEm09QFhSwUoQfyGY5b4B9EdoLDWVcjZqp33gwMfXS ICznIzEx5KI74hC9FsHiUlY1lrcxrb5htNQ/ak5YklmwRBh67ZBffydhelw9BHgh EtaYCgCOZHB0xdlr8Sjp0A866MFJcfeJk0m5g7VwL41uykQ8T5PPp7btkjX9lHjx ll/hQELi1E76sKbWYiiDRk1aqiCPRb5sz/zOKJwhK8+1FrQGxEhZmDbx3f1Qk9nA I8nIwWYh95Qyn/4lDw2HiELPr4QvWlpVr9ehYhEoYg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=RsEWah NArKCgIJHYFsOIyUVKxgTRxebjuL2Eq9cMurc=; b=0GAaqNjTwIqhwD2aAGPVac 0F/FcSw1yDQfmgr5vk53VFfOhiLPBZOIcmxm8yuGWDCUsRuE7ervBjHUqvXmJdUG 8sg4Y4FooVybOEXt8LStfYkN9PPFJMDJe8/Bq6/Ui/bOmknk8H1VfGnPnBfyfwOZ omTF0SWt/hHsGTgeE1j11yuXip+ej2/fiZv1mUo+tVpi9d9t0neDsQifB4g8cdua mgv9vbUXJQeB+Vt8RocB6zok/xLLX8Z1onw6JZRmNJkENM5JNCbOCtMGeO3GykdU QQw5iBXIU7q4ztR/sqXw1sxmvk5UwFiKgUi/Fw87VaBk0lAGlZbxbO9UMnFDFXfw ==
X-ME-Sender: <xms:UFyTXbEg9QXIDkzgLrgZklRBNy-ebQu_huiXLWONGPK9KXAOydJw-A>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrgeeggdejtdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvufgtsehttdertderredtnecuhfhrohhmpedfvehhrhhi shhtohhphhgvrhcuhghoohgufdcuoegtrgifsehhvggrphhinhhgsghithhsrdhnvghtqe enucfrrghrrghmpehmrghilhhfrhhomheptggrfieshhgvrghpihhnghgsihhtshdrnhgv thenucevlhhushhtvghrufhiiigvpedt
X-ME-Proxy: <xmx:UFyTXbxPy5rrbfG9AUHO4BAfXI6kn31kEjbW9xtRGvfDHqXZiSsYfA> <xmx:UFyTXZa3VrlhnZpCktFhhXmyAgqHVQwVzoYHtu5gcDvwvJIoTultYA> <xmx:UFyTXSGecgr6463nnVZ2ADJjykrWYlofl7I89xHlvtVsosP2ATyjwQ> <xmx:UVyTXdQDe0I5-KbDkpkij34gkeH9I3xn4mja0wUu9staRmbTK8iuNg>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id CB8BC3C00A1; Tue, 1 Oct 2019 10:01:52 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.1.7-334-g7f5110b-fmstable-20191001v2
Mime-Version: 1.0
Message-Id: <851aded9-70a7-4a9a-abd5-b75f98f86baf@www.fastmail.com>
In-Reply-To: <1971068.D9yiD15FoS@pintsize.usersys.redhat.com>
References: <156962803631.24993.3421537129925787732@ietfa.amsl.com> <1765606.IRqicVgrGs@pintsize.usersys.redhat.com> <62ee0774-5667-43a3-b5fa-144d52c04c4d@www.fastmail.com> <1971068.D9yiD15FoS@pintsize.usersys.redhat.com>
Date: Tue, 01 Oct 2019 07:01:32 -0700
From: "Christopher Wood" <caw@heapingbits.net>
To: "Hubert Kario" <hkario@redhat.com>
Cc: "TLS@ietf.org" <tls@ietf.org>
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/pydlMvxOyVsD4WhCdWeWiEajv1s>
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 14:02:05 -0000

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.

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

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

That works for me. We can add it in the next version. 

Best,
Chris