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

Martin Thomson <martin.thomson@gmail.com> Wed, 28 February 2018 01:00 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 C9E28124D68; Tue, 27 Feb 2018 17:00:45 -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 qvxkQ5GJ3ize; Tue, 27 Feb 2018 17:00:44 -0800 (PST)
Received: from mail-ot0-x22c.google.com (mail-ot0-x22c.google.com [IPv6:2607:f8b0:4003:c0f::22c]) (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 947B7124235; Tue, 27 Feb 2018 17:00:44 -0800 (PST)
Received: by mail-ot0-x22c.google.com with SMTP id l5so720634otf.9; Tue, 27 Feb 2018 17:00:44 -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=T7N4Nuj72Em0ztMDhDkoWJHHiTJS4xLcCDKMt8/69Nc=; b=lNKMRbcjhZwvYFmkZ/qbKrDD6JOVVYtQlTUwD4JoGzc4D1GPGy46p3pOWRBaw89K2T l66yWrHGDHBwhQjxdqg/C48/yiFmr1Jwfyp3B3817+INcbRwmsJHyDhe7hwD61woC7d6 L+7gbws8tbihZw5epPIkA6YrerYRPEkudmPOLF21B2Ju9qxG17jDcklOemGHvDHiPAP2 U3Y1/GKMSSrJDeKnra9EIF+p3onZELF5U+O6oBraaCMW2otmSvUshvVKC7tWkPnYCdVx cAq5Frfj+9deqjIwVOmZSeNzn9Q/f7BPC4+q8u2ccA3E49T5GtEgaIDxsjqZ3aJF1Wo6 Yy9w==
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=T7N4Nuj72Em0ztMDhDkoWJHHiTJS4xLcCDKMt8/69Nc=; b=RAdalClxd828uZvKHrFR25IMNqV6iuXb9CTqSh3lxr8tzg7PUKM58lZMAF1wg+HjZk Pc/OXjiyx0+YuWn3sT2BfR9+8fnB7rDiUjna7vnPRlWZe4pvluPGQC0iq5jV+TjCiVjU B0ZAi6QCYVnHuZoG5sZbtI+0qd1eVxxZ4jl5ZbWqfMqH98SJDwFivWgqBoBkb62HRaq2 ejdslc2oEFI+4YLLV774ubhYUJ69kQ2Gk10b1aaw6pK8KVFh4ONMYdQ+GA6HsCHu1s58 edznkMX+yfffE0UubB/ihJBiMp3DJJ+j5/f7LrrhnFzTl9h18nZ04B7Zel3siWLUfeN2 4WXw==
X-Gm-Message-State: APf1xPAJJwpksWN+OOvvlIpQ1ROCmCBVULzWDlkPln8VWUoK44U3uRRz 4OKbq+GoE7qSAEXdWI5nBzr6foek7G8zjrGW2L4=
X-Google-Smtp-Source: AG47ELv2M2MccXnKENd51UCGJVPm+1xPWtMSXmRdraRY/BdDQMM/Y4DTshYF5xrce/KqTP+SUzIY0BcTNuQDqQn1NRY=
X-Received: by 10.157.64.181 with SMTP id n50mr12089889ote.241.1519779643869; Tue, 27 Feb 2018 17:00:43 -0800 (PST)
MIME-Version: 1.0
Received: by 10.157.16.85 with HTTP; Tue, 27 Feb 2018 17:00:43 -0800 (PST)
In-Reply-To: <AM4PR0801MB2706045BB181BB0DBE95BCCFFAC00@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>
From: Martin Thomson <martin.thomson@gmail.com>
Date: Wed, 28 Feb 2018 12:00:43 +1100
Message-ID: <CABkgnnU57gbUNabrpvH1ZsAXikfa9nLUEb_nXjgR7fwHnMOaVQ@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/HYdP6E46cSx6Hhy5MvgtYI30-QE>
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: Wed, 28 Feb 2018 01:00:46 -0000

Thanks Hannes,

On Tue, Feb 27, 2018 at 9:27 PM, Hannes Tschofenig
<Hannes.Tschofenig@arm.com>; wrote:
> For example, imagine a certificate message that may contain multiple certificates that then need to be processed one by one by the recipient. Here the stack needs to be "smart" enough to send enough data that the recipient can actually do something with it (like one complete certificate) but also not too much so that it still fits into the buffer. For application data it may be less complicated since the application developer who had set the RSL limit is most likely aware of what to do when the stack cannot send all the data.

Yeah, if you are so constrained that a single datagram is all the
scratch space you have, then big certificates can be nigh on
impossible to manage.  My understanding is that raw public keys are
more common in this context.

> FWIW: The draft currently says that "unprotected messages - handshake messages in particular - are not subject to this limit.". I am not sure whether I fully understand that sentence. Does it mean that the limit does not apply to handshake messages at all or only to handshake messages that are unprotected? In either case I am not sure whether that scoping makes sense since handshake messages can become fairly large.

This was written with two things in mind.  TCP makes it easy to apply
back pressure and thereby enable progressive reads for larger
cleartext messages, assuming that you can read it all without holding
everything in memory at once.  More critically, a ClientHello will be
sent in ignorance of any preferences on a server, so a server has to
cope somehow.

If you remain concerned about constrained *clients*, maybe we can
change the requirement and have it apply immediately for the server's
handshake messages.  In TLS 1.2, it would then also apply to the
client Certificate, which I suppose is something.  It's definitely
possible to make this change. (Now that I think on it, my
implementation may already do this.  I should check.)