On Fri, Apr 25, 2014 at 05:57:24PM -0400, Tom Ritter wrote:
> Another example
> would be locally configured DNS names (smtp_host_lookup with 'native'
> in postfix?) - maybe a .local domain that resolve to public IP space
> or overrides in /etc/hosts. These are securely delivered even though
> they're not DNSSEC.
Names not found via DNS at all, or found via DNS, but not in DNSSEC
signed zones are out scope for DANE.
> So I would suggest a SHOULD
> proceed with TLSA lookup instead of a SHOULD NOT, noting that it in
> _most_ cases it won't actually increase security but we'll give it a
> shot because it won't _hurt_ security either.
For common vocabulary it may be helpful to read:
http://tools.ietf.org/html/draft-ogud-dane-vocabulary-02
Attempting to do DANE post insecurely obtained DNS Navigation (NS,
CNAME, DNAME) or Service Specification Records (MX, SRV, ...) seems
futile. In such a scenario is largely sufficient to just do
unauthenticated opportunistic TLS. If there is no MiTM the outcome
is the same, and if there is an active attack, you've likely lost
by the time you've followed the insecure MX records.
Yes, if the MX hostname is a secure zone and TLSA records exist,
you're arguably "half-secure" if you use them, in that if the MX
record was not forged, then DANE TLSA closes the rest of the gap.
I cannot with a straight face log such email connections as "verified"
when they are not in fact verified. Such a security chain that
consists of cast-iron links on one end and a piece of dental floss
on the other is certainly NOT suitable for mandatory DANE TLS (the
Postfix "dane-only" security level).
One might argue that with *opportunistic* DANE TLS, striving for
as much security as one can get might hypothetically include securing
the connection to a server that has TLSA records in a signed zone,
despite the fact that the Server Specification (MX) Records were
not secured.
In such a case, one would have to not consider any resulting
connection as secure (logging, user interface, ...), and yet one
would hypotheticall still refuse to use the connection when DANE
TLSA authentication fails. Would this be a sensible extension of
*opportunistic* TLS in the presence of TLSA records?
About the most compelling use-case for this would be various unsigned
mom/pop domains hosted by a large provider (say Gmail). If Gmail's
MX RRset is some day in a signed zone, and TLSA records exist, is
there sufficient value in enforced authentication of connections
to Gmail when delivering email to a domain whose MX records are
not signed?
Note, the MiTM attacker can easily divert the connection to some
unsigned MX host of his choice.
> If there were mechanisms in a MTA to somehow flag a message as
> 'securely delivered', which I don't believe there are, they would not
> apply.
The Postfix SMTP client logs DANE authenticated connections as
"Verified".
http://www.postfix.org/FORWARD_SECRECY_README.html#status
--
Viktor.
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
