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

Bret Jordan <jordan.ietf@gmail.com> Tue, 19 December 2017 05:42 UTC

Return-Path: <jordan.ietf@gmail.com>
X-Original-To: patient@ietfa.amsl.com
Delivered-To: patient@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D03B41205F0 for <patient@ietfa.amsl.com>; Mon, 18 Dec 2017 21:42:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tPptbpYWPMWT for <patient@ietfa.amsl.com>; Mon, 18 Dec 2017 21:42:02 -0800 (PST)
Received: from mail-qt0-x236.google.com (mail-qt0-x236.google.com [IPv6:2607:f8b0:400d:c0d::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16A2A120227 for <patient@ietf.org>; Mon, 18 Dec 2017 21:42:02 -0800 (PST)
Received: by mail-qt0-x236.google.com with SMTP id 33so22911407qtv.1 for <patient@ietf.org>; Mon, 18 Dec 2017 21:42:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=/IMkEMEnYbgCbPsXcIWKtgr02MiIK7tT8xUjSTQzlAY=; b=gRZg7Bpu24aqet+/O6nfwrr2Tv0yKw2pURQmkSseEfy9NK32cBrHGhDdpxU8ZKC7id 2pqZCJb/Qe/VYDMec0wtv5ObDHfcJIPv4hbvFVSjn0YWYHnzkkCWcXWdg6Y60+VI1OYf FO8aWp1bj7EJ1VQBlFi+eik1rZ6fDvuKM/64Qne0bIqL1dYRc6Bs+y28SNr/a6gxBY8H QBGV6jOeKBPGUUZrauDpgN82pTYGOn0lHLjGf6svOHEXJb7AsT37A+DfHQAVIRX6rxH1 dJ2RuMmznPyvZDGux522Oq67AEpZ1e18daNMpgmuYMrJIdmg6pRflORO/08Ocrika39u V9ew==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=/IMkEMEnYbgCbPsXcIWKtgr02MiIK7tT8xUjSTQzlAY=; b=RoqdYDva0Ghzq9WmNgpwSzXNQQ3WprfxylfU3FPb65IoYOlq6DK/YVfTHhYTLtLYSt F5TElA9iuIM0qPBB0yA0FR7gVQXHM0fs804uFLSkWfeNJfEaItNwWgEgli37I8/tJp2s O1XMyJeJSMtr/PA99SEyfFR+aZp/nqUCQG0BRlx743Vi58kdH6zZLEOl1UrsW5/xRYwX 3+cFWKHHFVf3vvyGrAqB9hiWPqP3hGGx2svJ2T/11HUNUuEwOvbbrou6iu1CNa2SltPa izRwDckhYpwlQrOoaAKZBhjVKIiZ4Qhun4jYibIFDc3F28KV8ThT1MAiZDl8cRFEtvm6 WyZQ==
X-Gm-Message-State: AKGB3mI3KQxKOvfqCVsQvmzZpYBiyhaiZCGr5odTUCP/EJ7IDfFcLu4g TOePdhuRwrc0KunBkuuIC6VQpvi1
X-Google-Smtp-Source: ACJfBoucCActQwQAPCAN7Y2W4pQqOnSbvHl9vKE1vhTO6Q6LSWr6Zj1UBNjFh3SM/JPrmpk45Qri6w==
X-Received: by 10.237.41.37 with SMTP id s34mr3487111qtd.154.1513662120694; Mon, 18 Dec 2017 21:42:00 -0800 (PST)
Received: from ?IPv6:2605:a601:3116:8400:d489:3c88:be4b:dd31? ([2605:a601:3116:8400:d489:3c88:be4b:dd31]) by smtp.gmail.com with ESMTPSA id u26sm9244528qtb.1.2017.12.18.21.41.58 for <patient@ietf.org> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 18 Dec 2017 21:41:59 -0800 (PST)
From: Bret Jordan <jordan.ietf@gmail.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Date: Mon, 18 Dec 2017 22:41:55 -0700
References: <MWHPR16MB14881688FE400E3277CA8A9393310@MWHPR16MB1488.namprd16.prod.outlook.com> <MWHPR16MB14889BEE3EB0ED5F328D7C3993370@MWHPR16MB1488.namprd16.prod.outlook.com> <MWHPR16MB14889B7535153E5844649CA393370@MWHPR16MB1488.namprd16.prod.outlook.com> <MWHPR16MB14880A12D15AC58FDD5CEC8793370@MWHPR16MB1488.namprd16.prod.outlook.com> <MWHPR16MB1488D43F3B53BC7BBE9D836593370@MWHPR16MB1488.namprd16.prod.outlook.com> <MWHPR16MB1488853B0E4F7BB8E557288D93370@MWHPR16MB1488.namprd16.prod.outlook.com> <MWHPR16MB148845FB069D03625BC399B193370@MWHPR16MB1488.namprd16.prod.outlook.com> <MWHPR16MB1488848D7AC828EBB8DA90B093350@MWHPR16MB1488.namprd16.prod.outlook.com> <DM5PR16MB148477E1FAA4C210A3B013F7930A0@DM5PR16MB1484.namprd16.prod.outlook.com> <dfdb52ca-81ae-50b7-cd5f-e256b5cb047d@cs.tcd.ie> <AF4C62E0-61AB-45DB-B3E6-56AB67A1070A@telefonica.com> <d47e82af-5c6f-9be5-4226-4d6713701148@cs.tcd.ie> <98E78B0A-0351-4702-98F5-62DAF2C125CD@telefonica.com>
To: patient@ietf.org
In-Reply-To: <98E78B0A-0351-4702-98F5-62DAF2C125CD@telefonica.com>
Message-Id: <217613C9-9D51-4CC9-8C8C-D632E1CECFF6@gmail.com>
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/patient/DaFvwcRa1raAfkk9gVEZ0kOZ73I>
Subject: Re: [Patient] [saag] Internet Draft posted as requested -
X-BeenThere: patient@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Protecting against Attacks Tunneling In Encrypted Network Tunnels <patient.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/patient>, <mailto:patient-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/patient/>
List-Post: <mailto:patient@ietf.org>
List-Help: <mailto:patient-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/patient>, <mailto:patient-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 19 Dec 2017 05:42:04 -0000

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