Re: [TLS] Industry Concerns about TLS 1.3

Watson Ladd <watsonbladd@gmail.com> Tue, 27 September 2016 19:50 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 BE14812B346 for <tls@ietfa.amsl.com>; Tue, 27 Sep 2016 12:50:04 -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 5hD5F6sZfPFN for <tls@ietfa.amsl.com>; Tue, 27 Sep 2016 12:50:02 -0700 (PDT)
Received: from mail-vk0-x234.google.com (mail-vk0-x234.google.com [IPv6:2607:f8b0:400c:c05::234]) (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 B146112B01D for <tls@ietf.org>; Tue, 27 Sep 2016 12:50:02 -0700 (PDT)
Received: by mail-vk0-x234.google.com with SMTP id z126so23929243vkd.0 for <tls@ietf.org>; Tue, 27 Sep 2016 12:50:02 -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=h70FJ6znM/DcMR+7nPjZTQg7saMckl896miIGsdwxYc=; b=S8kcjbu3bIHF64+bUz7IsfRfu20cTbDYtCHdRnRjvASqnOUXVHe3Cwc4MhtheA06xh RLJBcU8EQ5N4O/hAhy5EypEZuojr5IoErme55hJ5FB/YZ9aV5kqIO/BUXl0ceSLeU0L/ Gmbqhwh/coiWkfNHaoh7YivXNVBg4NXuOQuZtk37zob+YyUMpBN7HxXCs9UrvXQ4wRLj oz7pG1UYnjN/KmQHrWN+1EH90cuKhlwCFdfZj/0A+t01ISIoXRUFcQuPOlFq1kjUGrl4 0z8ibvKbBxt5sz55uAAQY/W9lhOV5f7Tw+miEeth/6RHRRmEy5QnJoI+s8uvc3MHlfWP NQQw==
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=h70FJ6znM/DcMR+7nPjZTQg7saMckl896miIGsdwxYc=; b=PSnXMi21FYGx585V9m+jF6La5qbw+4IzzO74iw9+YBoLi2+Y7MafEugxeksNEldWyU /b6tqINzdWNqaQWdt4ccidhpvBrKFKqKINCZQ83LR246iAEfGWmNEiF2EGg2OllMa/Rw H0RpvKYptXTBWfaBaHu39IKL4BbIEB1njT+zkW6r+nDWBv0LtEs89EVdwDTIZbUy85qp GdUs+ArYLZbK6H1ZviqWIgThleI+vSp9t/2YhnINx+UBFMXbja3w4sOeVdUdFIR/moo8 +HlgBCiu5LCfnM4XCvOa3TuSSn2I8a/tHTPHf5Y2vt13DHDx9Ib1sDIiLGP664zf0o6D kJlw==
X-Gm-Message-State: AA6/9RmUjfiidAMcrQJyadb3eQwwTsnkaYYO1gQwR3ZCJC9mniitK6QkWUcm8LqYvBCPh+AsJ/XGjSQVbcWN8Q==
X-Received: by 10.31.163.134 with SMTP id m128mr14120443vke.70.1475005801815; Tue, 27 Sep 2016 12:50:01 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.176.4.102 with HTTP; Tue, 27 Sep 2016 12:49:59 -0700 (PDT)
Received: by 10.176.4.102 with HTTP; Tue, 27 Sep 2016 12:49:59 -0700 (PDT)
In-Reply-To: <DM5PR11MB1419982941ECB14040873E6AF4CC0@DM5PR11MB1419.namprd11.prod.outlook.com>
References: <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> <72011214.413503.1474650126973@mail.yahoo.com> <e24a06b8d0d04ccc80b9a55d83bf5606@usma1ex-dag1mb1.msg.corp.akamai.com> <DM5PR11MB141926C5806296FFD7252A45F4C80@DM5PR11MB1419.namprd11.prod.outlook.com> <CABcZeBNCoB6hd-c-x8tzT3k7ZFKs85NS04Fs-_CO+U4YZ-WjQg@mail.gmail.com> <DM5PR11MB1419BC83C76834E7C0CC0B7CF4CC0@DM5PR11MB1419.namprd11.prod.outlook.com> <20160927182409.GA26653@LK-Perkele-V2.elisa-laajakaista.fi> <DM5PR11MB1419982941ECB14040873E6AF4CC0@DM5PR11MB1419.namprd11.prod.outlook.com>
From: Watson Ladd <watsonbladd@gmail.com>
Date: Tue, 27 Sep 2016 12:49:59 -0700
Message-ID: <CACsn0c=zviCEtdCfoLjd0pn1R3RCw4aDH2SYW1jbszBDVQeezw@mail.gmail.com>
To: BITS Security <BITSSecurity@fsroundtable.org>
Content-Type: multipart/alternative; boundary=001a1142d3c4dbf45d053d828c9a
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/JTgUMq3qzo8UBRGgmwB-CSfbdJI>
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: Tue, 27 Sep 2016 19:50:05 -0000

On Tue, Sep 27, 2016 at 11:34 AM, BITS Security <
BITSSecurity@fsroundtable.org>; wrote:
> Ilari - I understand yours (and others) view on this but there is no
technical reason why this couldn't be part of the standard. A potential
solution, like many cipher suite *choices* in past versions of TLS, would
be optional and up to both clients and servers to configure what they are
willing to support (or not support). You appear to be assuming everyone is
running off the same set of requirements (one-size-fits-all) and we are
here to tell you that isn't necessarily true.

Why does the TLS 1.3 document need to include this, as opposed to a
separate extension? I do think you are ignoring the very real weaknesses
your network architecture has: any user account with the ability to decrypt
TLS sessions networkwide can easily be a jumping off point for total
ownage. Many authentication solutions depend on TLS traffic being secure.

Sincerely,
Watson Ladd
>
> - Andrew
>
>
>
>
> -----Original Message-----
> From: ilariliusvaara@welho.com [mailto:ilariliusvaara@welho.com]
> Sent: Tuesday, September 27, 2016 2:24 PM
> To: BITS Security <BITSSecurity@fsroundtable.org>;
> Cc: Eric Rescorla <ekr@rtfm.com>;; tls@ietf.org
> Subject: Re: [TLS] Industry Concerns about TLS 1.3
>
> On Tue, Sep 27, 2016 at 06:07:28PM +0000, BITS Security wrote:
>> Hi Eric--Thank you for the prompt.
>>
>> Our requirements are for the same capabilities we have today with TLS
>> 1.2, namely to be able to take a trace anywhere in our enterprise and
>> decrypt it out of band (assuming that we own the TLS server). This
>> includes traces taken from physical taps, traces from span or mirror
>> ports, traces from the virtual environment, and/or traces from agents
>> on workstations. We need to be able to apply a key to sniffer
>> devices, security and fraud monitoring tools, APM devices, and/or TLS
>> decryption appliances.
>
> No changes to standards are going to happen to make that any easier.
> Don't waste your time.
>
>
> -Ilari
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

-- 
"Man is born free, but everywhere he is in chains".
--Rousseau.