Re: [TLS] I-D Action: draft-ietf-tls-ticketrequests-00.txt
Hubert Kario <hkario@redhat.com> Mon, 21 January 2019 15:10 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 D04BE130F88 for <tls@ietfa.amsl.com>; Mon, 21 Jan 2019 07:10:08 -0800 (PST)
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 ieMbXnIbPiJA for <tls@ietfa.amsl.com>; Mon, 21 Jan 2019 07:10:06 -0800 (PST)
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 570A1130FCD for <tls@ietf.org>; Mon, 21 Jan 2019 07:10:06 -0800 (PST)
Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 9169E757D6; Mon, 21 Jan 2019 15:10:05 +0000 (UTC)
Received: from pintsize.usersys.redhat.com (unknown [10.43.21.83]) by smtp.corp.redhat.com (Postfix) with ESMTP id D035E61090; Mon, 21 Jan 2019 15:10:04 +0000 (UTC)
From: Hubert Kario <hkario@redhat.com>
To: tls@ietf.org, Tommy Pauly <tpauly@apple.com>
Date: Mon, 21 Jan 2019 16:09:57 +0100
Message-ID: <15963767.JlSI183RGp@pintsize.usersys.redhat.com>
In-Reply-To: <154785795557.17452.3793151756514602603@ietfa.amsl.com>
References: <154785795557.17452.3793151756514602603@ietfa.amsl.com>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart1638868.PUVoOPF6UF"; micalg="pgp-sha512"; protocol="application/pgp-signature"
X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.26]); Mon, 21 Jan 2019 15:10:05 +0000 (UTC)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/PZYZqySXpNMJMpaZ5RgskMVN29w>
Subject: Re: [TLS] I-D Action: draft-ietf-tls-ticketrequests-00.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: Mon, 21 Jan 2019 15:10:09 -0000
On Saturday, 19 January 2019 01:32:35 CET internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts > directories. This draft is a work item of the Transport Layer Security WG > of the IETF. > > Title : TLS Ticket Requests > Authors : Tommy Pauly > David Schinazi > Christopher A. Wood > Filename : draft-ietf-tls-ticketrequests-00.txt > Pages : 6 > Date : 2019-01-18 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-tls-ticketrequests-00 > https://datatracker.ietf.org/doc/html/draft-ietf-tls-ticketrequests-00 The security section probably should note that large server self-imposed limit could be used for Denial of Service. "Servers MUST NOT send more than 255 tickets to clients." across the whole connection or directly after Finished? For long-lived connections that may be problematic, especially when connected with multiple post handshake authentication exchanges... What about ticket count after post handshake authentication? Should we allow the client to re-issue the extension in Certificate message? Should handling of "0" in extension be special? As in, if client is asking for 0 tickets (e.g. because it will not do resumption), "SHOULD" the server respect that and send no tickets? (while the min(srv_limit, clnt_request.count) will do that, I think it may be prudent to spell it out) Is the extension negotiated every time when resuming the session, or should it be saved as part of session data by server? What if client starts advertising it, drops it or changes value in the next ClientHello that offers resumption? I'm assuming that it cannot be changed by client in 2nd ClientHello when doing Hello Retry Request handshake. Shouldn't that be stated explicitly though? -- 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… Hubert Kario