[TLS] QUIC vs TLS1.3 initial_max_data (was RE: Updates on the "Transport parameters for 0-RTT connections" draft)

<emile.stephan@orange.com> Tue, 09 July 2019 21:14 UTC

Return-Path: <emile.stephan@orange.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 7E0A21200C7; Tue, 9 Jul 2019 14:14:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id eLVJg03GefyO; Tue, 9 Jul 2019 14:14:00 -0700 (PDT)
Received: from relais-inet.orange.com (relais-inet.orange.com []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 654D212006F; Tue, 9 Jul 2019 14:14:00 -0700 (PDT)
Received: from opfedar06.francetelecom.fr (unknown [xx.xx.xx.8]) by opfedar21.francetelecom.fr (ESMTP service) with ESMTP id 45jw6Z5Whsz7tkH; Tue, 9 Jul 2019 23:13:58 +0200 (CEST)
Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.42]) by opfedar06.francetelecom.fr (ESMTP service) with ESMTP id 45jw6Z45Qkz3wb8; Tue, 9 Jul 2019 23:13:58 +0200 (CEST)
Received: from OPEXCAUBM44.corporate.adroot.infra.ftgroup ([fe80::e8a4:8bb:d7c2:f4e2]) by OPEXCAUBMA2.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0439.000; Tue, 9 Jul 2019 23:13:58 +0200
From: <emile.stephan@orange.com>
To: "Lubashev, Igor" <ilubashe@akamai.com>, Kuhn Nicolas <Nicolas.Kuhn@cnes.fr>, "tsvwg@ietf.org" <tsvwg@ietf.org>, IETF QUIC WG <quic@ietf.org>, "'tls@ietf.org'" <tls@ietf.org>
CC: "'gorry@erg.abdn.ac.uk'" <gorry@erg.abdn.ac.uk>
Thread-Topic: QUIC vs TLS1.3 initial_max_data (was RE: Updates on the "Transport parameters for 0-RTT connections" draft)
Thread-Index: AdU2myLE/AUABr1hRZ2MXDXAZs+ZWw==
Date: Tue, 9 Jul 2019 21:13:57 +0000
Message-ID: <5269_1562706838_5D250396_5269_207_1_5AE9CCAA1B4A2248AB61B4C7F0AD5FB931E78610@OPEXCAUBM44.corporate.adroot.infra.ftgroup>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
x-originating-ip: []
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/UfzNsbX7BlPSwy7aOIWpRXPfeDA>
Subject: [TLS] QUIC vs TLS1.3 initial_max_data (was RE: Updates on the "Transport parameters for 0-RTT connections" draft)
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, 09 Jul 2019 21:14:03 -0000

Hi Igor,

You are right, QUIC TLS spec maps TLS1.3  'early_data' field in the "initial_max_data" transport parameter.
I don't know the motivation. It sounds good to move transport parameters out of the TLS NewSessionTicket.


-----Message d'origine-----
De : Lubashev, Igor [mailto:ilubashe@akamai.com] 
Envoyé : mardi 9 juillet 2019 19:43
À : Kuhn Nicolas; tsvwg@ietf.org; IETF QUIC WG; 'tls@ietf.org'
Cc : 'gorry@erg.abdn.ac.uk'c.uk'; STEPHAN Emile TGI/OLN
Objet : RE: Updates on the "Transport parameters for 0-RTT connections" draft

Nico, thanks for caring about clients behind high-latency links.

> The NewSessionTicket carries an additional field named 'early_data'
> that indicates to the client the maximum size of application data to
> insert in the 0-RTT message.

I see that draft-ietf-quic-tls requires use of initial_max_data instead and required "early_data" to carry no information.  See section 4.5 "Enabling 0-RTT".  Is there an advantage to use one vs the other? 

> BDP_metadata

All these parameters the client can calculate itself. You mention that the clients may actually reject BDP_metadata, if its contents seem suspect to it. So is this structure useful because some clients will be able to make use of these fields on a subsequent 0-RTT connection but would not care to implement the needed measurements themselves? Or is there some other reason?

Best wishes,

- Igor


From: Kuhn Nicolas <Nicolas.Kuhn@cnes.fr> 
Sent: Tuesday, May 21, 2019 9:47 AM
Subject: Updates on the "Transport parameters for 0-RTT connections" draft

Dear all, 

Following the different feedbacks on this draft, we have proposed an updated version on the "Transport parameters for 0-RTT connections". 

The draft proposes a solution where path characteristics are shared between the peers to improve the ingress traffic for 0-RTT connections.

The difference with version 01 are mainly based on the received feedback.
In short, we now a BDP_metadata structure so that various path parameters can be exposed to the client (MTU, RTT, bandwidth, loss-rate).
We have also added a section to discuss what happens when BDP is used incorrectly.

Let us know if we have any views or interest in this proposal. 


Nico for the authors


Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.