Move padding to the crypto layer

[ekr]

I think it would be good to make padding the responsibility of the crypto layer. TLS already has a reasonable padding scheme which we can just steal here.

[davidben]

This would probably require a tweak to TLS 1.3. Right now the specification implies that a second ClientHello after HelloRetryRequest can have no modifications besides what extensions imply. TLS 1.3 would need to allow the padding extension change between first and second ClientHello.

[ekr]

Sorry, I'm not following your comment here, so maybe you need to expand a bit. Is your point that you intend to use the S 7.7 padding to force the CH-containing frame to be ~1MTU and that you need to adjust it during CH/HRR?

In any case, in the same way as TLS makes a distinction between padding for the first handshake message (CH) and generic record padding, it seems like it might be good for QUIC to do the same, and pad all encrypted data in the encryption layer.

[davidben]

Oh, sorry, I completely misunderstood your ticket! Please ignore me. (I thought you were referring to using RFC 7685 to pad the initial packet which wouldn't work without changes.)

[marten-seemann]

I think PADDINGs are supposed to be a countermeasure to traffic pattern analysis. For example, a peer could pretend to be doing an upload when in reality all it doing is sending ACKs for a download and a lot of PADDINGs.

I'm not sure if this is possible with TLS 1.3, but since the spec doesn't require TLS, but just any appropriate crypto protocol, this shouldn't be an argument to remove the PADDING frame (unless you make the ability to send arbitrary padding a requirement for any crypto protocol that can be used for QUIC).

[martinthomson]

@ekr, is your intent to just use this for the initial handshake packets? As in #164. Padding is available at both layers (PADDING, the padding TLS extension, and TLS record layer padding for the server flight only).

I didn't port the record padding from TLS into our packet protection because PADDING existed. If that is what you are talking about, we should discuss.

[ekr]

On Tue, Jan 24, 2017 at 10:36 AM, Martin Thomson ***@***.***> wrote: @ekr <https://github.com/ekr>, is your intent to just use this for the initial handshake packets?

My proposal is to just use PADDING for CH and then use packet-protection for anything beyond that.

As in #164 <#164>. Padding is available at both layers (PADDING, the padding TLS extension, and TLS record layer padding for the server flight only). I didn't port the record padding from TLS into our packet protection because PADDING existed. If that is what you are talking about, we should discuss.

Yes, we should discuss.

…

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#197 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABD1oSqOWgZbaTu3jrGw6XFJCOgL8WBYks5rVVWcgaJpZM4LqqX1> .

[ianswett]

Since padding is used to ensure the MTU is large enough in both directions in QUIC, is it going to be hard to ensure the crypto layer adds the right amount of padding to generate a packet with the desired size?

And it seems like this suggestion only applies to the Crypto Handshake. If so, can we change the title of this issue to "Move crypto handshake padding to the crypto layer"?

[ianswett]

At some point, we changed padding to be a single byte to allow for padding to be placed between frames at the request of @larseggert This seems like a useful feature and we'd remove that if we got rid of padding entirely, so I don't think QUIC padding is going away.

Given that, this issue becomes 'sometimes move padding to the crypto layer', which is going to make congestion control and bytes in flight counting potentially more complex, since sometimes we'll do padding in one place and sometimes the other.

This is orthogonal to #837, since we need to decide how we want QUIC to work with padding. Where to put the padding doesn't change that. If we want padding that counts towards bytes in flight and one that doesn't, we can use PADDING and PING for the two different cases(or other approaches).

Given the above, @ekr is there a reason to keep this open?

[ekr]

I can live with closing this.

…

On Sat, Nov 11, 2017 at 2:00 PM, ianswett ***@***.***> wrote: At some point, we changed padding to be a single byte to allow for padding to be placed between frames at the request of @larseggert <https://github.com/larseggert> This seems like a useful feature and we'd remove that if we got rid of padding entirely, so I don't think QUIC padding is going away. Given that, this issue becomes 'sometimes move padding to the crypto layer', which is going to make congestion control and bytes in flight counting potentially more complex, since sometimes we'll do padding in one place and sometimes the other. This is orthogonal to #837 <#837>, since we need to decide how we want QUIC to work with padding. Where to put the padding doesn't change that. If we want padding that counts towards bytes in flight and one that doesn't, we can use PADDING and PING for the two different cases(or other approaches). Given the above, @ekr <https://github.com/ekr> is there a reason to keep this open? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#197 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABD1oVbmpisB83_gkhrqJl6aWKnM0OBeks5s1hjzgaJpZM4LqqX1> .