Re: [TLS] Industry Concerns about TLS 1.3

Adam Caudill <adam@adamcaudill.com> Fri, 23 September 2016 22:19 UTC

Return-Path: <adam@adamcaudill.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 CA42312B5B2 for <tls@ietfa.amsl.com>; Fri, 23 Sep 2016 15:19:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level:
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=adamcaudill.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 i0kYVByAHvtY for <tls@ietfa.amsl.com>; Fri, 23 Sep 2016 15:19:22 -0700 (PDT)
Received: from mail-vk0-x235.google.com (mail-vk0-x235.google.com [IPv6:2607:f8b0:400c:c05::235]) (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 E088812B3E8 for <tls@ietf.org>; Fri, 23 Sep 2016 15:19:21 -0700 (PDT)
Received: by mail-vk0-x235.google.com with SMTP id 192so3113591vkl.2 for <tls@ietf.org>; Fri, 23 Sep 2016 15:19:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=adamcaudill.com; s=google; h=subject:mime-version:from:in-reply-to:date:cc:message-id:references :to; bh=zz9rPs3kKNT/zNSlx5ZAc3lezH830mUKOwjORR9Vwfw=; b=Gnhhem+u0v30mAAAhio+/u5Lk/00UrXUw6ZmIPagmP/2ax6PQw6mLT+7Z8XFxRmPPw Xgh33jjqxknyGTT/5zjrd4U/NqdJXcabw940bLEXUPQD3av5BhOzbTUP/qNmkF9B2k/T byNUXzophWPfp1oF6r9brI/ca5AykGi+pzanY=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:mime-version:from:in-reply-to:date:cc :message-id:references:to; bh=zz9rPs3kKNT/zNSlx5ZAc3lezH830mUKOwjORR9Vwfw=; b=XhSX7gR1xUgq1pHjN1/NXR04HG5+WCbR3r8XZ1+J4j+77s2zYRab5th9xW65C0nvaI 5SGbri1utBofpTnBvEgi1xl+f2mP8lA4VNULRw/BHT7cr0vUwDcpk4LNPP1TQzpwE06x 1ov1pN7ACZvd2uvAU/qRukQfSgvZQAxGGy0I57ozlhITHBvTQJn8cmcp5dbT5VJklThv iS0XSresqZO1p87iBiZUN2wAedu5RtThTBpf1TXFFlEnfdCZK4Sy+rymbMVOqultimud rCieRSJVN5EDfPl2co3Z9HACNHJpbluohH9lb6kD5vUReGbTHehv3P5ljENicLUUq+oZ /GTQ==
X-Gm-Message-State: AA6/9RntnBrDkmnJkzjm2hTf4ITKR9MaTnsfEUaFI0o5cjHsaPXFB6D2dqgdruq6pzfZTA==
X-Received: by 10.31.94.198 with SMTP id s189mr496430vkb.168.1474669161002; Fri, 23 Sep 2016 15:19:21 -0700 (PDT)
Received: from [10.0.0.196] (c-66-177-183-93.hsd1.fl.comcast.net. [66.177.183.93]) by smtp.gmail.com with ESMTPSA id r1sm127704vkf.28.2016.09.23.15.19.19 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 23 Sep 2016 15:19:19 -0700 (PDT)
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
Content-Type: multipart/signed; boundary="Apple-Mail=_EE63164F-976C-4B0A-BB3A-807FB12D053E"; protocol="application/pgp-signature"; micalg="pgp-sha512"
X-Pgp-Agent: GPGMail
From: Adam Caudill <adam@adamcaudill.com>
In-Reply-To: <DM5PR11MB1419384BB86D2C5F791DD1A1F4C80@DM5PR11MB1419.namprd11.prod.outlook.com>
Date: Fri, 23 Sep 2016 18:19:18 -0400
Message-Id: <7E84BA2B-EF2B-4B92-BAEF-54FABB5CE9E4@adamcaudill.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> <72011214.413503.1474650126973@mail.yahoo.com> <e24a06b8d0d04ccc80b9a55d83bf5606@usma1ex-dag1mb1.msg.corp.akamai.com> <DM5PR11MB141926C5806296FFD7252A45F4C80@DM5PR11MB1419.namprd11.prod.outlook.com> <CY1PR15MB0778E06B122413B7D0C9E796FFC80@CY1PR15MB0778.namprd15.prod.outlook.com> <DM5PR11MB1419384BB86D2C5F791DD1A1F4C80@DM5PR11MB1419.namprd11.prod.outlook.com>
To: BITS Security <BITSSecurity@fsroundtable.org>
X-Mailer: Apple Mail (2.3112)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/KeMcl8IJT7eh3WX_ViqFekXUFK4>
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 22:19:24 -0000

Andrew,

You are requesting a major design change at the last minute, to restore a problematic feature that was removed due to its negative security impact. You should understand from the beginning that this is an extreme request. Moreso, you should understand that others in your industry have no problem complying with US and international regulations, while using PFS cipher suites.

I am personally aware of two of the largest financial organizations in the US that actually require PFS suites for all internal and external applications, and use endpoint security applications to handle this issue. It may not be as convenient as what you are doing now, but it is a problem that has already been solved, and solved effectively.

Before claiming that the IETF is eliminating your choice, you may want to take a closer look at how those your industry have already dealt with this. There are effective solutions that have already been mentioned, that don’t involve reducing the security of every TLS user around the globe.

Personally, I agree completely with Kenny’s response - the answer is simply no. It’s too large of a change, it has too large of a security impact, and there are established solutions to address your issues.

--
Adam Caudill
adam@adamcaudill.com
http://adamcaudill.com/


> On Sep 23, 2016, at 5:34 PM, BITS Security <BITSSecurity@fsroundtable.org> wrote:
> 
>> you can keep using TLS1.2 in your internal network, can't you?
> 
> There are both public and private sector regulators arcing towards being more prescriptive in this area.  It is possible, if not likely, in the not too distant future that my member companies will not have the choice to "downgrade" to "obsolete" TLS versions.
> 
> Note: the standards track document says it "Obsoletes: RFC 5246" which is TLS 1.2.  That's a signal that may prove difficult to divert in this rapidly evolving threat and regulatory environment.
> 
> - Andrew
>