Ben Schwartz wrote in
<caodqrvpxhvou8sefqc4zpiyyhos_u+20je59rruz5lbdqxz...@mail.gmail.com>:
|On Sat, May 30, 2026 at 3:14 PM S Kishore <[email protected]> wrote:
|...
|> Just a point of clarification: DNSSEC is not mandatory in the draft; \
|> it is recommended.
|
|Yes, but it needs to be mandatory in this design. Otherwise, any
|on-path attacker can replace the DKA TXT record with one that points
|to the attacker's DKA, allowing them to impersonate all identities on
|the victim domain.
|
|...
|> A .well-known pointer would also not eliminate the underlying DNS \
|> security dependency. A client still has to use DNS to reach the HTTPS \
|> origin serving that .well-known resource, so absent DNSSEC, both \
|> the DNS-based designation and the .well-known alternative remain \
|> vulnerable to DNS redirection at discovery time.
|
|No, HTTPS is not vulnerable to "DNS redirection" of the client. The
|attacker first has to fool the Certificate Authority in order to get a
|mis-issued certificate.
To me it seems all of DNS is highly suspicious unless DNSSEC usage
is omnipresent.
For example, a couple of weeks ago DENIC (manager of the .de top
domain) messed up their DNSSEC signature.
I was more than surprised to see that even the omnipresent and
omnipotent 8.8.8.8 nameservers, and more, do not even seem to
*verify* signatures at all. (In fact i would have thought they
use protected zone transfers or what, at that scale and potency.)
Also other upstream servers/recursive resolvers do not even
verify.
So in the end it was my local dnsmasq cache producing failures
because of DNSSEC verification, which is why i first thought
something wrong.
In short: they hammered through bogus data for hours.
I have not been "cultivated asian", but "8" is precious, and that
is just bogus. Not 8, anyhow.
|...
|> Control of an email address can be verified using existing Internet \
|> mechanisms, in particular mailbox control and DKIM.
|
|I think the draft should also note the possibility of the DKA and
|email host publishing key assignments by private arrangement. For
|email providers who already perform key management on behalf of the
|accounts on the domain, this seems likely to be more reliable than the
|"in band" mechanism.
I privately lost my teeth on bootstrapping, fwiw.
Personally i would feel best if i would have my own key that my
domain seller or top domain manager signs.
It is easy to create a certificate request, if only advised
humanly. I was deeply disappointed when about 25 years ago the
new German passport did not come with "S/MIME and PGP for
everyone", plus a little booklet, you know.
I would always prefer to use it if only i could.
(In the meantime the corresponding thing luckily belongs a.k.a. is
owned by Germany again. You know i hate the private sector where
it doesn't belong. Sure, General Electric builds atomic bombs,
but that is how it is.)
I am thankful for ACME, not to be misunderstood. I even do
$SERVER["socket"] == ":80" {
$HTTP["url"] =~ "^/\.well-known" {
url.redirect = ("" =>
"https://${url.authority}${url.path}${qsa}";)
}
}
and it works (but sure: fwiw).
But i would never praise certificate authorities, especially given
that I as user have very little insight into which programs use
which CA pool comes from where.
It may be visualization and centralization of such is acceptable
to average users on a system sold by a big vendor, .. but i have
doubts. (It definitely was terrifying ~15 years ago.)
DNSSEC with a local cache, that i possibly can look into etc, or
even (ha!), optionally, TOFU-hooked, that would be streamlined.
(It surely is hard to believe to get some nice user interface
given that firefox for example does not even offer a graspable
view on local data / cookies.)
--End of <[email protected]\
.com>
And those guys, for example, look up SPF and (RSA) DKIM. It could
be they use 8.8.8.8 for that.
--steffen
|
|Der Kragenbaer, The moon bear,
|der holt sich munter he cheerfully and one by one
|einen nach dem anderen runter wa.ks himself off
|(By Robert Gernhardt)
_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]
