Re: [Uta] Eric Rescorla's Yes on draft-ietf-uta-email-deep-09: (with COMMENT)

[Keith Moore <[e-mail]>]

On 10/25/2017 06:29 PM, Eric Rescorla wrote:
>
>
>
>     dh-group           = ALPHA *(ALPHA / DIGIT / "_")
>
>
> I might want to include hyphen here because "P-256"

done.
>
>         Line 405
>             implementation does not know the name of the cipher suite (a
>             situation that should be remedied promptly), a four-digit
>         hexadecimal
>             cipher suite identifier MAY be used.  The ABNF for the
>         field follows:
>         Hard to see how you could realistically get into this state...
>
>     Chris wrote this so this is just a guess on my part:   I'm
>     assuming there are TLS APIs out there that let the caller query
>     which ciphersuite is being used, but the implementation returns an
>     integer rather than the name, and provides no convenience routine
>     to look up the name text.
>
>
> OK. Chris?
>
>
>
>         Line 594
>             accounts SHOULD be at least use of TLS version 1.1 or
>         greater, and
>             successful validation of the server's certificate. 
>         (Future revisions
>             to this specification may raise these requirements or impose
>         This second requirement is more important.
>
>
>     Agree, or at least I think I do (are MiTM attacks taking advantage
>     of no or weak cert validation really more of a threat than attacks
>     on TLS < 1.1 protocol or ciphersuites?  yeah, I could see that.). 
>
>
> No, they're not.
>
>     But I certainly want implementors to pay more attention to cert
>     validation.
>
>     I'm not sure what change to the text you had in mind, but I
>     reversed the order to put cert validation first.
>
>
> I think that success validation needs to be a MUST.

Ah, now I understand.  Changed to MUST validate + SHOULD TLS >= 1.1.


>         Line 781
>             or interception; this is not intended to mitigate active
>         attackers
>             who have compromised service provider systems.
>         IMPORTANT: Client auth with TLS 1.2 reveals the user's
>         identity. This is a
>         privacy issue, and so we need to note it. The options here are
>         not great with <
>         1.3 because renegotiation is also bad, so I'm not suggesting a
>         normative
>         change, but I think the doc needs to be clear.
>
>
>     Added a paragraph:
>
>     Implementors should be aware that use of client certificates with TLS
>     1.2 likely reveals the user's identity to the server and therefore may
>     compromise the user's privacy.  There seems to be no easy fix other
>     than to avoid presenting client certificates except when specifically
>     configured to do so.
>
>
> The issue here is that it exposes it not to the  server (though it 
> does) but to anyone on the
> wire. This is actually better with TLS 1.3.

ok, clarified the paragraph that I wrote.

Keith