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

From: Keith Moore <[email-masked]>
Date: Tue, 21 Jul 2015 12:25:35 -0400

Of possible interest to this WG, or to the members of this WG, is 
draft-moore-smtp-addrquery-01
Basically this is an extension to SMTP to allow mail exchangers to be 
queried for information about the email addresses for which they accept 
mail.
Such information could include public keys.
TLS is required by this extension and is used to authenticate the responses.

Chris (my co-author) and I would appreciate feedback on this.

https://tools.ietf.org/html/draft-moore-email-addrquery-01

Keith

---

From: "John Levine" <[email-masked]>
Date: 21 Jul 2015 22:12:45 -0000

>TLS is required by this extension and is used to authenticate the responses.

This looks to me like a reasonable approach to distribute mail signing
keys.  I have concerns about some of the details, but in general, it
seems obvious that the way to distribute information about mail
addresses is through mail servers.

Concerns and niggles:

For AQPX, I think it either needs a port number, or redefine it so
that one AQPX follows the redirection chain and returns a response
other than 213.  There are still plenty of firewalled environments
that block everything other than port 443 and proxied port 80.
(That's why I run ssh on port 443, and I'm not the only one who does.)
I'm not too worried about malicious clients doing abuse by proxy,
since the submission server knows who the clients are and a competent
one has to deal with a range of client abuse issues already.

I fear that the response model is already too big, and we're likely to
end up with servers that can serve keys just fine, nobody provides
forwarding info (EXPN is still dead), and the other results are sort
of random.  It's also not clear to me what the security model for
transmit-signing-policy and the like are.  Even assuming we add a TTL
to deal with stale policy advice, I don't see what I as the recipient
of a perhaps unsigned message can usefully do with policy advice like
"when-able" since I have no way to tell whether the other end knows
what my policies are.

In section 6, the requirement that the TLS session has a certificate
with the same domain as the address in the response is unlikely to
work.  There are mail systems that handle mail for tens of thousands
of customer domains, and it's hard to imagine them maintaining tens of
thousands of certs to serve up with SNI.  I don't think this is
particularly hard to fix, perhaps the customer can provide the
relevant part of the JSON signed, and publish the signing key in a
TLSA record at _aqry.<domain>.

I want to emphasize that these concerns all look straightforward to
fix and the basic idea is well worth working out and trying out.

R's,
John

---

From: Keith Moore <[email-masked]>
Date: Wed, 22 Jul 2015 00:09:22 -0400

John,

Thanks very much for the review.   Comments inline.

> one has to deal with a range of client abuse issues already.

Hmm.   Maybe having a PORT option wouldn't be so bad.   I like that 
better than having AQPX follow redirects because that could take an 
arbitrary amount of time, and that seems likely to exacerbate timing 
hazards that already exist in SMTP.

> "when-able" since I have no way to tell whether the other end knows

I agree that it's desirable to keep the response model small, and also 
understand that many sites are going to be reluctant to expose 
forwarding information.

Here's an attempt to summarize my thoughts on the matter:

  * When a message is forwarded, the mail system probably doesn't know
    whether the message is being forwarded to the same person or not.

    If the message was encrypted for the originally-specified recipient,
    and that recipient has his mail forwarded to another recipient
    address, should the forwarding address be able to read the mail or
    not?   The best (short) answer I have is "it depends".   Ideally,
    perhaps, the sender decides which address to use.   (i.e. is this
    "recipient's eyes only" or is it ok if the person to whom the
    recipient has forwarded mail reads the message?)

  * I assume that some mail domains are going to insist on seeing
    messages in cleartext (maybe there's a legal requirement for
    logging, or maybe they're worried about viruses), and are going to
    either bounce or discard encrypted messages.
      o Such mail domains might, however, be willing to advertise a
        domain-wide public key for encryption use, and decrypt the
        message on behalf of their recipients after receiving it.
      o Mail domains that insist on seeing messages in cleartext, might
        or might not forward messages to other domains before that check
        is made.   The choice of which public key to use when encrypting
        (forwarded recipient's key or mail domain key of original
        recipient) depends on that.

  * Related to this is a question of how email users configure their
    address-related information, and to what extent they can do so.  If
    a recipient's MUA knows all of its user's addresses and can update
    all of his public key advertisements, that's one thing.   It might
    be relatively easy for users to manage their address-related
    information (including public key advertisements) if that's the
    case.   If some of those mail domains don't let users update their
    address-related information, that's another thing.   But I assume
    that the latter will be fairly common.

  * Another wrinkle: if the keys advertised via this mechanism are in
    their usual formats (e.g. openpgp or x.509v3 certs), the associated
    email addresses will be attached to the keys.   So if
    [email-masked] wants to forward his mail to [email-masked], is it
    okay if the key advertised at [email-masked] says [email-masked]
    instead of [email-masked]?   (probably not, though at least openpgp
    key files can have multiple aliases)

I'm hoping that a simple model that handles all of these cases (and 
probably some others) can be found.   So far, I haven't found it, but I 
haven't been looking very long.

