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

David Benjamin <davidben@chromium.org> Wed, 15 March 2017 19:32 UTC

Return-Path: <davidben@google.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 019C51317E6 for <tls@ietfa.amsl.com>; Wed, 15 Mar 2017 12:32:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=chromium.org
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 4G67_IicOTse for <tls@ietfa.amsl.com>; Wed, 15 Mar 2017 12:32:27 -0700 (PDT)
Received: from mail-pf0-x22c.google.com (mail-pf0-x22c.google.com [IPv6:2607:f8b0:400e:c00::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 AC4DE1317E1 for <tls@ietf.org>; Wed, 15 Mar 2017 12:32:27 -0700 (PDT)
Received: by mail-pf0-x22c.google.com with SMTP id x63so7719583pfx.2 for <tls@ietf.org>; Wed, 15 Mar 2017 12:32:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=2nJS7sv7TN73YCK1hb10saZlJPeH1vprL4oVw7rrcbU=; b=NphJ+dMNkj6pP/B823jPIlDlH19vQEiv21hndpThpYwXCwBU1uv7bn3EJ+JbdnyO8A 4KMIdeMT3AM1hzjBnoujzNzfGTvI7XzRQjJrIWEgX5rB/ALi/v/2HyC8j6eHwQ5a2z/C cFKZbkS89hdrRXVl0iUr0cYdSQpyq6dPJbxT8=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=2nJS7sv7TN73YCK1hb10saZlJPeH1vprL4oVw7rrcbU=; b=NsTtHwit2+H8rBlx7VMEnD25YD8gnaa7v1RMgcC24mSTwAU4aQ53li2U0gcOOGnvEM TQ0zeVzniw+nnvtcjxJkViSDw0b4T5n+3erqcDposRW5rY5bXeRFSqq3jRD9ERCd0hVj dq9W0aPIDjPm5uCPLv9JR6gUWr+4qDLf3PDDG+Fp7NyTa8VQchWeqSP2oRQiJF1HllFc FBE32UKo/40ijiRj9ymLwm2DD9pcPRuZc3/EnvxXEuWpgNjFvvvNjuinnmKxqkGRjgAa E6feHXfU5FdRlmp2b2+ZisBhxw+trsrf6Ryw6H7fH6xiYG8vbfqimvekFIGGJuo0koIq s/sw==
X-Gm-Message-State: AFeK/H3xD2rMf2cAx0dg3tMft6hb3E6ywuUgMMQp4YNlZLISUUm/lP2NYy2YXj73rXdNDtrYZihBPaFWk5uG7TXC
X-Received: by 10.99.102.135 with SMTP id a129mr5472707pgc.220.1489606347097; Wed, 15 Mar 2017 12:32:27 -0700 (PDT)
MIME-Version: 1.0
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>
In-Reply-To: <13268B67-A6EA-4B4C-9D16-C982A6EE92AA@gmail.com>
From: David Benjamin <davidben@chromium.org>
Date: Wed, 15 Mar 2017 19:32:16 +0000
Message-ID: <CAF8qwaByMcDQv1OYPeLHNA4pUPsU-P0V4yz6vq8zhb78keAx3A@mail.gmail.com>
To: Yoav Nir <ynir.ietf@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>
Content-Type: multipart/alternative; boundary="94eb2c0eee902cdf0c054aca0129"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/FTqynxAk4J56jYY9bYlKBzu-R4Q>
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:32:30 -0000

How's this look? https://github.com/tlswg/rfc4492bis/pull/37

On Wed, Mar 15, 2017 at 2:45 PM Yoav Nir <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> wrote:
>
> If there's to be a respin anyway, I have another small editorial comment:
> https://github.com/tlswg/rfc4492bis/issues/36
>
> On Wed, Mar 15, 2017 at 11:22 AM Eric Rescorla <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> 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
> > https://www.ietf.org/mailman/listinfo/tls
> >
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
>
>