[Cryptography] NSA security guidelines for videoconferencing

[Phillip Hallam-Baker]

On Tue, May 5, 2020 at 11:39 PM Bill Frantz <frantz at pwpconsult.com> wrote:

> On 5/4/20 at 10:11 PM, phill at hallambaker.com (Phillip
> Hallam-Baker) wrote:
>
> >So the approach I think we are going to want is not full hard boiled end
> to
> >end encryption but a sequence of encrypted frames so that the reflector
> has
> >sufficient metadata to intelligently manage the video but no access to the
> >content.
>
> This approach sounds to me like a DTLS application. There might
> be an issue if the reflector can't tell when one datagram stops
> and the next one starts.
>

I have nested crypto in my schemes currently but I am not doing real time
video (yet).

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.

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?

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.


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)

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.

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


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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.metzdowd.com/pipermail/cryptography/attachments/20200506/6ecff721/attachment.htm>