Re: [TLS] TLS Charter Revision
Nikos Mavrogiannopoulos <nmav@redhat.com> Wed, 04 December 2013 09:14 UTC
Return-Path: <nmav@redhat.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 236A31AE211 for <tls@ietfa.amsl.com>; Wed, 4 Dec 2013 01:14:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.903
X-Spam-Level:
X-Spam-Status: No, score=-6.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-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 0yUMHoQ2-JAc for <tls@ietfa.amsl.com>; Wed, 4 Dec 2013 01:14:22 -0800 (PST)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by ietfa.amsl.com (Postfix) with ESMTP id 7C94B1AE0D9 for <tls@ietf.org>; Wed, 4 Dec 2013 01:14:22 -0800 (PST)
Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id rB49ECWS032335 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 4 Dec 2013 04:14:12 -0500
Received: from [10.10.62.181] (vpn-62-181.rdu2.redhat.com [10.10.62.181]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id rB49EAog030629 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 4 Dec 2013 04:14:11 -0500
Message-ID: <1386148449.2047.57.camel@aspire.lan>
From: Nikos Mavrogiannopoulos <nmav@redhat.com>
To: "Joseph Salowey (jsalowey)" <jsalowey@cisco.com>
Date: Wed, 04 Dec 2013 10:14:09 +0100
In-Reply-To: <2F2286E3-7717-4E8F-B1EA-B2E4155F7C17@cisco.com>
References: <2F2286E3-7717-4E8F-B1EA-B2E4155F7C17@cisco.com>
Organization: Red Hat
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24
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: Wed, 04 Dec 2013 09:14:24 -0000
On Mon, 2013-12-02 at 19:23 +0000, Joseph Salowey (jsalowey) wrote: > o Develop a mode that encrypts as much of the handshake as > is possible to reduce the amount of observable data to > both passive and active attackers. I'd phrase that differently. I believe what we want to achieve is to protect the identity of the participants, as well as the purpose of connection (service), from passive (and if possible) from active attackers. That gives a purpose to the goal (encrypting stuff is good, but doesn't explain why we need that). > o Reevaluate record payload protection cryptographic > mechanisms and algorithms to address known weaknesses > in RC4 and the CBC block cipher modes. I think this contains two completely different issues. I'd split it into * Replace RC4 with a known to be secure stream cipher * Fix the known weaknesses in the CBC block cipher mode. (I'm not so strong about the splitting, but given the existing work on the topic the word Re-evaluate seems to be suggesting a further delay. There is nothing to evaluate in the RC4 issue - it is broken, and we already have more than one suggested solutions for the CBC issue) Moreover this goal is not reflected in the milestones. Given the work that is already there I'd expect to have these two points completed not later than the beginning of 2014. Except with the two points above, I agree with the charter revision. regards, Nikos
- [TLS] TLS Charter Revision Joseph Salowey (jsalowey)
- Re: [TLS] TLS Charter Revision Daniel Kahn Gillmor
- Re: [TLS] TLS Charter Revision Watson Ladd
- Re: [TLS] TLS Charter Revision Marsh Ray
- Re: [TLS] TLS Charter Revision Watson Ladd
- Re: [TLS] TLS Charter Revision Trevor Perrin
- Re: [TLS] TLS Charter Revision Nikos Mavrogiannopoulos
- Re: [TLS] TLS Charter Revision Martin Thomson
- Re: [TLS] TLS Charter Revision Mohamad Badra
- Re: [TLS] TLS Charter Revision Stephen Farrell
- Re: [TLS] TLS Charter Revision Joseph Salowey (jsalowey)
- Re: [TLS] TLS Charter Revision Yaron Sheffer
- Re: [TLS] TLS Charter Revision Stephen Farrell
- Re: [TLS] TLS Charter Revision Yoav Nir
- Re: [TLS] TLS Charter Revision Hovav Shacham
- Re: [TLS] TLS Charter Revision Salz, Rich
- Re: [TLS] TLS Charter Revision Michael Sweet
- Re: [TLS] TLS Charter Revision Patrick McManus
- Re: [TLS] TLS Charter Revision Michael Sweet
- Re: [TLS] TLS Charter Revision Eric Rescorla
- Re: [TLS] TLS Charter Revision Salz, Rich
- Re: [TLS] TLS Charter Revision Watson Ladd
- Re: [TLS] TLS Charter Revision Brian Smith
- Re: [TLS] TLS Charter Revision Salz, Rich
- Re: [TLS] TLS Charter Revision Marsh Ray
- Re: [TLS] TLS Charter Revision Joseph Salowey (jsalowey)
- Re: [TLS] TLS Charter Revision Rene Struik
- Re: [TLS] TLS Charter Revision Sean Turner