Re: [Uta] draft-moore-smtp-addrquery

[Keith Moore <[e-mail]>]

On 07/29/2015 06:02 PM, Viktor Dukhovni wrote:
> On Wed, Jul 22, 2015 at 02:55:02AM -0400, Keith Moore wrote:
>
>> Clearly this draft isn't insisting on "very secure", as it's relying on TLS
>> certs and the model that any trusted CA is trusted for all domains, which is
>> already known to have problems.   But to me, using TLS certs seems like a
>> good compromise for now.  They're somewhat secure and reasonably well
>> understood.
> 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.   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

(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.

I don't expect (b) to be at all easy.

>
>> (Also, I'm all for having DNSSEC-signed TLSA records as a second trust
>> anchor if both that and a x.509 TLS cert were required.   I'm much less
>> enamored with the idea of a signed TLSA record being used instead of an
>> x.509 cert.
> That's a mistake.  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?


>
>> I feel like that's a sideways step that's marginally better
>> for some use cases, but probably not an improvement overall.
> This feeling should pass with time.

Time will tell  :)

>
>> It's replacing something that has well-understood limitations, with
>> something that has poorly-understood limitations.   For instance, I'd
>> never trust a separate server to do DNSSEC signature validation.)
> 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?
>> That's not what concerns me.   What concerns me is whether all of those mail
>> domains would permit such updates.   This draft doesn't define an API for
>> posting or updating such information, but we'd need one.     Even if we had
>> such a standard, it's not clear to me whether most or all mail domains
>> supporting AQRY would support the update specification.
> 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.

>
> It is very unlikely that Postfix (for example) will ever implement
> an interface for remotely modifying database tables (such as address
> to public key) tables over SMTP.
>
> We're working on the scalability problem for key distribution
> (O(n^2)), not on the scalability problem for managing one's own
> keys (O(n)).

Both problems need to be addressed, though they are indeed different 
problems.   As I see it, the key distribution problem is actually easier 
because the n for that problem is much smaller.    A very few clients 
and servers serve the vast majority of mail users.  OTOH, there are 
billions of email users who would need to learn how to update their 
keys.   So in some sense the update problem is actually more crucial.

>
>> More generally, if the owner of a domain is already outsourcing email, web,
>> and DNS to different providers, should any of those providers be
>> axiomatically granted the ability to authenticate keys for users at that
>> domain?   I rather doubt it.  (Actually I was just making a note to have the
>> next version of the AQRY document recommend against using the same domain
>> name for either an MX or redirect SMTP server that is also being used for a
>> web server, because if you use the same domain name for both you're
>> effectively allowing your web server to authenticate AQRY responses where
>> you intended that or not.)
> This is nicely addressed with DANE for SMTP, because the key binding
> is per port.
>
> I should mention that there's no way that you're going to get all
> the domains using self-signed certs for SMTP (e.g. mine) to start
> deploying CA-issued certificates just to publish public keys for
> our own users.  If you want to pay for a CA with DANE, nothing
> stopping you, but CA certs for MX hosts are simply NOT going
> to scale.

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.

>
> This proposal is a non-starter without a scalable authentication
> model, and the WebPKI is not it.  Even DANE seems weak to you,
> consider that non-deployment is even weaker.
>
>      https://tools.ietf.org/html/draft-ietf-dane-smtp-with-dane-19#section-1.3
>      https://tools.ietf.org/html/rfc7435
>
> 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.

> Yes, very domains do DNSSEC today, but this is not a problem for
> a green-fields draft.  No MTA support the spec, and very few users
> have SMIME or PGP keys.

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.

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

Keith