Anyway, I think getting the data model for responses right is the 
hardest part of this.

> TLSA record at _aqry.<domain>.

This is one of the reasons for the redirect capability.   If the initial 
SMTP server is returning a redirect, then its cert only has to be valid 
for the domain name that appears as the target of the MX record (or the 
address in the response if that happens to be the case).   So an initial 
SMTP server doesn't need to have tens of thousands of certs, if it can 
return a redirect to a server that does have an appropriate cert.   The 
scenario that I had in mind was for the MSP to operate the initial SMTP 
server, and for the customer to operate the redirect server (and the 
customer would use its own cert for that server).    But I do understand 
that that won't suit all customers.

I think it's worth exploring use of JSON signatures to provide an 
alternate means of authenticating results.   However, I hope that we can 
find a better way to verify those signatures than relying on TLSA 
records, because I don't have faith that DNSSEC will be widely deployed 
anytime soon.   With all of the limitations on PKI and server certs, at 
least enterprise network admins understand by now how to obtain them.   
(Whether they understand how to properly safeguard their private keys 
is, of course, a completely different question.)   But the learning 
curve for DNSSEC is much steeper, and there's much less mindshare around 
it.

(If I had been willing to assume DNSSEC deployment, I would have said 
that a DNSSEC-signed MX record for the address's mail domain, + a TLS 
cert for the MX target were sufficient for a AQRY response to be 
trustworth.)

> fix and the basic idea is well worth working out and trying out.

thanks again,

Keith

---

From: "John Levine" <[email-masked]>
Date: 22 Jul 2015 05:59:13 -0000

Here's my use model: I set up my online access account at bigbank, and
give them the address [email-masked].  Then they fetch my
key and all the mail they send me is encrypted to my key.

I'm also thinking that we should avoid making the perfect the enemy
of the much better than we have now.  In particular, although I think
it is important to make it possible for key distribution to be very
secure, we shouldn't insist on it.  Most of the PGP keys on my keyring
were collected from mail that people sent me or from keyservers, where
I am reasonably sure the key matches the purported owner, but I haven't
ever asked to see someone's passport.

>    recipient has forwarded mail reads the message?)

You may be overthinking this.  If I want people who send mail to one
of my addresses to encrypt the mail they send me, I'll publish an
encryption key for that address that I can decode, regardless of the
forwarding path in between.  The MTA doesn't have to know anything
about it, since (give or take the next issue) it'll just pass the
encrypted stuff through.  Similarly, if I plan to sign mail from an
address, I'll publish a signing key.  PGP at least makes it fairly
easy to attach and detach addresses to a key so you can publish the
key with only an address that matches the one it's published for (give
or take JOHN vs john vs john+bigbank.)

>    either bounce or discard encrypted messages.

This part seems fine, I'm definitely OK with my broker's compliance
department reading his work mail.

>    address-related information, and to what extent they can do so.

Given that we're just making this up, I wouldn't spend too much time
working around hypothetical brokenness.  The people I know have a
reasonably good idea of what their addresses are.  It would be nice if
something could automagically update keys for every address, but if
they have to do it in two or three places, that's not a disaster.

>>  There are mail systems that handle mail for tens of thousands
>> of customer domains, ...

>The scenario that I had in mind was for the MSP to operate the initial SMTP 

I have a bunch of customers whose mail is hosted at Tucows.  I have
some control over their DNS, since I need to make the MX records
work but their web server is somewhere else entirely.  They don't
have anything like a mail server, that's why they outsourced it to
Tucows.

>anytime soon.

Me neither (about half of my domains are signed, the other half aren't
due to no way to install the DS records), but we need something that
doesn't require setting up a special server just to distribute the keys.

R's,
John

---

From: Keith Moore <[email-masked]>
Date: Wed, 22 Jul 2015 02:55:02 -0400

On 07/22/2015 01:59 AM, John Levine wrote:
> secure, we shouldn't insist on it.

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.

By contrast, unsigned TLSA records offer essentially zero security.   
There are way too many ways to fool a client into accepting or caching a 
bogus DNS response, and the typical DNS recursive server/proxy is 
implemented in a consumer grade router that is itself woefully insecure.

(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.   I feel like that's a sideways step that's marginally 
better for some use cases, but probably not an improvement overall.   
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.)
> You may be overthinking this.  [...]

That's entirely possible.   But I'd rather start by overthinking, than 
to blindly assume that these issues don't matter just because they're 
inconvenient to deal with.

> they have to do it in two or three places, that's not a disaster.

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.

Also, you're a sophisticated mail user, so you can jump through more 
hoops than the average user.   I'm thinking about a user who has 
multiple email addresses at multiple domains (typical), multiple MUAs 
(also typical: work PC, home PC, home tablet, cell phone). Assume that 
some of those MUAs support encryption and some don't (also a reasonable 
assumption, I think, since it seems much easier to get a usable openpgp 
plugin for a desktop MUA than for a mobile one).   It's easy to say that 
an MUA that supports AQRY should also be able to update the user's keys 
and other info appropriately, but that MUA doesn't know about the user's 
other MUAs and their capabilities.

