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

[Yoav Nir <[e-mail]>]

LGTM

> On 15 Mar 2017, at 21:32, David Benjamin <[e-mail]> 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 <[e-mail] <mailto:[e-mail]>> 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 <[e-mail] <mailto:[e-mail]>> 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 <[e-mail] <mailto:[e-mail]>> 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 <[e-mail] <mailto:[e-mail]>> 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
>> > [e-mail] <mailto:[e-mail]>
>> > https://www.ietf.org/mailman/listinfo/tls <https://www.ietf.org/mailman/listinfo/tls>
>> >
>> 
>> 
>> _______________________________________________
>> TLS mailing list
>> [e-mail] <mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/tls <https://www.ietf.org/mailman/listinfo/tls>
>> _______________________________________________
>> TLS mailing list
>> [e-mail] <mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/tls <https://www.ietf.org/mailman/listinfo/tls>
>