On Wed, Feb 27, 2019 at 03:27:00PM -0500, Viktor Dukhovni wrote: > 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).
Section 2 has this nice note about "MUST verify successfully using DANE as specified in RFC 7672". I am demanding an equivalent level of specification for the previous clause, about "verify successfully in a trust chain leading to a certificate trusted by the SMTP client", which sadly lacks a current single comprehensive reference. > > 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. It still needs to actually be specified somewhere! My understanding is that the intent here is to make the TLS verification of X.509 certificates for the non-DANE case more strict than current practices, and as such we need to actually specify the desired practices, here. > > "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. Then the document needs to say so! > > > 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. So why can't (4) use the string "STARTTLS" and be less confusing to the reader? > > > 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. Apparently the implicit "for the non-DANE case" got lost. Sorry. -Benjamin _______________________________________________ Uta mailing list [email protected] https://www.ietf.org/mailman/listinfo/uta
