" The STARTTLS client then expects to see STARTTLS in the EHLO response if it has a TLSA RRset." - this wasn't clear from my reading of the RFC. Where is that specified, or well understood? If that's a safe assumption, that certainly simplifies things, but this was not clear from my (admittedly hurried) reading of the RFC.
On Tue, Sep 3, 2013 at 7:25 PM, Mark Andrews <[email protected]> wrote: > > In message <CAF4kx8fSVL5UouVgJubkrNj=BJAyV= > [email protected]>, =?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
