Re: [TLS] WG adoption: draft-nir-tls-rfc4492bis

Yoav Nir <> Tue, 11 November 2014 09:58 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 112981A86F6 for <>; Tue, 11 Nov 2014 01:58:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ICTQYtZsZ_yY for <>; Tue, 11 Nov 2014 01:58:46 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400e:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6ADCE1A1B47 for <>; Tue, 11 Nov 2014 01:58:46 -0800 (PST)
Received: by with SMTP id bj1so10337455pad.31 for <>; Tue, 11 Nov 2014 01:58:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=VDFMe9RUWJ706ys9BYMQz9kb143MDrQPeuzU5au4yUY=; b=mCpRNedhDANDaYgJQ8hZWSshY1pO/H+7NMP7apuW2GKzWRIc716wo3XxVzudUn4yZc lcwsCkI8k4vdlZt3HVI1yUW/RK9RrZkc/0q9i/INpv4OxJMw93RZeNP9xTLzRIRRhTrf wWhRkTi1wqovk6tRS4j0n8j6O3e82QmVclanqVzKSIkYs3U+I5RjA9onKlOzy57SeuoH /2KrWWmPhOo7MtfLUICdhOFxXSyLRNFHrRe1cpcf3cs2ud4kSDnMR4/4uPJBH17COzx3 DAYyRXwSfb0aPGq4PIBkKpwowifftyx1gJr6T0zHVs71cn4+peYITs4GfcUeSpwnb7J8 WwQw==
X-Received: by with SMTP id rb10mr9049431pab.146.1415699925599; Tue, 11 Nov 2014 01:58:45 -0800 (PST)
Received: from [] ([]) by with ESMTPSA id ce4sm8033470pbc.78.2014. for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 11 Nov 2014 01:58:44 -0800 (PST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\))
From: Yoav Nir <>
In-Reply-To: <>
Date: Mon, 10 Nov 2014 23:58:38 -1000
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <>
To: Nikos Mavrogiannopoulos <>
X-Mailer: Apple Mail (2.1990.1)
Cc: " (" <>
Subject: Re: [TLS] WG adoption: draft-nir-tls-rfc4492bis
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: Tue, 11 Nov 2014 09:58:50 -0000

> On Nov 10, 2014, at 11:00 PM, Nikos Mavrogiannopoulos <> wrote:
> On Mon, 2014-11-10 at 17:17 -1000, Sean Turner wrote:
>> All,
>> This message is confirming the WG consensus we reached in Toronto about producing an updated RFC4492 that is bound for standard track.* Yoav has produced an individual draft that can be found here:
>> that we would like the WG to consider adopting.  Please let us know by November 18th whether you object to adopting Yoav’s draft (and why).
> Two points:
> 1. This document includes fixed ECDH ciphersuites (ECDH_RSA,
> ECDH_ECDSA). Given they have 0 deployment on the internet, the question
> is why? What are the practical use cases of these ciphersuites and why
> should they be defined in a standards track document.
> 2. This document includes arbitrary curve support. What is the rationale
> for including that as no implementations support that [0], and even for
> DH we are switching from arbitrary to named groups as well (I also
> ignore the known attacks for this option).
> Unless there is sufficient argumentation and applicability for the
> above, I support the document only with the above removed.

Hi, Nikos

The current draft is pretty much a copy of RFC 4492. The intent is to match whatever decision the WG will make for TLS 1.3.

So the changes that you suggest will be made after the document is adopted (either in the -00 or -01 version, whichever way the chairs prefer it). 

Following Sunday’s interim, we’re also likely to remove all the defined curves weaker than P-256 (or maybe P-224 to match the strength of 3DES, although I’m not in favor)

We are also likely to deprecate point format negotiation. We won’t remove it for TLS 1.2, just mandate non-compressed format for existing curves)

And when CFRG recommends a new curve, we will add it to this one.

So this document is in no way in its final form.

The question before the working group now is whether we want such a document that obsolete 4492 and aligns EC for TLS 1.2 with what we want for 1.3, or if we don’t.

Hope this clarifies the situation