Re: [TLS] Review of draft-ietf-tls-rfc4492bis-15
Stephen Farrell <stephen.farrell@cs.tcd.ie> Wed, 15 March 2017 15:07 UTC
Return-Path: <stephen.farrell@cs.tcd.ie>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96D1313162B; Wed, 15 Mar 2017 08:07:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.301
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie
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 B30DIquWdn_W; Wed, 15 Mar 2017 08:07:14 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC2B1131610; Wed, 15 Mar 2017 08:07:14 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id CBDEDBE39; Wed, 15 Mar 2017 15:07:11 +0000 (GMT)
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HeqYeGQwofr9; Wed, 15 Mar 2017 15:07:11 +0000 (GMT)
Received: from [134.226.36.93] (bilbo.dsg.cs.tcd.ie [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 23197BE2F; Wed, 15 Mar 2017 15:07:11 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; 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 <ekr@rtfm.com>, "tls@ietf.org" <tls@ietf.org>, IESG <iesg@ietf.org>
References: <CABcZeBPp2mJ3KeR_yzQH7bHzJ2TnJBmLzaFcCbbO7OYW9E7Svg@mail.gmail.com>
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Message-ID: <77ef8038-32ae-affa-341e-b104fc28a343@cs.tcd.ie>
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: <CABcZeBPp2mJ3KeR_yzQH7bHzJ2TnJBmLzaFcCbbO7OYW9E7Svg@mail.gmail.com>
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="dpWIsnh6UuieFkbNcQX2eMpxDDL0vff1I"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/4DeR1ngatFep7YbD8PaQkSeZN9M>
Subject: Re: [TLS] Review of draft-ietf-tls-rfc4492bis-15
X-BeenThere: tls@ietf.org
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." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/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, 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. Cheers, S. 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. > > > DETAILED > 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 > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >
- [TLS] Review of draft-ietf-tls-rfc4492bis-15 Eric Rescorla
- Re: [TLS] Review of draft-ietf-tls-rfc4492bis-15 Stephen Farrell
- Re: [TLS] Review of draft-ietf-tls-rfc4492bis-15 Eric Rescorla
- Re: [TLS] Review of draft-ietf-tls-rfc4492bis-15 David Benjamin
- Re: [TLS] Review of draft-ietf-tls-rfc4492bis-15 Yoav Nir
- Re: [TLS] Review of draft-ietf-tls-rfc4492bis-15 David Benjamin
- Re: [TLS] Review of draft-ietf-tls-rfc4492bis-15 Yoav Nir
- Re: [TLS] Review of draft-ietf-tls-rfc4492bis-15 Yoav Nir
- Re: [TLS] Review of draft-ietf-tls-rfc4492bis-15 Stephen Farrell
- Re: [TLS] Review of draft-ietf-tls-rfc4492bis-15 Eric Rescorla
- Re: [TLS] Review of draft-ietf-tls-rfc4492bis-15 Sean Turner
- Re: [TLS] Review of draft-ietf-tls-rfc4492bis-15 Yoav Nir
- Re: [TLS] Review of draft-ietf-tls-rfc4492bis-15 Yoav Nir
- Re: [TLS] Review of draft-ietf-tls-rfc4492bis-15 joel jaeggli