IETF Logo Mail Archive

Re: [TLS] Industry Concerns about TLS 1.3

Tony Arcieri <bascule@gmail.com> Fri, 23 September 2016 20:15 UTC

Return-Path: <bascule@gmail.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19DB512B654 for <tls@ietfa.amsl.com>; Fri, 23 Sep 2016 13:15:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 IspuT7O3IMTd for <tls@ietfa.amsl.com>; Fri, 23 Sep 2016 13:15:04 -0700 (PDT)
Received: from mail-vk0-x22b.google.com (mail-vk0-x22b.google.com [IPv6:2607:f8b0:400c:c05::22b]) (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 D3D4B12B603 for <tls@ietf.org>; Fri, 23 Sep 2016 13:15:03 -0700 (PDT)
Received: by mail-vk0-x22b.google.com with SMTP id 192so1161483vkl.2 for <tls@ietf.org>; Fri, 23 Sep 2016 13:15:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=YPQM8vHSoH1GMARrEAFcaze/4Pe4LA0gYI4wujOevgg=; b=hmEyJLaXGBTlJFuZv9SxiZqB00LUPQNDlbLotgEd9Qva4kCPZvANzRLJkoS4oyz1Bz hzpizzTyBLklksVP639phAehKR3XbZbKLDcaS3WrcJ6FmmjZJpgyd+wB+M3GtxA5Wq0D NB90eeR4glv/eRHW0K+oBpNnF0sniIUvSqKApngBV3snlUh/vx3tC/0gJrkF/DDkSQ80 E85mKLm9jXkNE2IJEr4SKwDYjceWWlSa3Mahag49r6liLVKtQTI0TxmhH3r73pBoeAip IFO0wYXB1jCqQPHWkAW6CuQ3qoj5o+BZdlU4sH3+HN8111OKbLgagE8OQuBCKGwEiVEL xf3Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=YPQM8vHSoH1GMARrEAFcaze/4Pe4LA0gYI4wujOevgg=; b=WhkBnRTZ2gt8wDR1GAUVf9Bmq/xvLJUjpbg986zgp+qiXmCV3kvPPdcC+aYxDaFHG8 xinIfZrhPLXnNMdjO9ucVBit/UpxOsdfbcy2LkDTu1jANge1xISKd9vb5fEE7t0fTmOt 2eVZpWMbSUaAb/7Dm0wd2M2wbGP2n55YFOYyK2e36v2R9M/ObELnNSHPNv2lbbfmSZBl QUsU1cUei0bWkUmJpBMJ1M/8WGk1MBSL3dTy3RlsapSv0fQBUYzkog5YrxOWaN0bbfFz 3dS/zk2JhsDThe0FEirZzYfOL8e956u+YRo1ObfMY3ph0kZ0i+liV0RkYFE2c4wGTxJd RwvA==
X-Gm-Message-State: AA6/9Rn5LjTwnwRzCJer8iv7s5w13hoAysl33bL2eJynPvsVFqog5sf5/14GBByNPT08QaGF2Z3XMkIRC9mF3w==
X-Received: by 10.31.41.23 with SMTP id p23mr185816vkp.10.1474661702983; Fri, 23 Sep 2016 13:15:02 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.103.47.209 with HTTP; Fri, 23 Sep 2016 13:14:42 -0700 (PDT)
In-Reply-To: <DM5PR11MB1419B782D2BEF0E0A35E420DF4C90@DM5PR11MB1419.namprd11.prod.outlook.com>
References: <DM5PR11MB1419B782D2BEF0E0A35E420DF4C90@DM5PR11MB1419.namprd11.prod.outlook.com>
From: Tony Arcieri <bascule@gmail.com>
Date: Fri, 23 Sep 2016 13:14:42 -0700
Message-ID: <CAHOTMVJjjR2oZti1FjuhrcEgGF=YP4b0HNrbVwUJ4NNtRWMu=g@mail.gmail.com>
To: BITS Security <BITSSecurity@fsroundtable.org>
Content-Type: multipart/alternative; boundary="001a113ef4bef8667e053d326e24"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/XtrwhAnPSXvgz6lZuTjY-9lkB9o>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Industry Concerns about TLS 1.3
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 23 Sep 2016 20:15:06 -0000

I work in the payments industry, but I am not speaking on behalf of my
employer.

I would like to note that if the approaches outlined in the "BITS Security"
post are the preferred ones for the companies they represent, those
companies have made a huge strategic blunder and should correct those
strategic blunders rather than requiring last-minute major design overhauls
to TLS 1.3 which would weaken its security.

+1000 Kenny Patterson's comments.

On Thu, Sep 22, 2016 at 10:19 AM, BITS Security <
BITSSecurity@fsroundtable.org> wrote:

> -  End point monitoring: This technique does not replace the pervasive
> network visibility that private enterprises will lose without the RSA key
> exchange.  Ensuring that every endpoint has a monitoring agent installed
> and functioning at all times is vastly more complex than ensuring that a
> network traffic inspection appliance is present and functioning.  In the
> case of monitoring of supervised employee communications, moving the
> monitoring function to the endpoint raises new security concerns focusing
> on deliberate circumvention - because in the supervision use case the
> threat vector is the possessor of the endpoint.
>

I strongly disagree. Endpoint security is paramount, and some sort of
network MitM system is absolutely not a replacement for endpoint agents. I
would highly suggest deploying agents on your endpoints. If you don't have
endpoint security, all is lost. I would suggest performing multiple
security checks regularly on all endpoints throughout your enterprise.

Modern endpoint agents can work at a level much higher than TLS network
packets (i.e. total memory inspection with kernel-level agents). MitMing
traffic in lieu of deploying an endpoint agent only provides monitoring of
"compliant" packet streams, which are unlikely to be used by either
attackers or insider threats. I'm not saying it's bad to run NIDS or a
rolling packet capture system, these are both great, but again, neither are
a replacement for an endpoint agent.

Until the critical concerns surrounding enterprise security, employee
> supervision, and network troubleshooting are addressed as effectively as
> internet MITM and surveillance threats have been, we, on behalf of our
> members, are asking the TLS 1.3 Working Group to delay Last Call until a
> workable and scalable solution is identified and vetted, and ultimately
> adopted into the standard by the TLS 1.3 Working Group.


If you're relying on MitMing S2S traffic for debugging a payment stack, it
sounds like your payment stack is opaque to you, which is not only a
concern for security, but the general reliable operation of your payment
stack as a whole. As a general recommendation, I would suggest building out
debugging facilities for your payment stack so you know it actually works,
and don't have to lean on crutches like MitMing traffic for debugging
purposes.

While such a crutch may in the short-term make debugging appear easier, it
also assists a patient attacker with internal network access who is
passively capturing traffic before attempting to obtain a decryption key
which would expose payment credentials e.g. cardholder info/PANs, ACH
account numbers, etc.

tl;dr: your suggestions would harm the security of more "forward thinking"
payments companies. Again, my personal opinion, not that of my employer.

-- 
Tony Arcieri

v2.23.0 | Report a Bug | By Email