RFC6698 contemplates the use of DANE records with SMTP. (_25._
tcp.mail.example.com is given as an example in the document). However, one
of the problems with SMTP is that it's not known to the sending server
whether the receiving server supports STARTTLS a-priori. (One connects to
the SMTP server, issues an EHLO command and is informed whether the server
supports STARTTLS or not. This can be trivially removed by a malicious
MITM). Similar downgrade vulnerabilities exist for other protocols that
rely on STARTTLS-type commands.
DANE lets one specify what certificate is acceptable if a certificate is
required, but not whether a certificate should be expected. I'm curious to
know if there's any appetite to allow this information to be conveyed via a
DANE record. For instance, again with SMTP as an example, one can remember
whether STARTTLS was offered on a previous connection to try to protect
against downgrade attacks, but this is rather brittle, doesn't work well
for new / long-tail hosts, and it's not clear in such a scenario if someone
simply disabled STARTTLS intentionally or if it's actually representative
of an attack.
One could use DANE to convey, for STARTTLS-type services, whether a client
should treat the lack of encryption support as a fatal error or not. One
possible way to achieve this would be using the high bit of the certificate
usage octet to specify whether the TLSA is advisory ("if you get a
certificate from me, it must match in the following manner") or mandatory
("I offer certificates that match in the following form, if you are unable
to obtain a certificate from me treat it as a hard failure"). I'm not stuck
on the particulars of which bit gets used or where it gets implemented,
other than it would be nice (from my perspective) if it could be combined
in an existing record rather than having to fetch yet another RR for just
one bit of information.
Fundamentally, the problem I'm trying to solve is the problem of downgrade
attacks against protocols like SMTP that advertise their STARTTLS
capability in the clear. It seems like DANE, where one is specifying a
policy about how to validate a TLS connection, might be a reasonable fit
for information about whether STARTTLS (be it POP3/IMAP, FTP, XMPP, LDAP or
any other protocol) should be expected or not. I'm not sure if this has
been considered or not.
Thoughts welcome.
-Ian
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
