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

Hubert Kario <hkario@redhat.com> Mon, 07 October 2019 14:46 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 CAEDF1200C7 for <tls@ietfa.amsl.com>; Mon, 7 Oct 2019 07:46:02 -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 fHTVu5tTrwn8 for <tls@ietfa.amsl.com>; Mon, 7 Oct 2019 07:45:58 -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 5C00112010E for <tls@ietf.org>; Mon, 7 Oct 2019 07:45:44 -0700 (PDT)
Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id DC100883859; Mon, 7 Oct 2019 14:45:43 +0000 (UTC)
Received: from pintsize.usersys.redhat.com (unknown [10.43.21.184]) by smtp.corp.redhat.com (Postfix) with ESMTP id 259C9544E6; Mon, 7 Oct 2019 14:45:42 +0000 (UTC)
From: Hubert Kario <hkario@redhat.com>
To: tls@ietf.org
Date: Mon, 07 Oct 2019 16:45:42 +0200
Message-ID: <7141986.K9k3K6lWjT@pintsize.usersys.redhat.com>
In-Reply-To: <f7a22127-21a2-4d7f-83da-c4bffb306d9d@www.fastmail.com>
References: <156962803631.24993.3421537129925787732@ietfa.amsl.com> <8055839.FEiR5CbC9I@pintsize.usersys.redhat.com> <f7a22127-21a2-4d7f-83da-c4bffb306d9d@www.fastmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart1660136.O7gKnjuQ9x"; micalg="pgp-sha512"; protocol="application/pgp-signature"
X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.6.2 (mx1.redhat.com [10.5.110.69]); Mon, 07 Oct 2019 14:45:44 +0000 (UTC)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/nImm524k0Mv3JjaIvMyBzwwLxiE>
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: Mon, 07 Oct 2019 14:46:03 -0000

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