On Mon, Nov 10, 2014 at 11:49:15PM +0000, Dan York wrote:
> All of these would seem to be related to operational processes where some
> part of the security layers get updated without other corresponding layers
> being also updated.
That's definitely the main problem. Though
to be fair with HTTPS sites, nobody cares if they don't verify,
browsers don't do DANE and seem unlikely to do so in the near
future. [ Yes, folks like us might install a plugin, which may or
may not work correctly. :-( ]
I think more/better tools to validate the configuration, and
awareness of those tools will help, as will the relevance of getting
the records right. If TLSA records are just a fashion statement
with no operational significance, the bits will rot.
For SMTP at least, one of these days people getting their records
wrong might actually feel some pain in the form of delayed mail,
and then the problem may start to self-correct as people acquire
the appropriate operational habits. That would be accelerated by
a large sender or two enabling opportunistic DANE TLS for SMTP.
No large providers appear in my curated list of 330 DANE-enabled
SMTP domains. Though, IIRC, Unity Media in Germany has ~500,000
users, which is nice, but not quite the requisite scale.
Speaking of SMTP, the same deploy360 site lists some SMTP test
domains. I'd like to suggest removal of dougbarton.us, or (with
his consent) adding that domain to a new category, his records are
PKIX-EE(1), and are not aligned with the DANE SMTP draft. (Per
the draft, these would be treated "unusable" in SMTP, resulting in
a sender policy of mandatory unauthenticated TLS).
--
Viktor.
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
