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

[Paul Wouters <[e-mail]>]

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.

>  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?

>  Faked answers can "prove" either assertion.

Sure. Not signing will not help against active attacks. But publishing
unsigned could help you agaisnt passive attacks.

> You don't get a viable trust anchor if you do get back a TLSA record
> 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>

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.

Paul