| Newsgroups |
gmane.ietf.dnsop,gmane.ietf.apps-discuss |
| Message-ID |
<[email protected]> |
From my perspective, and I might be completely wrong.
I am for a DNSSEC-signed record pointing to the DKA to enable the explicit declaration of the endpoint.
I am for requiring a (trusted-root anchored) CA-signed SSL certificate for the HTTP-endpoint.
Considering that many organizations outsource their “main” web to a hosting provider that _could_ provide falsified responses something more is needed to start the indication of trust. They (security org, webhost and email provider) might have completely different security requirements or even different organizational ownerships. Both (DNS record and certificate) should be required to establish trust(worthiness) but other discovery methods could be used. If DNSSEC is missing then the certificate could indicate trustworthiness but it should be flagged, If that is not acceptable then the trust should fail. If the CA-signed SSL certificate is missing then the DNSSEC-signed record is useless since an unprotected endpoint is open for hijacking and the trust should fail but it could be flagged instead. If both are missing then the trust should fail but could be flagged instead. Different levels of trust that can be assessed.
Internet is dangerous country – it is still the responsibility of each party to assess the security and trust in all matters - but if both measures resolves to “true” then it would indicate a certain (good?) level of trust. It is not perfect, a rogue DNS-operator with access to the domains DNSSEC-keys could forge whatever they want and establish their own HTTP-endpoint with a valid certificate, but no technical solution is ever perfect without the proper organizational rules, management and oversight – and even with all the “proper” rules in the world it won’t be perfect, but it just might be adequate.
Without a DNS record for DKA, if I have a large number of email domains at my organization then I would need to create/alias a .well-known for each with my webhost – and possibly extend the certificate with new alternate names each time. With DNS I can just point to the same DKA like I can with DMARC (should also follow the same DNS “backlink” authorization as DMARC?) at the time I establish a new domain with email capability. On the other side is email subdomains under different organizational ownership where a central DKA is unwanted if discovery is based on some style of "N level after TLD"-discovery. Personally I prefer explicit declaration since it affords me the most flexibility.
The fact that DNSSEC is not universally deployed is another problem and, IMHO, shouldn’t be used to discourage adding DNS-based (security related or not) measures.
Kind regards
Patrik Graeser
Systems engineer
IT-infrastructure unit
The Swedish Board of Agriculture
-----Ursprungligt meddelande-----
Från: Ben Schwartz <[email protected]>
Skickat: den 26 juni 2026 16:11
Till: [email protected]
Kopia: [email protected]; [email protected]
Ämne: EXTERNT: [DNSOP] Re: [art] Re: DNS-designated Public Key Authorities (DKA)
On Thu, Jun 25, 2026 at 2:57 PM John Levine <[email protected]> wrote:
...
> At a lot of organizations the people who run the mail and the people
> who run the website do not talk to each other. So if you want to
> publish key info for [email protected] ... you would often be told
> to forget it.
Dynamic integration between the email account database and the web serving could be difficult, sure, but that's not what we're talking about here. All we need is a static JSON file at ./well-known/dka.json that says {"dka-url":
"https://dka-provider.example/"}. Even a pretty disorganized operation should be able to manage that.
...
> While an SMTP extension is a technical possibility, in practice, again
> forget it. SMTP has a VRFY command that you have probably never heard
> of which is intended to let you check if a mail address exists.
> Spammers discovered it about 30 years ago to harvest mail addresses, and everyone turned it off. A key server extension would be similarly unpopular.
We are starting from the assumption that the SMTP server operator _wants_ to announce a key distribution server. So why wouldn't they want to announce that server over SMTP?
This approach doesn't require the key _lookup_ to occur over SMTP.
Key lookup can (potentially) use a different server and a different protocol.
> So I guess the mta-sts like hack is a possibility, but I would think
> hard about how you are going to make it usable without also making it an attractive nuisance.
Choosing a fixed subdomain is also possible I guess. I don't see why it's preferable over .well-known though.
--Ben
_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]
_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]