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

Yoav Nir <ynir.ietf@gmail.com> Tue, 21 March 2017 07:44 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 0BE5B129629; Tue, 21 Mar 2017 00:44:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 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_NONE=-0.0001, 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 kWj1c1R2VEuL; Tue, 21 Mar 2017 00:44:34 -0700 (PDT)
Received: from mail-wr0-x22c.google.com (mail-wr0-x22c.google.com [IPv6:2a00:1450:400c:c0c::22c]) (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 841EA129631; Tue, 21 Mar 2017 00:44:33 -0700 (PDT)
Received: by mail-wr0-x22c.google.com with SMTP id l37so106559756wrc.1; Tue, 21 Mar 2017 00:44:33 -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=pi0x4bFCfwMteYrrTH5ipdQ/lv6u4KVSYbmSXBqQuJc=; b=VvsLzlzRyg2r6Bc93z7zS4f+tTPiia+zAg5gPhgxAyQcm6/upPJfjTwYj9Mxgs45ed YsAyztf34QuoEshh1cowJTnpAYWVumBUHrLgwrVIuijIYc366qKpZadPlr6z5NQtQmqP NfOgkY3ClK+8doZ6CIAYxt6Y1NhG0aJA2JCKjMsNMzfw0AlAI1Id+BifGS4iIPs4K68i Ve3JD4HacvqjO63v1eehjKj8YvkVGeKlSn1UnfsO77WsalgTqvBI2JAUjQrFE2t25jmT DPkxRnYu4qUcgtwQftqZVCT+kamo/8UbE/QFNccPS2n1zakdX/NraWrcqRq7RREXQ7Vg 7yXw==
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=pi0x4bFCfwMteYrrTH5ipdQ/lv6u4KVSYbmSXBqQuJc=; b=GqJ1OQFGVDV21u/6lAn5oXlQJFMGkCJi97I5vKz7NLEdGDcQ198XFPoJCXqKGS0R9z 7DX4UXmIaj6Iko53+ZP4/d/pkLCWoeETTrn46XMzMXgOIJRHoENsufrqHC62neyJXJeE YkIK5r0u55oBQu24qIogtcPwAcXlrDtdRo3/JSb6B83E8RRBcQerO0R2Fw8u+gSf2AcU /BLRF4PfIIWHKI4KWtOndrIJUYbaiL1bNSZG7bB8SIQ7HV+erRJVPm/XxNe4vXmeI9Cg zIGH7ku2VNscHxcJEZYvlFUaUNfrmmMaZF6hNwe2tfTLBDRKkpKIhZUekXg3Xb91diYa qd6w==
X-Gm-Message-State: AFeK/H1tW8ecYsGUQt+0hVxNtB3/c1CEYOxknSz1FOFBHlDBOyJKREqqn+0jnUw8C1ojXw==
X-Received: by 10.223.150.205 with SMTP id u71mr29066020wrb.195.1490082272043; Tue, 21 Mar 2017 00:44:32 -0700 (PDT)
Received: from [192.168.1.18] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id q1sm13830810wra.65.2017.03.21.00.44.30 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 21 Mar 2017 00:44:31 -0700 (PDT)
From: Yoav Nir <ynir.ietf@gmail.com>
Message-Id: <014753DA-5D5A-47ED-88D3-2291DC3DE78A@gmail.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_733773FE-1AEC-4ED5-8618-45AFFD1DACC2"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
Date: Tue, 21 Mar 2017 09:44:28 +0200
In-Reply-To: <CABcZeBPp2mJ3KeR_yzQH7bHzJ2TnJBmLzaFcCbbO7OYW9E7Svg@mail.gmail.com>
Cc: "tls@ietf.org" <tls@ietf.org>, IESG <iesg@ietf.org>
To: Eric Rescorla <ekr@rtfm.com>
References: <CABcZeBPp2mJ3KeR_yzQH7bHzJ2TnJBmLzaFcCbbO7OYW9E7Svg@mail.gmail.com>
X-Mailer: Apple Mail (2.3259)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/vEli2fFQ1YqnlG19nPcUfNhNXAg>
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: Tue, 21 Mar 2017 07:44:37 -0000

Hi

This pull request addresses most of these comments.   https://github.com/tlswg/rfc4492bis/pull/39 <https://github.com/tlswg/rfc4492bis/pull/39>  There is some discussion on that PR

Some that are not addressed, I’ve answered below.  Let me know if you want me to merge and submit.

Yoav

On 15 Mar 2017, at 16:44, Eric Rescorla <ekr@rtfm.com> 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?

It’s the EC version of DH_anon, which is on the standards-track. I don’t expect to convert the web to use DH_anon, but its security is very much like what you get with a self-issued certificate, with many less bytes on the wire. Anyway, I don’t think this effort is the place to deprecate what is a pretty good mechanism for opportunistic security if nothing else.

> 
> 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/?

Since we’re deprecating all point formats other than uncompressed, I just removed the “and” and left it as choice of curves.

> S 5.1.1.
> Do you want to rename elliptic_curve_list to named_curve_list?

Yes

> 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.

Yeah, neither do I.  I reworded it.

> 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?

The place to remove 3DES is TLS 1.3. The alternative is to either deprecate it for TLS 1.2 or to not obsolete 4492.

NULL is a little more nuanced, but I think the same argument applies.

Yoav