Re: [TLS] CH padding extension

[David Benjamin <[e-mail]>]

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

> On Tue, Jun 12, 2018 at 11:32 AM David Benjamin <[e-mail]>
> wrote:
> >
> > On Tue, Jun 12, 2018 at 2:01 PM Christopher Wood <
> [e-mail]> wrote:
> >>
> >> On Tue, Jun 12, 2018 at 10:55 AM Kyle Nekritz <[e-mail]> 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.
> >>
> >> 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.
> >
> >
> > 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.)
>

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.