Re: [TLS] TLS Charter Revision

Nikos Mavrogiannopoulos <> Wed, 04 December 2013 09:14 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 236A31AE211 for <>; Wed, 4 Dec 2013 01:14:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.903
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 0yUMHoQ2-JAc for <>; Wed, 4 Dec 2013 01:14:22 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 7C94B1AE0D9 for <>; Wed, 4 Dec 2013 01:14:22 -0800 (PST)
Received: from ( []) by (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 [] ( []) by (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 <>
To: "Joseph Salowey (jsalowey)" <>
Date: Wed, 04 Dec 2013 10:14:09 +0100
In-Reply-To: <>
References: <>
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
Cc: "<>" <>
Subject: Re: [TLS] TLS Charter Revision
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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.