<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-size:small"><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Mar 30, 2021 at 10:37 PM jrzx <<a href="mailto:jrzx@protonmail.ch">jrzx@protonmail.ch</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div> On Monday, March 29, 2021 6:11 PM, Phillip Hallam-Baker <<a href="mailto:phill@hallambaker.com" target="_blank">phill@hallambaker.com</a>> wrote: <br></div><blockquote type="cite"><div dir="ltr"><div class="gmail_quote"><div><div style="font-size:small">Not for these use cases. And some of the devices may not have public key available.<br></div></div><div><div style="font-size:small">In the longer term, I want to be able to keep a symmetric key session going Kerberos style forever if need be. <br></div></div></div></div></blockquote><div><br></div><div>Building an identity system on long lived shared secrets seems like a bad idea, particularly as elite trust and trustworthiness is in long term decline, as for example the crisis of distrust in accountants and accounting that led to SoX.<br></div></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">The whole point of this project is to question existing assumptions and see what happens when we reject notions that are widely held but based on 197s thinking. thirty years of experience tells me that key rotation requirements are far more often a cause of failure than prevent an attack.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">There might well be concerns about long term secrets but these are separate from and disjoint from concerns at the physical layer.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Conventional thinking says that when Alice returns home and here mobile device can connect to the 960Mbs Wifi drop, her video conference call should move off her 2Mbs 3G connection to her house. Fair enough. But what if that house connection is flaky because the fiber is disconnected? And when should we make the transition? What if she is just going past her house?</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">I reject the notion of a sharp transition completely. The WiFi connection should be phased in and phased out and this process should not require any cryptographic concerns to be considered.</div></div><div><br></div><div><div class="gmail_default" style="font-size:small">Another real world use case is debugging an IoT device which may be WiFi connected or USB connected. I want my debug info to get through when I unplug either.</div><br></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"><div></div><div>Recommended practice on shared secrets in the Libsodium documentation is to keep them in locked memory so that they don't get stored to disk, and replace those shared secrets on every reasonable occasion to do so.</div></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">That might be appropriate for some devices. But probably not for a lightbulb running off an 8bit CPU that will never actually do anything other than authenticate commands to turn itself on and off.</div><br></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"><div>And it seems to me that change in network address is such an occasion - that you should not be keeping shared secrets around through an event that might correspond them no longer being in the control of a single client.  Maybe the network address changed because of physical events at the client end.<br></div></blockquote><div><br></div><div class="gmail_default" style="font-size:small">This is a concern embedded in a particular set of circumstances that is only sometimes applicable. It is a valid application concern, it is not a valid architectural concern. The architecture should allow the application to decide whether to react and react if appropriate. </div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Forcing application behavior in response to a set of limited concerns is a major red flag in architecture. At one point some bright spark decided that SMTP mail servers should automatically wrap the lines of email messages at 72 columns so they fit on a VT100. In the process, he ensured that the wrapping would be wrong for every other terminal width and you can still see the results of this mistake today.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">One of the main reasons Windows, Linux and OSX periodically pause for no particular reason is because some dim bulb decided to poll for the completion of some operation and the machine is busy waiting in a tight loop buried deep in some device driver.</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">Another aspect of the design of the presentation layer I have conceptualized but not yet implemented is a three way handoff in which Alice and Bob establish a connection through a presence service. This is constantly required in video conferencing situations. If Alice and Bob are both behind a NAT device, they have no means of knowing the external UDP port of the other. And Alice certainly doesn't want Bob to be able to call any time he chooses in any case. So we need a presence service.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">In the traditional situation, Bob calls the presence service, gets UDP address, port from the presence service and uses that to connect to Alice, fair enough but now we have that connection request happening EnClair. Yuk!</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Here is a better scheme:</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Alice's device connects to the presence service and uploads some number of stream IDs to it for use as 'connection tokens'.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Bob's device makes a connection request to the presence service (this may be direct or mediated through Bob's presence service). After the request is authenticated and authorized one of the stream IDs is returned to Bob together with the device connection info.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Bob's device can now make an encrypted connection request to Alice's device using the unique stream number. The only data Alice sends enclair now is her ephemeral key.</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">Of course, in a practical situation, we might well go a bit further and send a 'fat' connection token which has a one time authentication public key and a kerberized ticket. </div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small"><br></div></div></div>