Re: [EToSat] BDP parameters draft: security aspects

<emile.stephan@orange.com> Wed, 18 December 2019 10:14 UTC

Return-Path: <emile.stephan@orange.com>
X-Original-To: etosat@ietfa.amsl.com
Delivered-To: etosat@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09BD81200F7 for <etosat@ietfa.amsl.com>; Wed, 18 Dec 2019 02:14:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level:
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham 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 ga7gu6F6-jN4 for <etosat@ietfa.amsl.com>; Wed, 18 Dec 2019 02:14:13 -0800 (PST)
Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.70.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9BEF91200F4 for <etosat@ietf.org>; Wed, 18 Dec 2019 02:14:13 -0800 (PST)
Received: from opfednr04.francetelecom.fr (unknown [xx.xx.xx.68]) by opfednr25.francetelecom.fr (ESMTP service) with ESMTP id 47d9pW0kbWzCrTq; Wed, 18 Dec 2019 11:14:11 +0100 (CET)
Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.70]) by opfednr04.francetelecom.fr (ESMTP service) with ESMTP id 47d9pV5QwJz1xp4; Wed, 18 Dec 2019 11:14:10 +0100 (CET)
Received: from OPEXCAUBM44.corporate.adroot.infra.ftgroup ([fe80::e8a4:8bb:d7c2:f4e2]) by OPEXCAUBM33.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0468.000; Wed, 18 Dec 2019 11:14:09 +0100
From: emile.stephan@orange.com
To: Christian Huitema <huitema@huitema.net>, Kuhn Nicolas <Nicolas.Kuhn@cnes.fr>
CC: "'Gorry (erg)'" <gorry@erg.abdn.ac.uk>, "'etosat@ietf.org'" <etosat@ietf.org>
Thread-Topic: BDP parameters draft: security aspects
Thread-Index: AdW1gEyCNoBvQ74JQwGzxTFJSgT4Nw==
Date: Wed, 18 Dec 2019 10:14:09 +0000
Message-ID: <31545_1576664050_5DF9FBF2_31545_447_1_8150a728-149d-4502-9741-ef0673eb3416@OPEXCAUBM33.corporate.adroot.infra.ftgroup>
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.114.13.245]
Content-Type: multipart/alternative; boundary="_000_8150a728149d45029741ef0673eb3416OPEXCAUBM33corporateadr_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/etosat/YuolQTIeU-y4zR6ftqFdAOUCMp8>
Subject: Re: [EToSat] BDP parameters draft: security aspects
X-BeenThere: etosat@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "The EToSat list is a non-WG mailing list used to discuss performance implications of running encrypted transports such as QUIC over satellite." <etosat.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/etosat>, <mailto:etosat-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/etosat/>
List-Post: <mailto:etosat@ietf.org>
List-Help: <mailto:etosat-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/etosat>, <mailto:etosat-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 18 Dec 2019 10:14:16 -0000

Hi Christian,



Thanks for your analysis of the draft. See inline



-----Original Message-----
From: Christian Huitema [mailto:huitema@huitema.net]
Sent: mercredi 18 décembre 2019 03:03
To: Kuhn Nicolas
Cc: 'Gorry (erg)'; 'etosat@ietf.org'; STEPHAN Emile TGI/OLN
Subject: Re: BDP parameters draft (was: [EToSat] Re-chartering for extension work)



...



There is also a security aspect there. The server that blindly trusts

the BDP option will blast a large number of packets. What if the client

is trying to sabotage the local network? Why should the server trust the

client? The security section does not cover that...



[Emile]

The draft supposes that the BDP parameters are protected using the same mechanism that protect initial_max_data TP: the server has a mean to check that the parameters proposed by the client are those it sent to the client during the previous connexion. We will reword that in the security section but it is not an easy part as the usage of TLS1.3 newSessionTicket by QUIC is hard to summarize.



Cdt

Emile



On 12/17/2019 7:27 AM, Kuhn Nicolas wrote:

> Hi Mark, Lars,

>

> Many meetings discussed the impacts of QUIC encryption on satellite Performance-enhancing proxy (PEP) and the benefit of exchanging additional transport parameters.

> draft-kuhn-quic-0rtt-bdp was mentioned as a possible extension during « Quick QUIC Update » presentation.

>

> We have updated draft-kuhn-quic-0rtt-bdp-05 as an extension of QUIC.

> We propose to include it in the re-chartering discussion.

>

> Regards,

> Nicolas, Emile and Gorry

>

> https://datatracker.ietf.org/meeting/106/materials/slides-106-tsvarea-quick-quic-update-mark-nottingham-00.pdf

> https://tools.ietf.org/html/draft-kuhn-quic-0rtt-bdp-05

>



_________________________________________________________________________________________________________________________

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.