Re: [TLS] Industry Concerns about TLS 1.3

Watson Ladd <watsonbladd@gmail.com> Mon, 03 October 2016 21:46 UTC

Return-Path: <watsonbladd@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 27E9312958B for <tls@ietfa.amsl.com>; Mon, 3 Oct 2016 14:46:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.999
X-Spam-Level:
X-Spam-Status: No, score=-0.999 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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no 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 gJFSqiLS1NnI for <tls@ietfa.amsl.com>; Mon, 3 Oct 2016 14:46:38 -0700 (PDT)
Received: from mail-vk0-x229.google.com (mail-vk0-x229.google.com [IPv6:2607:f8b0:400c:c05::229]) (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 CF88D12957F for <tls@ietf.org>; Mon, 3 Oct 2016 14:46:34 -0700 (PDT)
Received: by mail-vk0-x229.google.com with SMTP id b186so37575964vkb.1 for <tls@ietf.org>; Mon, 03 Oct 2016 14:46:34 -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=YN8c0IQcyBFeAQUE2rv5XCZlybrzzTxx2/67vytlp+Y=; b=k4XkUNpEATDsksmORlzBTDBepcQTvOS1M08sGtw4xxaeTzYm5TJ6oPhUU20EQN19ez AvqZn9G7KWQzh769i15fwz5ygeH6QvPtU1uQnjTs9/y3OrgETk2WpO+mlXzmuZE6fz0H Tny0rE1O8Ehk7Spj0TUl6DLtYqAOsnswHIiI7EuBXJL1NKjCjZVaKKZuxH8oxy5EmZEc Lgk+gCaFc2Qh7Vgid0YbOt4ECTbjXTzXDgSS+gIW24NpMQwEKG4gdGKzrxagDReTPKeV y+VyHySQJoJC4Vup9xDC3BQaNSH0AxbKVtdFcT8dxpUFH0JijLpS6GukWokDW+9xo+SU KXoA==
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=YN8c0IQcyBFeAQUE2rv5XCZlybrzzTxx2/67vytlp+Y=; b=doVHs+wc85pm1GxuKyOYZXsZzuJ9ef650ywkDnCmglQUsvKtYP2OdQzmVqtuMJqhdT 5k+JLAHihfJuusmrk37Tj9fFz/nKXYPNR/1S53gaVtq0AF/3RaELIZ7TWOM/19uRpDhQ LAck+ACJbEdlqbqbLF8vsEOBYcuhNgygMKzvRRfXuzAE+WP6kzaneqwmyHNCio5kmMch Sd2ko0OKRSd0QI29ygThJg20Af7ohqU9Q91vwSE+p5qElSr0GCmUcg4RTT3G3TDucMUp drFFQ8mDhRZAwCfOqjzXD2w/ZZs/KAzoB3o5P0WDxF9juNpQ97N3TIZfop0wD0d5TgUs blBw==
X-Gm-Message-State: AA6/9Rlnh4kkm7cBGujD3eaaj04kAmHs/Uw7GzP7NNASscJeyQgvMyofUFnfLu8t3v7jGWwHl7sRZtGh8cN92A==
X-Received: by 10.31.151.78 with SMTP id z75mr151311vkd.41.1475531193901; Mon, 03 Oct 2016 14:46:33 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.176.4.102 with HTTP; Mon, 3 Oct 2016 14:46:32 -0700 (PDT)
Received: by 10.176.4.102 with HTTP; Mon, 3 Oct 2016 14:46:32 -0700 (PDT)
In-Reply-To: <CACsn0cnwZW1xeG8QOXOfog4tPRESry3Z4P2B8z51NMFBYCW6qA@mail.gmail.com>
References: <DM5PR11MB1419B782D2BEF0E0A35E420DF4C90@DM5PR11MB1419.namprd11.prod.outlook.com> <CO1PR07MB283F2C414B6478E993675DEC3C90@CO1PR07MB283.namprd07.prod.outlook.com> <394611bf-208f-03d3-620c-79aaf169645b@cs.tcd.ie> <4FC37E442D05A748896589E468752CAA0DBC66AE@PWN401EA120.ent.corp.bcbsm.com> <CAH8yC8kgYzYXwJ01NkK7WYxD-diponWEQOd+MNHssm+bLHE54w@mail.gmail.com> <4FC37E442D05A748896589E468752CAA0DBC699B@PWN401EA120.ent.corp.bcbsm.com> <CACsn0c=5vjzQmr=ah6sH1JzTj3peaKad7aCPertcqD4B2DLKiA@mail.gmail.com> <DM5PR11MB141941D8E156245A1CF6C911F4C80@DM5PR11MB1419.namprd11.prod.outlook.com> <126ee1b6-fc88-bf4e-c366-60d59a9b3350@gmail.com> <DM5PR11MB1419F8F0D0C80835C1DB49F2F4C80@DM5PR11MB1419.namprd11.prod.outlook.com> <CAK6vND_S-YRfY5mpvt_v_srNhdvYJkM8pVV84bywr9zMaYoE6A@mail.gmail.com> <DM5PR11MB1419620B8BA15C7780F60669F4CD0@DM5PR11MB1419.namprd11.prod.outlook.com> <CAHOTMVLv7F3-ZuKM+35eL-tOtr8ee-1gqwYy+9zQu2GKrsXkjQ@mail.gmail.com> <DM5PR11MB141951D29143A6785089FC5CF4C20@DM5PR11MB1419.namprd11.prod.outlook.com> <CACsn0cnwZW1xeG8QOXOfog4tPRESry3Z4P2B8z51NMFBYCW6qA@mail.gmail.com>
From: Watson Ladd <watsonbladd@gmail.com>
Date: Mon, 03 Oct 2016 14:46:32 -0700
Message-ID: <CACsn0cnG=A+28nEcheSxSvSL4ZFyqjnC5SsKqa5rU7cbfCzGtQ@mail.gmail.com>
To: BITS Security <BITSSecurity@fsroundtable.org>
Content-Type: multipart/alternative; boundary="001a1140e662aae9c7053dfce086"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/RfMv5nPTWkIrDWtoazY42xx3alI>
Cc: 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: Mon, 03 Oct 2016 21:46:40 -0000

>
> If you look at the industry reports like the Verizon PCI Breach and
Compliance Reports, private keys simply aren't being stolen.  Maybe there
is an outlier or two but there certainly isn't a documented trend I can
find.  If you have contravening information to provide I am all ears.

Surely you remember the day when all SWIFT provided devices had to be
replaced thanks to some fun in the random number generators. Then there is
POISON NUT.

The Shadow brokers leak included tools to extract VPN keys from Cisco
routers. TJ Maxx involved breaking WEP.

>
> - Andrew
>
>
>
> From: Tony Arcieri [mailto:bascule@gmail.com]
> Sent: Tuesday, September 27, 2016 4:17 PM
> To: BITS Security <BITSSecurity@fsroundtable.org>
> Cc: Peter Bowen <pzbowen@gmail.com>; tls@ietf.org
> Subject: Re: [TLS] Industry Concerns about TLS 1.3
>
> On Mon, Sep 26, 2016 at 12:01 PM, BITS Security <
BITSSecurity@fsroundtable.org> wrote:
> The PCI DSS is already requiring TLS 1.2 for financial institutions that
participate in the Payment Card Industry.  .BANK (exclusive top level
banking domain) is also planning to require TLS 1.2.   We're anticipating
that a regulatory body like these will require TLS 1.3 at some point in the
future.  Financial institutions then have to comply if they want to
continue to do business with the companies represented by the regulatory
body (like large credit card companies in the case of PCI).
>
> Hello again,
>
> I work firsthand enforcing these requirements at a payments company.
Again, I do not speak on behalf of my employer.
>
> It wasn't until last year that PCI decided to deprecate TLS 1.0, at the
time a 16 year old standard. I think your sense of emergency is highly
over-exaggerated.
>
> I find it highly unlikely that any group such as the PCI Council will
begin mandating TLS 1.3 any time soon. I would go as far as to call your
concerns "imaginary".
>
> If you are worried about such an eventuality, the IETF is the wrong place
to complain. It is far, far too late in the TLS 1.3 process to be voicing
these concerns. Where were you 2+ years ago when it was the appropriate
time in the TLS development cycle to voice such concerns? I think the view
of more "forward thinking" payments companies is TLS 1.3 has taken too long
already, and they would like to start deploying it in its current form and
would prefer unnecessary holdups/distractions which have already occurred
throughout the process.
>
> That said, there is still plenty of time to ensure that groups like the
PCI Council do not put in place requirements which would affect the
centralized traffic-decrypting MitM-capability on your payments stack.
Perhaps you should be voicing your concerns there? If you are worried about
a TLS 1.3 mandate preventing your MitM capability, the onus is on you to
convince the relevant payments standards bodies that mandating TLS 1.3 is a
bad idea for the payments industry. I think those organizations are better
poised to judge whether such an approach reflects on necessary requirements
versus pervasive antipatterns among complacent companies unprepared for the
future and ripe for a data breach.
>
> In the meantime, you have disclosed a veritable treasure map to a
traffic-decrypting single point of failure which ostensibly exists at all
of the companies you represent which attackers could leverage to recover
all payment credentials. That sounds like a huge security threat.
>
> Would you mind disclosing which companies you represent, so I can ensure
for the safety of my own money that I do not use them?
>
> --
> Tony Arcieri
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls