Re: [IAB] Mandatory encryption as part of HTTP2

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, Nov 15, 2013 at 9:56 AM, Steve Crocker <steve@xxxxxxxxxxxx> wrote:
I've been watching this thread for a while.  The idea of making it harder without actually expecting the encryption to work seems like an implicit admission of failure.  

+1

 
I think the right posture is to make privacy via encryption the default at every level, or perhaps even mandatory, and to expect it to work.  Key management has to be seamless and automatic, and the software and hardware have to be trusted.  

+1 

The question is what the attack model is and how we measure the work factor.

By 'secure' we mean 'increase the work factor to an infeasible level'. This is how the NSA thinks about systems when it is protecting them rather than trying to break them. I do not hold any security clearances and never have but I do have that part of NSA doctrine from multiple sources at the very highest levels in the organization.

Under the old metric the objective was to increase the cost of an attack to some multiple of the GNP of all potential adversaries for some number of years. Deciding on the work factor for the crypto part of the problem is really easy as there is virtually no cost to increasing the work factor exponentially. The hard part has always been calibrating the interface between the crypto and the real world. That is the WebPKI.


The attack model that the WebPKI was calibrated against was an organized criminal attack against commercial assets. 

Pervasive monitoring is a different attack. The attacker brings a different set of resources and has different goals and costs.

I have it on very high authority that the NSA is going to consider the risk of being caught as being far higher in the future. They have been caught twice through technical measures (StuxNet, Flame) and now they understand that they face an insider threat.


A trust management scheme that is vulnerable to active attack is completely unacceptable against a commercial attacker. We have numerous cases where that type of attack has been used. 

Active attack is also unacceptable as a control against targeted attack. And anyone who participates in IETF security area at a certain level is possible a target of attack. 

A scheme that forces an attacker to perform an active attack rather than a passive one is empirically a valuable control against covert passive monitoring provided that it is backed up with controls capable of detecting the active attacks and reporting them.


We need to be very clear about the difference between 'encryption everywhere' and 'TLS everywhere'. While there are obvious commercial advantages to a CA in TLS everywhere, I do worry that attempting that goal might well end up with TLS being reduced in security strength to the lowest common denominator.


In a complete security stack I would want all of the following encryption controls in place simultaneously:

1) Link level encryption to defend against traffic analysis attack.
2) Transport layer Security to protect metadata against confidentiality and integrity attacks
3) Message layer security to provide strong end-to-end confidentiality and integrity

For Web services I would want multiple overlapping encryption protections at the message layer. An email needs to be signed by both the sender and the mail gateways it passes through.


--
Website: http://hallambaker.com/

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]