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

Daniel Migault <daniel.migault@ericsson.com> Tue, 08 October 2019 14:04 UTC

Return-Path: <mglt.ietf@gmail.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 226B412007C for <tls@ietfa.amsl.com>; Tue, 8 Oct 2019 07:04:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.476
X-Spam-Level:
X-Spam-Status: No, score=-1.476 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.172, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 FsIISHetizPT for <tls@ietfa.amsl.com>; Tue, 8 Oct 2019 07:04:35 -0700 (PDT)
Received: from mail-vs1-f45.google.com (mail-vs1-f45.google.com [209.85.217.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43741120122 for <tls@ietf.org>; Tue, 8 Oct 2019 07:04:34 -0700 (PDT)
Received: by mail-vs1-f45.google.com with SMTP id z14so11347416vsz.13 for <tls@ietf.org>; Tue, 08 Oct 2019 07:04:34 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=5uw1I2EAWo4xm+J1wCY9VrpJPbfuUrbcQZNo9lrc8V8=; b=fOLnqUidOej4oCqqGSR0Bi8QTFEDo1tRFBazAd7wXV+Qg3aUoHmF4/mPBtSAFY/uaH c1Dsg6MKLs7ZVarwXs04Pr7uq1OTvrGKhHtZFKkGwr7rTWOmnw+2CxWLqmqmqpdTnEu7 0hf5r2oDIRbBiL0e23cKRuTsbMUY2tT/W4+6J547d+FJYWN6cyN0CpBQvr6IQ3n4PRrP qbKytuGfVpeyvx8nAccx32PTliBY+jsGUctJ6FlKZnVkAXeP8+UKOYqV2mRLrorj4kfx O2iSpwX2U0QWgr57MuopdM1yfOIb+kuoZUOQz4mrVnaFRzkkME8TaB+M/iZWuk1XbxhD ZgCQ==
X-Gm-Message-State: APjAAAXAMLoRGKPH1LWsrhdr1t0lOkLWUKsuGN2VzSKAa80Es7oHPzzW 1td/JtKncIN0/B3WlMvtc4R1MxlF3h67/IU4lck=
X-Google-Smtp-Source: APXvYqw85h/AiA9x/md4MH8d1gLiJ3/XCdNHfXPFynndzSnYsL39vGzgiysgRO1V2zGDNk9lncLfMfmJz16C1/97q9w=
X-Received: by 2002:a67:3355:: with SMTP id z82mr19549400vsz.169.1570543473198; Tue, 08 Oct 2019 07:04:33 -0700 (PDT)
MIME-Version: 1.0
References: <156962803631.24993.3421537129925787732@ietfa.amsl.com> <8055839.FEiR5CbC9I@pintsize.usersys.redhat.com> <f7a22127-21a2-4d7f-83da-c4bffb306d9d@www.fastmail.com> <7141986.K9k3K6lWjT@pintsize.usersys.redhat.com>
In-Reply-To: <7141986.K9k3K6lWjT@pintsize.usersys.redhat.com>
From: Daniel Migault <daniel.migault@ericsson.com>
Date: Tue, 08 Oct 2019 10:04:18 -0400
Message-ID: <CADZyTkkMu88+R_-DkVo5Kr-2DtqYWUXg9MvvM1tXNu2c6o1=Gg@mail.gmail.com>
To: Hubert Kario <hkario@redhat.com>
Cc: tls <tls@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000d30a36059466a542"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/cvtW5xivKQ4FyVKFPRXu_S-xmks>
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:04:37 -0000

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.

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
>