Wireshark-dev: Re: [Wireshark-dev] [pcap-ng-format] Proposal for storing decryption secrets in
On Thu, Oct 04, 2018 at 03:12:19PM -0700, Ben Higgins wrote:
> On Sun, Sep 30, 2018 at 10:47 AM Peter Wu <peter@xxxxxxxxxxxxx> wrote:
>
> > Hi all,
> >
> > Earlier this year, Ben Higgins proposed a new pcapng block to store
> > SSL/TLS session secrets that would allow users to enable decryption of
> > packet traces without further configuration. I would like to solicit for
> > some feedback on this proposed specification update:
> > https://github.com/pcapng/pcapng/pull/54
> >
> > Among the open spec issues:
> > - Are you happy with the chosen identifiers (10 for block type and
> > 0x544c534b ("TLSK") for the TLS key log secret type).
> > - Rename the block from the original proposal (it seems based on "IDB",
> > but "Decryption Secrets Block (DSB)" sounds better to me).
> >
>
> Both these sound good to me.
>
> - Is there a use case for multiple secret blocks?
> >
>
> Certainly if you have different secret block types (so you might need one
> of each).
Anders suggested having a TLV (which is present in the current
proposal). If that was hypothetically extended with support for multiple
TLVs, then multiple secrets could be stored in a single DSB. Though that
brings more complexity for the consumer and might not be worth it.
> Even for the same type it'd make it easier on producers that
> might not know the length of all secrets up front (i.e. it's filling up a
> buffer as it goes and spitting out a secret block once the buffer's full).
This is indeed a valid concern, and is a reason why the current spec
text allows multiple blocks.
> - For multiple secret blocks, is concatenation a good merge strategy?
> >
>
> Concatenation should work fine among TLSK blocks assuming all blocks have a
> final newline (or one is inserted if missing during concat; perhaps that
> needs to be specified).
The newline requirement is specified in the current proposal
https://github.com/pcapng/pcapng/pull/54/files#diff-83e833afc268a7be6b36d2b897656e28R1912
There is no explicit text on concatenation though.
--
Kind regards,
Peter Wu
https://lekensteyn.nl
