[Cryptography] Business opportunities in crypto

[Phillip Hallam-Baker]

On Wed, Apr 14, 2021 at 2:50 PM Christian Huitema <huitema at huitema.net>
wrote:

>
>
> I have personally done  work on that topic, including the implementation
> of randomized MAC addresses in Windows 10, and the specification of a
> privacy preserving version of DHCP (RFC 7844). These specifications hide
> the "fixed" MAC address of the client, but do not hide the address and
> SSID of the server. There are indeed scenarios in which you want to hide
> the identity of both parties -- mobile servers, personal area networks,
> meeting in airport lounges, etc. RFC 8882 provides a list of
> requirements in these scenarios, but I don't know of any deployed
> protocol that meets these requirements. Anonymous rendezvous is a vexing
> problem.
>
> -- Christian Huitema
>

I have been working on this very problem. and come up with a protocol:

Mathematical Mesh 3.0 Part VI: Reliable Datagram Protocol (ietf.org)
<https://www.ietf.org/id/draft-hallambaker-mesh-rdp-00.html>

I concur with Christian, Anonymous rendezvous is a vexing problem. And it
is not a problem I think worth solving.

If Alice's phone wants to talk to Alice's tablet via a direct, peer to peer
connection, this is not a symmetric problem. The interaction MUST be
initiated by one device or the other. And that means that the initiating
device has to discover what IP address etc the other is currently sitting
on. And that is not simple when we consider constraints such as NAT etc.

So the rule I have is that every connection is established by an initiator
talking to a responder and the responder has to be permanently available
via a static IP address that is either on the same LAN as the initiator or
is on the public Internet (i.e. not behind a NAT).

Since neither Alice's phone nor her tablet meet that criteria, we need an
intermediary to broker that type of connection. This is a presence problem
and both devices need to have a connection to at least one presence service.


For IoT devices that only connect to a LAN owned by Alice, the presence
service should probably be on the LAN side of the NAT scope so they still
work when the house loses its external Internet connection. For the mobile
and tablet, they probably need a presence service on the Internet and a NAT
tunnelling strategy.

I have taken a very different approach to maintaining connections to the
traditional crypto approach precisely so that I can support these use cases
fluently.

* Datagrams can span packets and be up to at least 64KB of data
* Connections are essentially permanent once created unless one party
decides it isn't.
* AES keys are constant for the lifetime of a stream.
* I rekey AES for every Datagram
* The only reason to renegotiate the shared secret is for forward secrecy,
this results in a new stream being created.
* A device can issue a 'connection ticket' consisting of a network
endpoint, shared secret and stream ID that is issued to a broker such as a
presence service.


This approach allows me to do things like perform a one time 'device
binding' to a digital camera and then configure it so that the user just
snaps photographs wherever, whenever they are and those image files
automatically end up on their home file server (or one in the cloud). The
image files are only deleted off the device after it is confirmed that they
have been fully and correctly backed up according to the user's specified
policy.

Establishing a complete separation between RDP streams and the network
endpoints across which they are realized allows for some really interesting
and useful approaches.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.metzdowd.com/pipermail/cryptography/attachments/20210414/fb765b68/attachment.htm>