Subject: [quicwg/base-drafts] Move padding to the crypto layer (#197)

From: ekr <[email-masked]>
Date: Sun, 22 Jan 2017 20:54:19 -0800

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.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/197

---

From: David Benjamin <[email-masked]>
Date: Sun, 22 Jan 2017 21:01:07 -0800

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.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/197#issuecomment-274401038

---

From: ekr <[email-masked]>
Date: Sun, 22 Jan 2017 21:20:41 -0800

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.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/197#issuecomment-274402795

---

From: David Benjamin <[email-masked]>
Date: Sun, 22 Jan 2017 21:28:43 -0800

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.)

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/197#issuecomment-274403540

---

From: Marten Seemann <[email-masked]>
Date: Sun, 22 Jan 2017 21:32:55 -0800

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).

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/197#issuecomment-274403956

---

From: Martin Thomson <[email-masked]>
Date: Mon, 23 Jan 2017 17:36:28 -0800

@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.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/197#issuecomment-274674976

---

From: ekr <[email-masked]>
Date: Mon, 23 Jan 2017 17:38:49 -0800

On Tue, Jan 24, 2017 at 10:36 AM, Martin Thomson <[email-masked]>
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 <https://github.com/quicwg/base-drafts/issues/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
> <https://github.com/quicwg/base-drafts/issues/197#issuecomment-274674976>,
> or mute the thread
> <https://github.com/notifications/unsubscribe-auth/ABD1oSqOWgZbaTu3jrGw6XFJCOgL8WBYks5rVVWcgaJpZM4LqqX1>
> .
>

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/197#issuecomment-274675355