> have anything like a mail server, that's why they outsourced it to
Some mail domains are going to outsource every service that they 
offer.   That's their decision to make, and for some mail domains it 
might well be more secure than trying to provide that service in 
house.   The way AQRY is written at the moment, a mail domain can 
outsource its AQRY redirect server to a different party than its mail 
service provider, so it's not having to trust their MSP with their 
private keys.   But any time that kind of service is outsourced, the 
customer almost inherently has less control over its private keys and 
less ability to prevent their exposure and/or misuse.

If the mail domain decides to outsource its DNS also (whether to you or 
anybody else), should it be automatically seen as extending that level 
of trust to its DNS provider, such that the provider can convincingly 
offer bogus information that's associated with an email address?  I 
don't think so.   I don't think that a mail domain that contracts with a 
DNS service understands that they're giving it the ability to spoof its 
users' public keys and forwarding addresses and read their encrypted 
mail, nor do I think that clients in general should treat unsigned DNS 
records as sufficiently trustworthy for this purpose.

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

> doesn't require setting up a special server just to distribute the keys.

I guess I've come to almost the opposite conclusion, which is that it's 
a Bad Idea to trust any of DNS, web, or outsourced SMTP server, to 
authenticate keys.

Keith

---

From: "John R Levine" <[email-masked]>
Date: 22 Jul 2015 03:38:02 -0400

> By contrast, unsigned TLSA records offer essentially zero security.

If they're not signed, sure.

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

If they don't, they don't.  People using those domains have to distribute 
their keys however they do now.  I think you'll find that most people's 
mail either isn't forwarded at all, or goes through at most one level, 
with some sort of remote access to change where the forwarded mail goes.

> Some mail domains are going to outsource every service that they offer. 
> That's their decision to make, and for some mail domains it might well be 
> more secure than trying to provide that service in house.   The way AQRY is 
> written at the moment, a mail domain can outsource its AQRY redirect server 
> to a different party than its mail service provider, so it's not having to 
> trust their MSP with their private keys.   But any time that kind of service 
> is outsourced, the customer almost inherently has less control over its 
> private keys and less ability to prevent their exposure and/or misuse.

Yup.  I think it's perfectly fine to define a way to let people run their 
own key servers, but I also think that if you require it, you might as 
well stop now because it's not going to work for enough people to be worth 
the effort.

One of my mail hosting clients is more or less an ad agency.  They know a 
lot about the ad business and nothing about e-mail.  If it were easy to 
use encrypted mail, they would, e.g., sending proofs to clients for 
campaigns for yet to be announced products.  But there is absolutely no 
way no how that they will ever run a key server unless someone else, i.e. 
Tucows or me, runs it for them.  I already know most of their passwords, 
because they trust me and it makes debugging stuff a lot easier.

I think that situation is far more common than the university or 
enterprise which has a skilled staff and a data center that can set up and 
maintain a key server and all of the necessary authentication goop.  If 
they do, great, but you can't depend on it.

> anybody else), should it be automatically seen as extending that level of 
> trust to its DNS provider, such that the provider can convincingly offer 
> bogus information that's associated with an email address?  I don't think so.

Since the DNS provider can already hijack all their mail, which means that 
these days he can get signed SSL certs in their name, I'd say that horse 
left the barn a long time ago.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail.

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 29 Jul 2015 22:02:04 +0000

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.  All those keys
securely obtained over TLS are authenticated via a certificate
authorized by responding to a cleartext email to [email-masked],
delivered to the MX host of example.com by the CA's SMTP server
that does not bother to use DNSSEC.

> implemented in a consumer grade router that is itself woefully insecure.

I don't see any contrast.  The same insecure process as for obtaining
DV certs.

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

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

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

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

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

> More generally, if the owner of a domain is already outsourcing email, web,
> and DNS to different providers, should any of those providers be
> 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.

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, which naturally leads to DANE, because once you're
doing DNSSEC to get to the right MX host, TLSA lookups are a
negligible barrier.

Note also that with DANE the MX host operator can use the same
certificate and same TLSA RRset for an arbitrary number of hosted
domains.  All the client has to do is publish a DNSSEC-validated
MX RRset.

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.

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.

-- 
	Viktor.

---

From: Keith Moore <[email-masked]>
Date: Thu, 30 Jul 2015 11:34:43 -0400

On 07/29/2015 06:02 PM, Viktor Dukhovni wrote:
> 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.

> via a more robust process than any CA certificate I might reasonably

Perhaps, but that's your domain.   The important question is, how does a 
client know that your TLSA records are reliable?

> This feeling should pass with time.

Time will tell  :)

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

> (O(n^2)), not on the scalability problem for managing one's own

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.

> stopping you, but CA certs for MX hosts are simply NOT going

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.

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

> a green-fields draft.  No MTA support the spec, and very few users

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.

> 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

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 30 Jul 2015 17:52:47 +0000

On Thu, Jul 30, 2015 at 11:34:43AM -0400, Keith Moore wrote:

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

