Wireshark-dev: [Wireshark-dev] Proposal for storing decryption secrets in a pcapng block
From: Peter Wu <[email protected]>
Date: Sun, 30 Sep 2018 19:47:07 +0200
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).
- Is there a use case for multiple secret blocks?
- For multiple secret blocks, is concatenation a good merge strategy?
- Is this format future-proof and usable for other formats like ZigBee?

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.

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