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

Hubert Kario <hkario@redhat.com> Thu, 14 November 2019 16:59 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 B4EE41208DB for <tls@ietfa.amsl.com>; Thu, 14 Nov 2019 08:59:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.3
X-Spam-Level:
X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=redhat.com
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 tFAGdYy1vpzP for <tls@ietfa.amsl.com>; Thu, 14 Nov 2019 08:59:05 -0800 (PST)
Received: from us-smtp-delivery-1.mimecast.com (us-smtp-2.mimecast.com [207.211.31.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF97C1208B6 for <tls@ietf.org>; Thu, 14 Nov 2019 08:58:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1573750738; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=gYwFUE4uGwqnmS6/OP3ltUoDNPwLpWTcNOfzozBrKvo=; b=QNPnM2Ah9LjVBa5y6ccaPeqCNiRbJep4b+1NI/SJQJITq3Keofc2A9Q5ANSk7GasBQSmmv OCy1FLE0MX89GSRWaXez/8JAeHrXhFRMLB6ns1E+ajmWrjcir77CuWNho3koranxVZm/Qx 3bmNqGsgTvpJNSkfpI+PDMhv/nJ0/+E=
Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-261-vtGRdu3bPi2ApJN8ZBxejA-1; Thu, 14 Nov 2019 11:58:57 -0500
Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 5715F18B9FC1 for <tls@ietf.org>; Thu, 14 Nov 2019 16:58:56 +0000 (UTC)
Received: from localhost (unknown [10.43.21.192]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 03A2D6135D for <tls@ietf.org>; Thu, 14 Nov 2019 16:58:55 +0000 (UTC)
From: Hubert Kario <hkario@redhat.com>
To: <tls@ietf.org>
Date: Thu, 14 Nov 2019 17:58:54 +0100
MIME-Version: 1.0
Message-ID: <6fc786f3-9fbe-4f8e-92d3-cd9ceb7f3703@redhat.com>
In-Reply-To: <CADZyTkkS-CipB00+JMRrjNZqXhyCTdBhV11oydCNCCeG_M6ORg@mail.gmail.com>
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>
Organization: Red Hat
User-Agent: Trojita/0.7; Qt/5.12.5; xcb; Linux; Fedora release 30 (Thirty)
X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11
X-MC-Unique: vtGRdu3bPi2ApJN8ZBxejA-1
X-Mimecast-Spam-Score: 0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/e269c_16yqHmeqjlEqV-KmWSoBI>
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 16:59:10 -0000

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