Re: [TLS] Review of draft-ietf-tls-rfc4492bis-15
Yoav Nir <ynir.ietf@gmail.com> Wed, 15 March 2017 19:39 UTC
Return-Path: <ynir.ietf@gmail.com>
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 F32B9131752; Wed, 15 Mar 2017 12:39:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Level:
X-Spam-Status: No, score=-2.698 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 GiUjJJrvTz13; Wed, 15 Mar 2017 12:38:58 -0700 (PDT)
Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C036C13171B; Wed, 15 Mar 2017 12:38:57 -0700 (PDT)
Received: by mail-wm0-x22b.google.com with SMTP id n11so31467813wma.0; Wed, 15 Mar 2017 12:38:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=Fi2BtyXxl19H//bPc/M3pdb2OBS99fYhXwClqTOJ7XE=; b=CZOUMuwNsumKee8q7vMBbDb7jao0BfOpOh336eZDzYHSstdnyd+S7xVx8fhPmNVzf6 hYABOv8apvwDaLmOgydbqGQ1zLru70OkK+dsuOfO1G0nw1qvDhpfra5SGGEqNKrkdPRq jF6maay913ZhvaHf6ImIafulidEbvII1eYBmmbttFLaYvlJhsRSSVjFztqUK933aF8es 0d9gpGjsmtgAo4zOQIYU4Fn/p3T02KJIq4J4P45kg93GjsSBeVWJknvhoNK5XNvYj5AU bEwewyrSC1qdPHeYPNReLUzwKp9g5JUPOQV9YrEEPkQAUtNgwZzlf7Lct/fguLvLtqEP gxLw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=Fi2BtyXxl19H//bPc/M3pdb2OBS99fYhXwClqTOJ7XE=; b=MEo6+2ok1r+LRxmqj++ajs9pcHRY11m852eS7d0+yjSWl7S3b/TOcHsip8Jkz+0vw+ FH0LEWCgUhY/crhRr4Xgzb2YCE6RBgihIInS3JVruBAsV8w0I41zN28LNKSJGMQux+pX xfgbWmvFJUZXniDPBhjcRAbB9wWvoHzr7akHAnUeh7p1lfvwqvDWlfjqjH/DP9HTf/CQ lAEMzsi60gOg0MosXS9H3Zuz5KDUkPbysF3Rez2J2POHCfyBj9VxcymzPrLVpcul4tme CPJDDJRVikLSC5afF9wLttudYV5opRDMzhzW+E4J8okn4z2/JR+78WxSX2gkS+jpCxzp Vs3Q==
X-Gm-Message-State: AFeK/H3Wz9P3Tyb3AVx+uyVszkyNbfCpdPdINxOPZqOJ4xwBz7ejMOtygj4AXdafbfWjcA==
X-Received: by 10.28.216.141 with SMTP id p135mr22192561wmg.71.1489606736238; Wed, 15 Mar 2017 12:38:56 -0700 (PDT)
Received: from [192.168.1.18] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id o63sm1568470wmo.30.2017.03.15.12.38.54 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 15 Mar 2017 12:38:55 -0700 (PDT)
From: Yoav Nir <ynir.ietf@gmail.com>
Message-Id: <DF4A15A1-61B7-4101-8F0E-743AD25222AB@gmail.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_963FAB8A-BC0D-486E-A536-6EF45A67792E"; protocol="application/pgp-signature"; micalg="pgp-sha512"
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
Date: Wed, 15 Mar 2017 21:38:52 +0200
In-Reply-To: <CAF8qwaByMcDQv1OYPeLHNA4pUPsU-P0V4yz6vq8zhb78keAx3A@mail.gmail.com>
Cc: Eric Rescorla <ekr@rtfm.com>, Stephen Farrell <stephen.farrell@cs.tcd.ie>, "tls@ietf.org" <tls@ietf.org>, IESG <iesg@ietf.org>
To: David Benjamin <davidben@chromium.org>
References: <CABcZeBPp2mJ3KeR_yzQH7bHzJ2TnJBmLzaFcCbbO7OYW9E7Svg@mail.gmail.com> <77ef8038-32ae-affa-341e-b104fc28a343@cs.tcd.ie> <CABcZeBN4sGyG1ajOJZ-SUHSm7HgpEnCF3QVykRwH4HCZf7FF=A@mail.gmail.com> <CAF8qwaCKma2r6JPv4abdYOUFM40L7ov-b2SM0xuSwSxv4ZQb5A@mail.gmail.com> <13268B67-A6EA-4B4C-9D16-C982A6EE92AA@gmail.com> <CAF8qwaByMcDQv1OYPeLHNA4pUPsU-P0V4yz6vq8zhb78keAx3A@mail.gmail.com>
X-Mailer: Apple Mail (2.3259)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/jbSymny8AUBqmZrqAEuhUEWFNB0>
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 19:39:01 -0000
LGTM > On 15 Mar 2017, at 21:32, David Benjamin <davidben@chromium.org> wrote: > > How's this look? https://github.com/tlswg/rfc4492bis/pull/37 <https://github.com/tlswg/rfc4492bis/pull/37> > > On Wed, Mar 15, 2017 at 2:45 PM Yoav Nir <ynir.ietf@gmail.com <mailto:ynir.ietf@gmail.com>> wrote: > There is (going to be a re-spin). There already is a PR there. > > If you can make a PR to solve your issue, that would be great. > >> On 15 Mar 2017, at 19:20, David Benjamin <davidben@chromium.org <mailto:davidben@chromium.org>> wrote: >> >> If there's to be a respin anyway, I have another small editorial comment: >> https://github.com/tlswg/rfc4492bis/issues/36 <https://github.com/tlswg/rfc4492bis/issues/36> >> >> On Wed, Mar 15, 2017 at 11:22 AM Eric Rescorla <ekr@rtfm.com <mailto:ekr@rtfm.com>> wrote: >> FWIW, there's a lot here, but I think it's all essentially editorial, so it shouldn't >> be that hard to clean up. >> >> -Ekr >> >> >> On Wed, Mar 15, 2017 at 8:07 AM, Stephen Farrell <stephen.farrell@cs.tcd.ie <mailto:stephen.farrell@cs.tcd.ie>> wrote: >> >> 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 <mailto:TLS@ietf.org> >> > https://www.ietf.org/mailman/listinfo/tls <https://www.ietf.org/mailman/listinfo/tls> >> > >> >> >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org <mailto:TLS@ietf.org> >> https://www.ietf.org/mailman/listinfo/tls <https://www.ietf.org/mailman/listinfo/tls> >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org <mailto:TLS@ietf.org> >> https://www.ietf.org/mailman/listinfo/tls <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