Re: [TLS] RFC 6066 - Max fragment length negotiation

Martin Thomson <martin.thomson@gmail.com> Tue, 21 March 2017 23:51 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 9565A129409 for <tls@ietfa.amsl.com>; Tue, 21 Mar 2017 16:51:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 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, URIBL_BLOCKED=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 mUBWHZ3JKP6z for <tls@ietfa.amsl.com>; Tue, 21 Mar 2017 16:51:22 -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 7D04C127977 for <tls@ietf.org>; Tue, 21 Mar 2017 16:51:22 -0700 (PDT)
Received: by mail-qk0-x233.google.com with SMTP id p64so147393168qke.1 for <tls@ietf.org>; Tue, 21 Mar 2017 16:51:22 -0700 (PDT)
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; bh=SZ8VcIhZrp15XLjj8VOp2KgytH2jYQcuMQ9ttJiuNHI=; b=iHZ6cbT9RsygEMZ86BAf/KV/WZzskC7OmfKxqYzDgGqVRn0iy2XJVFqmoSdZe4+W7n f2r72Uox82n5w4ZSylGKiM0lpdt8ZEq43Kdpv9o7NL3MuoBg20kqPRUo9egsyXuym2Op 6BwrqgIDpSAE/lC8aSZtaeP0EwPQNT8YAXASr9nHKihKEjeaWMNhziH3flfAeRJRK2e8 fvHnCA0/XGhQGFKur0g8NyKJivEcqnp0i84uimoow/Oo34j++Id2g4LQoUfVgXjl7uFk K9g9dReMIa/F9SzDnfIIKk87rzTOG/7hrqUrXnsHYHvOj3CZ2Qn3ZjcgWKQ71MAYQco0 mX6w==
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; bh=SZ8VcIhZrp15XLjj8VOp2KgytH2jYQcuMQ9ttJiuNHI=; b=shj1y1T4P12jo36dzXAqzyLJUaE6cK30WBCNtGd22g4Zs0zrzW+FZkSeK51oI7Kvcd YWtJJ4zJuygnLpot91wV6ykKYUtiaj/ww90brqDPIT35H2SbhHhdk9JA368vdOJAnVlk GuRu9WUIXe/kJLeG20aHDkQ5qZyvwLXJPA5UC064amSQFNAPFHPPxu/KF3EnRLAucjqb 3RqPFTkYMJnRIEf6Hi94rgyyycGFdzlHcUHnKz+eJorrUja7Q82ZKaKneuVKhrZfq6Zf BmuIZsJ2DIa35y5USs3inE+6t0OnpJJBzIkVe7KkmEmTBImoagm61UY4IykkjLKi0WT9 abBw==
X-Gm-Message-State: AFeK/H2zXx0xoCJNzCiYAPKXSBN47uhMKY54owyUGnqjphRUQRVpDarFl3wVCW3lgAmvj4J37e0UFYMROZLCWw==
X-Received: by 10.233.237.20 with SMTP id c20mr34886533qkg.144.1490140281623; Tue, 21 Mar 2017 16:51:21 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.140.27.194 with HTTP; Tue, 21 Mar 2017 16:51:20 -0700 (PDT)
In-Reply-To: <20170321131514.GA9342@bolet.org>
References: <CAD8WAomJLs4hdaso9hT036=UORjT9=H5-oCHbdSofuv++n3rYg@mail.gmail.com> <1489706298995.98317@cs.auckland.ac.nz> <855C5079-FDA7-4E68-AE29-1E9605B495D7@broadcom.com> <1489707933992.42551@cs.auckland.ac.nz> <CABkgnnVRZBwXHZ6w=gX9pykNpXp80OLP1pe-VMg-uO-C6O8yEQ@mail.gmail.com> <1489710142144.88978@cs.auckland.ac.nz> <CABkgnnXiB5ksGbbPqDP3D=FVdQu9ht0vD8-T-5HTaEKQQE4+9w@mail.gmail.com> <1489721710740.52293@cs.auckland.ac.nz> <CABkgnnWq_5e8TJgJV+okqi6vo-_5=811pOZRtUCp0TD07SmNoQ@mail.gmail.com> <CABkgnnW=Pz+6M8UYoB+MTY8rQp9vsHyh6aqiSb3EbTT_BdWokA@mail.gmail.com> <20170321131514.GA9342@bolet.org>
From: Martin Thomson <martin.thomson@gmail.com>
Date: Wed, 22 Mar 2017 10:51:20 +1100
Message-ID: <CABkgnnXViCs02T1JK-gnCr8RHvHs9LNZCvWc5_yx4SDqwuDhEg@mail.gmail.com>
To: Thomas Pornin <pornin@bolet.org>
Cc: "tls@ietf.org" <tls@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/CT6yHQ8N06nNEwamjvfDdCN0vXg>
Subject: Re: [TLS] RFC 6066 - Max fragment length negotiation
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
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, 21 Mar 2017 23:51:24 -0000

