In message
<CAF4kx8fSVL5UouVgJubkrNj=BJAyV=xdru_kofkrs-o1pdn...@mail.gmail.com>,
=?UTF-8?B?SWFuIEZldHRlI
CjjgqTjgqLjg7Pjg5Xjgqfjg4Pjg4bjgqMp?= writes:
> --===============5680513047430573670==
> Content-Type: multipart/alternative; boundary=047d7bd7689804b84f04e584c415
>
> --047d7bd7689804b84f04e584c415
> Content-Type: text/plain; charset=UTF-8
>
> 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
The presence of the rrset prevents the downgrade attack. A validating
resolver can detect when there should be a RRset but it is not being
returned. The STARTTLS client then expects to see STARTTLS in the
EHLO response if it has a TLSA RRset.
Mark
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: [email protected]
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