Part of the catch-22 has been lack of a compelling incentive to
deploy DNSSEC, and I think that DANE for SMTP is starting to look
like a genuine reason to do so:

    http://www.internetsociety.org/deploy360/blog/2015/06/wednesday-june-30-is-dnssec-day-in-germany/

	This "DNSSEC Day" is a cooperative effort between three organizations:

	* The German government's information security agency (BSI)
	* DENIC, the registry behind the .DE top-level domain
	* Heise online, a leading technology media site

    The BSI is recommending that German domains implement DNSSEC:

	https://www.bsi.bund.de/DE/Presse/Pressemitteilungen/Presse2015/Empfehlung_DNSSEC-29062015.HTML

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

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

In my experience (b) "just works" (establishing authenticity of
TLSA RRs).  What some early adopters are struggling with is not
"authenticity" of TLSA RRs but "accuracy".  They sometimes forget
to update TLSA RRs before updating certificates.

We need to give them better How-To documents, and better testing
tools.  Also they are not yet a representative sample of the target
market.  To date, these are mostly small domains operated by individual
hobbyists, who I am guessing enable DANE more as political statement
than an operational commitment.  A year later, they forget that
the TLSA record is there.

Once a few large providers implement DANE outbound, and defer on
failure, the small domains will notice quite quickly if/when they
mess up, and the problem will be self-correcting.

If mail delivery depends on trustworthy/accurate TLSA RRs, then
key discovery gets a free ride.

> >The TLSA records for my domain are provisioned

DNSSEC RRSIG.

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

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

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

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

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

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

> Agree.   Really I think that 95% of the work will be in getting the data

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.

-- 
	Viktor.

---

From: Keith Moore <[email-masked]>
Date: Thu, 30 Jul 2015 16:02:58 -0400

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

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

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

> TLSA RRs).

Just because something appears to work doesn't mean it's secure.

>> client know that your TLSA records are reliable?

Right, but what libraries can a client use to do the verification 
correctly, and without making that verification vulnerable to attack?

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

> 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.
> (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.)
> for now there's no real alternative to DANE (provided DNSSEC adoption

The more I think about this, the more convinced I become that MUAs must 
be able to do their own verification.
> does not matter).  The MX host certificate lists none of these.

Obviously from my previous response, I'm aware of this.

> not a barrier here.  I still don't know what "trusting" issue

You're assuming that having the MSA do the verification for the client 
is sufficient.    I'm fairly certain that it is insufficient.

> 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

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 31 Jul 2015 15:28:57 +0000

On Thu, Jul 30, 2015 at 04:02:58PM -0400, Keith Moore wrote:

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

Perhaps you're using the phrase "local resolver" in some novel way
that I don't understand.  Why shouldn't an application trust
responses from 127.0.0.1:53?  Those are in my view more trustworthy
than any library the application might attempt to use to perform
validation.  

The local resolver is far more likely for example to have a working
implementation of RFC 5011 (and thus not have a stale root trust
anchor).

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

No, that's not the chief advantage.  The chief advantage is that
it makes it possible to impelement a downgrade-resistant mechanism
to authenticate MTA-to-MTA STARTTLS (for opportunistic transport
security).  In the context of this draft, if authentication is
mandatory, then it makes it possible to deploy MX host certificates
at scale, without trusting DV or being easily vulnerable to DNS
MiTM.

Remote port 25 from the MUA is just as unreachable with or without
DNSSEC.  So DANE does not authenticate an impossible connection
from the MUA to an unreachable server, and often the MUA is in
a captive portal where DNSSEC is not available.

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

The MSA needs to be trusted, because the mailbox provider controls
the reverse channel (mail you receive) and any keys published for
you in the reverse direction.  So your mailbox provider can MiTM
the reverse traffic, recovering most of the forward traffic.

> Just because something appears to work doesn't mean it's secure.

What threat model do you have in mind?

> Right, but what libraries can a client use to do the verification correctly,
> and without making that verification vulnerable to attack?

Postfix uses libresolv to 127.0.0.1:53, with the AD=1 bit signalling
verification.  What attack did you have in mind?

> Axiomatically trusting the MSA is not sufficient.   We need a better way.

The addrquery draft unavoidably trusts the MSA.  If that's not
acceptable, this draft may be DOA.

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

You Chris Newman and I can probably chat over Skype too.  I open
for that, and it would likely save some bandwidth on the list.

> The more I think about this, the more convinced I become that MUAs must be
> able to do their own verification.

Not possible when the data source is the remote domain's MTA on
port 25 as specified in this draft.

> You're assuming that having the MSA do the verification for the client is
> sufficient.    I'm fairly certain that it is insufficient.

It is a core feature of your draft, I don't see any way to get
around that, the introduction problem is a bear with trusted third
parties.  Speaking of parties, how many key-signing parties do you
attent? :-)

> straightened out, we'll know what changes we need to make to the protocol.

The protocol just carries the payload around and authenticates the
peer conveying it.  The two parts are independent, and if we can't
reach consensus on the architecture of the key distribution system,
we're working on the wrong draft.  The payload issues are important,
but not difficult.  I don't at present have the cycles to do both
discussions in parallel.  I think we need to decide whether:

    MUA <---> MSA  <---> recipient domain's MX host

