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 <por...@bolet.org> 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 _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
