Re: [TLS] WGLC for draft-ietf-tls-ticketrequests

Daniel Migault <daniel.migault@ericsson.com> Thu, 14 November 2019 17:19 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 EF4E112092B for <tls@ietfa.amsl.com>; Thu, 14 Nov 2019 09:19:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.649
X-Spam-Level:
X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, 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 n6PkA9F-oaeK for <tls@ietfa.amsl.com>; Thu, 14 Nov 2019 09:19:05 -0800 (PST)
Received: from mail-vk1-f169.google.com (mail-vk1-f169.google.com [209.85.221.169]) (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 11205120A5B for <tls@ietf.org>; Thu, 14 Nov 2019 09:19:05 -0800 (PST)
Received: by mail-vk1-f169.google.com with SMTP id r4so1652806vkf.9 for <tls@ietf.org>; Thu, 14 Nov 2019 09:19:05 -0800 (PST)
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=0oEKGFgBqD2IPNfJtXPCeKJ2iHH61FEm50yLq/DJ6wM=; b=SivWqOQOG0sW11ICegyfBOsCaBF8g6hqjOWyqlzFkm/MQSa4l4190Hrismeerqx6gQ SjlBEfG8J5z9dcs6AR4KC2xMqB1qjdNmcoweoiS4+0e0mKVmwuYbO3g7biUZx3ogSP1Y I/4EQWcAmP1nu5gsIL6HUe6XRpVGd62ceO8/AM9vz/E81LC8ymH1jDaozPTZr46Uf25B B4C4oh3h7KTSauHAdvM1MSSn5PsPp9YCEUkGdbzPc/6uzqru4SH4hCx6IaWiM81O+glQ rEXV0nU5KJ4DgOKv3fKnYXz+lvm46hA65U3T5UNyvonhBSx2/KUz4f4ZBPtA0YhqbD59 JQ+w==
X-Gm-Message-State: APjAAAX2Ioosl/qCA2cbgWy804MGXK0Pd7B7tQh3mOP+JnjrDiwIYc/L h54F7oEKVErrU7llHuZyfUL/tiymSzLuOcZwt8w=
X-Google-Smtp-Source: APXvYqwv/GeQ97V+/+uXVsv7ZO4f/t3Tk4bRFl51kCL7KGIQfByRl3+cXqReyR9xIp6K/sGQalKsuWTPWhOqxFxRWuY=
X-Received: by 2002:a1f:9553:: with SMTP id x80mr6085240vkd.39.1573751943877; Thu, 14 Nov 2019 09:19:03 -0800 (PST)
MIME-Version: 1.0
References: <2FB1D8AD-2C22-4A09-B7AF-0EFD6F0DBACA@sn3rd.com> <0469b84c-3009-427a-99ca-e7f6817f0b6c@www.fastmail.com> <CADZyTknhZDi2JD5WRbKEOGDafHjhTkUm6QhOhv1kkA9BT1nekw@mail.gmail.com> <37ff9a64-2749-4558-a675-5b251f06eb3a@www.fastmail.com> <CADZyTkkS-CipB00+JMRrjNZqXhyCTdBhV11oydCNCCeG_M6ORg@mail.gmail.com> <6fc786f3-9fbe-4f8e-92d3-cd9ceb7f3703@redhat.com>
In-Reply-To: <6fc786f3-9fbe-4f8e-92d3-cd9ceb7f3703@redhat.com>
From: Daniel Migault <daniel.migault@ericsson.com>
Date: Thu, 14 Nov 2019 12:18:52 -0500
Message-ID: <CADZyTkny6jpk=0gg-=yT3C3zY6N88a6t1RKjfKN+bNU6YbLshw@mail.gmail.com>
To: Hubert Kario <hkario@redhat.com>
Cc: tls <tls@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000009458d5059751ade8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/nGrfSJ-EcCHfT3701oPU9Uwdryk>
Subject: Re: [TLS] WGLC for draft-ietf-tls-ticketrequests
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: Thu, 14 Nov 2019 17:19:07 -0000

Hi Hubert,

The reason I would prefer the client to enforce the count is that if a
client has constraints - memory / bandwidth, he wants to make sure its
preference is respected, and this independently of the evolution of how the
hint will be interpreted in the future or depending on different
implementations.

I understand the reasons for SHOULD. At least this should be documented. To
address your first point, of course the specification applies to the server
that support the extension. Your second concern is solved by limiting the
NTS of KEX. The third point is addressed by the minimum of the (count,
server_nbr). Note that I see count as a maximum. Overall I do not think
this would add much complexity.  The only complexity I see is when a server
sends NTS at different time in the KEX.

Yours,
Daniel

On Thu, Nov 14, 2019 at 11:59 AM Hubert Kario <hkario@redhat.com>; wrote:

> On Thursday, 14 November 2019 17:19:55 CET, Daniel Migault wrote:
> > Hi Chris,
> >
> > Thanks for the responses, please see my comments inline.
> >
> > Yours,
> > Daniel
> >
> > On Thu, Nov 14, 2019 at 11:02 AM Christopher Wood
> > <caw@heapingbits.net>; wrote:
> > On Thu, Nov 14, 2019, at 7:50 AM, Daniel Migault wrote:
> >> Hi,
> >>
> >> The current version is clearer than the previous one. However, as I
> >> understand the document, it still seems very asymmetric in the sense
> >> that it does not provide the client the ability to enforce a number. I
> >> believe more guidances/specifications are needed on how to interpret the
> >> count value. Interpretation is usually based on implicit assumptions of
> >> today's usages, and explicit signaling should, in my opinion,
> >> be preferred. In
> >> other words, I believe that long term interop will benefit from these
> >> additional specifications.
> >
> > I disagree with this assessment. The document is clear on this:
> >
> >    A supporting server MAY use TicketRequestContents.count when
> >    determining how many NewSessionTicket messages to send to a
> >    requesting client, and SHOULD place a limit on the number of tickets
> >    sent.  The number of NewSessionTicket messages sent SHOULD be the
> >    minimum of the server's self-imposed limit and
> >    TicketRequestContents.count.
> >
> > As has been stated before, the count is a *hint* to the server,
> > nothing more.
> >
> > That is my point, in my opinion a hint is under specified.
> >
> >> The problem stated in the introduction is that the server needs some
> >> information from the client in order to generate the appropriated number
> >> of tickets. In fact the client is likely to be the one that better knows
> >> the number of tickets to be generated, but the current text does not
> >> enable the client to enforce that number. Instead this is entirely left
> >> to the server.
> >
> > As above, I think you're misunderstanding the point of this
> > document. Ticket requests are hints to servers.
> >
> > On the contrary, I think I understood it correctly.
>
> we discussed it on the list, and the reason for such phrasing is
> multi-fold:
>  - the server doesn't have to implement this extension, as such, as per the
>    basic TLS 1.3 RFC, it can send arbitrary number of extensions to client,
>    so clients, to be RFC compliant, need to be able to process abritrary
> number
>    tickets at arbitrary time after handshake finish
>  - making value in extension the exact number requested by client makes the
>    implementation much more complex: is that number per connection? per
>    session? what about post-handshake authentication? what about Session
> Ticket
>    Encryption Key rollover? do we really want the client to abort the
> connection
>    if server misbehaves and sends too many or too few tickets?
>  - while the client may think that it knows how many tickets it requires,
> that
>    information may be out of date. If an HTTP server has been brought
> down,
> a
>    connection to a given SNI may lead to a redirection page - in such cases
>    there is no point in server sending tickets.
>
> so please, tell: what issue would be solved by making the count requested
> by
> client mandatory?
> Because I see it only increasing complexity of implementation for no
> benefit.
> --
> 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
>