is the right model.  The MUA <---> MSA link is mutually authenticated
with TLS cert for the server (WebPKI or DANE as appropriate).  The
MSA <---> MX is also authenticated TLS, DANE would also make it
possible to authenticate the client (Shumon Huque and I are working
on a DANE client auth spec), which can facilitate limiting abuse.

What alternative did you have in mind?

-- 
	Viktor.

---

From: Watson Ladd <[email-masked]>
Date: Fri, 31 Jul 2015 08:33:31 -0700

> than any library the application might attempt to use to perform

Because the stub resolver on the box uses a recursive resolver on the ISP
which doesn't send back the information required to determine validity, but
a single bit.

Since getting DNSSEC wrong is right now consequence free, don't expect it
to be fixed when the alternative is no DNS.

> > generally, DNSSEC-signed keys) over server certs is that DANE could
permit
> > Right, but what libraries can a client use to do the verification
correctly,
> > I'm not planning on attending, but it's not far from me.  I could
probably
> > The more I think about this, the more convinced I become that MUAs must
be
> > You're assuming that having the MSA do the verification for the client
is
> _______________________________________________
> Uta mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/uta

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 31 Jul 2015 15:49:16 +0000

> which doesn't send back the information required to determine validity, but

I did say "127.0.0.1", not ISP iterator.  I keep saying *local*
(perhaps I should have said "loopback") resolver, but nobody seems
to be reading the fine print. :-(

    stub resolver <---> validating loopback iterator <---> Untrusted nameservers

If the *local/loopback* resolver happens to use the ISP as a
forwarder, that's not especially relevant, modulo the usual privacy
considerations.

I think we need to return the core subject of this discussion (high
level addrquery architecture).  Authentication technology aside for
the moment, is the

	MUA <---> MSA <---> MX host

transaction model acceptable or not?  We can then talk about how
to authenticate each hop.  If this is not acceptable, how does
addrquery get to the MX host?  [ I'd be very reluctant to implement
a new MX host service which has many orders of magnitude more remote
clients than the existing MX host SMTP service. ]

This proposal looked promising because it piggy backs on the existing
SMTP backbone.  If it abandons that, then my enthusiasm for it will
likely wane.

--
    Viktor.

---

From: Watson Ladd <[email-masked]>
Date: Fri, 31 Jul 2015 08:51:49 -0700

> forwarder, that's not especially relevant, modulo the usual privacy

It absolutely is relevant. It means an OS provided component can completely
change the security guarrienties of an application with no visible sign. I
don't like that.

---

From: Keith Moore <[email-masked]>
Date: Fri, 31 Jul 2015 14:23:25 -0400

On 07/31/2015 11:28 AM, Viktor Dukhovni wrote:
> responses from 127.0.0.1:53?

The vast majority of hosts don't operate a resolver, and even if they 
do, there's no particular reason to believe that it's well-maintained.  
(though this will differ from one platform to another; some vendors are 
good about software updates, others not so good).

> Those are in my view more trustworthy

The MUA vendor can at least control what library it uses.   It has no 
control over what resolver is available on the customer's host or 
enterprise network.

> implementation of RFC 5011 (and thus not have a stale root trust

Sure, but there are other reasonable ways of updating trust anchors, 
including normal software update mechanisms (if they're properly 
authenticated).
> security).

I was referring specifically to potential benefits with use of DANE with 
AQRY, not to other uses of DANE.

> In the context of this draft, if authentication is

Perhaps.   But DNSSEC has to be deployed by each mail domain (requiring 
a steep learning curve and support from the domain's registrar and DNS 
service provider).   And the client needs to have reason to trust either 
the resolver or library that's used (or both), and those are actually 
much harder at present than being able to trust a TLS server cert.

> a captive portal where DNSSEC is not available.

If the information returned from AQRY were signed, and there were a way 
to validate the public keys with which those information were signed, 
AQPX could simply pass through those signatures to the client.   The 
client wouldn't have to trust the MSA to validate those signatures.
> the reverse traffic, recovering most of the forward traffic.

a) The MSA is not necessarily operated by the same party as the mailbox 
provider, and there are good reasons to not do this.
b) If the mailbox provider always lies about the keys that you publish, 
you can detect this.
(detecting cases where the mailbox provider selectively lies is harder)

(But thanks for pointing out that attack - I'll add it to security 
considerations.)
> What threat model do you have in mind?

Too many to list right now, but it sounds like I need to write a 
complete threat analysis.
> The addrquery draft unavoidably trusts the MSA.

If you use AQPX, that's true.   But I'm now thinking that this needs to 
be fixed.

> for that, and it would likely save some bandwidth on the list.

Either or both is fine.   We should probably take this off the UTA list 
anyway, as I suspect the work won't end up being done in this WG.
> port 25 as specified in this draft.

It's possible, but it means we can't rely on TLS and the MTA's server 
cert to authenticate the data.
> It is a core feature of your draft

