Subject: [TLS] CH padding extension

From: Christopher Wood <[email-masked]>
Date: Tue, 12 Jun 2018 10:41:15 -0700

Hi folks,

In Section 4.2 of the latest TLS 1.3 draft [1], the padding(21)
extension is restricted to the CH and no other handshake messages.
Another plausible spot for this extension is in the Certificate
message. Specifically, although we're encrypting this message, we may
not want to reveal its length. Adding a padding extension seems to
address that problem. Granted, RFC7685 [2] clearly indicates that this
padding is for the CH, and that server "MUST NOT echo the extension."
However, I don't think that rules out server-chosen padding for the
Certificate.

What do others think? Is this worth a change?

Best,
Chris

[1] https://tools.ietf.org/html/draft-ietf-tls-tls13-28#section-4.2
[2] https://tools.ietf.org/html/rfc7685

---

From: Kyle Nekritz <[email-masked]>
Date: Tue, 12 Jun 2018 17:55:26 +0000

Since the Certificate message is sent in an encrypted record, the normal record padding mechanism (section 5.4) can be used, rather than sending the padding as actual handshake data.

-----Original Message-----
From: TLS <[email-masked]> On Behalf Of Christopher Wood
Sent: Tuesday, June 12, 2018 1:41 PM
To: <[email-masked]> <[email-masked]>
Subject: [TLS] CH padding extension

Hi folks,

In Section 4.2 of the latest TLS 1.3 draft [1], the padding(21) extension is restricted to the CH and no other handshake messages.
Another plausible spot for this extension is in the Certificate message. Specifically, although we're encrypting this message, we may not want to reveal its length. Adding a padding extension seems to address that problem. Granted, RFC7685 [2] clearly indicates that this padding is for the CH, and that server "MUST NOT echo the extension."
However, I don't think that rules out server-chosen padding for the Certificate.

Best,
Chris

[1] https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dtls-2Dtls13-2D28-23section-2D4.2&d=DwICAg&c=5VD0RTtNlTh3ycd41b3MUw&r=l2j4BjkO0Lc3u4CH2z7jPw&m=NoLDoqqN97BKYlmPkPtLv4JlT3y32nA2pmpAcfRDGDc&s=ULkmSYAHjmTYA-5NcfzbLoiexbGrO9m-LTuTZoMz_T8&e=
[2] https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc7685&d=DwICAg&c=5VD0RTtNlTh3ycd41b3MUw&r=l2j4BjkO0Lc3u4CH2z7jPw&m=NoLDoqqN97BKYlmPkPtLv4JlT3y32nA2pmpAcfRDGDc&s=DCiLNYn2n-dm1n-a96cwNup4Yrm8jxj66ynWdfUIzOY&e=

_______________________________________________
TLS mailing list
[email-masked]
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_tls&d=DwICAg&c=5VD0RTtNlTh3ycd41b3MUw&r=l2j4BjkO0Lc3u4CH2z7jPw&m=NoLDoqqN97BKYlmPkPtLv4JlT3y32nA2pmpAcfRDGDc&s=gqkkU78PTKoxJ2uHr1YonppiXHwkRP3SRTPlEnP4iE8&e=

---

From: Christopher Wood <[email-masked]>
Date: Tue, 12 Jun 2018 11:00:40 -0700

> Since the Certificate message is sent in an encrypted record, the normal record padding mechanism (section 5.4) can be used, rather than sending the padding as actual handshake data.

Of course, and that requires padding on the fly and some way for the
sender to know what is the correct amount of padding per Certificate.
Plumbing up that API seems non-trivial. In comparison, one could
imagine pre-padding wire-encoded Certificate messages a priori using
the extension. So I still think restricting padding to CH is a bit
extreme.

Best,
Chris

---

From: David Benjamin <[email-masked]>
Date: Tue, 12 Jun 2018 14:32:16 -0400

On Tue, Jun 12, 2018 at 2:01 PM Christopher Wood <
[email-masked]> wrote:

> > Since the Certificate message is sent in an encrypted record, the normal
> record padding mechanism (section 5.4) can be used, rather than sending the
> padding as actual handshake data.
>

Using the padding extension isn't going to mesh well with the compressed
certificates draft. (Compression is perfectly compatible with hiding the
length. If all your certificates compress well---they probably do---you can
pad based on the distribution of compressed lengths you're trying to mask.
Of course, this will leak whether compression happened, but that's not the
information that's interesting to hide.)

Record-level padding is indeed kind of annoying to plumb properly though.
I've always thought the excitement for padding at that layer was somewhat
misplaced. I could imagine allowing handshake messages to be punctuated by
no-op padding messages, but then it's just one layer to route through to
get to the record layer here. I think it's more at higher up the stack
where record-level padding really becomes impractical.

David

---

From: Christopher Wood <[email-masked]>
Date: Tue, 12 Jun 2018 11:44:41 -0700

On Tue, Jun 12, 2018 at 11:32 AM David Benjamin <[email-masked]> wrote:
>
> On Tue, Jun 12, 2018 at 2:01 PM Christopher Wood <[email-masked]> wrote:
>>
> Using the padding extension isn't going to mesh well with the compressed certificates draft. (Compression is perfectly compatible with hiding the length. If all your certificates compress well---they probably do---you can pad based on the distribution of compressed lengths you're trying to mask. Of course, this will leak whether compression happened, but that's not the information that's interesting to hide.)

