Re: [secdir] Secdir review of draft-ietf-tls-record-limit

Hannes Tschofenig <Hannes.Tschofenig@arm.com> Tue, 06 March 2018 09:07 UTC

Return-Path: <Hannes.Tschofenig@arm.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D815A126BF0; Tue, 6 Mar 2018 01:07:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.911
X-Spam-Level:
X-Spam-Status: No, score=-2.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.onmicrosoft.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 UJMtx7LTdI2o; Tue, 6 Mar 2018 01:07:40 -0800 (PST)
Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0087.outbound.protection.outlook.com [104.47.0.87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24D18120724; Tue, 6 Mar 2018 01:07:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector1-arm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Keym2P+ja3mYGns//F2vmxpAl53Td4RdW0OoqLWozdg=; b=n06N4bGGm82TWHDmvXmEP/1VTLH5RZUkcWtH4gStkx1h14xSMRHCjrVBiqQCJDhNcJeMtG/jCTwkCNrpdkpfyjx1Gn3Od/evGUIzVZQPBxw3Z86P+7VRwONd2Pb8SMepdyL8V3ficEcOIT4wnTHir+y2LeRrkb2J3+YPyM9Hh+Q=
Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com (10.173.75.16) by VI1PR0801MB1936.eurprd08.prod.outlook.com (10.173.73.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.548.13; Tue, 6 Mar 2018 09:07:36 +0000
Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::783f:d09c:fea6:f83d]) by VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::783f:d09c:fea6:f83d%17]) with mapi id 15.20.0548.016; Tue, 6 Mar 2018 09:07:36 +0000
From: Hannes Tschofenig <Hannes.Tschofenig@arm.com>
To: Martin Thomson <martin.thomson@gmail.com>
CC: Benjamin Kaduk <kaduk@mit.edu>, Alan DeKok <aland@deployingradius.com>, "draft-ietf-tls-record-limit@ietf.org" <draft-ietf-tls-record-limit@ietf.org>, IESG <iesg@ietf.org>, "secdir@ietf.org" <secdir@ietf.org>
Thread-Topic: Secdir review of draft-ietf-tls-record-limit
Thread-Index: AQHTrqGSa72OyyaNEUOT8kn5vxYs5KO4BpFggAD7SYCAB0Hm4IAAZ/uAgAE7axCAAQmDgIAABxuA
Date: Tue, 6 Mar 2018 09:07:36 +0000
Message-ID: <VI1PR0801MB2112F08E700BA9BC8F5B035BFAD90@VI1PR0801MB2112.eurprd08.prod.outlook.com>
References: <5C2E06FE-8685-457D-ACED-5600092C1CB1@deployingradius.com> <CABkgnnVYbK-==zHyUTPiWxQ_so9XepWKpUpdd=1-OsJuv_0VFQ@mail.gmail.com> <F9726F86-DF0E-46DE-B0E4-F688C7D9A51C@deployingradius.com> <20180223191714.GG50954@kduck.kaduk.org> <CABkgnnULmVtg+a0ukGSETF1nJTav+Q969u93LgL-cO-=bx2RSA@mail.gmail.com> <AM4PR0801MB2706045BB181BB0DBE95BCCFFAC00@AM4PR0801MB2706.eurprd08.prod.outlook.com> <CABkgnnU57gbUNabrpvH1ZsAXikfa9nLUEb_nXjgR7fwHnMOaVQ@mail.gmail.com> <AM4PR0801MB27065F0A56B01AB7F43F9380FADB0@AM4PR0801MB2706.eurprd08.prod.outlook.com> <CABkgnnUHTwD==Rh1+S+GV8Wn5Y8kpTM=iOA3M7+LXc6frccYQQ@mail.gmail.com> <VI1PR0801MB2112466561756E9E5095D38CFADA0@VI1PR0801MB2112.eurprd08.prod.outlook.com> <CABkgnnWj_i6XPRDdbV6GatYYEzJq2v4UPoLnN821k1bZJfWRfg@mail.gmail.com>
In-Reply-To: <CABkgnnWj_i6XPRDdbV6GatYYEzJq2v4UPoLnN821k1bZJfWRfg@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com;
x-originating-ip: [80.92.122.126]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; VI1PR0801MB1936; 7:M0Epfd4tDYiUo6Pp6T0tKpp85RpfdkwnlhPhWgtThp2pOmT1OPKkzCamiFzsph4X4Z7tdX4vBiNkK0fV4a1Sxg000j6DZlEDvsiGegNKHdwQuv0Qcyt5T8JNlI9Nk0NYYRb5wHKH0kuS6+Y2Ei0AdKioKvPOb+kfrANj2MvYQEiUNA24TAr04974nPy0xzgLmRXexV2PS+aOzkQXZiK5mIPvmOuCTARP7iRFbtOBPlCLPo161mkmcgIyiJr3znTV
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: bebdf606-739d-44a5-6e1a-08d58341b434
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(48565401081)(5600026)(4604075)(3008032)(2017052603328)(7153060)(7193020); SRVR:VI1PR0801MB1936;
x-ms-traffictypediagnostic: VI1PR0801MB1936:
x-microsoft-antispam-prvs: <VI1PR0801MB193601BA8CEA0B4B3711CEE7FAD90@VI1PR0801MB1936.eurprd08.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(158342451672863)(180628864354917)(85827821059158);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040501)(2401047)(8121501046)(5005006)(93006095)(93001095)(3231220)(944501244)(52105095)(10201501046)(3002001)(6055026)(6041288)(20161123564045)(20161123562045)(20161123558120)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:VI1PR0801MB1936; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0801MB1936;
x-forefront-prvs: 06036BD506
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(366004)(39380400002)(39860400002)(346002)(376002)(40434004)(51444003)(199004)(189003)(13464003)(106356001)(66066001)(305945005)(2950100002)(5660300001)(6916009)(59450400001)(97736004)(33656002)(478600001)(74316002)(53546011)(186003)(6506007)(26005)(72206003)(2900100001)(6436002)(81156014)(8676002)(7736002)(81166006)(229853002)(102836004)(93886005)(8936002)(55016002)(9686003)(53936002)(54906003)(3280700002)(105586002)(6246003)(76176011)(7696005)(5250100002)(99286004)(6116002)(86362001)(3846002)(316002)(25786009)(4326008)(68736007)(5890100001)(3660700001)(39060400002)(2906002)(14454004); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0801MB1936; H:VI1PR0801MB2112.eurprd08.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: Dzz+WOwXhWj6DnxnPa1ratRg/laIlFkFIOELMNLzTsZ+VhcvzqL2zFaQ8wLEOGNqDEbIaSNx2KX8wBexpJfaGyDSc8nvX/q5Ju9FQWxVlreD2cyRFQj/LB0hihm2apak/eudxyJ1jtNugk0YiPg9b1srcoXLX1ZuekaIxtyxDvYGQxFnbXm5tg4XjUv9EnfyOw7Sl90w1T8ElD9bV6Z/WoINOHrDr/pbM1VPZo55Kyy4ZXRMDaek7ZvaLNKFfrTzdOyt7g6weA6jvH/tcYwc0876aW5nrVmCOKpoTI/J+sPW772xikgc6BhD9RDFEFNbaKDrPaqtIZMAMKgxnNue9A==
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: arm.com
X-MS-Exchange-CrossTenant-Network-Message-Id: bebdf606-739d-44a5-6e1a-08d58341b434
X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Mar 2018 09:07:36.1147 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0801MB1936
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/DWNqHUs2gjRuFftEuYAN49ZLbbk>
Subject: Re: [secdir] Secdir review of draft-ietf-tls-record-limit
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 06 Mar 2018 09:07:43 -0000

