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

[Peter Wu]

On Sun, Sep 30, 2018 at 07:43:04PM -0400, Michael Richardson wrote:
> Peter Wu <peter at lekensteyn.nl> wrote:
>     > 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.
> 
> I prefer this, but I would support having a flag in the block that
> says that no other blocks exist in the file until at least X-bytes.
> 
> So, a producer (or something downstream of it), could scan for the
> blocks, move them to the front, and indicate how far into the file it cover.
> Naturally, if X >= file size, then the work is done.

This could potentially break if a tool supports filtering and merging
capture files, but without special handling of secret blocks. Block
count or elapsed time might also be a better metric than byte size.

In order to optimize scanning through a file, I think that a separate
mechanism would be better suited. Some kind of index block, or the
experimental "Fixed Length Block".

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


At https://code.wireshark.org/review/29901, James Ko asked:

> If multiple SDBs are supported would any known key be able to decrypt
> any future EPB?  The scenario is for key rotations where a new key may
> be distributed before (but not necessarily immediately before) any
> encrypted packet using that key.  Packets may arrive using a previous
> key before actively switching to the new key.

Handling of multiple blocks is not precisely specified, but one possible
strategy (implemented in the above patch) is just to concatenate all
identifiers + secrets as they are encountered. Any subsequent EPB can
then indeed use any of the previously known secrets.

The intended use case was to replace an out-of-band supplier of secrets.
If instead you want to attach secrets to an individual EPB (and all
subsequent packets), then an option might be a better idea.

The secrets format is expected to include sufficient information to map
to a secret. In the TLS case, the 256-bit ClientHello.Random field acts
as such identifier and maps to session secrets. In the WireGuard
protocol, the secrets block could contain Curve25519 private keys from
which public keys can be computed (these public keys act as identifier).

> In a Time Slotted radio the Absolute Slot Number (ASN) may be used as
> part of the nonce in the encryption/decryption.  Does the SDB allow
> for this?

Does the ASN act as identifier that can be found in a packet as well? If
so, then the secrets format could define it as such.
-- 
Kind regards,
Peter Wu
https://lekensteyn.nl