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

[Ben Higgins]

On Sun, Sep 30, 2018 at 10:47 AM Peter Wu <peter at 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). 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).

- 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).

- Is this format future-proof and usable for other formats like ZigBee?
>

Not sure if the merge strategy could be uniform among other secret formats,
but otherwise this spec seems future-proof since a new secret type can
entail a new secret format.


> Advantages of allowing multiple blocks:
> - Producers can write secrets directly while writing packets.
> - Merging multiple capture files is simpler.
>
> Requirements for block placement:
> - No requirement. Producers are allowed to write the block anywhere.
>   Disadvantages for consumers: requires a two-pass scan to collect
>   secrets before they are used.
> - Place secrets before the packet blocks that require them. Consumers
>   can read and decrypt in one pass. Disadvantage: producers cannot
>   always guarantee availability of secrets while writing the capture.
>
- Place a single secret block before the first packet block. Consumers
>   can read and decrypt in one pass. Disadvantage: requires producers to
>   post-process (rewrite) the capture file to insert secrets.
>

I'm fine with the second option given that, as you note, "No requirement"
is more challenging on consumers.

As these blocks contain sensitive (session) secrets, they should be
> carefully handled, but that's probably a different discussion. The
> current Wireshark patches that implement *read-only* support is at
> https://code.wireshark.org/review/29901
>
> Your feedback is welcome.
> --
> Kind regards,
> Peter Wu
> https://lekensteyn.nl
> _______________________________________________
> pcap-ng-format mailing list
> pcap-ng-format at winpcap.org
> https://www.winpcap.org/mailman/listinfo/pcap-ng-format
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.winpcap.org/pipermail/pcap-ng-format/attachments/20181004/30bf3c60/attachment.html>