Thanks, Martin!

-----Original Message-----
From: Martin Thomson [mailto:martin.thomson@gmail.com]
Sent: 06 March 2018 09:42
To: Hannes Tschofenig
Cc: Benjamin Kaduk; Alan DeKok; draft-ietf-tls-record-limit@ietf.org; IESG; secdir@ietf.org
Subject: Re: Secdir review of draft-ietf-tls-record-limit

Just to follow-up. I think that removing the "especially handshake messages" will help resolve this.  This implies that handshake messages are always unprotected, which is not the case.

The change that I propose:

-RecordSizeLimit value it receives from its peer.  Unprotected messages - -handshake messages in particular - are not subject to this limit.
+RecordSizeLimit value it receives from its peer.  Unprotected messages
+are not subject to this limit.


On Tue, Mar 6, 2018 at 3:51 AM, Hannes Tschofenig <Hannes.Tschofenig@arm.com>; wrote:
> I believe we are on the same page with regards to this issue.
>
> -----Original Message-----
> From: Martin Thomson [mailto:martin.thomson@gmail.com]
> Sent: 04 March 2018 23:03
> To: Hannes Tschofenig
> Cc: Benjamin Kaduk; Alan DeKok; draft-ietf-tls-record-limit@ietf.org;
> IESG; secdir@ietf.org
> Subject: Re: Secdir review of draft-ietf-tls-record-limit
>
> On Mon, Mar 5, 2018 at 2:57 AM, Hannes Tschofenig <Hannes.Tschofenig@arm.com>; wrote:
>> [Hannes] I am not sure I fully understand the approach. Even if
>> someone uses TCP a RAM limitation will not go away. TCP is likely to
>> make the situation worse since it requires some amount of RAM as well
>> even with the best possible configuration. (There is this work in
>> LWIG on TCP implementation guidance where the authors are supposed to
>> provide some information about the actual RAM usage of various TCP
>> features and settings.)
>
> Let me try to explain more.
>
> An endpoint that can't handle a big packet (whether that be a big TCP segment or a big UDP datagram) can always pretend that this is a link issue and send the appropriate ICMP message.  That limits the size of packets they receive, at least to the point that the minimum for the IP version in use is reached (576 for v4, 1280 for v6).  I'm not sure what fragmentation does here, other than make things far worse.
>
> If there are multiple packets arriving and no space for more than one, then the endpoint can pretend that it didn't receive the packet.  TCP also has ACKs, which the endpoint can withhold until it has space.
>
> Thus, the endpoint can hold as little as a single MTU of data at once.
> Given that it is not encrypted, my understanding is that there is no need to constrain how it is turned into records.
>
> Note that a constrained server has to handle a full ClientHello - the client won't know the limit at the server.
> IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.