<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Sun, Sep 30, 2018 at 10:47 AM Peter Wu <<a href="mailto:peter@lekensteyn.nl">peter@lekensteyn.nl</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi all,<br>
<br>
Earlier this year, Ben Higgins proposed a new pcapng block to store<br>
SSL/TLS session secrets that would allow users to enable decryption of<br>
packet traces without further configuration. I would like to solicit for<br>
some feedback on this proposed specification update:<br>
<a href="https://github.com/pcapng/pcapng/pull/54" rel="noreferrer" target="_blank">https://github.com/pcapng/pcapng/pull/54</a><br>
<br>
Among the open spec issues:<br>
- Are you happy with the chosen identifiers (10 for block type and<br>
  0x544c534b ("TLSK") for the TLS key log secret type).<br>
- Rename the block from the original proposal (it seems based on "IDB",<br>
  but "Decryption Secrets Block (DSB)" sounds better to me).<br></blockquote><div><br></div><div>Both these sound good to me.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
- Is there a use case for multiple secret blocks?<br></blockquote><div><br></div><div>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).</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
- For multiple secret blocks, is concatenation a good merge strategy?<br></blockquote><div><br></div><div>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).</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">- Is this format future-proof and usable for other formats like ZigBee?<br></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Advantages of allowing multiple blocks:<br>
- Producers can write secrets directly while writing packets.<br>
- Merging multiple capture files is simpler.<br>
<br>
Requirements for block placement:<br>
- No requirement. Producers are allowed to write the block anywhere.<br>
  Disadvantages for consumers: requires a two-pass scan to collect<br>
  secrets before they are used.<br>
- Place secrets before the packet blocks that require them. Consumers<br>
  can read and decrypt in one pass. Disadvantage: producers cannot<br>
  always guarantee availability of secrets while writing the capture.<br></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">- Place a single secret block before the first packet block. Consumers<br>
  can read and decrypt in one pass. Disadvantage: requires producers to<br>
  post-process (rewrite) the capture file to insert secrets.<br></blockquote><div><br></div><div>I'm fine with the second option given that, as you note, "No requirement" is more challenging on consumers.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
As these blocks contain sensitive (session) secrets, they should be<br>
carefully handled, but that's probably a different discussion. The<br>
current Wireshark patches that implement *read-only* support is at<br>
<a href="https://code.wireshark.org/review/29901" rel="noreferrer" target="_blank">https://code.wireshark.org/review/29901</a><br>
<br>
Your feedback is welcome.<br>
-- <br>
Kind regards,<br>
Peter Wu<br>
<a href="https://lekensteyn.nl" rel="noreferrer" target="_blank">https://lekensteyn.nl</a><br>
_______________________________________________<br>
pcap-ng-format mailing list<br>
<a href="mailto:pcap-ng-format@winpcap.org" target="_blank">pcap-ng-format@winpcap.org</a><br>
<a href="https://www.winpcap.org/mailman/listinfo/pcap-ng-format" rel="noreferrer" target="_blank">https://www.winpcap.org/mailman/listinfo/pcap-ng-format</a></blockquote></div></div>