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

"Christopher Wood" <caw@heapingbits.net> Tue, 01 October 2019 17:26 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 D4F46120908 for <tls@ietfa.amsl.com>; Tue, 1 Oct 2019 10:26:55 -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=mNtepacM; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=K6oEaMFY
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 RC4JYtexZhBO for <tls@ietfa.amsl.com>; Tue, 1 Oct 2019 10:26:54 -0700 (PDT)
Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE17012096D for <tls@ietf.org>; Tue, 1 Oct 2019 10:26:53 -0700 (PDT)
Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 09694214CE; Tue, 1 Oct 2019 13:26:53 -0400 (EDT)
Received: from imap4 ([10.202.2.54]) by compute6.internal (MEProxy); Tue, 01 Oct 2019 13:26: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:content-transfer-encoding; s=fm2; bh=8k MQwB7wxlNlusVIWgwSqO3e6ciEI3jvKB6I7FICXm0=; b=mNtepacMDAi8C3tv5u /jJxafZ5FL1z/NhPDFz2UhMWp8d9zbp2PD7FPoDPAO0Oq/EqFwce+IzzJINEtDtR DNBgVDi4FprzXf+9bXkp5uGbbmS/LUrsyUc6kuxMHm5CFI62LVJI83YjCTJoNgrb v6402RRlfJZZOrisP2+tQ3tNDizE6qylwwOPOXBdsCRtETKI5/7dkQ39WVuSIfV2 53uBzOQgIJsRkfLJketHE98Xdp9hB8eS93Nsg8D4zf4X5TtaEZwhhojuZvnKrK/v 1XH80pkOwlt7hp53arRw/ReZy1ja8/P98PujjTvstxOMQ7Ikl30drYNaZM0ybux8 26Pw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding: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=8kMQwB7wxlNlusVIWgwSqO3e6ciEI3jvKB6I7FICX m0=; b=K6oEaMFYtG9slEPLOYiWIYTapwqK0watCCLQq6+42X2qCEgZacewhWe54 4WpxtthPcrk5qbQ/UoqBxJyk6wpqn8ZVj8a3fTuEbyOUuTQqA86w787bWBCfxhE/ 9n9pVQCNBufUfS4bzo/d2z9Z/zaXkgcK2gWYZB3sDin3bKym2DClNc31cZDgfSWa U/dchZ9LssYaszm5n0snrluHLHVg3z0wv8EDrh/8cN0S0LSTrc8tpA/uT9STjR8e y1Ih3MqoiX6haifNMBo79Rc9LwJmxR1fqAJ57JAuoRp8fN3NDF1ag4biE2GRo/en 2adu6CjhVvcra38613YdYdfScxEyg==
X-ME-Sender: <xms:XIyTXZr0cLK1CIVuXJFJBI_m9EFwQJf2nJYAWnWB9il4_ja6IHJflA>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrgeeggdduudduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgfgsehtqhertderreejnecuhfhrohhmpedfvehh rhhishhtohhphhgvrhcuhghoohgufdcuoegtrgifsehhvggrphhinhhgsghithhsrdhnvg htqeenucffohhmrghinheprhgvughhrghtrdgtohhmnecurfgrrhgrmhepmhgrihhlfhhr ohhmpegtrgifsehhvggrphhinhhgsghithhsrdhnvghtnecuvehluhhsthgvrhfuihiivg eptd
X-ME-Proxy: <xmx:XIyTXeCnRGO8l7jqxGEd7u1LCRhYBwRui3PmxvWLREzRLVPcCUHaCg> <xmx:XIyTXfe7Ie_lHYGQZ_CixMoiOLErQvM58URbVudyVYmpNob8J3QPzQ> <xmx:XIyTXYCdsSXNTgdX2QFByzK3ZeptZzSQGWQav7W1endMX3nmJS9mHg> <xmx:XYyTXQOBZOQtsyzOWn4gUk7NBxn1Hi0KNlQyoVWgk5TTRd2s5nx-Uw>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 905A13C00A1; Tue, 1 Oct 2019 13:26: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: <350020eb-c43b-4941-93e9-06ea9a0cacc3@www.fastmail.com>
In-Reply-To: <1708345.JU3unZtj4k@pintsize.usersys.redhat.com>
References: <156962803631.24993.3421537129925787732@ietfa.amsl.com> <1971068.D9yiD15FoS@pintsize.usersys.redhat.com> <851aded9-70a7-4a9a-abd5-b75f98f86baf@www.fastmail.com> <1708345.JU3unZtj4k@pintsize.usersys.redhat.com>
Date: Tue, 01 Oct 2019 10:26: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;charset=utf-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/z0iId-PAHAHBBvIAZfRGZq7cE48>
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 17:26:57 -0000


On Tue, Oct 1, 2019, at 9:15 AM, Hubert Kario wrote:
> 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.

I was referring to the "SHOULD NOT send more than TicketRequestContents.count NewSessionTicket messages" blurb. Indeed, the MUST NOT above should also be a SHOULD NOT. Thanks for your patience in working through the kinks!

> 
> 
> -- 
> 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
> Attachments:
> * signature.asc