Re: [TLS] I-D Action: draft-ietf-tls-ticketrequests-02.txt
Hubert Kario <hkario@redhat.com> Tue, 08 October 2019 14:28 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 7770512084D for <tls@ietfa.amsl.com>; Tue, 8 Oct 2019 07:28:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level:
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=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 XU-H1VLR6BGl for <tls@ietfa.amsl.com>; Tue, 8 Oct 2019 07:28:14 -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 1B650120843 for <tls@ietf.org>; Tue, 8 Oct 2019 07:28:14 -0700 (PDT)
Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id A769310CC205; Tue, 8 Oct 2019 14:28:13 +0000 (UTC)
Received: from pintsize.usersys.redhat.com (unknown [10.43.21.184]) by smtp.corp.redhat.com (Postfix) with ESMTP id 028305DE5C; Tue, 8 Oct 2019 14:28:12 +0000 (UTC)
From: Hubert Kario <hkario@redhat.com>
To: Daniel Migault <daniel.migault@ericsson.com>
Cc: tls <tls@ietf.org>
Date: Tue, 08 Oct 2019 16:28:12 +0200
Message-ID: <15867803.7oPl4jV29m@pintsize.usersys.redhat.com>
In-Reply-To: <CADZyTkkMu88+R_-DkVo5Kr-2DtqYWUXg9MvvM1tXNu2c6o1=Gg@mail.gmail.com>
References: <156962803631.24993.3421537129925787732@ietfa.amsl.com> <7141986.K9k3K6lWjT@pintsize.usersys.redhat.com> <CADZyTkkMu88+R_-DkVo5Kr-2DtqYWUXg9MvvM1tXNu2c6o1=Gg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart3900847.uKFYVagsbe"; micalg="pgp-sha512"; protocol="application/pgp-signature"
X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.6.2 (mx1.redhat.com [10.5.110.65]); Tue, 08 Oct 2019 14:28:13 +0000 (UTC)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/syiPFlAiQYfQ_2YjCi5gkQTzPFI>
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, 08 Oct 2019 14:28:18 -0000
On Tuesday, 8 October 2019 16:04:18 CEST Daniel Migault wrote: > If we suppose all tickets are sent by the server at once, I am wondering if > we have any case where the server will send more tickets that the number > provided by the hint. long lasting connection and a ticket encryption key expiring > Yours, > Daniel > > On Mon, Oct 7, 2019 at 10:46 AM Hubert Kario <hkario@redhat.com> wrote: > > On Saturday, 5 October 2019 14:08:45 CEST Christopher Wood wrote: > > > On Fri, Oct 4, 2019, at 6:17 AM, Hubert Kario wrote: > > > > On Thursday, 3 October 2019 22:15:14 CEST Daniel Migault wrote: > > > > > On Thu, Oct 3, 2019 at 7:56 AM Hubert Kario <hkario@redhat.com> > > > > wrote: > > > > > > On Wednesday, 2 October 2019 22:42:32 CEST Daniel Migault wrote: > > > > > > > I understand the meaning of count is the higher limit of ticket > > > > and > > > > > > > > > the > > > > > > > server can provides any tickets between 0 and count. If that is > > > > > > > correct, > > > > > > > this could be clearly stated and indication to chose an > > > > appropriated > > > > > > > > value > > > > > > > > > > > > > for each cases may be provided. > > > > > > > > > > > > > > I would rather see the count value as a hard line from the > > > > > > > server > > > > > > > with a > > > > > > > MUST NOT instead of a SHOULD NOT statement. > > > > > > > > > > > > see my previous comments: this ignores existence of post handshake > > > > > > authentication, ticket lifetimes and KeyUpdate > > > > > > > > > > I think we agree on the problem which is it is hard to have a > > > > specific > > > > > > > count as tickets may be sent at multiple time during the key > > > > exchange or > > > > > > > the later during the session. If the "SHOULD" is addressing this > > > > aspect > > > > > > > I > > > > > believe that more text is needed.. From my perspective, what I > > > > proposed > > > > > > > I > > > > > imagined that count was related to the maximum number of ticket > > > > provided > > > > > > > **each time the server is sending tickets**. The reason for having > > > > the > > > > > > > same > > > > > number is that the server does not know how the client will use > > > > > these > > > > > tickets and the client does not know precisely when the server sends > > > > the > > > > > > > tickets. So at the end the number of tickets sent is likely to be > > > > > n*count > > > > > when n represents the number of times during the session tickets are > > > > > provided. > > > > > > > > > > My understanding of the SHOULD is that it makes legitimate for a > > > > server > > > > > > > to > > > > > ignore the count value provided by the client. > > > > > > > > yes, it looks like we are in agreement > > > > > > > > Sounds like something that should be spelled out explicitly in the > > > > draft. > > > > > > I.e. it should talk about groups of tickets, not tickets in > > > > connection, > > > > and it should definitely not specify the maximum number of tickets a > > > > server can send in a connection. > > > > > > Since it's meant as a hint, removing that clause (maximum number of > > > > tickets > > > > > a server can send in a connection) is reasonable, and sounds like it > > > > should > > > > > address the concerns here. (Assuming we also include text which says > > > servers should obviously place a cap on what they send, as they do > > > > today.) > > > > > Would you agree? I'm really trying to avoid this becoming overly > > > complex, > > > as it's a very small feature. > > > > yes, having a "server SHOULD place a cap on the number of tickets it sends > > at > > once" with a note in security section that "not having such a limit may > > expose > > the server to DoS or amplification attacks" would be enough > > > > (note that without client certificate authentication, the server can use > > early > > exit from handshake method and thus send the extensions just as a result > > of a > > single ClientHello message) > > -- > > 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 mailing list > > TLS@ietf.org > > https://www.ietf.org/mailman/listinfo/tls -- 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