Re: [lamps] The Status of OCSP and its future

["Dr. Pala" <[e-mail]>]

Hi Phillip, All,

thanks for the reply - lots of interesting considerations. Please 
forgive me if I am not familiar with the details around your proposal 
(Mesh), however I think it is a good idea to work in the space - as you 
say, although the approach might be different, the problem is actually 
the same.

 From what you write, it seems that your approach is more "radical" and 
try to tackle the problem for a specific angle - the security of keys. I 
do not see this to be a competitor solution, but more as a comprehensive 
approach. In this vision, the two solutions might also have different 
time horizons: shorter for the OCSP optimization and longer for more 
comprehensive changes.

This said, I would like to re-focus the conversation on the proposed 
idea and ask you if you see any issue related to the proposal itself. 
Without more text and an I-D it is difficult to have a clear vision 
around it, but at least the core idea is there :D

Also, in case we do move forward, would you like to participate in the 
effort ?

Cheers,
Max

On 10/24/19 10:11 AM, Phillip Hallam-Baker wrote:
> On Thu, Oct 24, 2019 at 11:01 AM Dr. Pala <[e-mail] 
> <mailto:[e-mail]>> wrote:
>
>     Given these considerations - and the fact that large PKIs are
>     being deployed, today, for the IoT case - we would like to start
>     the discussion around the current status of OCSP and possibly work
>     on a proposal for moving forward with a more efficient protocol.
>
>     What do you think ? Anybody would like to tackle this problem
>     together ?
>
> I am interested in the problem. I just disagree with the notion that 
> X.509/PKIX is a useful way to think about IoT devices. It is not what 
> the architecture was originally designed to serve and it doesn't 
> actually serve it at all well.
>
> The reason we need revocation in the WebPKI is that the primary 
> concern that infrastructure was originally designed to address was the 
> appearance of fake Web Merchants. The design brief was to make online 
> commerce as safe as bricks and mortar. The fundamental concern 
> VeriSign Class 3 was designed to meet was to establish accountability 
> so that posing as a fake Web merchant was unprofitable. And that 
> limited goal was achieved with enormous success. Or at least it was 
> before big tech thought it a good idea to strip out the security 
> signal from the browsers.
>
> The problem with the WebPKI is that it does not serve every purpose 
> well. And it has been co-opted to a rather sordid dispute into who can 
> invade users privacy to bombard them with ads and who can't. So we 
> have the current Congressional hearings and the looming anti-Trust 
> lawsuits. People who thought PKIX would be so much better without the 
> lawyers and were happy to see them disappear are going to be in for a 
> nasty shock in the next couple of years.
>
> We are long past the point where it is prudent for any of the Web 
> Browser providers with more than 5% market share to allow any of their 
> employees to contribute to discussions on the WebPKI without having 
> every email vetted by company lawyers and company lawyers attend every 
> meeting.
>
>
> The question to ask is why we need revocation at all. In the WebPKI it 
> is because:
>
> 1) Private keys are weakly bound to the devices and are prone to 
> disclosure.
> 2) WebPKI certificates conflate authentication and authorization and 
> it is necessary to revoke certificates that are being used by 
> criminals to steal money.
>
> Neither of these need be a concern in the IoT space. But certificate 
> expiry and revocation are deeply bound into the architecture. If you 
> decide neither is needed, you can greatly simplify the architecture: 
> Bind a keypair into the device during manufacture so that it can never 
> be extracted without serious effort and 99% of the causes of key 
> compromise disappear. Separate authentication and authorization and 
> there is no need for the PKI to be concerned with it.
>
> This is of course the approach I have taken in the Mesh (Singapore, 
> Friday 10:00am). But before people accuse me of using this to promote 
> my own work, it was this exact set of concerns that led me to design 
> the Mesh in the first place.
>
> And yes, we can't trust keys that come from a manufacturer and nor do 
> I suggest that we ever should. PKIX was designed according to the 
> cryptographic capabilities as they were understood in 1978 when 
> Kohnfelder wrote his master's thesis. We have moved on since. The 
> techniques I am applying were invented in the 1990s but since people 
> are loathe to recognize technology unless it is all bright and shiny, 
> I have re-branded them 'meta-cryptography'.
>
> Point is that today we face a number of concerns that were almost 
> entirely theoretical or limited to the most sensitive applications in 
> the 1990s:
>
> * Alice used to share her computer with more than 50 other students, 
> now she owns more than 50 computers. The key provisioning problem has 
> changed completely as a result.
>
> * Compromise in the supply chain is no longer a theoretical problem, 
> nor is the problem a single state actor as some suggest. The supply 
> chains are large, complex and opaque. Nobody really knows the 
> provenance of anything unless it is one of the handful of devices from 
> a trustworthy foundry.
>
> * The shortest password that is secure is far longer than the longest 
> password that is memorable and this cannot be solved by changing the 
> hash function. The capabilities of massively parallel machines 
> outstrips the capacity of a single core by many orders of magnitude. 
> There is no technical means of making exhaustive search prohibitive.
>
> * We are no longer just providing security to government employees, 
> academics and students. We can't expect them to adapt to our 
> technologies any more. _*Don't try to change the user*_.
>
> * The Internet has 5 billion users and 50 billion devices. Deployment 
> of technology is a vastly harder challenge than designing or 
> implementing it. We have to design for deployment and we cannot do 
> that with a design from the 1970s.
>
> This does not mean that PKIX is irrelevant, far from it. What I have 
> done in the Mesh is to take the use patterns that emerged from the 
> deployment and use of PKIX and reified them as architecture. So Alice 
> can now use online/offline key management to protect her data but 
> don't tell Alice that because she doesn't need to know thats what she 
> is doing.
>
>
> To paraphrase Keynes: We have unused cryptography in a world of 
> security need.
>
-- 
Best Regards,
Massimiliano Pala, Ph.D.
OpenCA Labs Director
OpenCA Logo