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

Martin Thomson <martin.thomson@gmail.com> Sun, 04 March 2018 22:02 UTC

Return-Path: <martin.thomson@gmail.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 C8FE1126B72; Sun, 4 Mar 2018 14:02:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 NaZVv1YNOQ61; Sun, 4 Mar 2018 14:02:34 -0800 (PST)
Received: from mail-ot0-x22f.google.com (mail-ot0-x22f.google.com [IPv6:2607:f8b0:4003:c0f::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B53E126CC7; Sun, 4 Mar 2018 14:02:34 -0800 (PST)
Received: by mail-ot0-x22f.google.com with SMTP id f11so13271245otj.12; Sun, 04 Mar 2018 14:02:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=GojSAyWi4oCo0cRmAOqTy/9oAY/k7LDesatcR40XbQ0=; b=JRP0AqHLp3Rru/mcrQLTtvTcYVGp4D4Y3R+C7udTUWgLuDxD3hLBbK3e2KqSUpOUgy o+e23ngzYGv8SFdVbJQjHPb7VHrJi2SUI24agox6hJjR+lmDVlVNyMvMk1Wk097abXOm tQwZ8i4oG8nXFJgwhXZ6FEw7zmWwceQkCspUiBmzOvDgZ9XtLICz5mVAK05URNLJhq7i V3yqESesXU34wtTtZlKmvJucarTJwR67SlbfhCxwqB2W44WPK2rFvVtfhmLYSPx+cFeD DFF/IhvHc/vVs1rE2KCWpd4JBqZtiHL9Uq0xYmELa4WvB1lwvBABSzQBKNBkFNaRwXnG q+Vw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=GojSAyWi4oCo0cRmAOqTy/9oAY/k7LDesatcR40XbQ0=; b=GVrYb3mWScIpFvKM7OY6Rs6QcFiATsa05J5XNNO6HfkNRuTtmoCXaUr7lAHE/aMER/ qVeF07L+zAbiOrALhdfhmXczBiGZjfm9FHrHE8DJSxSVjm6WUciYmKsVw+uZmKQEv5+R mvrwuSYXe2p0bLRy41EXq6FELAyTzNz1qezNyHkYTzDo79TWSMI7k1CGmpHU7GpR+HLj cktVDdCVDtUI+bcVwMwGKrmT8WhAbuTuJhixPAhRLRDd0feOlgbEKJ28BDLMBp7P4is/ Z0a/UsCP8tYGNGobNWT7viXKf8Rjgq5jwVjRrEERZlWJXxmPkqydc/uVczfCptR8xBlO TXCg==
X-Gm-Message-State: AElRT7HakSRtBE21jCtk+tGHS2a0bI3NFN2V9pdJIusF68rne2mbvpue a7nyXYl8rDaU57IilPQgpxPkRJBGvh2PMoWd/kU=
X-Google-Smtp-Source: AG47ELuh729xv8JcP7decbL1WZ6zTUVxGghrCPC0fTJCWfEr2jdpcV5hDyvBzwsA/cowL9Zu9JPEwaTYdoAW2zCiJ78=
X-Received: by 10.157.78.16 with SMTP id p16mr1378774otf.15.1520200953587; Sun, 04 Mar 2018 14:02:33 -0800 (PST)
MIME-Version: 1.0
Received: by 10.157.16.85 with HTTP; Sun, 4 Mar 2018 14:02:33 -0800 (PST)
In-Reply-To: <AM4PR0801MB27065F0A56B01AB7F43F9380FADB0@AM4PR0801MB2706.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>
From: Martin Thomson <martin.thomson@gmail.com>
Date: Mon, 5 Mar 2018 09:02:33 +1100
Message-ID: <CABkgnnUHTwD==Rh1+S+GV8Wn5Y8kpTM=iOA3M7+LXc6frccYQQ@mail.gmail.com>
To: Hannes Tschofenig <Hannes.Tschofenig@arm.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>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/4pkABmGNrrMLpMBZ6EfYaOxNP4s>
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: Sun, 04 Mar 2018 22:02:36 -0000

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.