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

From: Adam Langley <[email-masked]>
Date: Tue, 1 Sep 2015 10:11:11 -0700

On Mon, Aug 31, 2015 at 9:16 AM, Vincent Roca <[email-masked]> 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

---

From: Vincent Roca <[email-masked]>
Date: Thu, 3 Sep 2015 11:42:42 +0200

Hello Adam,

> amplification factor of DTLS.

There is a misunderstanding here. Let me reformulate.
What happens if the sender specifies an extension_data length value
that differs (i.e., the value is either smaller or larger) from the actual
padding extension in the packet sent? Well, it depends how it’s
implemented at a receiver… My point was to suggest the receiver to
check this extension_data length value carefully before processing it.
Perhaps this comment is too paranoid? Perhaps the way it works avoids
problems? In that case just ignore it.

> anything new about extensions in general, I feel that it shouldn't

I understand, no problem.

Cheers,

  Vincent