Re: [Patient] [EXT] Re: [saag] Internet Draft posted as requested -

[Mark Kennedy <[e-mail]>]

This might be a good place to inject the work from ICSG's Encrypted Traffic Inspection group.  Give this a read as a starting point for some very broad requirements.

Requirements
Definitions: 

An ETI middlebox is any device (physical or virtual) that is designed and deployed to inspect/modify encrypted traffic, including the encrypted payload. These devices include but are not limited to security devices, performance enhancing devices (caching), traffic shaping devices.

A participant is an endpoint (terminator of the encrypted connection) or an ETI middlebox.

Requirements

1.	All ETI middleboxes must be visible to everyone in the communication.
2.	Participants must be able to set policies on which ETI middleboxes can decrypt which parts of their traffic. 
3.	Participants must be able to set policies on which ETI middleboxes can modify which parts of their traffic. 
4.	The protocol must produce a cryptographically strong audit trail of who changed, or inspected, what, when, where, and why whenever an ETI middlebox changes/inspects content.
5.	ETI middleboxes must provide an attestation of the degree to which they conform to the standard.
6.	ETI middleboxes must not negatively impact the strength of the encryption.

We feel these are minimal requirements to ensure that nothing is hidden, everyone knows who the players are and by what rules they are playing.  All the participants can then decide if they are satisfied with the landscape and whether or not to allow the conversation.

Mark 

Mark Kennedy
Distinguished Engineer
Security Technology And Response
Symantec Corporation
www.symantec.com
-----------------------------------------------------
Office: 424-750-7661
Interoffice: 6 [424] 7661
Mobile: [phone]
Fax: [phone]
Email: [e-mail]
-----------------------------------------------------


-----Original Message-----
From: PATIENT [mailto:[e-mail]] On Behalf Of Bret Jordan
Sent: Monday, December 18, 2017 9:42 PM
To: [e-mail]
Subject: [EXT] Re: [Patient] [saag] Internet Draft posted as requested -

Diego, I agree with you and your points are valid.

I think there is a fundamental element that many are overlooking...  Whether you like network based protections or not, they are not going away.  TLS 1.3 does not prevent or restrict network based security solutions at all. In fact, many large organizations are rolling out new ways of using network based protections to protect their clients and data, just look at Google's BeyondCorp for an example of a new and innovative solution.

Given that network based protections are going to exist, and some percentage of the population will elect to use them. It would be nice if there was a better way for clients to:
1) know more about what was being done to their session
2) know if there are additional upstream solutions that they can not see
3) know for sure what was changed or defanged to protect them

We as a community need to try and find ways to enable the network and clients to be more robust and more secure. Simply thinking that if the session is encrypted, then it is secure, is lacking. Threat actor groups and intrusion sets make good use of encrypted sessions, and if history is a guide, we can bet that all malware sites, phishing sites, droppers sites, and CnC sites will be fully encrypted with valid certs at some point in the near future. 

While some members of this community may philosophically not like network based protections or want all of the protections to reside on the client, it is not theirs to decide. Users, clients, organizations, businesses, grandmas, cats, and dogs should all have a choice of how they want to be protected. Further, the market should ultimately decide what solution or set of solutions is the best way to protect users, we just need to make sure the protocols works and are solid. 

I would ask that we focus on figuring out how we can make things better for everyone. Just like we do not get to say in the HTTP WG that everyone should use HTTP and no other protocol should be worked on by the IETF, we can not say that everyone should secure their networks the way I, you, or someone else secures their network.  We design protocols not policy or business plans.  

Bret
_______________________________________________
PATIENT mailing list
[e-mail]
https://clicktime.symantec.com/a/1/cDSVRFwNPy0Yz41-lsHsP0BgkS7znx9HGbYfCtQkgCg=?d=R72HnQP6upzIjCWnwQhbW-p60Le7-AcIkbdbnoh2s_f8Syjzm4rJmGZXLgJZjVMCW1gf-n2tpBkb6gaIn9xEi934vDdmK0vMt5JP4Vp1xlAr7QY6u6293eyVI0frq74G39zOx7VmBaFWCGUFpzlLNrt1gyqoLDeoSDytkHc2aAQ8MFzpcibtup1Ca29rv1Lw7_a25WVtZp9nU_J9eHuiMSZ82KGCA9VJjAbvGrDRfOAK8vtWNc6152nIKlRP80Xu68R9xZT9KIKCl3p3Oeoujmvj2rZRZKwW7aF2KzzoKexz43gzA6PyxxsDAcqb3ubyYZqgUFoo2XUyyetMjoaDRXvFbDJ2W7WRHIkui1svcU6wnaOL-Owt2dOfTDylvz6ISBPi7WODX4ZVYLUhrNAnOA8feJk%3D&u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fpatient