Re: [secdir] Secdir review of draft-ietf-tls-padding-02

[Adam Langley <[e-mail]>]

On Mon, Aug 31, 2015 at 9:16 AM, Vincent Roca <[e-mail]> wrote:
> That’s perhaps a naive question, but let me ask it. Shouldn’t a receiver
> check
> that the actual length of the extension_data field is in line with the value
> of the
> extension_data length field. Since those zero bytes are actually carried
> over
> the net and present in the reception buffer, there could be several ways to
> calculate this length… (I really don’t know if it’s the case or not)

I don't think that we want to pin down the exact length of the padding
and would rather leave it up to the sender. Although, for now, we have
only a single use case for this, some other uses have been
suggested(*) and it would be nice just to have a single padding
extension if we decide that we need them in the future.

(*) for example, padding a DTLS ClientHello to reduce the
amplification factor of DTLS.

> Additionally, section 3 says:
>
>    The client MUST fill the padding extension completely with zero
>    bytes, although the padding extension may be empty.
>
> I think that you mean « padding extension_data field » and not « padding
> extension »:

Done, thanks.

> And finally, in the example (figure), instead of:
>
> 16-bit, extension_data length
>
> I’d rather add a « _ » as in:
>
> 16-bit, extension_data_length

Although I don't have strong feelings either way, I didn't make this
change. In the TLS 1.2 RFC
(https://tools.ietf.org/html/rfc5246#section-7.4.1.4), extension_data
is a named field, but extension_data_length is not. Rather it's an
implicit part of extension_data. Since this draft isn't defining
anything new about extensions in general, I feel that it shouldn't
name new things here.


Cheers

AGL