On 07/30/2015 01:52 PM, Viktor Dukhovni wrote:
On Thu, Jul 30, 2015 at 11:34:43AM -0400, Keith Moore wrote:
The secret swept under the rug is that there is no security at all
in the provisioning process for DV certificates.
Ok, I agree with you there. A DNSSEC signature is not less reliable than a
DV certificate.
Thanks. I see this as a healthy starting point for the security
discussion. As I see it, in terms of trustworthiness:
EV >> DANE >> DV
Now we can't expect more than a tiny fraction of email domains to
have EV certs (these might account for a very large fraction of
the users, but any standard needs to be more comprehensive than
just catering to the largest email providers).
So as I see it our choice is between DANE and DV, and *if* we can
more domains to deploy DNSSEC (yes I admit that it is an "if"),
then DANE is a much better fit for SMTP than DV.
I'm okay with supporting both (if we can work out the problems), but I
don't want to force domains to choose one or the other. Partially this
is because the vast majority of users are lumped into a very small
number of email domains which can quite adequately support TLS certs
(even EV certs if clients bother to check), and these are
well-understood and relatively simple for clients to verify. Insisting
on DANE authentication for these domains would make AQRY much less
deployable. The second reason is that, long term, we're better off not
forcing clients to rely on a single trust anchor.
Part of the catch-22 has been lack of a compelling incentive to
deploy DNSSEC,
Perhaps, but that's not DNSSEC's only problem. Getting people to
understand how to use it and how to manage their keys, getting support
for it in registrars and DNS service providers, getting client library
bugs fixed - these are all significant barriers. The lack of a usable
standard DNS update protocol doesn't help either (too many routers
intercept port 43 traffic and break dynamic update). And finally, the
idea that a DNS client could simply trust its local resolver to do
DNSSEC validation for it never made any sense at all.
So basically I think DNSSEC as originally conceived is severely
flawed. And while I think those flaws are fixable, they don't help the
overall DNSSEC deployability situation.
And I've changed my thinking somewhat: I'm amenable to specifying use of
TLSA with AQRY (as an alternative trust anchor), if we can somehow specify
it in such a way that:
(a) mail domains have clear guidance as to what they have to do to advertise
keys that are likely to be considered trustworthy by clients, and
Just publish either "3 1 1" or "2 0 1" TLSA records that bear a
SHA2-256 digest of the leaf public key or the trust-anchor certificate:
https://tools.ietf.org/html/draft-ietf-dane-smtp-with-dane-19#section-3.1.1
https://tools.ietf.org/html/draft-ietf-dane-smtp-with-dane-19#section-3.1.2
https://tools.ietf.org/html/draft-ietf-dane-ops-14#section-5.1
https://tools.ietf.org/html/draft-ietf-dane-ops-14#section-5.2
https://tools.ietf.org/html/draft-ietf-dane-ops-14#section-8.1
https://tools.ietf.org/html/draft-ietf-dane-ops-14#section-8.4
(Many sites choose "3 0 1", which is also fine).
(b) we can specify client requirements for DNSSEC validation that actually,
in practice, assure that the TLSA records are authentic, given the
unpredictability of client operating environments and the generally poor
and unpredictable state of DNSSEC validation code that currently exists
in the wild.
While DNSSEC from mobile devices is a challenge in captive portal
environments and on the multitude of end-user platforms, the
requirement for this draft would DNSSEC between the *MSA* and the
recipient-domain's MTA (MX host).
I am not aware of any significant obstacles to the use of DNSSEC
in a server-to-server environment, where captive portals and other
"middle boxes" don't play a major role.
Hmmm. As far as I can tell, the chief benefit of using DANE (or, more
generally, DNSSEC-signed keys) over server certs is that DANE could
permit MUAs to directly verify the signatures on returned data, by
having those keys signed by their domains and looking up the domains'
signatures using DNS. I really don't like having MUAs trust MSAs to do
their verification for them, as MSAs are too easily compromised. The
only reason AQPX exists in the current proposal is to work around port
25 filtering and the consequent inability of MUAs to directly contact MX
servers.
I don't expect (b) to be at all easy.
In my experience (b) "just works" (establishing authenticity of
TLSA RRs).
Just because something appears to work doesn't mean it's secure.
The TLSA records for my domain are provisioned
via a more robust process than any CA certificate I might reasonably
obtain.
Perhaps, but that's your domain. The important question is, how does a
client know that your TLSA records are reliable?
DNSSEC RRSIG.
Right, but what libraries can a client use to do the verification
correctly, and without making that verification vulnerable to attack?
Not sure what separate server you have in mind. On my mail server,
DNSSEC validation is performed by unbound running on 127.0.0.1.
The DNSSEC code in unbound is maintained by DNS experts. I would
not expect equal quality of any stand-alone dns library that happens
to ship with the OS. In fact I know of multiple such libraries
that are flawed, and I would NOT trust DNSSEC validation performed
*outside* a well-maintained validating iterative resolver.
So the question for AQRY use of TLSA becomes: How do we specify it in such
a way that a client vendor can ship code that will properly validate
DNSSEC-signatures on TLSA records, regardless of the environment in which it
runs, given that such code can't rely on having access to a well-maintained
validating iterative resolver?
Because the destination MTA is reached on port 25, which is almost
universally blocked for end-user systems. I don't see any role
for direct MUA to MTA key lookup. All lookups are via the MSA.
Axiomatically trusting the MSA is not sufficient. We need a better way.
The provider's MSA will not have much difficulty with DNSSEC/DANE.
I'll be adding support for DANE to OpenSSL. I'll probably be at
the Atlanta MAAWG meeting in October, anyone who wants to discuss
implementation pitfalls should free to corner me there...
I'm not planning on attending, but it's not far from me. I could
probably get down there if you want to meet in person.
Updates will be a local matter between the mailbox provider and
the user. Gmail has a settings interface, as does Yahoo, Outlook.com.
If there's no standard means of updating user profiles, it will greatly
hinder use of AQRY in practice. That doesn't necessarily mean that updates
have to be handled via SMTP.
The "standard way" is initially to upload the keys via some your
provider's website. A real standard can be developed separately
if there's enough interest between the providers and MUA implementors.
I think that's separate from this effort. If/when this effort bears
fruit, there may be some incentive to handle the follow-on problem.
(May we have such problems...)
I think it's necessary but agree that it's a separate effort. But it's
really not a follow-on problem, unless we want to build a key
distribution protocol that is not actually widely usable in practice.
(IMO, a huge problem with many IETF security efforts is that not nearly
enough thought has been given to the whole picture - so we've developed
several technologies that, even if they were sound by themselves, turned
out to not be very useful.)
And for most users, it's even harder to get DNSSEC set up than to get a
CA-issued cert. But again, I'm fine with giving mail domains a choice
about whether to use a CA-issued cert, a DNSSEC-signed TLSA record, or both
(or for that matter, if the MX record is DNSSEC-signed and it points to an
SMTP server with a CA-issued cert with the name matching the target of the
MX record.) IF we can specify rules for the client that provide reasonable
assurance of resistance to attack.
Indeed one could simply let the MSA choose how to authenticate the
remote MTA per local policy. If for some MSAs they have a better
way than DANE to authenticate some MTAs (pinned certs, WebPKI, ...)
they should be free to do so. Basically, authenticate the remote
domain by whatever means are suitable, but if this is to scale,
for now there's no real alternative to DANE (provided DNSSEC adoption
moves forward).
The more I think about this, the more convinced I become that MUAs must
be able to do their own verification.
Because an essential step in this proposal is a connection to the
recipient domain's MX hosts, its security depends critically on
DNS security
Actually no. It only depends on having a certificate that matches the mail
domain of the address for which you're requesting information. Though as
has been pointed out, this is especially difficult for MSPs that serve large
numbers of mail domains.
See Section 1.3 of the DANE SMTP draft. Outlook.com hosts many
thousands of domains (likely 10's or 100's of thousands, but it
does not matter). The MX host certificate lists none of these.
Obviously from my previous response, I'm aware of this.
Just because this is a "green-fields draft" doesn't mean that it can hope to
be successful if it ignores deployment issues. While I'm very much in
favor of both DNSSEC and TLSA, and want them both to succeed, I also cannot
ignore that there are serious problems with DNSSEC, both in deployment and
in trusting signature verification, and this inherently affects the utility
of TLSA.
Deployment suffers from last mile on mobile devices, but that's
not a barrier here. I still don't know what "trusting" issue
you have in mind.
You're assuming that having the MSA do the verification for the client
is sufficient. I'm fairly certain that it is insufficient.
Speaking of keys, this draft needs a result format that can vend
(as in DANE), digests of signatures keys as well as full keys for
payload encryption. We'll to spend some time on the payload format
once the protocol issues are hashed out.
Agree. Really I think that 95% of the work will be in getting the data
model right.
I hope we get to the meat of the problem in the not too distant
future, but I think we do first need to clear the protocol hurdles.
Actually I think it's the other way around. We need to focus our
attention on the data model sooner rather than later. Once we get that
straightened out, we'll know what changes we need to make to the protocol.
Keith
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
