<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-size:small">On Tue, May 5, 2020 at 11:39 PM Bill Frantz <<a href="mailto:frantz@pwpconsult.com">frantz@pwpconsult.com</a>> wrote:<br></div></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 5/4/20 at 10:11 PM, <a href="mailto:phill@hallambaker.com" target="_blank">phill@hallambaker.com</a> (Phillip <br>
Hallam-Baker) wrote:<br>
<br>
>So the approach I think we are going to want is not full hard boiled end to<br>
>end encryption but a sequence of encrypted frames so that the reflector has<br>
>sufficient metadata to intelligently manage the video but no access to the<br>
>content.<br>
<br>
This approach sounds to me like a DTLS application. There might <br>
be an issue if the reflector can't tell when one datagram stops <br>
and the next one starts.<br></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">I have nested crypto in my schemes currently but I am not doing real time video (yet).</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">In my view you need to have a transport layer enhancement to protect against traffic analysis AND a message layer enhancement for data at rest security.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Data At Rest is going beyond 'end-to-end' to address the real problem which was that the DNC emails were stored in the clear on the server. OK so 'end-to-end' covers the mail server. But what about the file server where the employees have their mail spools?</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Yes, S/MIME and PGP absolutely give the right protection (when used right). But the bigger point is that this is about more than data in motion. it has to be data at rest as well.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">One of the things I am doing in the Mesh is to separate bulk data from control. Control messages are limited to 32KB. That is large enough to allow for all of the 'setup' messages I have devised so far but not so large as to cause performance issues when synchronizing a mail spool or the like. It is also short enough that padding out the packets to a fixed size becomes practical. (and yes, 8096 might make more sense so messages fit in a jumbo packet)</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">The control messages are between the client and service by definition so they are going to be transport layer encrypted. If there is an enclosed data message then that portion will be encrypted twice.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">So if I was moving bulk data between clients via a reflector on UDP, my approach would be to reserve the first block (i.e. 128 bits) and put the frame information (sequence number, stream, number of bytes) in that. Then I would encrypt that ECB under a key shared between the client and service because why give Mallet anything to work with? ECB is going to be fine for that purpose as the sequence numbers are going to be unique (or we can ensure that this is so).</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small"><br></div></div><div class="gmail_default" style="font-size:small">DTLS doesn't really do it for me... I would much prefer I could separate out the TLS key agreement and roll my own framing. Use OCB3 instead of GCM, that sort of thing.</div><div> </div></div></div>