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
_______________________________________________
TLS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tls
