Re: [Secdispatch] [Smart] New Version Notification for draft-lazanski-smart-users-internet-00.txt

[Bret Jordan <[e-mail]>]

Ekr,

It is not so much that it was designed wrong, but that when critical functionality was removed, there was no alternative method added to support critical use cases. So one can argue that some decisions were done from a myopic point of view, without realizing the problems they will create. 

There are many examples, but let us just take two for right now.  I am sure I will enrage people to no end and cause an uproar, but so be it. 


Hiding the Server Certificate
This is a wonderful thing for open internet sessions as it help prevent passive analysis of users traffic and where a user is going. So from that side, it is great. However, from the managed network stand point it is terrible. This feature/data is a critical element used in managed networks and is critical for ensuring regulatory compliance. The problem is not so much that the WG decided to hide it. The problem is the WG did not and has not yet provided an alternative solution to fill in the missing gap. So either the WG does not understand the operational security requirements around it, or they are just choosing to ignore them.


DNS over HTTPS and DANE
This is also a really neat idea. However, when you layer this with DANE+DNS_SEC you get to a point where installed trust anchors no longer become effective.  Further, managed networks really rely on DNS data for both first line defense and retrospective analysis of threat actor / CnC behavior.  So DNS over HTTPs by itself is not a bad thing.  But the way it is being implemented in products and the possibility of using it with other solutions like DANE can make operational security significantly more challenging if not impossible.  Threat Actors are already starting to use DoH to launch attacks, since it provides a way for them to get around some security controls. So it becomes critical that for things like DoH that products provide a way for it to be turned off, or for managed networks to specify their own DoH servers.  Further, managed networks need to start looking at locating their internal DNS servers on the WAN side of their proxies / firewalls so that they can create islands of trust and rewrite the DNS_SEC on the fly if they need too.  But all of this should be called out and where possible, we should provide ways for management networks to still do what they need. 


So I would like the security considerations to be updated to help ensure that we ask the questions, like “what is this going to do to operational security?”, “how is this going to impact incident response and network forensics?”.  I want to also be super clear that I am not against these technologies by themselves. But we need to ask these hard questions and provide solutions that can still enable managed networks to protect themselves.   Thinking that everything can and should be done on the endpoint is just outright naive. 



Thanks,
Bret
PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050
"Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg."

> On Jul 15, 2019, at 9:25 AM, Eric Rescorla <[e-mail]> wrote:
> 
> 
> 
> 
> On Mon, Jul 15, 2019 at 7:50 AM Bret Jordan <[e-mail] <mailto:[e-mail]>> wrote:
> Kathleen,
> 
> 
>> I do think there is work for the IRTF as well and would like to see that encouraged.  The shift to strong encryption is good, but upends the current security management models for many.
> 
> This is one of the points I made during my talk at RSA.  These technologies by themselves, are all really great.  The problem comes is when you start using all of them together.  To the naive comment earlier that this is about vendors trying to sell product, no, this is about network and cyber defenders and SoC analysts trying to do their job. There are things like regulatory compliance that organizations and enterprises are required to follow. Some times I feel like we are so worried about one piece of the security pie, that we completely neglect the others. 
> 
> Bret,
> 
> As I said before, this is extremely general and hard to act on.
> 
> What would be most helpful at this point would be for you to describe a few ways in which you think the IETF should have designed protocols differently, so that we can discuss them.
> 
> -Ekr
> 
> 
> Here in the IETF everyone needs to better understand how SoC analysts and network/cyber defenders do their jobs, what they are asked to do, and what tools are available to them. 
> 
> Bret