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

[Eric Rescorla <[e-mail]>]

On Tue, Mar 21, 2017 at 12:44 AM, Yoav Nir <[e-mail]> wrote:

> Hi
>
> This pull request addresses most of these comments.
> 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 <[e-mail]> 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.
>

Well, assuming you don't do TOFU.

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

Well, we certainly did that, but why?



> The alternative is to either deprecate it for TLS 1.2
>

This seems like it might be reasonable at this point.



> or to not obsolete 4492. NULL is a little more nuanced, but I think the
> same argument applies.
>

What we probably should actually do is make this depend on the IANA draft
and then mark
these Not Recommended.

-Ekr


>
> Yoav
>
>
>