Re: [Potential Spoof] Re: Getting to consensus on packet number encryption

Roberto Peon <fenix@fb.com> Tue, 10 April 2018 07:44 UTC

Return-Path: <prvs=7638027d87=fenix@fb.com>
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFD01124319 for <quic@ietfa.amsl.com>; Tue, 10 Apr 2018 00:44:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.72
X-Spam-Level:
X-Spam-Status: No, score=-2.72 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_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fb.com header.b=lI68uRsy; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.b=AFyEmvcR
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 kb0hPCVszrmx for <quic@ietfa.amsl.com>; Tue, 10 Apr 2018 00:44:24 -0700 (PDT)
Received: from mx0a-00082601.pphosted.com (mx0a-00082601.pphosted.com [67.231.145.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EBCCE12711D for <quic@ietf.org>; Tue, 10 Apr 2018 00:44:22 -0700 (PDT)
Received: from pps.filterd (m0044008.ppops.net [127.0.0.1]) by mx0a-00082601.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w3A7iHd9028613; Tue, 10 Apr 2018 00:44:18 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.com; h=from : to : cc : subject : date : message-id : content-type : content-id : content-transfer-encoding : mime-version; s=facebook; bh=7+RNxSM2N2WD0fCyRc86Mu2UadLNAXsbZcOEWbpr2AM=; b=lI68uRsyfUcQn2HqPL2YeOFCsSfvWnZK3Hd4zC+3/0IcBrZQNpFh91clHnjXjZDwyvJH I0CE+sAi2OsxaWfadj+JPyWzuFGGKhaO1wxIp918FOJOmb2DNTot10i+pQG888alINPz SQGWssZO6Pt6qz++nQxgh3ZaXhcC6eflwNg=
Received: from maileast.thefacebook.com ([199.201.65.23]) by mx0a-00082601.pphosted.com with ESMTP id 2h8p848be6-1 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 10 Apr 2018 00:44:18 -0700
Received: from NAM02-SN1-obe.outbound.protection.outlook.com (192.168.183.28) by o365-in.thefacebook.com (192.168.177.32) with Microsoft SMTP Server (TLS) id 14.3.361.1; Tue, 10 Apr 2018 03:44:15 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.onmicrosoft.com; s=selector1-fb-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=7+RNxSM2N2WD0fCyRc86Mu2UadLNAXsbZcOEWbpr2AM=; b=AFyEmvcRwwYGxJhl/1MFKF3xlTu8nOJofq8602J958Tq/45Cv9BVPwLdDffzb/d4Y2SGSZ1AFq0JWYuVp9U2jn1pQ4Mgj/+nz0/+bgU/YkB8zCRnQHW9q/yGu/PFg3ziOd2oRT5cP7Yjge9ZPPOR8moWUFJFi4LTSXrbYjYwhWQ=
Received: from BY2PR15MB0775.namprd15.prod.outlook.com (10.164.171.11) by BY2PR15MB0151.namprd15.prod.outlook.com (10.163.64.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.653.12; Tue, 10 Apr 2018 07:44:13 +0000
Received: from BY2PR15MB0775.namprd15.prod.outlook.com ([fe80::78a6:3a7a:1195:dd02]) by BY2PR15MB0775.namprd15.prod.outlook.com ([fe80::78a6:3a7a:1195:dd02%13]) with mapi id 15.20.0653.018; Tue, 10 Apr 2018 07:44:13 +0000
From: Roberto Peon <fenix@fb.com>
To: Mirja Kühlewind <mirja.kuehlewind@tik.ee.ethz.ch>, Christian Huitema <huitema@huitema.net>
CC: "quic@ietf.org" <quic@ietf.org>
Subject: Re: [Potential Spoof] Re: Getting to consensus on packet number encryption
Thread-Topic: [Potential Spoof] Re: Getting to consensus on packet number encryption
Thread-Index: AQHT0J+3yDxxFSXxnU2EEOelq+HwJw==
Date: Tue, 10 Apr 2018 07:44:12 +0000
Message-ID: <15E8D686-EF5C-40D8-A727-3099777D8F34@fb.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.a.0.180210
x-originating-ip: [70.103.56.2]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; BY2PR15MB0151; 7:W5W6Ua8yTLeSi+VybWpdvOyaIuRNfF8/NnTxKtru/XD0BbTsjm/jnMLlzYCPdqH8YPpZfO2+2y9SPhJ/vWYK0Rdfd7mW7xQRnzYy5BsOu4Dt8deHKXEdQ2XpAJAuufgptPvrwY7DtnuHr3DBL1r++mTHbceebFUIo885ZoBzS34QSzn63tB1M+ZH1vUG/Xl7x5XrFx4fuLpGoQ2RFwOKSDbWptT5fVAdS2HAAtbrJMoV0AxEHqukZ9ukSKB+3MSO; 20:ViJWOxPMmlU9u1642yHGLJtH/ogAQQbfb2jA7jHldhwxIPEqnvnURFyFs5/7xvhHrFf9AaVsebUsZqDEZbDE+Zb2yChA93NJLc1Mxz44ME+n2YquPlo9G+3fMgoG/XeZTDFlhWqPbgY5jY8kldoSJvBZJ06jUfildT/8kExn33g=
x-ms-exchange-antispam-srfa-diagnostics: SOS;
X-MS-Office365-Filtering-Correlation-Id: d8ef1d57-5af5-41e0-cdf8-08d59eb6da86
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:BY2PR15MB0151;
x-ms-traffictypediagnostic: BY2PR15MB0151:
x-microsoft-antispam-prvs: <BY2PR15MB01517DF143235CDAABC9298DCDBE0@BY2PR15MB0151.namprd15.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(67672495146484)(100405760836317);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(3002001)(10201501046)(93006095)(93001095)(3231221)(11241501184)(944501327)(52105095)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123558120)(20161123562045)(20161123564045)(6072148)(201708071742011); SRVR:BY2PR15MB0151; BCL:0; PCL:0; RULEID:; SRVR:BY2PR15MB0151;
x-forefront-prvs: 0638FD5066
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(346002)(366004)(39380400002)(396003)(376002)(189003)(199004)(54014002)(25786009)(53546011)(6436002)(26005)(4326008)(5660300001)(5250100002)(8936002)(229853002)(33656002)(105586002)(486006)(82746002)(305945005)(99286004)(186003)(476003)(478600001)(81166006)(59450400001)(6486002)(83716003)(66066001)(7736002)(14454004)(2616005)(81156014)(86362001)(8676002)(97736004)(2906002)(3660700001)(110136005)(58126008)(6116002)(3846002)(6506007)(102836004)(6512007)(53936002)(316002)(68736007)(3280700002)(6246003)(2900100001)(106356001)(36756003)(427584002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR15MB0151; H:BY2PR15MB0775.namprd15.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: fb.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: jszxl1/UImO02ALRAqcAcLk/mGzAtrTo9F2VwHMPvhQuIqs7qvt48yf4HJjZ+2o0OBKkus8b7aVq5SDq+i//QhYv149SRghA5vR3qSM2lTDAY2H1DsUM95ybCYOlblGP71/hDGewSmapgvCsxoPL8UsjGS2MPKH9shwnX43IW7y8sCWriOSr/VfWYv23rYX5LIxi/QBjKQuqjH3lie1YmFy3SGYdkhAZzdh1Aeu1/+lFD6O1t59mD9d/01M9RU4R5YrS+Pa9OCPXuOyNPWvdZ2YU+fwEpglzHPijyehQS9rQAT996sobKA3L404dIpT0Wuwmt8xM+2/h340n/FOz07ydI63ORBLuNSum4lC3H4P/9lcB2FfOe9iRNkvNTDg8I36v+sW/qQ+PrpzufFg7hF/oC8zHZncNHvldNhnfHZU=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: <2B68550F9B39E341881EF41D56FEEAE7@namprd15.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: d8ef1d57-5af5-41e0-cdf8-08d59eb6da86
X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Apr 2018 07:44:12.8734 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR15MB0151
X-OriginatorOrg: fb.com
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-04-10_03:, , signatures=0
X-Proofpoint-Spam-Reason: safe
X-FB-Internal: Safe
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/mnma_Kruujr_fv4LVHdXpKfF11M>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <quic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic>, <mailto:quic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic/>
List-Post: <mailto:quic@ietf.org>
List-Help: <mailto:quic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic>, <mailto:quic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 10 Apr 2018 07:44:27 -0000

I love it when mail is delivered some days after it is sent. :/
-=R

On 4/9/18, 6:05 PM, "QUIC on behalf of Roberto Peon" <quic-bounces@ietf.org on behalf of fenix@fb.com> wrote:

    Adding another PN would probably not be sufficient-- one would need to ensure that the ossified PN was presented with the right sequencing as well, which might be difficult, or expensive.
    Ossification is surprisingly difficult to work around once it sets in, as even figuring out how it is impacting you can be substantial work.
    
    -=R
    
    On 4/5/18, 2:27 AM, "QUIC on behalf of Mirja Kühlewind" <quic-bounces@ietf.org on behalf of mirja.kuehlewind@tik.ee.ethz.ch> wrote:
    
        Let me repeat another position then as well:
        
        > Am 05.04.2018 um 02:44 schrieb Christian Huitema <huitema@huitema.net>:
        > 
        > If we are in the business of repeating our positions, so be it. I am pretty much on the same line as Patrick and others:
        > 
        > 1) Privacy is not optional. And yes, removing "linkability through PN" is important, because when the connection ID and the source address also change, the only other cue for linkability is timing. Timing can be addressed by having overlapping connections.
        > 
        Timing doesn’t help here either because you still have the same destination IP, both port numbers and the fact that a migrated connection does not have a handshake. If we want to address the linkability problem, we would need to do much more, probably baring more hits on performance. 
        
        I thought we discussed this already endlessly and concluded that PNE does not help linkability.
        
        Then an argument for ossification was broad up. However, we really cannot compare the situation here with TCP. With TCP everything is in the clear incl. also the retransmissions. In case of MPTCP this was rather the problem the the seq# because if you’d use the same seq# number space on both connections it would like loss but without a retransmission. Further boxes that reorder, usually do that in situation where packets were transmitted for a known reason out-of order previously, e.g. when multiple paths are used in the network. The recommendation we still give in the IETF transport area is that in such a situation the scheduling should not be done on a per-packet level but per-flow. However, those scheme that do per-packet scheduling usually also apply mechanism to re-order afterwards. They can just use the TCP seq# for that but for non-TCP they would simply add their own encapsulation with a seq#…
        
        Please keep in mind that even if an (unencrypted) PN gets ossified by the network,
        in case of QUIC that does not mean that we can’t change the transport machinery anymore. Currently the exposed PN is also used for congestion control and retransmission, however, we can still add another PN in the encrypted part and resolved the fact that the current PN is overloaded for different functions.
        
        Currently, I really still don’t see the benefit of PNE but only additional complexity and known performance degradation.
        
        Mirja