It wasn't intended to be a core feature.   But I do admit that port 25 
blocking is widespread, which is why I now think AQPX requiring the 
client to trust the MSA is a serious flaw.

> is the right model.

It's not the right model if the MSA has to be trusted to verify the MX 
host's cert.   It's more-or-less the same problem as trusting the DNS 
resolver to honestly set the AD bit.   Both increase the attack surface 
significantly.

> What alternative did you have in mind?

I'll work on it for the next revision.

Keith

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 31 Jul 2015 20:33:11 +0000

On Fri, Jul 31, 2015 at 02:23:25PM -0400, Keith Moore wrote:

> The vast majority of hosts don't operate a resolver, and even if they do,
> there's no particular reason to believe that it's well-maintained.  (though
> this will differ from one platform to another; some vendors are good about
> software updates, others not so good).

This is irrelevant.  The only hosts that would need a local resolver
would be the MSAs.  They'd also need new SMTP software to support
AQRY.  That software would need to be well maintained too.  I trust
the DNSSEC validation code in unbound and BIND more than I would
trust the same to some application library.  The former are likely
to get more relevant scrutiny.

> control over what resolver is available on the customer's host or enterprise
> network.

The MUA is not the one doing the DNSSEC verification of the remote MTA.
THat's on the MSA to MTA side of the divide:

    MUA <--WebPKI + SASL user auth--> MSA <--DANE, ideally mutual--> Remote MTA

> including normal software update mechanisms (if they're properly

I'm not holding my breath for those.

> Perhaps.   But DNSSEC has to be deployed by each mail domain (requiring a
> steep learning curve and support from the domain's registrar and DNS service
> provider).

Only the domains that want to publish e2e keys, which is even more
bleeding-edge than DNSSEC.

> And the client needs to have reason to trust either the resolver or library
> that's used (or both), and those are actually much harder at present than
> being able to trust a TLS server cert.

You can trust anything you want, but the DV TLS cert does not merit
any trust.  On the MSA/MTA I operate, I also operate the unbound
server, and I've reason to trust it about as much as one can trust
software written by fallible humans.

> If the information returned from AQRY were signed, and there were a way to
> validate the public keys with which those information were signed, AQPX
> could simply pass through those signatures to the client.

How does the MUA learn trustworthy valid signature keys for that?

Making solutions to "the introduction problem" scale while trying
to avoid trusted third parties (introducers) is a balacing act
between rock and hard place.  You can't have it all.  Trade-offs
are unavoidable.

Doing this without trusted third parties is unavoidable, and I'm
not going to trust the CNNIC CA to introduce me to my next door
neighbours.  At least DNSSEC is sensibly partitioned.
 
> The client
> wouldn't have to trust the MSA to validate those signatures.

Sure it would, because it would learn the trust anchors for that
from the MSA, or have to trust every self-appointed CA on the
planet.  I'd rather trust my MSA.

> provider, and there are good reasons to not do this.

With DMARC, DKIM, SPF, ... sure it is.  How else do you authenticate
to the MSA and get to send mail from your mailbox domain?

> b) If the mailbox provider always lies about the keys that you publish, you
> can detect this.

Yes, selective lies to certain clients which are then MiTMed are
more difficult to detect.  The issue is largely symmetric, lying
by the MSA to the MUA is also prone to discovery.  This is not an
easy space in which to operate invisibly.

> If you use AQPX, that's true.   But I'm now thinking that this needs to be
> fixed.

I think you'll lose my support with any plausible "fix", but I'm
willing to suspend disbelief for now.

> anyway, as I suspect the work won't end up being done in this WG.

Chris has my Skype contact info.  I'm in US/Eastern, let's try to
set something up.

> blocking is widespread, which is why I now think AQPX requiring the client
> to trust the MSA is a serious flaw.

I call it a design feature.  I think AQPX makes this scale much
better, and allows the MSA to MX protocol to evolve separately from
the MUA to MSA protocol (product upgrade cycles for MUAs are
glacial).  The MTA market is far more agile now that the hosting
providers are doing software as a service and the rest of the
infrastructure is largely on open source.

> resolver to honestly set the AD bit.   Both increase the attack surface

