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

[Peter Wu]

On Fri, Oct 05, 2018 at 10:38:34AM +0000, Anders Broman wrote:
> "... since pcap-ng offers the wonderful option of reading blocks backwards we could put them all at the end."
> Perhaps not such a good idea in this case as stated above, but interesting. I noted that a capture I have, has the address resolution block at the end which makes it unusable as the resolved
> Addresses are written on the first pass(?), perhaps we should peek at the end of the file to see if there's something there...

If the file is not truncated, that might work. The pcapng spec however
does not put any requirement on the position of NRBs though, so it might
not be at the end of a file.

For Wireshark (which support async name resolution) perhaps it is not a
problem either (except when actually filtering based on resolved names).

> In addition to be able to write the decryption block at any place in the file I think it should contain a TLV type structure
> 
> Tag = Type of "secret" 32 bits. A number allocated by the pcap-ng format responsible on a first come first served basis
> Value = "The secret formatted as specified by tag"
> Length = The length of the secret data
> Pad to 32 bit boundary.
> 
> In this way we can calculate if options are present or not.

Very good point, this additional length field is now incorporated in the
proposal. There is no extra text about padding, I hope it should be
clear from "3.1. General Block Structure" which says that the Block Body
is variable length, padded to 32 bits.

Anders (in private) also discussed the idea of potentially allowing
multiple TLVs, but the idea is not applied because:
- Multiple TLVs requires slightly more work from the consumer.
- The expected number of different secret types are small. The overhead
  of the block (12 bytes) should be negligible compared to the secrets.
- If a protocol has multiple session secrets, it is currently expected
  that the secrets format itself provides a means to identify the type
  of such a secret. This is for example done in the TLS 1.3 key log
  format which typically has at least four different secrets per
  identifier.
-- 
Kind regards,
Peter Wu
https://lekensteyn.nl