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

Eric Rescorla <ekr@rtfm.com> Wed, 15 March 2017 14:53 UTC

Return-Path: <ekr@rtfm.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 497111315BD for <tls@ietfa.amsl.com>; Wed, 15 Mar 2017 07:53:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 ogcbfVc1cUIG for <tls@ietfa.amsl.com>; Wed, 15 Mar 2017 07:53:43 -0700 (PDT)
Received: from mail-yw0-x229.google.com (mail-yw0-x229.google.com [IPv6:2607:f8b0:4002:c05::229]) (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 55CD11315AE for <tls@ietf.org>; Wed, 15 Mar 2017 07:45:33 -0700 (PDT)
Received: by mail-yw0-x229.google.com with SMTP id v198so11882449ywc.2 for <tls@ietf.org>; Wed, 15 Mar 2017 07:45:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=/7A60iwNzjyP1SfygigRcpN3UdmOyIjAu+SE7x+eO7c=; b=wkX19lQhb3LKQhCOFgz3z4jxDOPJpg4khHm+gvYiHL74bJfO91UPatl7JJZGAQgDKU MqYCSQtmPbLL5BhjTXbISrnvqxW4/4j52XR/CFpd3LywIPTLAwnI3VpS6HmMJN3LED5w PTTXL7pawQj37Oq/5AMAA9YfozaE5MQvYrwUqUIK1Or5v7g6pTVNKNH7Bu/x0ZkH+SXf T234WhbTyu4kIWU3QaLzPE6BWr9isZwnoHGVWT8lZW6NEQbZ2i7y3OXm3WXV+pw/JDtL b1mfcxUdfPsRsIWowCqRRaz0YTRTLhco03z33ynBkJk2THLOSh2QOkkAnKhKVfKJLpgj TYlw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=/7A60iwNzjyP1SfygigRcpN3UdmOyIjAu+SE7x+eO7c=; b=OdUm163XGXJoO2fcDleca3r/QruHrbfUx+LrkfEHIXKanW+ysrvrFoXdFzw9rQ4QWs kBVWF5QJ79jkg41ZzIq/f0cyDOwHMM55NmatmtuxnDI1TAiOR+X6QasiAAaxHcQwdT/t Y8ysv5TBqOWNzJ3/xIucCYaftQrJC7g+wRRsWzjNVjmqVrOaxz2NAJEjh1e//Kbr2+gt 2Qk2JE3ucXZBtHMopFL1jMEbzgbunfnB3ovYTj+jZ9olyQbLKnfWuoGXXqxgDdO0FmES ePnBkBFPR1cGWf03hoooZSw1a2gB5QME3tJvk/+yoTkfuP4VKHgJrDWrZtEMRpWQXCVB mzGg==
X-Gm-Message-State: AFeK/H1M3Z1YWOSErRloAw+VVPyll4WuVXQA4TtyRcAtdZiDHJLdegHMSU6XbRzQ9fPoqnr5Qg/8LEtZ1HeOfg==
X-Received: by 10.129.125.5 with SMTP id y5mr2739066ywc.120.1489589132151; Wed, 15 Mar 2017 07:45:32 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.129.154.210 with HTTP; Wed, 15 Mar 2017 07:44:51 -0700 (PDT)
From: Eric Rescorla <ekr@rtfm.com>
Date: Wed, 15 Mar 2017 07:44:51 -0700
Message-ID: <CABcZeBPp2mJ3KeR_yzQH7bHzJ2TnJBmLzaFcCbbO7OYW9E7Svg@mail.gmail.com>
To: "tls@ietf.org" <tls@ietf.org>, IESG <iesg@ietf.org>
Content-Type: multipart/alternative; boundary=001a1149364415722a054ac5ffb9
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/yyrc12JjsLDIP1TOPuZdACrN0rw>
Subject: [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 14:53:45 -0000

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