Re: [pcap-ng-format] Proposal for storing decryption secrets in a pcapng block

[Peter Wu <peter () lekensteyn nl>]

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 () lekensteyn nl> 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
___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
Archives:    https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request () wireshark org?subject=unsubscribe