[TLS] TLS 1.3 and max_fragment_length

Martin Thomson <martin.thomson@gmail.com> Tue, 14 March 2017 03:38 UTC

Return-Path: <martin.thomson@gmail.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D3B7129C15 for <tls@ietfa.amsl.com>; Mon, 13 Mar 2017 20:38:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 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_LOW=-0.7, 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 BnhWWPL_RGzs for <tls@ietfa.amsl.com>; Mon, 13 Mar 2017 20:38:15 -0700 (PDT)
Received: from mail-qk0-x233.google.com (mail-qk0-x233.google.com [IPv6:2607:f8b0:400d:c09::233]) (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 6F2D11293F5 for <tls@ietf.org>; Mon, 13 Mar 2017 20:38:15 -0700 (PDT)
Received: by mail-qk0-x233.google.com with SMTP id v125so234021816qkh.2 for <tls@ietf.org>; Mon, 13 Mar 2017 20:38:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=4UUyhfu9Rc1YHs58tl5qQ8aS2A4BGoTPKK5Vo5GVrTE=; b=KdekpUVKX3DlHuYtDFU8h6jWzIlCUVajBLspbXnzrF5ZshX+bR54Du1OrhHg7j4QDr LkwBobz8O4Fs5bsQ6y2Qo1RlJufXxFolVUn6Chb2NTIEOjaFLfMGPIb3h0NA8t9L97Fz d9FviXmiyUIEliNPb4deRJFalQ2v5PTYcYl3eLE4LvuN508+01NzdmsaXpBIhBelqIlv RvQcsi5RP1xA/kyVxa4VccdzbIBsNpOhHIX2cde8OQGiZEss2Oli7Qz1/fgT3rqyK3jn SA1bMPmxycI7tlE2oV+7aEUVgbPL8eB2tJqngjm6EdUnlOQcgUqPL8qVLbRcgDTp08V0 QIAA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=4UUyhfu9Rc1YHs58tl5qQ8aS2A4BGoTPKK5Vo5GVrTE=; b=R74fhaMB2WFo5CSCq4G6Ug/Gu2fz6lXRjUXgAlhzjTNqVD6wSjEbyqOtGctkghST8w zDXQRPvymZhjmtf0/kAC9JKPoIasqWB+QRUw3l7nA4Hh++vfkk7nv8seQm+qC6oigK22 JJfy7eKNOa2Z6HIa+WLkFcXph0ZWQP8FEl55QYzl6fhBC1yor8nt2UqUXs9GL7qnY6SQ luZH+fGxB0j1AiI//FtZ/iQyHl+5pO6f9SuSNI7QguwWUu+gN7vKsnTKxGeriJq6U6Mt ZdtsmKnDyiD6S6DLGe85VI91TkRSNuecL6hIQNRMJH2/22AxFmteRhMw6xZ0lHWZnuK2 EDcQ==
X-Gm-Message-State: AFeK/H0WFzS5+ngwLqzoD/utymeVmj7oPmcYnJ7NCaP5D9Pv3H7bM1tCMUC4vYgMxEbr5q49UZ37XCmhYvYLZw==
X-Received: by 10.55.18.144 with SMTP id 16mr35612398qks.5.1489462694431; Mon, 13 Mar 2017 20:38:14 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.140.27.194 with HTTP; Mon, 13 Mar 2017 20:38:14 -0700 (PDT)
From: Martin Thomson <martin.thomson@gmail.com>
Date: Tue, 14 Mar 2017 14:38:14 +1100
Message-ID: <CABkgnnWZgo5xs=+26j6C=o+AMgWHmyQwuMWw7vL=+xvRnpZgog@mail.gmail.com>
To: "tls@ietf.org" <tls@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/qeWlMFbgdBu-P4cL3iEUh4U0aGo>
Subject: [TLS] TLS 1.3 and max_fragment_length
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 14 Mar 2017 03:38:16 -0000

When we added padding to TLS 1.3, we created an ambiguity with the
max_fragment_length extension.

Does the limit apply to len(TLSInnerPlaintext) or does it apply to
len(TLSInnerPlaintext.content) (i.e., TLSPlaintext.length)?  That is,
does is include the padding and content type, or not?

Including the padding would recognize the limitations apply to
handling large blobs of encrypted data (see earlier email from Thomas
Pornin).  That would be my preference.  I think that we need to say
that though.  I guess the second-order question is whether to roll
RFC6066-bis or patch these things in TLS 1.3 directly.

(BTW, RFC 6066 is quite poor.  It's not very precise in identifying
what it is talking about, it also describes a negotiation design
unlike anything else in TLS, one that can't be extended ever.)