Subject: [TLS] draft-thomson-tls-record-limit-00

From: Martin Thomson <[email-masked]>
Date: Tue, 28 Mar 2017 06:35:24 -0500

I just submitted a version of the draft we've discussed a little on the list.

I don't think we concluded the discussion about what to do about block
cipher padding.

...
A new version of I-D, draft-thomson-tls-record-limit-00.txt
has been successfully submitted by Martin Thomson and posted to the
IETF repository.

Name:           draft-thomson-tls-record-limit
Revision:       00
Title:          Record Size Limit Extension for Transport Layer Security (TLS)
Document date:  2017-03-27
Group:          Individual Submission
Pages:          6
URL:
https://www.ietf.org/internet-drafts/draft-thomson-tls-record-limit-00.txt
Status:         https://datatracker.ietf.org/doc/draft-thomson-tls-record-limit/
Htmlized:       https://tools.ietf.org/html/draft-thomson-tls-record-limit-00
Htmlized:
https://datatracker.ietf.org/doc/html/draft-thomson-tls-record-limit-00

Abstract:
   An extension to Transport Layer Security (TLS) is defined that allows
   endpoints to negotiate the maximum size of protected records that
   each will send the other.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Thomas Pornin <[email-masked]>
Date: Tue, 28 Mar 2017 16:00:56 +0200

> I don't think we concluded the discussion about what to do about block

I don't have strong preferences on this, but I would incline toward
using the plaintext length in the extension. In any case, adding a
longer-than-necessary padding in order to defeat traffic analysis does
not make sense if it expands the size beyond the minimal record size for
a full record (i.e. if an endpoint wants to add extra padding bytes to a
record with 16384 bytes of padding, it is only _revealing_ extra
information, not hiding it).

I suggest altering this paragraph:

   The size limit expressed in the "record_size_limit" extension doesn't
   account for expansion due to compression or record protection.  It is
   expected that a constrained device will disable compression and know
   - and account for - the maximum expansion possible due to record
   protection based on the cipher suites it offers or selects.  Note
   that up to 256 octets of padding and padding length can be added to
   block ciphers.

into this:

   The size limit expressed in the "record_size_limit" extension doesn't
   account for expansion due to compression or record protection.  If
   and endpoint advertises a size limit which is lower than the
   protocol-defined limit, then the peer SHALL NOT send a record whose
   final, protected size exceeds that of the minimal protected size of a
   record that contains exactly "record_size_limit" plaintext bytes and
   uses no compression.
   
   For instance, if using TLS 1.2 and a cipher suite that mandates
   AES/CBC encryption and HMAC/SHA-256 for protection, and an endpoint
   advertises a "record_size_limit" of 700 bytes, then the minimal
   protected record size for 700 bytes of plaintext contents is 757
   bytes:

     - 700 bytes of plaintext
     - 32 bytes for the HMAC/SHA-256
     - 4 bytes of padding to reach the next multiple of the AES block
       size (which is 16 bytes)
     - 16 bytes for the explicit IV
     - 5 bytes for the record header

   The padding may have length 1 to 256 bytes as per protocol rules;
   but in the presence of a "record_size_limit" of 700 bytes expressed
   by the peer, an endpoint SHALL refrain from sending records whose
   total protected size exceeds 757 bytes.

   It is expected that a constrained device will disable compression;
   moreover, the practice of adding a longer-than-minimal padding is
   done in order to defeat traffic analysis, and sending records longer
   than the minimal size for full records is counterproductive (such a
   record would reveal extra information to onlookers, and thus should
   be avoided).

------------------

Another unrelated comment: in section 3, there is the following:

   The "max_fragment_length" extension is also ill-suited to cases where
   the capabilities of client and server are asymmetric.  The server is
   required to select a fragment length that is as small or smaller than
   the client offers and both endpoints need to comply with this smaller
   limit.

Actually, it is worse than that: per the wording of RFC 6066, if a
client advertises a length of L bytes, the server must respond with
_exactly_ the same length L; the server is not allowed to select a
smaller length. The relevant RFC text is:

   The "extension_data" field of this extension SHALL contain a
   "MaxFragmentLength" whose value is the same as the requested maximum
   fragment length.

and it is reinforced some lines later:

   Similarly, if a client receives a maximum fragment length negotiation
   response that differs from the length it requested, it MUST also
   abort the handshake with an "illegal_parameter" alert.

The "max_fragment_length" extension is completely client-driven: it is
used only on the client's initiative, and uses the client's length. The
server's only choice is to accept the will of the client, or reject the
connection. Thus, it handles only the case of constrained clients
talking to big servers, not the other way round.

	--Thomas Pornin