Yep, valid point.

>
> Record-level padding is indeed kind of annoying to plumb properly though. I've always thought the excitement for padding at that layer was somewhat misplaced. I could imagine allowing handshake messages to be punctuated by no-op padding messages, but then it's just one layer to route through to get to the record layer here. I think it's more at higher up the stack where record-level padding really becomes impractical.

To be clear, are you suggesting that adding a padding extension to the
Certificate message is impractical? (I wouldn't consider this
record-level padding.)

Best,
Chris

---

From: David Benjamin <[email-masked]>
Date: Tue, 12 Jun 2018 14:48:35 -0400

On Tue, Jun 12, 2018 at 2:44 PM Christopher Wood <
[email-masked]> wrote:

> >> > Since the Certificate message is sent in an encrypted record, the
> normal record padding mechanism (section 5.4) can be used, rather than
> sending the padding as actual handshake data.
> >>
> > Record-level padding is indeed kind of annoying to plumb properly
> though. I've always thought the excitement for padding at that layer was
> somewhat misplaced. I could imagine allowing handshake messages to be
> punctuated by no-op padding messages, but then it's just one layer to route
> through to get to the record layer here. I think it's more at higher up the
> stack where record-level padding really becomes impractical.
>

Sorry, that was probably unclear. What I meant was: I agree that
record-level padding is pretty difficult to use in general, but this
particular instance is probably(?) not too bad, so it seems sufficient to
use the existing mechanism rather than make a wire-incompatible change
(unsolicited Certificate extensions are forbidden) at this stage.

Though I otherwise don't particularly object to jamming the padding
extension into more places, the compressed certificates point aside.

---

From: Christopher Wood <[email-masked]>
Date: Tue, 12 Jun 2018 12:07:31 -0700

Got it — thanks for the clarification! I agree with your conclusion assuming we do not want to make an incompatible wire format change. However, if we’re willing to budge on that, I think it’s worth including. I’m curious to hear what others think.

Best,
Chris
On Jun 12, 2018, 11:48 AM -0700, David Benjamin <[email-masked]>, wrote:
> > On Tue, Jun 12, 2018 at 2:44 PM Christopher Wood <[email-masked]> wrote:
> > Sorry, that was probably unclear. What I meant was: I agree that record-level padding is pretty difficult to use in general, but this particular instance is probably(?) not too bad, so it seems sufficient to use the existing mechanism rather than make a wire-incompatible change (unsolicited Certificate extensions are forbidden) at this stage.
> >
> > Though I otherwise don't particularly object to jamming the padding extension into more places, the compressed certificates point aside.

---

From: Roelof duToit <[email-masked]>
Date: Tue, 12 Jun 2018 15:21:37 -0400

You could use the existing Certificate padding mechanism.  Which mechanism?!   The one in this paragraph:

For maximum compatibility, all implementations SHOULD be prepared to handle
potentially extraneous certificates and arbitrary orderings from any
TLS version, with the exception of the end-entity certificate which
MUST be first.

I ran an experiment a while ago in which all major browsers (at that point) accepted an arbitrary X.509 certificate in the Certificate message.   In other words, you could just build a blob that looks like a DER encoded X.509 certificate and include it in the chain.

It is indeed a hack, but in all seriousness, would the client endpoint stacks even bother to change that behavior? (disclaimer: I have not checked the latest behavior).

--Roelof

> On Jun 12, 2018, at 3:07 PM, Christopher Wood <[email-masked]> wrote:
> 
>> On Tue, Jun 12, 2018 at 2:44 PM Christopher Wood <[email-masked] <mailto:[email-masked]>> wrote:
>> On Tue, Jun 12, 2018 at 11:32 AM David Benjamin <[email-masked] <mailto:[email-masked]>> wrote:
>> >
>> > On Tue, Jun 12, 2018 at 2:01 PM Christopher Wood <[email-masked] <mailto:[email-masked]>> wrote:
>> >>
>> >> On Tue, Jun 12, 2018 at 10:55 AM Kyle Nekritz <[email-masked] <mailto:[email-masked]>> wrote:
>> >> >
> https://www.ietf.org/mailman/listinfo/tls