[Patient] Requested Feedback - Protecting Endpoints

Patrick Maroney <pmaroney@wapacklabs.com> Thu, 14 December 2017 15:54 UTC

Return-Path: <pmaroney@wapacklabs.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 80467120227 for <patient@ietfa.amsl.com>; Thu, 14 Dec 2017 07:54:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=wapacklabs.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 rCBceL1L7haQ for <patient@ietfa.amsl.com>; Thu, 14 Dec 2017 07:54:47 -0800 (PST)
Received: from mail-qt0-x232.google.com (mail-qt0-x232.google.com [IPv6:2607:f8b0:400d:c0d::232]) (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 60953124B0A for <patient@ietf.org>; Thu, 14 Dec 2017 07:54:47 -0800 (PST)
Received: by mail-qt0-x232.google.com with SMTP id d4so8502640qtj.5 for <patient@ietf.org>; Thu, 14 Dec 2017 07:54:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wapacklabs.com; s=google; h=from:mime-version:subject:message-id:date:to; bh=CyF0IdNmA79RDj78NprWYRQw8hzZQZIZeU1z4yo/DI4=; b=e+dYMbQwXJrRQfcjeG5Gb0LvYS8Orn8CwYXtMQEXylqP/Nz60bvg5WbHvuGnvcuzvN Rkn3grQfd2PZqP2AIRaD2bM6T/Nc1C59mmwJco2+dJ9bWPLfw0m8II5skqzJ+elihl7J +L4r1RoP08zCch/MORxP1rkdXnwYM0GFMqCj0o+exVWoM3FJJMNjo0BqxCNgJ8xCtslU gFygTeJM7UG3f0ArknzUvp8f0w7EH5PBbjLMtzaarBGbIj4R5XBwo5SyvPMN9XpNgrGe rUFImjR/3WHTaXIxOX2ZeJ8pOGhv/XYu6Kk6JpLhCfy51waQfuTPEhRwnsXGWiEchVO8 qXtQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:message-id:date:to; bh=CyF0IdNmA79RDj78NprWYRQw8hzZQZIZeU1z4yo/DI4=; b=hfFMNVVp8COQ9BJ+eT5ge0yHKZpV2ao3kKT+61H1KQa6DGAo/fyP9d4VO6FGVHw0AM LG2Ejz5aLtv8yp8fGZ8p/qUNntqoHdqGlT+n168WGOyApk8aKyRTRmZOB+7d+CmgayzZ Fy1yAQiiqEbzu0yyOtx7cKd2mb5BA1wYy8ua6a5FDx9nEseL5T5+SCI8H2Ush1uqjuq9 W8/Wxyh5eNK4/Y3DqaQqp1aScIhNCqNmDkJsoTldCQvRjOaWEWbsHLnr9ATJw9RwSD0Y H8PW0LHCEySkI9tgru+9Usgo+3OEf63Z1RCLf1Wm/53tN0dIqb36Ha2u1KD4m+UAPtAb iihw==
X-Gm-Message-State: AKGB3mILjK6CPSsQ/SnGGab03555dSDXg1ovEV/B7MgDvZQxMXn6h+PS /f6NlzQEYNYKR+rcR9iRiQeJ1C22qCs=
X-Google-Smtp-Source: ACJfBovqi2XtW8wkGg6yu0HnEcDo/5sKMuXoP0sf+vxRs4myahGmYKIjl1YkEx397T3jE8iqMM7qsQ==
X-Received: by 10.200.42.14 with SMTP id k14mr16638722qtk.20.1513266886374; Thu, 14 Dec 2017 07:54:46 -0800 (PST)
Received: from [172.16.6.2] (pool-108-24-82-189.cmdnnj.fios.verizon.net. [108.24.82.189]) by smtp.gmail.com with ESMTPSA id y45sm2836065qtc.20.2017.12.14.07.54.45 for <patient@ietf.org> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 14 Dec 2017 07:54:45 -0800 (PST)
From: Patrick Maroney <pmaroney@wapacklabs.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_14417E08-740A-4919-B05B-837B169BDBAE"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Message-Id: <B36DAF90-A27A-49E7-B40E-5CC7315BA18D@wapacklabs.com>
Date: Thu, 14 Dec 2017 10:54:44 -0500
To: patient@ietf.org
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/patient/MZ57Bu-AAX4aMm9TFpjTJyy7yCw>
X-Mailman-Approved-At: Thu, 14 Dec 2017 09:02:39 -0800
Subject: [Patient] Requested Feedback - Protecting Endpoints
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: Thu, 14 Dec 2017 15:56:10 -0000

Brian,

Per your request for comment*:

I'm glad to see this discussion.

Having directly observed nation state adversaries enjoying the benefits of "legitimate" channels, there's an oft overlooked aspect of the dichotomy of secure channels.

An adversary controlling an endpoint may simply wait for establishment of a secure channel (with strong Multi-factor Authentication from the legitimate user/application) to the target endpoint to obfuscate their presence, activities, and objectives.  The strongest secure channels can be exploited - giving all of the advantages of same to the adversary.  Though typically the case for many tunneling attacks, the adversary does not need interactive command and control of the initiating endpoint.  They merely need to be able to sense/test the state/existence of the secure channel to execute "store and forward" command and control.


Patrick Maroney
Principal Engineer - Data Science & Analytics
Wapack Labs LLC
(609)841-5104
pmaroney@wapacklabs.com

Public Key: http://pgp.mit.edu/pks/lookup?op=get&search=0x7C810C9769BD29AF

* "If you get a chance, please read the v00 Internet Draft which we just posted to IETF ( https://www.ietf.org/id/draft-witten-protectingendpoints-00.txt ) then send a quick comment, like "hate it," "love it," "glad to see the discussion," or (apparently popular) "why you hate the IETF" type comment to patient@ietf.org mailing list."