Re: [Uta] Benjamin Kaduk's Discuss on draft-ietf-uta-smtp-require-tls-07: (with DISCUSS and COMMENT)

[Viktor Dukhovni <[e-mail]>]

On Wed, Feb 27, 2019 at 02:11:38PM -0600, Benjamin Kaduk wrote:

> > > I'm also unsure exactly how tightly nailed down the (non-DANE) TLS
> > > certificate validation process is supposed to be as a result of this
> > > document; more in the COMMENT section.  It seems that without some form
> > > of strict certificate (host)name validation, this mechanism does not
> > > actually mitigate the lack of server authentication by the client that's
> > > described as a goal.
> > In what respect is the certificate name validation not strict? DNSSEC or
> > MTA-STS is required to make sure that the MX hostname can't be altered
> > in a DNS response, and that should be the name on the certificate.
> 
> DANE and/or MTA-STS give me an MX hostname.

MX records give you an MX hostname.  With DANE, that MX hostname is
DNSSEC verified.  With MTA-STS the hostname is checked against the
MTA-STS policy via a (sometimes cached) HTTPS callout.

> Do I require that exact hostname to be present in the X.509 certificate
> presented by the TLS server?

Not in the case of DANE (for SMTP).  The certificate can be completely
anonymous, and would still be matched via a "3 [01] [012]" TLSA record.

With MTA-STS, yes, the name would have to match the certificate.
(Which makes deployment more difficult in some use-cases, but
c'est la vie).

> I didn't see any text in the document that clearly says the answer
> is "yes".

Since, the answer is not always yes, the appropriate behaviour is
left to the security mechanism.

> "verify successfully" is pretty vague.  Do I just verify the signatures
> along the chain?  Do I need to check those fiddly keyUsage bits?  Do I care
> what the CN/SAN is?  We cite RFC 6125 in Section 4.2.1, but it's probably
> prudent to reference it here as well.

In the case of DANE-EE(3) the only requirement is that the "3 X Y"
TLSA record matches.  Name checks and expiration, etc. are out of
scope, but I would expect friction with some implementations if the
keyUsage is not compatible with TLS or the negotiated key exchange
mechanism.  So the certificate keyUsage SHOULD be provisioned with
under same constraints the same as would apply with WebPKI.

With MTA-STS, all the usual WebPKI stuff applies.

> > Either STARTTLS or implicit TLS (i.e., on a different port) would
> > satisfy this requirement. It's because of the "straight to TLS" case
> > that STARTTLS isn't mentioned here. This is REQUIRETLS, not
> > REQUIRESTARTTLS.
> 
> I'm complaining more about the transition from (3) to (4) than either one
> per se.  If I open a connection and then establish a (new?) TLS-protected
> session, that seems to mostly be STARTTLS.  But if I use implicit TLS, why
> do I need to bother with (3) at all?

There is no implicit TLS for MTA-to-MTA relay, and none in the
foreseeable future, so this issue is moot.

> Given that 4954 just talks about the client's "understanding of the server
> hostname", I'd suggest that this document explictly state that the MX
> hostname must match, independently of the question of citing 4954 and/or
> 6125 here.

Except that's not the case with DANE.

-- 
	Viktor.