<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-size:small">On Mon, Apr 12, 2021 at 1:05 PM Kent Borg <<a href="mailto:kentborg@borg.org">kentborg@borg.org</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">
  
    
  
  <div>
    <p>There are a <i>whole</i> lot of threats that full disk
      encryption does not address, and they need to be addressed.</p></div></blockquote><div><div class="gmail_default" style="font-size:small">Yes but how far do we have to go down the rabbit hole to deliver something that provides a useful quantum of security?</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">I don't know of anyone who has proposed anything as wide in scope as the Mesh. But I get far more complaints about the lack of direct consideration against end-point compromise than people suggesting the scope should be narrower. </div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">I don't do endpoint compromise precisely because it is a never ending problem. No, signing the operating system is not a full protection against rootkits. Rootkits can live in the firmware of your graphics cards, your network cards and many other places. If the endpoint is compromised, the user is hosed and detecting and recovering from that is not my problem. </div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Whole disk encryption is like IPSEC, it provides a particular quantum of security but a rather limited one. It provides protection against laptops being stolen from cars, data being breached through hard drives being sold on EBay and allows a box to be checked on the auditor's list. </div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">It is a limited but useful quantum of security. Other measures fail to make a useful quanta. Forcing users to include a capital and a digit in their password does absolutely nothing useful, it actually reduces security since all they do is change password to Password1 so only 8 of the 9 characters are contributing.</div><br></div><div><br></div><div><div class="gmail_default" style="font-size:small">There are some controls that are easily defeated because they do not provide a sufficient quantum of security and other times when a piffling objection to the lack of a PERFECT SOLUTION means we overlook the good.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">For example: If employees are dealing with sensitive documents like patents, customer data etc. surely these should all be encrypted by default so only authorized employees have access. We have known how to do that for 30+ years. We have better ways of doing that today but we could encrypt every document with S/MIME in a really flexible way that doesn't impact end users. I call this problem Confidentiality Control and I believe it is a useful quantum of security.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Why don't we do it? Well Alice who is authorized might communicate the data to Mallet. So lets make sure that cannot possibly happen by completely redesigning the operating system to make it Trustworthy and then rewrite the apps so they stop Alice disclosing the document. And that is the whole CRM/DRM tar baby which we all know is impossible. Except of course that DRM does actually provide a very useful quantum of security to industries whose concern in protecting revenues from copyright content which is not actually a confidentiality issue at all.</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">When I started doing crypto we would ask where the right place to do encryption is. I now know that is the wrong question because there isn't one right answer. For communications, I want to encrypt at the transport level and the message level. For storage I want to encrypt the disk and also the individual data files on the disk. And in some cases I might want to encrypt folders as well. And I also want to automatically create copies of all my data so that if I lose one disk, there is always another copy. And I want to automatically notarize all data so that I can detect integrity attacks, etc. etc.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">We need a yardstick to distinguish an appropriate concern that a control does not provide a meaningful quantum of security with a piffling objection that the control does not deliver the kitchen sink.</div></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Some ways of distinguishing:</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">* What is the cost of the proposed attack vector?</div><div class="gmail_default" style="font-size:small">* Does the control provide meaningful mitigation even if it is not 100% effective?</div><div class="gmail_default" style="font-size:small">* What proportion of uses are affected by the stated vulnerability?</div><div class="gmail_default" style="font-size:small">* If there was a solution to the identified vulnerability, would the control still be needed?</div><div class="gmail_default" style="font-size:small">* If someone proposed a solution for the proposed vulnerability would someone object that the issue addressed by this vulnerability would remain?</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Raising the cost of an attack is a valid security control. The main reason I wrote the DotCrime Manifesto was simply that I was fed up of having to wade through dozens of irrelevant objections when trying to discuss a particular control. I could simply answer 'I explained how to address that in my book'.</div></div></div>