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

Daniel Migault <daniel.migault@ericsson.com> Fri, 04 October 2019 13:55 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 70229120046 for <tls@ietfa.amsl.com>; Fri, 4 Oct 2019 06:55:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.477
X-Spam-Level:
X-Spam-Status: No, score=-1.477 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] 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 YDAzAxOtPu1O for <tls@ietfa.amsl.com>; Fri, 4 Oct 2019 06:55:36 -0700 (PDT)
Received: from mail-vk1-f171.google.com (mail-vk1-f171.google.com [209.85.221.171]) (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 E67DC120043 for <tls@ietf.org>; Fri, 4 Oct 2019 06:55:35 -0700 (PDT)
Received: by mail-vk1-f171.google.com with SMTP id u4so1476453vkl.6 for <tls@ietf.org>; Fri, 04 Oct 2019 06:55:35 -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=nuTpfAzbwWMac55/v2hkXF2nSui0nXOlao07DHKKPbw=; b=Jqh6TojYg4Lp4/NPL2LvnkuQvFUyPDaMYOg0jk2BfGv9BkKHtfGa8cPLo21LdcZM10 hwN9nc2aNPpPNArXRLp+q+BfA8M4oihQnHx8eH6aV3lSLK3jho8dg37gOeQbjPY0CfYd 7SKCMXZEkBeaCvK/01lUxhHrOEf/JzH66amgnnXK2smRWBqxNU+qA8JgYQLIaYAkE7qx xojKsu3QFHS/rbIHDgMevZT0exkELLbaUP8Qx04veg6XnuM1ljt3KxOZN3noHvNv6g9x RuIyCW/vkZNTNRgDKnXukNSxy7vWxXoGG8TFHOHbkWkt/tTpiei1AIG+Ebw0LRw+wyxW W6KA==
X-Gm-Message-State: APjAAAWVFx5TnaOTNR0v+v9qM4POkmq581Rr5TWaXamsdBy4gReTETOo gM9guYkA2VkRb7P0NRUNpPtXaNFjyinuREd+opU=
X-Google-Smtp-Source: APXvYqxHIXg3cve0Jb6NuKAlkAYNt1/OKAPP5Bg2ZRcZy4+eC60bIiyLsx9ocwQlh/59GIXidekDlteXotkfmSRuX1M=
X-Received: by 2002:a1f:a181:: with SMTP id k123mr7942847vke.55.1570197334818; Fri, 04 Oct 2019 06:55:34 -0700 (PDT)
MIME-Version: 1.0
References: <156962803631.24993.3421537129925787732@ietfa.amsl.com> <2328460.Fs94otCilB@pintsize.usersys.redhat.com> <CADZyTk=8sRmoyP-HHv7+0BiiwVXVP6kk3dMWLgaeZ8+NdEFamg@mail.gmail.com> <8055839.FEiR5CbC9I@pintsize.usersys.redhat.com>
In-Reply-To: <8055839.FEiR5CbC9I@pintsize.usersys.redhat.com>
From: Daniel Migault <daniel.migault@ericsson.com>
Date: Fri, 4 Oct 2019 09:55:23 -0400
Message-ID: <CADZyTkmhXa59mOJwUY+MiQWVzaVnwz4O0i2KbY_tN8VXYUsERw@mail.gmail.com>
To: Hubert Kario <hkario@redhat.com>
Cc: "TLS@ietf.org" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000005e82310594160e53"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/SmhCfJgENQsDcJhYUEzN6MY4FZU>
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: Fri, 04 Oct 2019 13:55:38 -0000

Hi Hubert,

I agree.
Yours,
Daniel

On Fri, Oct 4, 2019 at 9:17 AM Hubert Kario <hkario@redhat.com> 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.
>
> > > > The ability to request 255 tickets with one byte can be seen as an
> > > > amplification vector, especially when a server sends directly the
> > > > tickets
> > > > after its Finished message. I believe that additional text in the
> > >
> > > security
> > >
> > > > consideration could be added.
> > >
> > > true
> > >
> > > > Yours,
> > > > Daniel
> > > >
> > > > On Tue, Oct 1, 2019 at 1:27 PM Christopher Wood <caw@heapingbits.net
> >
> > >
> > > wrote:
> > > > > 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
> > > > >
> > > > > _______________________________________________
> > > > > 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 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 mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>