Re: [dane] Barry Leiba's Discuss on draft-ietf-dane-smtp-with-dane-17: (with DISCUSS and COMMENT)

[Mark Andrews <[e-mail]>]

In message <[e-mail]>, Paul Wouters wr
ites:
> On Tue, 26 May 2015, Mark Andrews wrote:
> 
> > In addition it is just plain pointless to do the lookup.
> >
> > If the A/AAAA is insecure the TLSA lookup will be insecure due to
> > there being not DNSSEC trusted path the TLSA node.
> 
> I don't understand this. Wether the A/AAA is spoofed or someone
> with sufficient power to redirect routing of that range to them
> is the same thing. So even if the A/AAAA were trusted by DNSSEC,
> you don't know if you are talking to the real or rogue servers
> in that IP.

If the A/AAAA result is secure you do the TLSA lookup.
 
> >  You can't prove
> > whether the server was supposed to offer STARTTLS or not.
> 
> Yes you can? The presence of TLSA means you MUST do STARTTLS,
> and not downgrade to plaintext. Sure, it can be spoofed but
> you're not posting anything signed with DNSSEC, you're not
> losing any security here?

If the answer is INSECURE you can't prove the TLSA exists.  The
MUST only applies if you get a SECURE response to the TLSA record
which will not happen if the A/AAAA response is insecure.

> >  Faked answers can "prove" either assertion.
> 
> Sure. Not signing will not help against active attacks. But publishing
> unsigned could help you agaisnt passive attacks.

And you can tell the difference how?

Spoofed affirmative TLSA responses can lead to a DoS if they are
accepted either because the server does not offer STARTTLS or the
TLSA does not match the CERT offered.

> > as the answer will be insecure.  SMTP servers can already be
> > configured to accept CERTS where you don't have a trust anchor for
> > that server if you just want to have a encrypted stream to stop
> > casual snooping of traffic and the server happens to say it supports
> > STARTTLS.
> 
> That is true. You don't win much by an out-of-band insecure TLSA lookup.
> 
> > The main reason for not doing the lookup is that it is pointless
> > (see above).  The very much secondary reason for not doing the
> > lookup is that there is a very small percentage of servers that
> > mishandle TLSA lookups.  SMTP servers are going to have to handle
> > these broken servers once they get secure A/AAAA responses.
> 
> If broken servers are indistinguishable from an attack, then it is
> an attack, and things should break. (yes spoken without operator hat on)
> 
> >>> When the MX RRset is secure, but the A/AAAA records are insecure,
> >>> no TLSA lookup takes place.  I think that proceeding with (soft-fail)
> >>> TLSA lookups when the MX RRset is insecure invites implementation
> >>> errors.
> 
> I don't like that because I would like to be able to publish TLSA
> records in my nohats.ca zone pointing to some mail service I use
> that uses certificates but are not themselves dnssec signed. eg:
> 
> nohats.ca. IN MX 5 mail.insecure-bigmail.com.
> nohats.ca. IN TLSA <blob>

Which no SMTP client will lookup.  Much better to write to their
support@ address and say you are moving your email to someone that
supports TLSA if they don't add the records with <reasonable period>
them carry through with the threat if they don't.  There is nothing
stopping any SMTP service operator configuring and signing TLSA
records other than pigheadedness on the part of the operator.

> As for insecure TLSA records themselves, while I would prefer we
> would use them in a better-than-nothing sense, I am more fearful of
> implementations just not bothering or forgetting to check for DNSSEC
> and blindly trusting these. So I think it is more clear to just say
> ignore insecure TLSA records.

Except they are not better-than-nothing.  Using them requires that
you deal with the failure modes of dealing with them.  They introduce
their own new threats.  They also don't enhance security.

Ignoring them doesn't prevent opportunic use of STARTTLS.  

> Paul
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: [phone]                 INTERNET: [e-mail]