Thanks Thomas, inline responses.

On 22 March 2017 at 00:15, Thomas Pornin <pornin@bolet.org> wrote:
> Therefore, I propose to replace this paragraph:
>
>     An endpoint that has no limit on the size of data they receive can
>     set this value to any value equal to or greater than the maximum
>     possible record size, such as 65535. A larger value does not allow
>     the endpoint to send larger records than the protocol permits. An
>     endpoint that receives a value larger than the maximum defined in
>     the protocol MUST NOT exceed protocol-defined limits. For TLS 1.3
>     and earlier, this limit is 2^14 octets.
>
> with the following:
>
>     An endpoint that supports all sizes that comply with the
>     protocol-defined limits MUST send exactly that limit as value for
>     maximum record size (or a lower value). For TLS 1.3 and earlier,
>     that limit is 2^14 octets. Higher values are currently reserved for
>     future versions of the protocol that may allow larger records; an
>     endpoint MUST NOT send a value higher than 2^14 unless explicitly
>     allowed by such a future version and supported by the endpoint.
>
>     When an endpoint receives a maximum record size limit larger than
>     the protocol-defined limit, that end point MUST NOT send records
>     larger than the protocol-defined limit, unless explicitly allowed by
>     a future TLS version.

Added, tweaked a little:
https://github.com/martinthomson/tls-record-limit/commit/62a5ef2306c123394b4045913b81aee9f529dd90

(My original thought was that perhaps we could keep this orthogonal to
any potential extension that tweaked the maximum size, but this has
the same effect with less ugliness.)

> Of course, larger-than-16384 records are not meant for constrained
> systems, but for big systems. Overhead for 16384-byte records with
> ChaCha20+Poly1305 is 21 bytes (for AES/GCM in TLS 1.2, this is 29
> bytes), i.e. less than 0.2%, which seems small enough to me; but there
> still is some demand for larger records, so it makes sense not to
> prevent them from ever happening with tighter wording.

Note that the main reason cited for having larger records is not the
size overhead (as you say, that's negligible), but the processing
overheads associated with processing each record.  Willy Tarreau gave
a great presentation at a workshop a while ago showing how moving
between different layers of his stack had a material effect on
performance.  Larger records means doing any per-record processing
less often.

> Another point which was made is that CBC cipher suites have a
> variable-length padding, up to 256 bytes (length byte + padding), which
> is not fully negligible: an endpoint with a 500-byte buffer would have
> to send a "maximum record size" of 223 bytes only, in order to fully
> support AES/CBC+HMAC/SHA-256 in all cases, while in practice most if not
> all endpoints will stick to minimal-sized paddings. Maybe there should
> be some extra wording saying that when a "maximum record size" was
> received, with a value less than the protocol-defined limit, then an
> endpoint SHOULD strive to use minimal-sized padding in cipher suites
> that have a variable-sized padding.

Yeah, the hazard there is that they don't minimally pad and then you
have no real recourse if you haven't reserved space for the extra
padding.  If you are going to do that, you need to make it a MUST I
think.

I didn't want to do this, because it's basically a prohibition on any
sort of padding-for-traffic-analysis-resistance (lame though it might
be).

So we have a trade-off.  I think that your suggestion is probably OK,
though that means making the limitation obvious.

> This would be only for the benefit of CBC cipher suites with TLS 1.2 and
> earlier, not for TLS 1.3, because recent AEAD cipher suites have
> predictable (and small) overhead.

Well, in TLS 1.3 any padding is counted, so requiring minimal padding
at the cipher level would be possible even if the cipher required some
padding.

> Arguably, pre-TLS-1.3 versions also have problem with compression, which
> should be in all generality avoided, just like CBC cipher suites should
> also be avoided. Maybe this is not a problem after all, and constrained
> systems that are recent enough to implement this new extension will also
> "naturally" avoid CBC cipher suites anyway. (In any case, if an endpoint
> requires small records, then it cannot really talk with peers that don't
> support the proposed maximum_record_size extension, so it needs recent
> implementations that _should_ already implement at least TLS 1.2 and
> some AEAD cipher suites.)

Yes, I think that I ultimately decided that I didn't care enough to
solve this problem for block ciphers and I would let someone who cared
about them propose the solution that best suits them.