Re: [TLS] TLS Charter Revision

"Salz, Rich" <rsalz@akamai.com> Fri, 13 December 2013 14:06 UTC

Return-Path: <rsalz@akamai.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEC091AE285 for <tls@ietfa.amsl.com>; Fri, 13 Dec 2013 06:06:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham
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 mp4sp8sl4kM5 for <tls@ietfa.amsl.com>; Fri, 13 Dec 2013 06:06:10 -0800 (PST)
Received: from prod-mail-xrelay08.akamai.com (prod-mail-xrelay08.akamai.com [96.6.114.112]) by ietfa.amsl.com (Postfix) with ESMTP id A9B371AD6BF for <tls@ietf.org>; Fri, 13 Dec 2013 06:06:08 -0800 (PST)
Received: from prod-mail-xrelay08.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id F1C63482C0; Fri, 13 Dec 2013 14:06:01 +0000 (GMT)
Received: from prod-mail-relay03.akamai.com (prod-mail-relay03.akamai.com [172.27.8.26]) by prod-mail-xrelay08.akamai.com (Postfix) with ESMTP id E5232482BC; Fri, 13 Dec 2013 14:06:01 +0000 (GMT)
Received: from usma1ex-cashub.kendall.corp.akamai.com (usma1ex-cashub7.kendall.corp.akamai.com [172.27.105.23]) by prod-mail-relay03.akamai.com (Postfix) with ESMTP id C65FE2FD51; Fri, 13 Dec 2013 14:06:01 +0000 (GMT)
Received: from USMBX1.msg.corp.akamai.com ([169.254.1.14]) by usma1ex-cashub7.kendall.corp.akamai.com ([172.27.105.23]) with mapi; Fri, 13 Dec 2013 09:06:01 -0500
From: "Salz, Rich" <rsalz@akamai.com>
To: Eric Rescorla <ekr@rtfm.com>
Date: Fri, 13 Dec 2013 09:06:00 -0500
Thread-Topic: [TLS] TLS Charter Revision
Thread-Index: Ac73ohcPHm+8nAS4TCKUmzXBUPZLqwAag0Gw
Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C711E4675369@USMBX1.msg.corp.akamai.com>
References: <2F2286E3-7717-4E8F-B1EA-B2E4155F7C17@cisco.com> <CACsn0ckzA9hd3+zTH5FNNBbPAQqUqaXD8_Z35a8vKEG6WjXbTg@mail.gmail.com> <53edda7bf2804289817f54a8c2ecce33@BY2PR03MB074.namprd03.prod.outlook.com> <2A0EFB9C05D0164E98F19BB0AF3708C711E42D63D8@USMBX1.msg.corp.akamai.com> <CABcZeBNPWZfnO4vdB9gbpf8nU9E5R=PO+gcsY9Vy6qxFukYPBg@mail.gmail.com>
In-Reply-To: <CABcZeBNPWZfnO4vdB9gbpf8nU9E5R=PO+gcsY9Vy6qxFukYPBg@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "<tls@ietf.org>" <tls@ietf.org>
Subject: Re: [TLS] TLS Charter Revision
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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, 13 Dec 2013 14:06:15 -0000

On Thu, Dec 12, 2013 at 11:22 PM, Salz, Rich <rsalz@akamai.com>; wrote:
> I agree with Marsh that PFS should be included.

> Can you elaborate more on this? TLS already supports PFS, so are you arguing we should maintain that support or that we should strip out all non-PFS cipher suites (see the thread on static RSA...)

I think we should have an explicit discussion point if PFS is a MUST or a SHOULD.

>> I would like to add a bullet that says backward compatibility with previous  versions is not a requirement. Given all that downgrade fallback issues that continually arise here, we should strongly consider if the right thing to do is just break the chain.

> I think this is actually backwards: it's precisely having some sort of secure backward negotiation that allows for clean deployment. The problem is that people have screwed up those mechanisms. If we just do a clean break there is no chance that secure version detection will work.

So do we think the problem will be solved this time around?  I don't know, so I guess it goes into the discussion threads.

	/r$

--
Principal Security Engineer
Akamai Technology
Cambridge, MA