On Tue, Jun 12, 2018 at 2:44 PM Christopher Wood < christopherwoo...@gmail.com> wrote:
> On Tue, Jun 12, 2018 at 11:32 AM David Benjamin <david...@chromium.org> > wrote: > > > > On Tue, Jun 12, 2018 at 2:01 PM Christopher Wood < > christopherwoo...@gmail.com> wrote: > >> > >> On Tue, Jun 12, 2018 at 10:55 AM Kyle Nekritz <knekr...@fb.com> 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.
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