The resolver on the MSA is part of the OS operated by the same
sysadmin who operates the MSA.  He should trust himself at least,
but also implement monitoring (even Roland Reagan new about "doveryaj
no proveryaj").

[ I guess that not too many folks on this list have postmastered
  a domain with 80,000 or more users for a decade (the MTAs and
  MSAs had local resolvers way before DNSSEC, that was just the
  right thing to do anyway to make them more performant/reliable). ]

The key question is whether the MUA trusts the MSA to deliver the
right keys or not (likely to be discovered if not and the correspondents
share additional channels of communication).

How exactly the MSA authenticates the MTA so it does not get fooled
by a bogus upstream is a secondary problem, that warrants attention
of course, but since we've not yet agreed on the big picture should
likely not distract us from the main issue.

> I'll work on it for the next revision.

I think it makes sense to discuss the architectural outline before
investing too much time in a formal writeup.

-- 
	Viktor.

---

From: Keith Moore <[email-masked]>
Date: Fri, 31 Jul 2015 18:49:59 -0400

On 07/31/2015 04:33 PM, Viktor Dukhovni wrote:
> would be the MSAs.

That would considerably weaken this proposal, by making the MSAs 
extremely attractive targets for compromise.

> They'd also need new SMTP software to support

And you might be right.   But what you find trustworthy, and what is 
available to most users, are completely different things.

> The MUA is not the one doing the DNSSEC verification of the remote MTA.

You can keep saying that as many times as you want, and it still won't 
be acceptable to impose that restriction.

It _might_ be okay for an MUA running in a resource-constrained 
environment to trust the MSA to do DNSSEC verification and signature 
verification on the data.  But if an MUA implementor is going to go that 
route, it might as well just be a split MUA and have the server side of 
that MUA responsible for encryption.   I find it dubious that an 
environment that is too resource constrained for key verification is not 
too resource constrained to do public key encryption of the message.

I don't think we can stop people from building split MUAs that do 
encryption on the server side, any more than we can stop people from 
implementing webmail clients that do encryption and decryption on the 
server side.   But that doesn't mean we should cripple our key 
distribution protocol to enforce that kind of restriction.

> I'm not holding my breath for those.

I'm not holding my breath to have DNSSEC and trustworthy resolvers for 
it widely deployed.
> bleeding-edge than DNSSEC.

Nope.

> any trust.

Neither do DNSSEC-signed TLSA records, then.   As far as I can tell, 
they're approximately equivalent in that respect.

> How does the MUA learn trustworthy valid signature keys for that?

I have some ideas, but want to work them out in more detail before I 
discuss them further.

> between rock and hard place.  You can't have it all.  Trade-offs

Yes, but you're recommending "trade-offs" that appear to create serious 
vulnerabilities.

> neighbours.  At least DNSSEC is sensibly partitioned.

I agree with that much.    What I don't agree with is axiomatically 
trusting either the MSA or its DNS resolver code.

>   
>> The client wouldn't have to trust the MSA to validate those signatures.
> planet.

Just because it learns the trust anchors from the MSA doesn't mean that 
it has to axiomatically trust those trust anchors.

Also, even with the current proposal, any MUA vendor that wishes to do 
so can provide its own proxy to bypass local port 25 blocking. For 
vendors that don't mind paying for those servers, that seems far 
superior to trusting the MSA.

> to the MSA and get to send mail from your mailbox domain?

I use my own domain names (as do many enterprises) that don't impose 
those restrictions.
> easy space in which to operate invisibly.

Offhand, it seems harder to detect the MSA lying without the MUA having 
an independent verification path.  And if it it has an independent 
verification path, there's no reason for the MUA to trust the MSA.
> willing to suspend disbelief for now.
Well, I can't tell what bugs you about the fix, but I hope you'll wait 
to see it before passing judgment.

> Chris has my Skype contact info.  I'm in US/Eastern, let's try to

Let's work out the details off-list.

> better,
I don't see how.   It doesn't lessen the load on either the MX server or 
the MUA client, and it increases network traffic overall.

>   and allows the MSA to MX protocol to evolve separately from
> glacial).

Actually, the current proposal requires the MUAs to track changes in 
AQRY response format.   Even if the query uses AQPX, the MSA just 
returns the data provided by the MX server.

> sysadmin who operates the MSA.

Perhaps.    But axiomatically expecting the MUA to trust the MSA is 
still a Bad Idea.   If the MSA host is compromised, it doesn't matter 
whether the compromise is in the MSA code itself or in its resolver.

>   He should trust himself at least,

Sure, having a local resolver is a good idea for performance reasons.   
That's an entirely separate issue from designing a key discovery 
protocol that axiomatically requires a user to trust his MSA to not lie.

> likely not distract us from the main issue.

I'd prefer to try to fix this problem up front, rather than leave a 
gaping security hole to be fixed later.

> investing too much time in a formal writeup.

I think it makes sense to not waste time arguing about a proposal that 
isn't yet developed in sufficient detail.   That time is better spent 
actually developing a proposal.   I appreciate the feedback on the 
current proposal and hope it leads to making the next proposal stronger.

Keith

---

From: Viktor Dukhovni <[email-masked]>
Date: Sat, 1 Aug 2015 05:14:34 +0000

> available to most users, are completely different things.

Again what is available to users is largely irrelevant provided
all the hard-lifting is done by the MSA.

> You can keep saying that as many times as you want, and it still won't be
> acceptable to impose that restriction.

We clearly disagree, and we'll have to find where the rough
consensus lies, John Levine IIRC was leaning towards minimal security
(ala DKIM), a trusted MSA is a fortress by comparison.

> It _might_ be okay for an MUA running in a resource-constrained environment
> to trust the MSA to do DNSSEC verification and signature verification on the
> data.  But if an MUA implementor is going to go that route, it might as well
> just be a split MUA and have the server side of that MUA responsible for
> encryption.   I find it dubious that an environment that is too resource
> constrained for key verification is not too resource constrained to do
> public key encryption of the message.

