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

Stephen Checkoway <> Thu, 27 November 2014 16:16 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 697A61A00D1 for <>; Thu, 27 Nov 2014 08:16:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Q7Ihwucc43Gf for <>; Thu, 27 Nov 2014 08:16:04 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8D6F31A00BD for <>; Thu, 27 Nov 2014 08:16:04 -0800 (PST)
Received: by with SMTP id s7so3422672qap.22 for <>; Thu, 27 Nov 2014 08:16:03 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=ecWLAWWdbaxKGqlmhPloNyZ48Oz0qBUF+4ibJsCvZ0Y=; b=gzjJXtkX7HD1+Co/q1NycQQgYVZ20OjzztNWFZwMYqwuLrwFyWkJftW82LGt8sSVPf 4Vf9p2wki7mvU9RAagKvC4jDQmD1HaWCDQz/PIxZLWlCfRKsUh81DuryGLa/cXbDBMV/ 4T4DzkrdIegXyLUQuqCDACa2iKY1xV1v96UOwjPT2vn1xB9vy1J0TuuV+NUi5LYen7U/ WoeHnKKG45qGKGyN190pbVZpXGDa19lF+dKUYx8hXoaasu6bQzEL0GlEE/ucGIIkHZHY WNVIZCwASoBFJRUM3Cn3HY3SrYgWqPC+UYiS7EECu3wz5WFc5N4zRrp3H7E1gQqaMdVp SDJQ==
X-Gm-Message-State: ALoCoQkbWj2VkOG4N7QJs9/vZCoqQt9eaot2Xw99vfEaAOyQXCz6wK41luozC3tad7iOmh/IMi09
X-Received: by with SMTP id d6mr53613579qga.104.1417104963846; Thu, 27 Nov 2014 08:16:03 -0800 (PST)
Received: from ([]) by with ESMTPSA id s2sm6894531qan.29.2014. for <multiple recipients> (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 27 Nov 2014 08:16:02 -0800 (PST)
Received: from [] ( []) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id B6009AC2896; Thu, 27 Nov 2014 11:16:00 -0500 (EST)
Content-Type: text/plain; charset="windows-1252"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Stephen Checkoway <>
In-Reply-To: <>
Date: Thu, 27 Nov 2014 11:15:59 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <>
To: Yoav Nir <>
X-Mailer: Apple Mail (2.1878.6)
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: Thu, 27 Nov 2014 16:16:06 -0000

On Nov 27, 2014, at 3:13 AM, Yoav Nir <> wrote:

> Seeing as the 18th has come and gone, can I take the near silence as confirmation that I can resubmit as a WG draft?

I support adopting this draft.

Maybe this isn't the right time to ask, but I think I'm misunderstanding a part of it.

   Note that while the ECDH_ECDSA, ECDHE_ECDSA, ECDH_RSA, and ECDHE_RSA
   key exchange algorithms require the server's certificate to be signed
   with a particular signature scheme, this specification (following the
   similar cases of DH_DSS, DHE_DSS, DH_RSA, and DHE_RSA in the TLS base
   documents) does not impose restrictions on signature schemes used
   elsewhere in the certificate chain.

Why should we require that the certificate be signed with the signature scheme corresponding to the public key? It's easy to produce working certificates that don't meet this:

$ openssl genrsa -out ca.key 2048
$ openssl req -new -x509 -days 2 -key ca.key -out ca.crt -sha256

$ openssl ecparam -out server.key -name prime256v1 -genkey
$ openssl req -new -sha256 -key server.key -out server.csr
$ openssl x509 -req -in server.csr -CA ca.crt -CAkey ca.key -out server.crt -days 1 -sha256 -CAserial ca.seq -CAcreateserial

Now I have a cert with a P-256 public key that is signed with signature algorithm sha256WithRSAEncryption. That is, this does not meet the MUSTs in your draft.

Using openssl s_server and s_client, I get a connection using ECDHE-ECDSA-AES256-GCM-SHA384.

Is my reading correct that this is disallowed by the draft? If so, can you explain why that's the case?

Stephen Checkoway