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

Hubert Kario <hkario@redhat.com> Thu, 14 November 2019 17:32 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 948A2120802 for <tls@ietfa.amsl.com>; Thu, 14 Nov 2019 09:32:51 -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 11FoQwZdAMQa for <tls@ietfa.amsl.com>; Thu, 14 Nov 2019 09:32:49 -0800 (PST)
Received: from us-smtp-1.mimecast.com (us-smtp-delivery-1.mimecast.com [205.139.110.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E725B120074 for <tls@ietf.org>; Thu, 14 Nov 2019 09:32:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1573752767; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=u89ANBtVJXxKpAQVHZq0AqZ1qcihcODXk3Apur9Fwzs=; b=DQe7JJbjURqht+4o5DqrubImtIOn2xSLX6hQ0RSYSbtcVRcEBgv+mLLZTlJo6clGnouA/t gqIVOqLdalg/fB5rr+BfygmHWVOlyPz4GzFT5PuvSPH7WlST1MzPOeDfEPf2ulTd1Zv1DF 1fnsoHWzdGtUglss8B2TQRJZJd7dWRw=
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-368-vZm5-UGoM1-S81rM-2eAgw-1; Thu, 14 Nov 2019 12:32:43 -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 0441918B6393; Thu, 14 Nov 2019 17:32:43 +0000 (UTC)
Received: from localhost (unknown [10.43.21.192]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 355DA60303; Thu, 14 Nov 2019 17:32:41 +0000 (UTC)
From: Hubert Kario <hkario@redhat.com>
To: Daniel Migault <daniel.migault@ericsson.com>
Cc: tls <tls@ietf.org>
Date: Thu, 14 Nov 2019 18:32:39 +0100
MIME-Version: 1.0
Message-ID: <07d49b6f-e79d-4058-878f-7a57d5b6f241@redhat.com>
In-Reply-To: <CADZyTkny6jpk=0gg-=yT3C3zY6N88a6t1RKjfKN+bNU6YbLshw@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> <6fc786f3-9fbe-4f8e-92d3-cd9ceb7f3703@redhat.com> <CADZyTkny6jpk=0gg-=yT3C3zY6N88a6t1RKjfKN+bNU6YbLshw@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: vZm5-UGoM1-S81rM-2eAgw-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/bPyj0IWXly0qVyBBzRV3LrNuym4>
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:32:52 -0000

On Thursday, 14 November 2019 18:18:52 CET, Daniel Migault wrote:
> 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.

bandwidth I sort of understand, but then if client asks for 0 tickets, it's 
explicitly stated in the draft that server should understand it as "will 
not use, don't bother" – I really don't see how in the future that can be 
reinterpreted as "nah, send tickets anyway" – also, please remember that 
the size of the ticket is very variable, so just accepting one ticket may 
be a significant size anyway

as for memory – just because server sends them, doesn't mean client has to 
remember them

finally: ok, so the server misbehaves and sends 4 tickest instead of three, 
what the client should do? close the connection?

> 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. 

by "KEX" you mean handshake? but New Session Ticket messages are not sent 
during handshake, they are sent after handshake is finished

so how exactly you want to decide when server stopped sending NSTs after 
handshake finished?

> 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.

again, and what if the server misbehaves?

> 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 ...
>> 
>> 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
>> 
>
>

-- 
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