Re: [TLS] Review of draft-ietf-tls-rfc4492bis-15

Stephen Farrell <> Wed, 15 March 2017 15:07 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 96D1313162B; Wed, 15 Mar 2017 08:07:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.301
X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id B30DIquWdn_W; Wed, 15 Mar 2017 08:07:14 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id AC2B1131610; Wed, 15 Mar 2017 08:07:14 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id CBDEDBE39; Wed, 15 Mar 2017 15:07:11 +0000 (GMT)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id HeqYeGQwofr9; Wed, 15 Mar 2017 15:07:11 +0000 (GMT)
Received: from [] ( []) by (Postfix) with ESMTPSA id 23197BE2F; Wed, 15 Mar 2017 15:07:11 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=mail; t=1489590431; bh=mqArW1VZZEcI9N3Gtu4nN3hDaNMjjkKNHGk/GTaPR10=; h=Subject:To:References:From:Date:In-Reply-To:From; b=MLqkDSJqk6bNm82K7LzmjEb5MvOClMNddPFTlvpJsOimj54L7shH4ox5PEIHTj6TA J6m3EGj/I7eKqYB6u8Y+I9/oXExdxUbHOFraUuWBIJ5A80BXYGLoN3K6tHBZEt9RY9 q7j8mlcSK94cdGxMeLsrlzJat2TpG95Lk/bP+COA=
To: Eric Rescorla <>, "" <>, IESG <>
References: <>
From: Stephen Farrell <>
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Message-ID: <>
Date: Wed, 15 Mar 2017 15:07:10 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="dpWIsnh6UuieFkbNcQX2eMpxDDL0vff1I"
Archived-At: <>
Subject: Re: [TLS] Review of draft-ietf-tls-rfc4492bis-15
X-Mailman-Version: 2.1.22
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, 15 Mar 2017 15:07:18 -0000

Thanks Eric,

Let's see what folks say in response to this and I can post
anything not immediately resolved as a DISCUSS ballot. We
can then process that in the coming week or two, and you
can take over the DISCUSS for whatever's not resolved by
the swap-over in Chicago. Or if someone else wants to
make some or all of Eric's comments a DISCUSS that'd work
too, but I'm fine with taking it.


On 15/03/17 14:44, Eric Rescorla wrote:
> Sorry for the late review of this document. I just got to it this
> week. I'm sending this as comments rather than issues/PR due to
> how late it is in the proces.
> I have two high-level comments:
> - This document seems to still have a bunch of material about
>   static DH (especially static DH authentication). I thought we
>   had agreed to remove that.
> - You are inconsistent about using capital 2119 language
>   and I expect you want to be consistent.
> S 2.
>    All of these key exchange algorithms provide forward secrecy.
> This is actually only true if each side generates fresh ephemerals
> which does not seem to be required by the spec.
> Do we really want to promote ECDH_anon to standards track?
> Nit: you want a line break between the last line of Figure 1
> and the legend explaining the message types.
> S 2.3.
>    This specification does not impose restrictions on signature schemes
>    used anywhere in the certificate chain.  The previous version of this
>    document required the signatures to match, but this restriction,
>    originating in previous TLS versions is lifted here as it had been in
>    RFC 5246.
> This section is about ECDH_anon, so maybe this text belongs in S 2.1 or
> 2.2.?
> S 3.
> You have a bunch of lower case 2119 key words here.
>    If these conditions are not met, the client should send a client
>    Certificate message containing no certificates.  In this case, the
>    ClientKeyExchange should be sent as described in Section 2, and the
>    CertificateVerify should not be sent.  If the server requires client
>    authentication, it may respond with a fatal handshake failure alert.
> Actually, this "should not be sent" is a MUST NOT, because if you send
> an empty certificate, you're forbidden to send CertificateVerify.
> S 4.
>    choice of curves and compression techniques specified by the client.
> s/compression techniques/point formats/?
> S 5.1.1.
> Do you want to rename elliptic_curve_list to named_curve_list?
> S 5.1.2.
>    Three point formats were included in the definition of ECPointFormat
>    above.  This specification deprecates all but the uncompressed point
>    format.  Implementations of this document MUST support the
>    uncompressed format for all of their supported curves, and MUST NOT
>    support other formats for curves defined in this specification.  For
>    backwards compatibility purposes, the point format list extension
>    MUST still be included, and contain exactly one value: the
>    uncompressed point format (0).
> This implies that you have to send supported point formats, but in
> S 5.1, this is a SHOULD. I believe what you may be trying to say
> here is that if you send the extension, it must be non-empty.
> Also, maybe I'm missing it, but where do you say that the default
> is to assume that the other side supports uncompressed if it doesn't
> do so. This is a backwards compat issue.
> S 5.3.
> You don't define what "authorized for signatures" is, but I suspect
> you're talking about KeyUsage, etc.? If so, don't you need to say
> this about ECDHE_ECDSA as well.
> S 5.4.
>    The value named_curve indicates that a named curve is used.  This
>    option SHOULD be used when applicable.
> When would you not?
> S 5.5.
> This defines:
>              rsa_fixed_ecdh(65),
>              ecdsa_fixed_ecdh(66),
> But the specification doesn't actually support this. Note that
> the fixed_DH authentication mechanism are specified as having
> the client's cert be on the same curve as the long-term
> ECDH key, but you've deprecated those KE mechanisms, so as far
> as I can tell, static DH auth is impossible
> Also:
> 1. Why isn't the ECDSA cert required to be signing capable.
> 2. You probably should standardize on ECDSA_sign or ecdsa_sign.
> S 5.7.
> More text about static DH auth. Also "implicit" can probably go away.
>    The client selects an ephemeral ECDH public key corresponding to the
>    parameters it received from the server according to the ECKAS-DH1
>    scheme from IEEE 1363.  It conveys this information to the client in
>    the ClientKeyExchange message using the format defined above.
> I don't understand what this means.
> S 5.8.
>    This message is sent when the client sends a client certificate
>    containing a public key usable for digital signatures, e.g., when the
>    client is authenticated using the ECDSA_sign mechanism.
> This is the only way that things can work now.
> S 5.1.1.
>    Failing to
>    do so allows attackers to gain information about the private key, to
>    the point that they may recover the entire private key in a few
>    requests, if that key is not really ephemeral.
> To the best of my knowledge, this only applies to DH, not signature
> verification.
> S 6.
> Do we really want to promote NULL and 3DES to ST?
> -Ekr
> _______________________________________________
> TLS mailing list