<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-size:small">On Wed, Feb 17, 2021 at 1:03 AM John Gilmore <<a href="mailto:gnu@toad.com">gnu@toad.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">Phillip Hallam-Baker <<a href="mailto:phill@hallambaker.com" target="_blank">phill@hallambaker.com</a>> wrote:<br>
> TLS would seem like a poor choice, a messaging layer approach like S/MIME<br>
> would be a better fit.<br>
<br>
My guess is that about 10,000 times as many emails get encrypted via<br>
TLS, as via S/MIME.  Just counting the mail flowing between Gmail and<br>
Outlook!  And TLS secures many more things besides email -- not just the<br>
web, not just email, but DNS, WebRTC audio and video, etc.<br></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">But what you are proposing is an end to end security solution.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">OTP security between Alice and Bob: Good</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">OTP from Alice to Alice's MSP then plaintext, then OTP from Alice's MSP to Bob's MSP then plaintext, then OTP from Bob's MSP to Bob: I really fail to see the point.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">If you want to establish TLS between Alice and Bob, you have disrupted the model far more than switching to SMIME would.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Sure, most people don't want S/MIME because of the faff. But OTP is going to be vastly more faff than S/MIME or OpenPGP today.</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">It's certainly not standardized in draft or issued RFCs.  Want to help?<br></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">I am currently trying to finish 15 internet drafts specifying a Threshold Key Infrastructure to make using OpenPGP and S/MIME as easy as using regular SMTP email. </div><br></div><div><br></div><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">
> The big problem technically would be conserving your supply of one time<br>
> material. You have to exchange that out of band if there is going to be<br>
> security.<br>
<br>
Let's not be stuck in 1990s thinking.  Moving terabits from one place to<br>
another is not as big a problem as it used to be. </blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">It is not just moving it, you have to be able to generate it. And you have to be absolutely sure you never use the same material twice and the other end of the communication knows where you are in the transmission.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">I agree the storage is no longer such an issue. Though migrating my NAS from its 6TB disks to a set of 16TB disks it turning into a two week job. and I only had 26TB of data. </div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">The bottom line is Alice has to really, really wanna talk to Bob securely for this to make sense. And I am having a hard time seeing how I can fit it into any model for Data At Rest security. OTP is really about the channel. </div><div class="gmail_default" style="font-size:small"></div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">> For most of us, 'one time pad' is a sure fire sign of<br>
> crypto snakeoil.<br>
<br>
Y'mean we would actually have to examine products to see if they were<br>
secure?  Rather than come to a snap judgment based on their name?  ;-/<br></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">Examine products to see if they are secure before relying on them? Sure.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Examine products to determine that they are not yet more snake oil before discarding them? I have other priorities.</div><br></div><div><div class="gmail_default" style="font-size:small">The best reason I can see for doing this would actually be to demonstrate just how limiting a genuine OTP scheme would be.</div><br></div><div class="gmail_default" style="font-size:small">There is good reason OTP is pretty much limited to diplomatic traffic.</div></div></div></div></div>