I did not mention anything about resource constraints.  The contraints
are rather mobility in and out of captive portals and port 25
blocking.  With super-computers in every pocket, I'm not too
concerned about the cost of performing a couple of public key
operations now and then.  Much cheaper than streaming Neflix.

And sure in some environments the MSA will not support key lookups
by users, or will vend a "gateway" key, and will virus scan, DLP
scan and archive the mail, before possibly encrypting to the final
recipient.

> I don't think we can stop people from building split MUAs that do encryption
> on the server side, any more than we can stop people from implementing
> webmail clients that do encryption and decryption on the server side.   But
> that doesn't mean we should cripple our key distribution protocol to enforce
> that kind of restriction.

Not cripple, just trust the MSA to not lie, or not easily consistently
get away with it.  This simplifies the model, and makes it much
more manageable.

> I'm not holding my breath to have DNSSEC and trustworthy resolvers for it
> widely deployed.

Not widely, just on MSAs that choose to support AQPX.  Which can
choose to do WebPKI with selected peers or trust DV if they please
(but will not be able to query any of the domains with DANE-EE or
DANE-TA certs).  We can only suggest a preferred authentication
model, we can't police it.

Even the BSI in Germany is recommending DANE/DNSSEC, it is not a
mandate.

> Neither do DNSSEC-signed TLSA records, then.

The logic escapes me.

> As far as I can tell, they're approximately equivalent in that respect.

No DNSSEC is stronger than DV because the registrar definitively
knows who controls the customer domain.  A certfificate from some
random stranger attesting that that seemed to be the case at a
passing glance is much weaker.  Also TLSA records are service-specific,
while X.509 PKI certs name hosts conflating HTTPS certs with SMTP certs, ...

> Let's work out the details off-list.

Sounds like a plan.

> I don't see how.   It doesn't lessen the load on either the MX server or the
> MUA client, and it increases network traffic overall.

It facilitates controlling abuse, which would otherwide dwarf the
volume of legitimate traffic.

> Actually, the current proposal requires the MUAs to track changes in AQRY
> response format.   Even if the query uses AQPX, the MSA just returns the
> data provided by the MX server.

I'm not discussing the payload yet.  That's a subsequent conversation.
Also there's more to the protocol than just the payload, e.g.
evolution in the transport security model between MSA and MTA which
could be transparent to the MUA.

> Perhaps.  But axiomatically expecting the MUA to trust the MSA is still a
> Bad Idea.  If the MSA host is compromised, it doesn't matter whether the
> compromise is in the MSA code itself or in its resolver.

Indeed, if the MSA is compromised, users may see forged keys, but
the MSA would have to stay compromised indefinitely, or users would
later see unforged keys, and MUAs might let users know that keys
for a recipient changed, and that they might double check that this
happened with the correspondent.  Users who already have keys and
are just verifying freshness might also be alerted to the change.

To reduce alert frequency, we could look into payload formats in
which new keys are signed by old keys, so that routine key changes
are not a source of constant false positives, and only "unplanned"
key changes raise alerts.

> I think it makes sense to not waste time arguing about a proposal that isn't
> yet developed in sufficient detail.   That time is better spent actually
> developing a proposal.   I appreciate the feedback on the current proposal
> and hope it leads to making the next proposal stronger.

Sure we can chat off-list if that might be helpful, and resume the
public discussion after the next version.  Over and out.

-- 
	Viktor.

---

From: Keith Moore <[email-masked]>
Date: Sat, 01 Aug 2015 01:31:02 -0400

> all the hard-lifting is done by the MSA.

It's pointless to continue arguing about this.

> operations now and then.  Much cheaper than streaming Neflix.

Agree about pocket super-computers.  Can you elaborate on what you mean 
by "mobility in and out of captive portals"?

>> Neither do DNSSEC-signed TLSA records, then.

Both X.509 DV and DNSSEC-signed TLSA records basically equate control 
over the domain with the required assurance.   That's already a leap 
because an email address really isn't a person's identity, the domain 
isn't really designed to be a CA (even for its own users), and the 
sender really wants to send to a person rather than whoever happens to 
be currently associated with an email address.   But let's accept that 
as a necessary limitation for now.   X.509 DV has the additional problem 
that any trusted CA can sign any key.   DNSSEC has better partitioning, 
as you point out, but trusting the AD bit is a hole big enough to fly a 
747 through, and there are lots of known implementation bugs.   So the 
threats are different, but I can't make a case that in practice DANE is 
inherently more secure than X.509 DV.

> No DNSSEC is stronger than DV

Only if you ignore the other weaknesses in DNSSEC protocol and 
implementations.  See above.

> volume of legitimate traffic.

No it doesn't, because there's no way to prevent abusive clients from 
talking directly to SMTP servers.   Port 25 blocking, while widespread, 
is far from universal.

> happened with the correspondent.

So it's just like when using an ssh client that says "hey, the remote 
host's key changed".   Users learn to click "ok" and continue as if 
nothing happened.

Keith