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

[Martin Thomson <[e-mail]>]

Hi Thomas,

Sorry for taking so long to get back to this.

https://github.com/martinthomson/tls-record-limit/pull/1 covers the
major changes.  I decided to add a section covering the expansion
issue so that I could do it justice.  I was going to write more, then
I realized that the dumb approach is probably safest: pad to get to
record_size_limit or less, then pad to reach the block size.
Attempting to explain what to do in more detail was only making it
less clear.

I've added a commit that should fix my error.  It makes it clear that
the problem for constrained servers even more acute:
https://github.com/martinthomson/tls-record-limit/commit/5051d510471014f172b

On 29 March 2017 at 01:00, Thomas Pornin <[e-mail]> wrote:
> On Tue, Mar 28, 2017 at 06:35:24AM -0500, Martin Thomson wrote:
>> 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.
>
> 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