Subject: Quic: the elephant in the room

From: Michael Thomas <[email-masked]>
Date: Fri, 9 Apr 2021 16:16:18 -0700

I wrote a blog post about how something like DANE could be used instead 
of certificates for the TLS handshake to get it back to the original 3 
packet handshake. I know that isn't news to a lot of people, but the 
interesting part is that a Google could perform an experiment to see how 
well it works in real life just like they did with Quic and Spdy. Since 
Quic is all about making setup time faster, it seems like a pretty 
reasonable experiment since it would cut out 2 packets generally 
speaking since DNS can be cached.

https://rip-van-webble.blogspot.com/2021/04/quic-elephant-in-room.html

Mike

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 9 Apr 2021 19:26:23 -0400

It is only a 'three packet handshake' if you ignore the off path
interactions with the DNS service. The timeout on DNS tens to be rather
smaller than that most would be comfortable with for crypto.

---

From: Michael Thomas <[email-masked]>
Date: Fri, 9 Apr 2021 16:34:37 -0700

On 4/9/21 4:26 PM, Phillip Hallam-Baker wrote:
> interactions with the DNS service. The timeout on DNS tens to be 
> rather smaller than that most would be comfortable with for crypto.

I don't see why it can't be long lived, but even normal TTL's would get 
amortized over a lot of connections. Right now with certs it is a 5 
message affair which cannot get better. But that is why one of 
$BROWSERVENDORS doing an experiment would be helpful.

Mike

>
> On Fri, Apr 9, 2021 at 7:17 PM Michael Thomas <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>
>     <https://rip-van-webble.blogspot.com/2021/04/quic-elephant-in-room.html>
>
>     Mike
>

---

From: Ben Laurie <[email-masked]>
Date: Sat, 10 Apr 2021 10:29:42 +0100

On Sat, 10 Apr 2021 at 00:35, Michael Thomas <[email-masked]> wrote:

> amortized over a lot of connections. Right now with certs it is a 5 message
> affair which cannot get better. But that is why one of $BROWSERVENDORS
> doing an experiment would be helpful.
>

When I was designing Certificate Transparency, Chrome ruled out any side
channel communications requirement during handshake. Given that DNS is
required anyway, perhaps this would be different. However, the other
problem is introducing DNS as a trust root - the DNS hierarchy is
considerably less secure than CAs were even before CT but now it's really a
very poor option in comparison.

Could be fixed with DNS Transparency, of course.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Sat, 10 Apr 2021 11:49:25 +0200

On Sat, Apr 10, 2021 at 10:29:42AM +0100,
 Ben Laurie <benl=[email-masked]> wrote 
 a message of 138 lines which said:

> However, the other problem is introducing DNS as a trust root - the
> DNS hierarchy is considerably less secure than CAs were even before
> CT but now it's really a very poor option in comparison.

It doesn't matter since, if you control the DNS, you can have your
certificate, anyway. So, it doesn't change the picture.

---

From: Ben Laurie <[email-masked]>
Date: Sat, 10 Apr 2021 11:38:27 +0100

> certificate, anyway. So, it doesn't change the picture.

This is only relevant if the controller of the DNS is not the "right" one -
in which case, CT will reveal both the existence of the cert and the
implied DNS compromise, which they can then rectify. If DNS were the only
authority it would be much harder to detect.

So. it does matter.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sat, 10 Apr 2021 12:58:28 -0400

> Could be fixed with DNS Transparency, of course.

That is not the approach I am planning to take.

DNSSEC will always be an afterthought and Domain Validation in the WebPKI
will always be weak because the role of the CA is to recover information
thrown away in the DNS registration scheme.

Build out the name registry and the PKI in parallel and the need for Domain
Validation goes away entirely.

My current proposal is focused on the never solved problem of credentialing
people rather than organizations and employees in organizations. But it
could also be used for organizations:

GitHub - hallambaker/Callsign <https://github.com/hallambaker/Callsign>
Mathematical Mesh 3.0 Part VII: Mesh Callsign Service (ietf.org)
<https://www.ietf.org/id/draft-hallambaker-mesh-callsign-00.html>

This is not built on Certificate Transparency but it does apply many of the
same ideas.

---

From: Michael Thomas <[email-masked]>
Date: Sat, 10 Apr 2021 10:04:30 -0700

On 4/10/21 2:29 AM, Ben Laurie wrote:
>
>
> On Sat, 10 Apr 2021 at 00:35, Michael Thomas <[email-masked] 
>     I don't see why it can't be long lived, but even normal TTL's
>     would get amortized over a lot of connections. Right now with
>     certs it is a 5 message affair which cannot get better. But that
>     is why one of $BROWSERVENDORS doing an experiment would be helpful.
>
>
> When I was designing Certificate Transparency, Chrome ruled out any 
> side channel communications requirement during handshake. Given that 
> DNS is required anyway, perhaps this would be different. However, the 
> other problem is introducing DNS as a trust root - the DNS hierarchy 
> is considerably less secure than CAs were even before CT but now it's 
> really a very poor option in comparison.
>
DNS is the natural trust anchor for the internet. And I don't know what 
"considerably less secure" means. If you mean that DNSSec is broken, 
then you should say that. If you mean that DNSsec deployment is thin, 
that is quite another thing, and that is all about the incentives to 
deploy. I don't consider a plethora of CA's of varying security 
responsibility to be a feature and in fact is a bug.

Mike

---

From: Nico Williams <[email-masked]>
Date: Sat, 10 Apr 2021 12:57:13 -0500

> very poor option in comparison.

I disagree with that last sentence.

First, having a PKI with hard naming constraints and a single root
(though with alternatives supported) is considerably better than WebPKI,
which has neither of those.  This alone is not enough because resolvers
generally send the full qname to every DNS server on the resolution
path, so . and ccTLDs get a chance to impersonate if they want to, but...

...second, using qname minimization makes it very difficult for root
zone or ccTLD operators to mount impersonation attacks because they
can't know the full qname, so if they want to impersonate, they have to
impersonate all qnames you end up asking for, not just the one target.
It can be done, of course.  I imagine something like a stingray device
that is preloaded with .'s signing keys and so can MITM everything,
though that would be an enormous risk to the device's operators.

I expect an objection about how many round trips qname minimization
adds.  Though if you're not hitting caches then you have those extra
round trips anyways, and recursive caching resolvers should get the full
qname, so maybe qname minimization is not a performance disaster.

> Could be fixed with DNS Transparency, of course.

Well, yes, that could and should be done.

Nico
--

---

From: Viktor Dukhovni <[email-masked]>
Date: Sat, 10 Apr 2021 14:08:30 -0400

> On Apr 10, 2021, at 1:57 PM, Nico Williams <[email-masked]> wrote:
> 
> which has neither of those.

Ben's claim that CAs are "more secure" than DNSSEC is demonstrably
in error in a world where all that CAs do is issue DV certs that
attest to "domain control".

If you don't trust the ICANN root, you can't trust DV certs, since
all they do is memoise some DNS-derived data you don't trust.  Indeed
it takes DNSSEC (and CAs honouring DNSSEC-signed CAA records) to somewhat
improve the rather weak assurance that DV provides.

Perhaps CT adequately hardens this model for Google's domains, if
they're sufficiently vigilant to detect unauthorised certificate
issuance (after the fact), but for the rest of us, tracking the
CT logs is not actually practical.

-- 
	Viktor.

---

From: Michael Thomas <[email-masked]>
Date: Sat, 10 Apr 2021 11:13:23 -0700

On 4/10/21 2:29 AM, Ben Laurie wrote:
> DNS is required anyway, perhaps this would be different.

It occurs to me that it would be possible to return the DANE RR's as 
additional RR's in the address query so that it is always the case that 
it is in cache for the sake of the handshake. Or it could possibly be 
the other way around: you query for the DANE RR and get back A/AAAA 
records as well. I don't know how this might work in real life, but it 
seems theoretically possible. That would satisfy the no "side channel" rule.

Mike

---

From: "John Levine" <[email-masked]>
Date: 10 Apr 2021 14:31:19 -0400

>attest to "domain control".

More than that, the security of your DNS depends on the providers in
the chain between you and the root, which is typically short, and over
which you have a lot of control. If you have a valuable domain, you
can use a high security registrar that applies controls to zone
changes. With PKI, your security is only as good as the worst of all
of the CAs in someones browser, nearly all of which have no relation
to you and most of which you've never heard of.

This is not a new argument and I doubt we're going to say anything new here.

R's,
John

PS: I know about CAA, but if you believe it matters, that means CA
security can be at best as good as DNS security.

---

From: Michael Thomas <[email-masked]>
Date: Sat, 10 Apr 2021 11:54:57 -0700

> This is not a new argument and I doubt we're going to say anything new here.
The jist of my post was not that there was something new, per se but 
that there are many companies like google, ms, apple who are in a good 
position to run an experiment and see how it pans out from a deployment 
standpoint. One of the good things to come out of quic and spdy is the 
revelation that if you own both ends of the platform, you don't have to 
get buy in to just see if you're on the right track or not. I mean I 
could build up an experiment just to show proof of concept, but I don't 
have the ability to see in the real world how much it helps like the 
real world data they got with quic and spdy.

Heck, maybe even IETF or W3C could have a hand in coordinating 
experiments so that they can be fed back to the appropriate working 
groups. Like I said, probably the biggest takeaway of quic is that we 
can prove whether something deserves more work or not instead of usual 
Build it and They Will Come failure mode which DANE seems to be 
suffering as well from what I can tell.

Mike

---

From: Nico Williams <[email-masked]>
Date: Sat, 10 Apr 2021 14:50:49 -0500

> CT logs is not actually practical.

Indeed, CT works only if people bother to do enough log checking to
increase the risk -real and perceived- to malefactors with access to CA
credentials.  CT can fail to get there generally, leaving us with the
same old name-constraint-less, multi-root WebPKI.

CT is not the answer, and it's not even an answer.  CT might help, and
it's better than nothing, but it's certainly not better than also
addressing the other issues, and it's not better than only addressing
the other issues either.

If QUIC were to depend on DANE, the result would be a shot in the arm to
DNSSEC deployment, which would instantly address the two biggest
problems with WebPKI.

Nico
--

---

From: Michael Thomas <[email-masked]>
Date: Sat, 10 Apr 2021 12:59:34 -0700

> DNSSEC deployment, which would instantly address the two biggest
Yeah, I was trying to verify whether google, amazon and facebook sign 
but it appears not? my dig fu is admittedly bad so I might be full of it 
(hopefully).

Let me ask a pointed question: if we used DANE+DNSSec do we have 
confidence in the security of the solution? I think we'd have to have a 
lot of confidence in both that they are really ready for prime time.

Again, this yet another reason why an experiment would be extremely 
instructive because they could limit the scope to steer out of 
ecommerce, etc, until the results are in.

Mike

---

From: Nico Williams <[email-masked]>
Date: Sat, 10 Apr 2021 15:39:36 -0500

On Sat, Apr 10, 2021 at 12:59:34PM -0700, Michael Thomas wrote:
> Let me ask a pointed question: if we used DANE+DNSSec do we have confidence
> in the security of the solution? I think we'd have to have a lot of
> confidence in both that they are really ready for prime time.

I do, for the reasons I gave.  It can't be worse than WebPKI, that's for
sure.  At least in a pre-post-quantum world.  In a PQ world I suspect
we'd want to have something more akin to a PKI + Needham-Schroeder to
optimize PQ PK.

I think I would prefer a single-root PKIX PKI with name constraints to
DNSSEC/DANE.  Perhaps we can still get that by getting registries/
registrars to operate name-constrained CAs, and replace WebPKI with a
DNS-parallel PKI.  But at this point DNSSEC/DANE seems much more
realistic as a way to get to a single-root name constrained PKI for
domainnames.  Also, DNSSEC can do secure denial of existence while PKIX
cannot because wheras DNSSEC is based on a directory (DNS), x.509/PKIX,
though it was meant to be used with directories (DAP) doesn't really
have a viable global directory scheme (imagine using LDAP as we use
DNS!), and doesn't have a directory that can do secure denial of
existence either.

Nico
--

---

From: Viktor Dukhovni <[email-masked]>
Date: Sat, 10 Apr 2021 16:49:32 -0400

> but it appears not? my dig fu is admittedly bad so I might be full of it 

The largest US-based Internet companies have not yet signed their DNS
zones.  The DNSSEC-signed domains among the top 500 Alexa-ranked sites
are:

    europa.eu 53
    nih.gov 62
    paypal.com 81
    cloudflare.com 91
    chaturbate.com 115
    cdc.gov 118
    canva.com 158
    stanford.edu 173
    nasa.gov 198
    force.com 201
    time.com 208
    salesforce.com 211
    doi.org 235
    foxnews.com 238
    padlet.com 254
    thestartmagazine.com 256
    themeforest.net 258
    debian.org 271
    berkeley.edu 279
    statcounter.com 285
    addtoany.com 290
    mediafire.com 309
    taboola.com 313
    ikea.com 321
    loc.gov 331
    pixabay.com 334
    ietf.org 336
    pki.goog 344
    irs.gov 349
    discord.com 354
    fda.gov 375
    avito.ru 385
    hubspot.com 387
    quizlet.com 392
    whitehouse.gov 412
    usda.gov 447
    state.gov 448
    epa.gov 489
    noaa.gov 490
    sciencedaily.com 491

-- 
    Viktor.

---

From: Michael Thomas <[email-masked]>
Date: Sat, 10 Apr 2021 16:28:37 -0700

> zones.  The DNSSEC-signed domains among the top 500 Alexa-ranked sites

[]

Wow, that's really sad. But this is all about having some incentive is 
my bet. "I should sign my zone" is a lot different than "I should sign 
my zone so that quic is even quic-er"

Mike

---

From: Michael Thomas <[email-masked]>
Date: Sat, 10 Apr 2021 17:07:23 -0700

> DNS!), and doesn't have a directory that can do secure denial of
My take on DNSSec is that I only understand some of the large contours 
but that I trust that IETF process would not produce something a 
complete flop from a technical standpoint, though that does happen too. 
But DNS is pretty damn important, so I hope the clue level looking it 
was intense. The biggest IETF failing is solving problems nobody needs 
solved. Maybe DANE can be a sleeper that was just ahead of its time.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sun, 11 Apr 2021 00:20:28 -0400

The number of people signing is utterly irrelevant. Nothing was ever
secured by creating a digital signature, not once, not ever.

Only VERIFYING digital signatures provides security. And nobody knows what
to do when DNSSEC validation fails so nobody really does it and nobody is
likely to if people keep trying to apply 1990s thinking to 2020s problems.

What this means for NFTs is left as an exercise for the reader...

On the trust root issue. Alice should be the root of trust for Alice, Bob
should be the root of trust for Bob. That is what I have been building. And
with an application that secures data at rest without rendering it unusable.

What if Alice could register a lifelong callsign enrolled in an append only
log which is ultimately notarized by every relying party?

@alice -> [key: <alice's root key>, service: @provider]
@provider -> [key: <provider root key>, DNS 10.10.10.10]

What is this, well we have roots of trust for Alice and her Mesh service
provider. And her service provider publishes the authoritative zone
alice.mesh from an alt.root DNS service at 10.10.10.10 and this is DNSSEC
signed under a root key countersigned under <alice's root key> providing
security policy information and the TLS certs are signed under a chain
cross certified by <alice's root key>.

If six people here tell me they have read the drafts, I will add IPv6 to
the testbed service when it goes live later this year.

If successful, this will disrupt the business model of every CA that does
not have the foresight to become a Mesh Service Provider in which case the
threshold approach I make use of will provide them with significant and
more substantial new business opportunities.

The core concept of the callsign registry is that it is 'number portability
for the Internet'. Alice owns @alice for life. The only time a callsign is
ever reassigned without consent is when it is a trademark issue. I
predicted the anti-trust storm and I have thought of a way out.

Of course the callsign registry will have to be public goods administered
through a not for profit. Callsigns have to be sufficiently cheap to create
that we can give everyone on the planet at least one. DNS names cost
$10/yr. I want to make names available for $0.10 for life. At that price
banks and health care providers will likely find it cheaper to by them on
behalf of customers who haven't got one yet.

---

From: Viktor Dukhovni <[email-masked]>
Date: Sun, 11 Apr 2021 00:35:31 -0400

On Sun, Apr 11, 2021 at 12:20:28AM -0400, Phillip Hallam-Baker wrote:

> to do when DNSSEC validation fails so nobody really does it

This is false both in premise and conclusion.  I was tempted to ignore
the rest of the post, but ...

> with an application that secures data at rest without rendering it unusable.

I concur that the mesh is a good idea worth pursuing, you don't need to
try to prove everything/everyone else wrong in order be right.

If the mesh some day also ends up authenticating not only individuals
but also network services, so be it.  I hope it works out.

-- 
    Viktor.

---

From: Ben Laurie <[email-masked]>
Date: Sun, 11 Apr 2021 15:34:06 +0100

On Sat, 10 Apr 2021 at 18:04, Michael Thomas <[email-masked]> wrote:

> "considerably less secure" means. If you mean that DNSSec is broken, then
> you should say that. If you mean that DNSsec deployment is thin, that is
> quite another thing, and that is all about the incentives to deploy. I
> don't consider a plethora of CA's of varying security responsibility to be
> a feature and in fact is a bug.
>
What I mean is that the authorities for DNS get compromised far more often
than CAs do. Also, DNS has the same plethora of authorities with varying
security responsibility.

---

From: Ben Laurie <[email-masked]>
Date: Sun, 11 Apr 2021 15:38:32 +0100

> attest to "domain control".

If that were the only consideration, I would agree. However, as I replied a
few minutes ago, the security of the operators is also important and it was
that I was referring to.

> improve the rather weak assurance that DV provides.

Incorrect - CT would reveal ICANN's misbehaviour.

> CT logs is not actually practical.

I do agree that we really also need verifiable maps of domain -> certs
which would make it easy for anyone to monitor their own domains. However,
there are also plenty of services that will do this tracking for you (yes,
you do have to trust them to behave themselves).

---

From: Ben Laurie <[email-masked]>
Date: Sun, 11 Apr 2021 15:39:56 +0100

On Sat, 10 Apr 2021 at 21:40, Nico Williams <[email-masked]> wrote:

> confidence
> sure.

It is not for sure, because DNS has no transparency requirements.

>   At least in a pre-post-quantum world.  In a PQ world I suspect

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sun, 11 Apr 2021 10:56:03 -0400

> the rest of the post, but ...

If nobody is ever going to check the sigs, they could simply be random
bytes.

I had a PGP sig on some of my USENET posts for a while. Nobody ever checked
it and nobody ever noticed it was a static sig that never changed.

> try to prove everything/everyone else wrong in order be right.

There are two possible ways forward. One it to use the Mesh itself and the
other is
to backport ideas proven in the Mesh back to the legacy system.

To justify the deployment of a new infrastructure, I do have to show that
backporting is infeasible. I have paid particular attention to the reason
for
the failure of DNSSEC and DANE precisely because I want to understand what
the criteria are for success.

The conclusion I find it difficult to avoid is that it is possible to graft
some
security features onto an insecure system but it is not practical to move
from an insecure default permit environment to a secure default deny
environment.

---

From: Michael Thomas <[email-masked]>
Date: Sun, 11 Apr 2021 08:28:41 -0700

On 4/11/21 7:56 AM, Phillip Hallam-Baker wrote:
>
>
> On Sun, Apr 11, 2021 at 12:36 AM Viktor Dukhovni 
> <[email-masked] <mailto:[email-masked]>> wrote:
>

If Google implemented DANE in Chrome, that's who checks. It's really 
that simple.

> backporting is infeasible. I have paid particular attention to the 
> reason for

My take is that the reason for lack of uptake is that they are viewed as 
essentially superfluous. The same thing happened to SCTP as it was 
painful to get kernel adoption and firing up multiple TCP streams was a 
good enough bandaid. Then Quic came around with the goal of greatly 
reducing the setup time and finally fixing HoL blocking, and also 
learning that external dependencies is a good route to /dev/null. Google 
and others are completely at liberty to finish the job with Quic by 
adopting DANE and finally get back to a 3 way handshake (on average or 
possibly always). And they don't need to ask your, my, or anybody else's 
opinion on the matter which is a Good Thing.

Mike

---

From: Michael Thomas <[email-masked]>
Date: Sun, 11 Apr 2021 08:42:26 -0700

On 4/11/21 7:34 AM, Ben Laurie wrote:
>
>
> On Sat, 10 Apr 2021 at 18:04, Michael Thomas <[email-masked] 
>>>         It is only a 'three packet handshake' if you ignore the off
>>>         path interactions with the DNS service. The timeout on DNS
>>>         tens to be rather smaller than that most would be
>>>         comfortable with for crypto.
>>
>>         certs it is a 5 message affair which cannot get better. But
>>         that is why one of $BROWSERVENDORS doing an experiment would
>>         be helpful.
>>
>>
>>     When I was designing Certificate Transparency, Chrome ruled out
>>     any side channel communications requirement during handshake.
>>     Given that DNS is required anyway, perhaps this would be
>>     different. However, the other problem is introducing DNS as a
>>     trust root - the DNS hierarchy is considerably less secure than
>>     CAs were even before CT but now it's really a very poor option in
>>     comparison.
>>
>     DNS is the natural trust anchor for the internet. And I don't know
>     what "considerably less secure" means. If you mean that DNSSec is
>     broken, then you should say that. If you mean that DNSsec
>     deployment is thin, that is quite another thing, and that is all
>     about the incentives to deploy. I don't consider a plethora of
>     CA's of varying security responsibility to be a feature and in
>     fact is a bug.
>
> What I mean is that the authorities for DNS get compromised far more 
> often than CAs do. Also, DNS has the same plethora of authorities with 
> varying security responsibility.
>
Huh? Source?

Mike

---

From: Viktor Dukhovni <[email-masked]>
Date: Sun, 11 Apr 2021 11:59:35 -0400

On Sun, Apr 11, 2021 at 03:34:06PM +0100, Ben Laurie wrote:

> than CAs do.

But any compromise of a registrant, registrar or registry also
compromises CA certificate issuance.  The CAs are redundant so
long as the attestation they're performing is "domain control".

> Also, DNS has the same plethora of authorities with varying
> security responsibility.

Choose a security-conscious registrar, and apply registrar lock, and any
other available/applicable options to prevent unauthorised changes to
domain registration metadata.

-- 
    Viktor.

---

From: Michael Thomas <[email-masked]>
Date: Sun, 11 Apr 2021 09:08:54 -0700

> long as the attestation they're performing is "domain control".

Also: this seems highly suspect as there are a plethora of companies 
that offer both domain and certificate services. I find it pretty 
questionable that they would be competent on the CA front and 
incompetent on the DNS front. It doesn't do me any good to have a CA 
cert when nobody can route to it after all.

Mike

---

From: Nico Williams <[email-masked]>
Date: Sun, 11 Apr 2021 11:46:06 -0500

> than CAs do. Also, DNS has the same plethora of authorities with varying

When a registrar/registry gets compromised, it can issue credentials
only for things in and below its zone(s).  Customers can choose
registrars known for security.

When a WebPKI CA gets compromised, it can issue credentials for any
domainname anywhere in the DNS.  Customers can't choose to make lame CAs
not able to hurt them.

This is because one system has unyiedling name constraints, and the
other has none.  Name constraints are absolutely essential to a decent
PKI.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Sun, 11 Apr 2021 11:47:10 -0500

On Sun, Apr 11, 2021 at 03:39:56PM +0100, Ben Laurie wrote:
> > > confidence in the security of the solution? I think we'd have to
> > > have a lot of confidence in both that they are really ready for
> > > prime time.
> >
> > I do, for the reasons I gave.  It can't be worse than WebPKI, that's
> > for sure.
> 

It is for sure for the reasons I gave in other replies.  And CT can be
added.

---

From: "Salz, Rich" <[email-masked]>
Date: Sun, 11 Apr 2021 17:23:03 +0000

*   I don't see why [DNS timeouts] it can't be long lived, but even normal TTL's would get amortized over a lot of connections. Right now with certs it is a 5 message affair which cannot get better. But that is why one of $BROWSERVENDORS doing an experiment would be helpful.

There are use-cases where a five-second DNS TTL is important.  And they’re not amortized over multiple connections from *one* user, but rather affect *many* users.  Imagine an e-commerce site connected to two CDN’s who needs to switch.

---

From: Michael Thomas <[email-masked]>
Date: Sun, 11 Apr 2021 11:13:59 -0700

On 4/11/21 10:23 AM, Salz, Rich wrote:
>
>   * I don't see why [DNS timeouts] it can't be long lived, but even
>     normal TTL's would get amortized over a lot of connections. Right
>     now with certs it is a 5 message affair which cannot get better.
>     But that is why one of $BROWSERVENDORS doing an experiment would
>     be helpful.
>
> There are use-cases where a five-second DNS TTL is important.  And 
> they’re not amortized over multiple connections from **one** user, but 
> rather affect **many** users.  Imagine an e-commerce site connected to 
> two CDN’s who needs to switch.
>
The worst case is that it devolves into what we already have: 5 messages 
assuming NS records are cached normally.

Another approach using current infrastructure would be for the client to 
cache the certs and hand the server cert the fingerprint(s) in the 
ClientHello and the server sends down the chosen cert's fingerprint 
instead of the cert which could get it back to 3 messages too. That 
would require hacking on TLS though (assuming that somebody hasn't 
already thought of this). That has the upside is that it's the server 
chooses whether it wants to use the cached version or not too.

Mike

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sun, 11 Apr 2021 15:11:17 -0400

I made essentially the same argument to people at Google BEFORE the DANE
group was ever proposed. The answer they gave me then has not changed.

DANE was chartered over a decade ago. Individuals in that group made clear
that no input was going to be accepted from anyone who was a part of the
WebPKI world. The tactics used were intentionally exclusionary. Those of us
pointing out the limitations of the proposed approach were never given a
fair hearing.

It is now ten years since DANE was chartered. DANE has failed beyond the
very limited application to SMTP which was never really covered. The
argument for DANE was weak before LetsEncrypt was launched and it seems
highly unlikely future events are going to change that.

The TLSA model is simply the wrong model. If you want to change the way
discovery is done, you need to think about the full discovery chain. And
not least because DOH is another factor in this mix.

DANE and DPRIV should have all been a part of one effort that should have
included the introduction of SRV records for HTTP.

The key weakness in the DNS protocol is that the client-resolver
interaction is of an entirely different character to resolver-authoritative
and the current client-resolver interaction only supports requests for one
record at a time.

The kick off meeting for DPRIV was quite interesting. There should be
standing IESG instructions to prohibit chartering of any WG that is
premised on the need to finish something in a year, so it is essential that
it be done in exactly the way the proposers have already decided. Even more
so when the results from DPRIV could be easily foreseen from the fact it
was the same group that had hijacked DNS security policy with DANE.

I don't claim to always do the right thing but there are some folk who seem
to keep doing the same thing with the same outcome and for some reason they
get priority over folk who have actually built stuff that was successfully
deployed and is in use.

On Sun, Apr 11, 2021 at 2:14 PM Michael Thomas <[email-masked]> wrote:

>    - I don't see why [DNS timeouts] it can't be long lived, but even
>    normal TTL's would get amortized over a lot of connections. Right now with
>    certs it is a 5 message affair which cannot get better. But that is why one
>    of $BROWSERVENDORS doing an experiment would be helpful.
>
> There are use-cases where a five-second DNS TTL is important.  And they’re
> not amortized over multiple connections from **one** user, but rather
> affect **many** users.  Imagine an e-commerce site connected to two CDN’s
> who needs to switch.
>
> ClientHello and the server sends down the chosen cert's fingerprint instead
> of the cert which could get it back to 3 messages too. That would require
> hacking on TLS though (assuming that somebody hasn't already thought of
> this). That has the upside is that it's the server chooses whether it wants
> to use the cached version or not too.
>
> Mike
>
>
>

---

From: Michael Thomas <[email-masked]>
Date: Sun, 11 Apr 2021 12:34:35 -0700

On 4/11/21 12:11 PM, Phillip Hallam-Baker wrote:
> I made essentially the same argument to people at Google BEFORE the 
> DANE group was ever proposed. The answer they gave me then has not 
> changed.
>
> DANE was chartered over a decade ago. Individuals in that group made 
> clear that no input was going to be accepted from anyone who was a 
> part of the WebPKI world. The tactics used were intentionally 
> exclusionary. Those of us pointing out the limitations of the proposed 
> approach were never given a fair hearing.
>
> It is now ten years since DANE was chartered. DANE has failed beyond 
> the very limited application to SMTP which was never really covered. 
> The argument for DANE was weak before LetsEncrypt was launched and it 
> seems highly unlikely future events are going to change that.
>
>
> The TLSA model is simply the wrong model. If you want to change 
> the way discovery is done, you need to think about the full discovery 
> chain. And not least because DOH is another factor in this mix.
>
> DANE and DPRIV should have all been a part of one effort that should 
> have included the introduction of SRV records for HTTP.
>
> interaction is of an entirely different character to 
> resolver-authoritative and the current client-resolver interaction 
> only supports requests for one record at a time.
>
>
> premised on the need to finish something in a year, so it is essential 
> that it be done in exactly the way the proposers have already decided. 
> Even more so when the results from DPRIV could be easily foreseen from 
> the fact it was the same group that had hijacked DNS security policy 
> with DANE.
>
> I don't claim to always do the right thing but there are some folk who 
> seem to keep doing the same thing with the same outcome and for some 
> reason they get priority over folk who have actually built stuff that 
> was successfully deployed and is in use.
>
We already have a widely adopted example where we ignored the webpki 
folks too: DKIM. Certs are simply not needed in the vast majority of 
cases. DKIM could be adapted for this too, and doesn't have the downside 
of a new RR type which is always problematic. I assume that the people 
doing DANE were looking at DKIM's success as a template. Quite 
reasonably, IMO.

And I don't know how something that could reduce the message count to 
the original 3 way handshake is somehow the "wrong model". In what way? 
Is DKIM the wrong model too?

My larger point is that a Google-like company could and should run 
experiments to reduce the message count to 3 again to finish off what 
Quic is trying to accomplish. That is achievable, the only question is 
whether it's worth it which experiments would show.

Mike

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sun, 11 Apr 2021 15:56:14 -0400

On Sun, Apr 11, 2021 at 3:34 PM Michael Thomas <[email-masked]> wrote:

> seem to keep doing the same thing with the same outcome and for some reason
> they get priority over folk who have actually built stuff that was
> successfully deployed and is in use.
>
> We already have a widely adopted example where we ignored the webpki folks
> too: DKIM.
>
That is completely false. I was a member of the DKIM working group and its
predecessors. Two years before the DKIM WG was started, I designed a DNS
based key credentialing scheme together with a major technology vendor.
This was demonstrated to Yahoo by my CEO, Stratton Sclavos before the date
of the Yahoo patent claim.

The history here is that about a year earlier, I had had discussions with
Jon Callas, then CTO of PGP to see if we could persuade the market to move
beyond the S/MIME vs PGP format war. The thing that ultimately prevented
that work getting off the ground was not DKIM itself but the spam crisis
that had prompted it. It was clearly not time to propose a second,
different scheme. Some of the proposals I made in that group were intended
to keep the door open to progress towards an encryption solution.

I attended every plenary and interim meeting of DKIM and was in constant
contact with my peers in the wider industry.

> Certs are simply not needed in the vast majority of cases. DKIM could be
> adapted for this too, and doesn't have the downside of a new RR type which
> is always problematic. I assume that the people doing DANE were looking at
> DKIM's success as a template. Quite reasonably, IMO.
>
DANE works in a very different way and its cardinal sin is to mix
publication of security policy with publication of keys.

> And I don't know how something that could reduce the message count to the
> original 3 way handshake is somehow the "wrong model". In what way? Is DKIM
> the wrong model too?
>
DKIM is very definitely the wrong model and we knew that when we wrote the
spec. DKIM is simply the best model that was possible within the time frame
and with the vast and ugly legacy of SMTP deployment. It would have been
even uglier if not for SPF giving us some breathing room.

Given where we are now with all SMTP using STARTTLS, I would probably look
to implement TLS client auth instead which would allow fast restart to
amortize the public key operations. But thats not where we were then.

---

From: Nico Williams <[email-masked]>
Date: Sun, 11 Apr 2021 14:58:55 -0500

On Sun, Apr 11, 2021 at 05:23:03PM +0000, Salz, Rich wrote:
> they’re not amortized over multiple connections from *one* user, but
> rather affect *many* users.  Imagine an e-commerce site connected to

Not for DANE though.  If you want long-lived TLSA RRs + the ability to
quickly change keys, then use TLSA RRs to "certify" an intermediate PKIX
CA.

---

From: Michael Thomas <[email-masked]>
Date: Sun, 11 Apr 2021 13:13:05 -0700

On 4/11/21 12:56 PM, Phillip Hallam-Baker wrote:
>
>
> On Sun, Apr 11, 2021 at 3:34 PM Michael Thomas <[email-masked] 
>     We already have a widely adopted example where we ignored the
>     webpki folks too: DKIM.
>
> That is completely false. I was a member of the DKIM working group and 
> its predecessors. Two years before the DKIM WG was started, I designed 
> a DNS based key credentialing scheme together with a major technology 
> vendor. This was demonstrated to Yahoo by my CEO, Stratton Sclavos 
> before the date of the Yahoo patent claim.

Uh, Jim and I didn't use certificates in the design of IIM and neither 
did Mark with DK. Since the three of us were the basis of the combined 
protocol I think I have a little bit of insight into our thinking. So 
yes, we ignored the webpki guys including you. Thank goodness for that 
because a trip down that rat hole would have doomed it.

>
> The history here is that about a year earlier, I had had discussions 
> with Jon Callas, then CTO of PGP to see if we could persuade the 
> market to move beyond the S/MIME vs PGP format war. The thing that 
> ultimately prevented that work getting off the ground was not DKIM 
> itself but the spam crisis that had prompted it. It was clearly not 
> time to propose a second, different scheme. Some of the proposals I 
> made in that group were intended to keep the door open to progress 
> towards an encryption solution.

We showed Jon our design before we released it as a sanity check. At no 
time did he say anything about certificate based approaches.

>
> I attended every plenary and interim meeting of DKIM and was in 
> constant contact with my peers in the wider industry.
>
>     Certs are simply not needed in the vast majority of cases. DKIM
>     could be adapted for this too, and doesn't have the downside of a
>     new RR type which is always problematic. I assume that the people

The original IIM design used SRV records to find key servers. It's 
looking more and more that it was actually the right design. But Cisco 
was nobody with email so it was easier to go with flow of DK. I was the 
original one in our group to advocate that and I'm at peace with that.

>     And I don't know how something that could reduce the message count
>     to the original 3 way handshake is somehow the "wrong model". In
>     what way? Is DKIM the wrong model too?
>
> DKIM is very definitely the wrong model and we knew that when we wrote 
> the spec. DKIM is simply the best model that was possible within the 
> time frame and with the vast and ugly legacy of SMTP deployment. It 
> would have been even uglier if not for SPF giving us some breathing room.
I have no idea how something that signs billions and billions of 
messages a day can be considered the "wrong model" whatever that means.
>
> Given where we are now with all SMTP using STARTTLS, I would probably 
> look to implement TLS client auth instead which would allow fast 
> restart to amortize the public key operations. But thats not where we 
> were then.

TLS doesn't do anything to help the end-to-end authentication.

Mike

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sun, 11 Apr 2021 17:27:28 -0400

On Sun, Apr 11, 2021 at 4:13 PM Michael Thomas <[email-masked]> wrote:

>> e already have a widely adopted example where we ignored the webpki folks
>> too: DKIM.
>>
> Uh, Jim and I didn't use certificates in the design of IIM and neither did
> Mark with DK. Since the three of us were the basis of the combined protocol
>
I am very surprised that you are unaware of the Sender-ID protocol. Surely
Jim mentioned it to you. That was joint work with a third party. We agreed
not to put our proposal on the table so as to make it easier for work to
proceed.

Allowing others to take credit is one thing, misrepresenting my position is
quite another. There was never a question of using certificates. At the
time I was deeply involved trying to get the DNSSEC spec modified so we
could deploy it. The Assertion infrastructure in SAML was originally from
my Trust Assertion XML Infrastructure from the late 1990s. Together with
Barb Fox and Brian LaMacchia at Microsoft and Dave Solo at Citi, I had
proposed XKMS which doesn't have anything like a certificate.

> I think I have a little bit of insight into our thinking. So yes, we
> ignored the webpki guys including you. Thank goodness for that because a
> trip down that rat hole would have doomed it.
>
VRSN wanted a protocol with either raw keys or hashes of keys in the DNS so
that we could create a use case for DNSSEC.

> time did he say anything about certificate based approaches.
Again, you assume that VRSN was only interested in certificates.

The original IIM design used SRV records to find key servers. It's looking
> more and more that it was actually the right design. But Cisco was nobody
> with email so it was easier to go with flow of DK. I was the original one
> in our group to advocate that and I'm at peace with that.
>
I agree SRV was the right tool to do the job right, if you want to see the
approach I would do instead of DANE:

https://tools.ietf.org/id/draft-hallambaker-web-service-discovery-05.html
DNS Web Service Discovery (ietf.org)
<https://tools.ietf.org/id/draft-hallambaker-web-service-discovery-05.html>

Take the following service description:

_mmm._tcp.example.com SRV host1.example.com 0 10 80 host1.example.com
_mmm._tcp.example.com SRV host2.example.com 0 40 80 host2.example.com
_mmm._tcp.example.com TXT "version=1.0-2.0"
mmm.example.com       CNAME host3.example.com
host1.example.com     A 10.0.1.1
host2.example.com     A 10.0.1.2
_mmm._tcp.host2.example.com TXT "path=/service"
host3.example.com     A 10.0.1.1
host3.example.com     A 10.0.1.2

The text in the spec doesn't have TLS policy but you can see exactly where
it would go. I could decorate the _mmm._tcp.example.com record to specify
policy for all the hosts or do it on a granular per-host basis on _mmm._
tcp.host2.example.com.

Starting with TLSA and then trying to work out how SRV fitted in was an
obvious non starter.

> I have no idea how something that signs billions and billions of messages
> a day can be considered the "wrong model" whatever that means.
>

DKIM was designed for SMTP and SMTP alone. It is not a model that can be
generalized to other protocols and we knew that at the time. It is
certainly not a pattern I would want people to repeat as a paragon.

IIM was a better approach if you wanted to go for policy. The
web-service-discovery draft above is basically taking ideas from IIM and
Stuart Cheshire's DNS Service Discovery work.

> TLS doesn't do anything to help the end-to-end authentication.
DKIM provides 'middle to end' authentication, not end to end. Since it is
(usually) checked only in the middle, middle to middle might have been as
good a choice.

The reason I think it might have been the right approach is that we
wouldn't have needed to sit through the endless discussions of envelope vs
sender From, the vagaries of sending mail etc. But at the time it was the
wrong approach because much as I would have wanted to use spam to drive
STARTTLS deployment, that approach almost never works.

---

From: "Salz, Rich" <[email-masked]>
Date: Sun, 11 Apr 2021 22:18:39 +0000

>  Imagine an e-commerce site connected to

I don't understand.  Suppose www.ecomm.com, a big e-commerce site (or www.kingdom.com, a government-run broadcasting company, many examples work), uses cdn1 and cdn2 in some specific order and www.ecomm.com is CNAME'd to cdn1. Suppose they want to switch from cdn1 to cdn2 for some reason.

How does www.ecomm.comm switch their DNSSEC records quickly enough?  I'm sure I am missing something.

---

From: Ben Laurie <[email-masked]>
Date: Sun, 11 Apr 2021 23:18:39 +0100

On Sun, 11 Apr 2021 at 17:00, Viktor Dukhovni <[email-masked]>
wrote:

> often

CT makes that untrue. Why is this not obvious?

> domain registration metadata.

Of course anyone can trivially figure this out. Not.

---

From: Ben Laurie <[email-masked]>
Date: Sun, 11 Apr 2021 23:20:30 +0100

> than CAs do. Also, DNS has the same plethora of authorities with varying
I am sorry that my source is not verifiable (see "transparency is a good
thing"). My experience is that certificates have been seriously compromised
at least an order of magnitude less often than domains.

On "plethora of authorities" that is obvious from inspection.

---

From: Michael Thomas <[email-masked]>
Date: Sun, 11 Apr 2021 15:26:32 -0700

On 4/11/21 2:27 PM, Phillip Hallam-Baker wrote:
> On Sun, Apr 11, 2021 at 4:13 PM Michael Thomas <[email-masked] 
>>         e already have a widely adopted example where we ignored the
>>         webpki folks too: DKIM.
>>
>>     That is completely false. I was a member of the DKIM working
>>     group and its predecessors. Two years before the DKIM WG was
>>     started, I designed a DNS based key credentialing scheme together
>>     with a major technology vendor. This was demonstrated to Yahoo by
>>     my CEO, Stratton Sclavos before the date of the Yahoo patent claim.
>
>     Uh, Jim and I didn't use certificates in the design of IIM and
>     neither did Mark with DK. Since the three of us were the basis of
>     the combined protocol
>
> I am very surprised that you are unaware of the Sender-ID protocol. 
> Surely Jim mentioned it to you. That was joint work with a third 
> party. We agreed not to put our proposal on the table so as to make it 
> easier for work to proceed.

I don't remember when we became aware of sender-id. i don't know what it 
has to do with anything either.

>     We showed Jon our design before we released it as a sanity check.
>     At no time did he say anything about certificate based approaches.
>

It is a big part of their business model.

>
> DKIM was designed for SMTP and SMTP alone. It is not a model that can 
> be generalized to other protocols and we knew that at the time. It is 

The key fetching mechanism was purposefully made agnostic. We always 
envisioned it as being useful for other key distribution needs.

> web-service-discovery draft above is basically taking ideas from IIM 
> and Stuart Cheshire's DNS Service Discovery work.
>
>
>>     Given where we are now with all SMTP using STARTTLS, I would
>>     probably look to implement TLS client auth instead which would
>>     allow fast restart to amortize the public key operations. But
>>     thats not where we were then.
>
> DKIM provides 'middle to end' authentication, not end to end. Since it 
> is (usually) checked only in the middle, middle to middle might have 
> been as good a choice.

The point remains: DKIM brought something that goes beyond point to 
point to anchor reputation on.

Mike

---

From: Viktor Dukhovni <[email-masked]>
Date: Sun, 11 Apr 2021 18:33:29 -0400

> CT makes that untrue. Why is this not obvious?

Because:

    * CT is after the fact, plausibly too late.

    * As I mentioned before, CT is often impractical for
      typical domains != google.com.

      - They need to track the CT logs
      - They need to keep track of all legitimately issued certificates.
      - They need to detect unauthorised issuance quickly and have
        a mechanism in place to demand revocation.
      - Clients need to actually support CRLs, OCSP, ... 

      There's an awful lot of preconditions there for CT to actually be
      effective in practice.

> Of course anyone can trivially figure this out. Not.

It certainly isn't a secret, has been discussed on many lists over the
years, but I don't know of a canonical place to find this advice.  We
could publicise this better, not sure whether an IETF BCP would be the
right mechanism.  Yes, you're unlikely to learn this from a discount
registrar competing only on price and not on quality/security of service.

-- 
    Viktor.

---

From: Ben Laurie <[email-masked]>
Date: Sun, 11 Apr 2021 23:39:04 +0100

>     * CT is after the fact, plausibly too late.

And the on time DNS version is...?

>       typical domains != google.com.

Agree we need more.

>       - They need to keep track of all legitimately issued certificates.

You have a suggestion that does not need this?

>       There's an awful lot of preconditions there for CT to actually be

CT has been very effective in practice, despite these caveats. I do agree
there are problems it doesn't inherently solve.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sun, 11 Apr 2021 18:52:20 -0400

Since people continue to debate the CA vs DNS Registrar thing, I will just
point out that we haven't had a case where an outright criminal operation
has set up as a CA. In the DNS space we have had fully accredited
registrars that have been just that.

Also, the WebPKI is not designed to provide confidentiality or even
authenticate the parties. It is designed to make electronic commerce
possible in an open network by establishing accountability. Back in 1995,
export crypto was limited to 40 bits. People seem to forget that.

If people have a limited understanding of what the WebPKI is designed to do
and ignore all the parts that don't meet their expectations, well of course
they will end up assuming something else could do the same. But that
doesn't make it true.

I have never seen much if any value to domain validated certs at all. Just
use raw keys or self signed certs and you will get pretty much the same
benefit. I suggested Web browsers stop giving out the silly WARNING THIS
CONNECTION IS SECURED BUT NOT ENOUGH messages back in the 1990s. If a
browser is going to accept an entirely insecure connection, it should not
complain when something better is offered, but it shouldn't show a padlock
icon either.

The WebPKI is all about accountability through incorporation credentials.
That is why we never suggested it as the basis for DKIM technology. If
there was going to be a PKI backing up DKIM it would be advising sender
reputation.

---

From: David Conrad <[email-masked]>
Date: Sun, 11 Apr 2021 15:58:32 -0700

On Apr 11, 2021, at 7:56 AM, Phillip Hallam-Baker <[email-masked]> wrote:
> If nobody is ever going to check the sigs, they could simply be random bytes.

People are validating. See, e.g., https://stats.labs.apnic.net/dnssec

As you’re undoubtedly aware, validation failure results in a SERVFAIL response. In the case of an A or AAAA query, applications do not get an IP address back so it isn’t possible for users to "click through” to potentially compromised sites. Not an ideal error handling approach but arguably safer than alternatives.

Regards,
-drc

---

From: David Conrad <[email-masked]>
Date: Sun, 11 Apr 2021 16:00:18 -0700

On Apr 11, 2021, at 3:52 PM, Phillip Hallam-Baker <[email-masked]> wrote:
> Since people continue to debate the CA vs DNS Registrar thing, I will just point out that we haven't had a case where an outright criminal operation has set up as a CA. In the DNS space we have had fully accredited registrars that have been just that.

Who?

Thanks,
-drc

---

From: Viktor Dukhovni <[email-masked]>
Date: Sun, 11 Apr 2021 19:05:49 -0400

> And the on time DNS version is...?

Well the point (already made upthread, ...) is that if domain control is
compromised, so is certificate issuance, Let's Encrypt will happily
issue a certificate for a domain that's been taken over.  With CT
presently ineffective for most domains, the upshot (as stated upthread)
is that WebPKI is at least as vulnerable to compromise as DNS.

Now with DNSSEC and a registrar chosen for good security practices, one
can do better than DV.  True, there's no CT for DNSSEC, but in fact it
is considerably more difficult to surreptitiously compromise DNSSEC
without the domain owner noticing than it is to obtain a certificate
from the least meticulous CA.

There are of course pros/cons for CT and pros/cons for DNSSEC, but my
take is that architecturally DNSSEC is better suited for securing the
typical domain on the public Internet.  Adoption has been hampered
difficult KSK enrollment rollover, immaturity of tooling and by habitual
cynicism from plausibly authoritative voices.

Now in fact the tooling has improved dramatically in the last year or
two (see e.g. BIND 9.16 key management policies), and
registries/registrars are starting to implement CDS/CDNSKEY, see e.g.
recent talks by Brian Dickson of Godaddy about their plans.

Adoption has risen significantly over the last couple of years as well,
though sure, not yet at the pace I'd ultimately like to see.

Which leaves just the naysaying, which sounds mostly like a broken
record, that is disconnected from the changing realities on the
ground.  My take on the naysaying is: lead, follow or get out of
the way!.

> You have a suggestion that does not need this?

I recognise the reality of this, and therefore don't give as much weight
to the efficacy CT as you do.  The main thing that helps is short(er)
term certificates.  Perhaps LE could move from 90 days to 30 days or
even 7 days, but that would sure stress the CT logs even further.

> there are problems it doesn't inherently solve.

I agree it can be effective for well-resourced highly automated
operations, like e.g. google.com.  I am sceptical that it is
adding any value for the "average" domain.

-- 
    Viktor.

---

From: Keith Moore <[email-masked]>
Date: Sun, 11 Apr 2021 19:57:15 -0400

On 4/11/21 7:05 PM, Viktor Dukhovni wrote:

> typical domain on the public Internet.
Architectural arguments are great, but pragmatically speaking there seem 
to be significant deployment problems with DNSSEC.
> Adoption has been hampered

These aren't the problems (except perhaps immaturity of tooling) that 
most immediately come to mind.

Where is the easy to understand guide for how to sign your own RRs or 
zone(s), and to verify that the signing is properly done?

Which registrars provide tools for signing, or do you have to operate 
your own master DNS server in order to do that?

How long does it take for the typical domain name owner to sign their 
RRs for the first time?

What's the ongoing commitment in time for a domain owner to maintain 
DNSSEC for their RRs?

What's the immediate benefit to the signer from signing one's own RRs?   
(Note: if nothing is verifying signatures, the immediate benefit is zero.)

And how do we close these (and doubtless other) gaps?

I'd love for the Internet to be able to make better use of DNSSEC and to 
need to rely less on PKI.  But for all that I love about this idea, I 
don't think this is going to happen until most of these problems are fixed.

Keith

p.s. and I doubt I'm a plausibly authoritative voice on this subject, 
but please don't interpret this as cynicism so much as a genuine desire 
to get people using these tools.

---

From: Michael Thomas <[email-masked]>
Date: Sun, 11 Apr 2021 17:11:54 -0700

On 4/11/21 4:57 PM, Keith Moore wrote:
>
>
> What's the immediate benefit to the signer from signing one's own 
> RRs?   (Note: if nothing is verifying signatures, the immediate 
> benefit is zero.)

If a major browser vendor started using it to their advantage for faster 
session startup, you're now creating a reason to deploy. DNS manifestly 
works well enough in its "trust but verify" mode with webpki, but if you 
change some external things like speeding up serving up ads, etc 
hopefully ears will perk up.

Half of the battle with standards is answering the question "why should 
i care" with things that involve $$$.

Mike

---

From: Nico Williams <[email-masked]>
Date: Sun, 11 Apr 2021 19:26:35 -0500

> How does www.ecomm.comm switch their DNSSEC records quickly enough?  I'm sure I am missing something.

You publish TLSA RRs for the new one and after the switch you delete the
ones for the old one.  You can have more than one TLSA RR in a TLSA
RRset.

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 12 Apr 2021 01:54:23 +0000

Thanks for the explanation.  I don't know enough DNSSEC to know if that's actually deployable, but okay

---

From: Nico Williams <[email-masked]>
Date: Sun, 11 Apr 2021 21:59:32 -0500

> that's actually deployable, but okay

You can tune down TTLs before the change, etc.

Perhaps there is room for a certificate extension that says "invalidate
cached TLSA RRs cached before this $timestamp" (the timestamp might even
be the certificate's notBefore).  Then there would be no need to tune
down TTLs.

Nico
--

---

From: Viktor Dukhovni <[email-masked]>
Date: Sun, 11 Apr 2021 23:38:09 -0400

On Sun, Apr 11, 2021 at 10:18:39PM +0000, Salz, Rich wrote:

> > I don't understand.  Suppose www.ecomm.com, a big e-commerce site
> > (or www.kingdom.com, a government-run broadcasting company, many
> > examples work), uses cdn1 and cdn2 in some specific order and
> > www.ecomm.com is CNAME'd to cdn1. Suppose they want to switch from
> > cdn1 to cdn2 for some reason.
> > 

I often see CNAMEs used with CDNs:

    www.example.com. IN CNAME www.somecdn.example.

one may as well delegate the TLSA record management to the CDN:

    _443._tcp.www.example.com. IN CNAME _443._tcp.www.somecdn.example.

since the CDN in any case manages the certificate deployment, ...
Therefore, when it is time to switch CDNs:

    www.example.com. IN CNAME www.someothercdn.example.
    _443._tcp.www.example.com. IN CNAME _443._tcp.www.someothercdn.example.

If both providers are known to use the same intermediate CA (say Let's
Encrypt), then the TLSA RRSet can be published on the customer side,
and will survive certificate rollovers so long as the intermediate CA
key is not replaced (as it was recently for Let's Encrypt X3 -> R3).

But any sort of TLSA RR on the customer side, while the cert rollover
are managed by the CDN is too fragile.  The TLSA RRs should properly
be published by the CDN as above.

If indeed sub-minute migration from one CDN to another is required, then
the TTL for the _443._tcp.[...] CNAME would need to be sub-minute.  Is
such a short cutover time really a requirement?

-- 
    Viktor.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sun, 11 Apr 2021 23:39:07 -0400

> be the certificate's notBefore).  Then there would be no need to tune

Formula One autosport provides a model for what is and is not possible.

If you want to achieve the very highest level of performance it is
necessary to abandon the traditional engineering approach by which systems
are broken down into independent components and either consider different
decompositions that yield better performance or to abandon the
compartmentalization entirely and optimize across multiple concerns at
once. Thus the engine block is not merely the container for the pistons and
bearings, it is a structural member for the vehicle, a part of the
aerodynamic systems, etc. etc.

If you start with the assumption that you want to encrypt the
client-resolver lookup for privacy then you are going to be making a
breaking change there. Once a breaking change is proposed, we should seek
to absolutely maximize the value we get in return.

Omnibroker was a proposal that would have allowed the entire trust path to
be cached along with the DNS discovery data. Combine DNS resolution with
SRV/TXT policy publication, with SCVP delegated path discovery and apply
DNSSEC to the ensemble and for the cost of a single IP round trip to the
omnibroker and you can receive the network endpoint, the TLS credential
path in order so all the RP needs to do is to check the workings, and a
shared secret to encrypt the initial TLS handshake.

One round trip would save you many.

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 12 Apr 2021 00:53:19 -0400

> to be significant deployment problems with DNSSEC.

Historically, yes.  But substantial improvements have been made, and it
is now much easier than it used to be.

> > Adoption has been hampered by difficult KSK enrollment, rollover,
> > immaturity of tooling and by habitual cynicism from plausibly
> > authoritative voices.
> 

With BIND 9.16, just pick one of the stock policies, and BIND does the
rest, generates keys, keeps the signatures current, periodically rolls
the ZSK, even rolls the KSK and publishes CDS/CDNSKEY RRs, and I believe
delays retiring the old KSK until the parent domain actually updates
the DS RRs (whether via CDS, or manual update).  Try it!

> your own master DNS server in order to do that?

If you're talking about registrars that sign zones for you, there are
many.  Some of the ones hosting large numbers of signed domains are:

    - one.com
    - ovh.net
    - googledomains.com
    - Amazon Route 53
    - transip.nl
    - domeneshop.no
    - forpsi.cz

Many others, those are just some of the larger ones.

> How long does it take for the typical domain name owner to sign their 

With BIND 9.16, just add a policy to the zone definition.  A few
seconds.

> What's the ongoing commitment in time for a domain owner to maintain 

None, BIND keeps the zone signed.  Of course wether you're signing or
not, service monitoring is highly recommended, to check signature
validity I use

    named-compilezone -i local -jD -f raw -o - $zone $zonedb |
        ldns-verify-zone -e P0Y0M3DT3H23M54S -V1 -S /dev/stdin

> (Note: if nothing is verifying signatures, the immediate benefit is zero.)

Since "nothing is verifying" is simply false, the benefit is that
verification indeed takes place.  The strongest case is hardening
of CAA records and TLSA records.  Soon also HTTPS and SVCB records,
which have security-relevant information, worth hardining IMHO.

> And how do we close these (and doubtless other) gaps?

My zone has been signed since ~2014, no gaps to report, but for more
complex environments work is being done to address

    - multi-provider signing (Shumon Huque, et. al. doing great work)
    - CDS support by registries and registrars, .CZ, .ZA, soon
      Godaddy...

We're not standing still, lots of good activity to close the gaps both
new and longstanding.

> don't think this is going to happen until most of these problems are fixed.

That's why lots of work is happening to address the remaining adoption
barriers.

-- 
    Viktor.

---

From: "Andrew McConachie" <[email-masked]>
Date: Mon, 12 Apr 2021 12:36:43 +0200

On 11 Apr 2021, at 20:13, Michael Thomas wrote:

>> they’re not amortized over multiple connections from **one** user, 
>> but rather affect **many** users.  Imagine an e-commerce site 
>> connected to two CDN’s who needs to switch.
>>
> The worst case is that it devolves into what we already have: 5 
> messages assuming NS records are cached normally.
>
> Another approach using current infrastructure would be for the client 
> to cache the certs and hand the server cert the fingerprint(s) in the 

For the past 2 years or so I’ve been performing HTTPS DANE validation 
on all TLS 1.1 and 1.2 connections egressing my house. I use custom code 
written for OpenWRT that installs ACLs to block TLS connections that 
fail DANE validation.

More info here.
<https://www.middlebox-dane.org/>

The short story is that it works pretty well. I usually forget I have it 
running, and on the off chance I hit a website with invalid TLSA RRs 
that gets blocked it usually takes me a few minutes to try and figure 
out why the website isn’t loading.

One thing I’ve learned from this experiment is that, atleast in my 
situation, DNS is always faster than any TLS setup time that matters. 
The web is horrendously slow, so even if TLS setup completes my OpenWRT 
box will kill the TLS connection long before any real data gets 
transferred. These things happen asynchronously, and I have Unbound 
running directly on the OpenWRT box, so DNS always wins. But even if the 
TLS handshake were to complete fully and only then get killed by OpenWRT 
it would be the same outcome.

When looking at how one might implement DANE for HTTPS/TLS I don’t see 
any reason to handle these things sequentially. You don’t have to 
change TLS you just have to do things asynchronously. Query for TLSA RRs 
at the same time as sending the TLS ClientHello, and kill the connection 
setup when/if DANE validation fails. On the off chance that the DNS 
actually takes longer than TLS, maybe delay sending data via TLS until 
DNS responds. But I bet this almost never happens.

If you really don’t want any slow down from DANE just setup TLS 
normally and only kill it once DANE validation fails. The web is so slow 
that the chances something significant will happen prior to the client 
fetching the TLSA RR and performing DANE validation are practically nil.

Thanks,
Andrew

---

From: Keith Moore <[email-masked]>
Date: Mon, 12 Apr 2021 08:25:03 -0400

Viktor,

Thanks for the update.   It looks as if progress is indeed being made.   
Now I wonder: what is being done to publicize DNSSEC to try to get wider 
adoption?

Keith

---

From: Petite Abeille <[email-masked]>
Date: Mon, 12 Apr 2021 14:39:24 +0200

> On Apr 12, 2021, at 14:25, Keith Moore <[email-masked]> wrote:
> 
> Thanks for the update.   It looks as if progress is indeed being made.   Now I wonder: what is being done to publicize DNSSEC to try to get wider adoption?

As it stands — one has to get out of its way to find it.

dnsimple has good support for it out-of-the-box:

https://support.dnsimple.com/articles/dnssec/

https://dnssec-analyzer.verisignlabs.com/textprotocol.com
https://dnssec-analyzer.verisignlabs.com/textprotocol.net

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 12 Apr 2021 12:54:20 +0000

>    You can tune down TTLs before the change, etc.

The TTL is already a small number of seconds so that in the standard DNS case, they can switch within five seconds.

Sounds to me that, as I thought, they will have to sign a TLSA record every five seconds.  No?

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 12 Apr 2021 12:57:21 +0000

>    one may as well delegate the TLSA record management to the CDN:

Sure, if you're never going to switch CDN's.

Many big customers switch CDN's and will not delegate because, well, they need to switch.

There is a whole industry and providers around switching CDN's in real time.  Web-search "Cdn switch" will find them, for example.

Sure, if there's one CDN.

If millions of dollars of commerce are happening per minute, then yes.  Or the head of state dies and the official news source is overloaded.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 12 Apr 2021 10:44:12 -0400

Rich brings up a very important point which is worth generalizing:
Proposals to change a deployed infrastructure must support every feature of
that legacy infrastructure if they are going to be a replacement.

People start off saying 'we will build on X because it is widely used'.
What they don't realize is that when you do that, you have to spend time
discovering and working around all the bizarre ways X is being used. The
design of CAA is a case in point, it uses the DNS to publish information
and was originally based on one set of assumptions. Between the original
spec being written and the CABForum making it a requirement the use of CDNs
went from being a niche concern to a common one and that required the
handling of wildcards to be retooled.

It was the exact same thing with DKIM where most of the work was
discovering and working around bizarre corner cases.

Any proposal that begins 'lets change the way people use DNS'  has a mighty
hard lift. And it is not just the technical infrastructure you need to
understand, it is the commercial. The reason I was so heavily involved in
DKIM was that our resellers were the businesses that would have to
implement the TXT records.

Ten years after DANE started, my very very large Web hosting provider I use
for my secondary hosting does not support TLSA records. And they appear to
have no plans to do so. And there are tens of thousands of other similar
businesses that have no plans to implement TLSA because doing so is simply
going to take revenue out of their pocket. They sell domains at cost and
they only make profits from added value services, the biggest of which is
selling SSL certificates.

Same thing happened with IPv6, for at least the first decade of IPv6, the
people working on it naively assumed that the way to make it attractive was
to reserve functionality that would only be supported in IPv6. IPSEC being
originally part of that. Only gradually did some people start to understand
that the applications were not going to make use of any functionality that
wasn't supported by at least 95% of the network and so features that were
IPv6 only would be uninteresting and unusable. And some folk are still in
denial.

And the thing that worries me here is that the IETF likes to think of
itself as fostering discussion and interworking between specialists in
different areas. Which sounds fine in practice only those of us who
actually do work at multiple layers are not exactly made to feel welcome
anywhere.

On Mon, Apr 12, 2021 at 8:58 AM Salz, Rich <rsalz=
[email-masked]> wrote:

> There is a whole industry and providers around switching CDN's in real
> time.  Web-search "Cdn switch" will find them, for example.
>
> If millions of dollars of commerce are happening per minute, then yes.  Or
> the head of state dies and the official news source is overloaded.
>
>
>

---

From: Marco Davids <[email-masked]>
Date: Mon, 12 Apr 2021 17:02:02 +0200

> Thanks for the update. It looks as if progress is indeed being made. 

I second that.

> Now I wonder: what is being done to publicize DNSSEC to try to get wider 

I can only speak for the situation in my country. And there is lot's of 
good vibes there. Quite some awareness and good adoption of DNSSEC in 
the .nl-zone (56% of all .nl domains are signed). On the validation side 
a few of the countries largest ISP's have enabled it:

https://stats.labs.apnic.net/dnssec/NL

The government is also quite committed to stimulating adoption.

Let me (once more) recommend https://en.internet.nl/, a testing-platform 
that we developed within a consortium of stakeholders in the 
Netherlands, both from the private as well as from the public sector. It 
has become quite popular with international spin-offs like 
https://xn--sikkerpnettet-vfb.dk/ !

We're not there yet, but it is certainly not all that bad either!

-- 
Marco Davids

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 12 Apr 2021 11:11:01 -0400

Responding back to Michael's original post, I and many others have tried to
get Google to implement some trial feature in Chrome. And on occasion, we
have succeeded. DANE was in some versions of Chrome at one point.

But persuading someone we know to frob Chrome is not a scalable approach.
And from the point of view of the stability of the Internet as a whole it
is a really bad idea to be alpha testing ideas on a testbed of a billion
users. Google is not the only gatekeeper of course, there is Safari and
Microsoft Edge. But those have also got rather large footprints. They are
still too big to play games with.

There is a large amount of customization possible within Chrome of course
but very little of the work we do in IETF is work that fits easily into a
Javascript extension. We want to be playing with the low level crypto
engine, the transports, etc. All the stuff we do NOT want to be accessible
to a plug in. Not ever.

So what is the solution?

What I think we need is a community of knowledge that can help get IETF and
other ideas into an alpha/beta test situation without having to become
total wonks on the Chrome code base which is very very large and keeping up
with it is pretty much a job in itself. Just setting up a machine to
compile Chrome is a major undertaking.

What we really need is a version of Chrome or Edge that has some of the old
extension points built back in and some new ones added so we can use it as
an engineering test bed. APIs like.

* Password vault interface (to drop in choice of password manager).
* Discovery interface (to change DNS lookup).
* Transport interface (to trial new TLS / QUIC like proposals).
* Compression interface (to enable testing of new compression and content
encryption schemes).
* Certificate validation

That is my API list wish at any rate. Other people might have different
asks but I don't think even a maximal list would be very long.

If there was a community interested in building such a tool, we should be
able to find the funds necessary to do it really right from somewhere. Much
of the knowledge we need exists within the browser community, it is just a
case of getting the right expert to tell us how to do something right.

The way I would find an audience for such a browser is really simple. Just
give me the ability to limit Chrome/Edge to never ever allocating more than
X GB of memory and I will switch to it immediately. I am sure many others
would do the same. No matter how much RAM I put in a machine, it is never
going to be enough if Chrome wants half, Visual Studio wants the other half
and I try to open Microsoft Word.

The business model for the non-profit callsign registry is to fund exactly
that sort of project but that is a couple of years off at this point.

---

From: Michael Thomas <[email-masked]>
Date: Mon, 12 Apr 2021 08:13:41 -0700

> If millions of dollars of commerce are happening per minute, then yes.  Or the head of state dies and the official news source is overloaded.
So the whole world needs to revolve around somebody's corner case. But 
this is all rather pointless: short TTL DNS devolves into the 
certificate case's message count. For normal TTL records, it would be 
usually be a 3 way handshake. Also: certificates are not going to be 
deprecated; if they work better keep using them. It's really that simple.

Mike

---

From: Michael Thomas <[email-masked]>
Date: Mon, 12 Apr 2021 08:16:22 -0700

> Sounds to me that, as I thought, they will have to sign a TLSA record every five seconds.  No?

Are you issuing new certificates every 5 seconds? If not, no.

Mike

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 12 Apr 2021 11:22:05 -0400

On Mon, Apr 12, 2021 at 11:14 AM Michael Thomas <[email-masked]> wrote:

> So the whole world needs to revolve around somebody's corner case.
>

Welcome to my world.

If you want to get this deployed, you are far more likely to make progress
by working out a way to meet Rich's need than by dismissing him.

The fact that Rich's customers are shredding the DNS to get what they need
is itself rather significant. That is clearly a pain point and thus a place
where new solutions are likely to be of interest.

---

From: Michael Thomas <[email-masked]>
Date: Mon, 12 Apr 2021 08:22:45 -0700

On 4/12/21 3:36 AM, Andrew McConachie wrote:
> change TLS you just have to do things asynchronously. Query for TLSA 
> RRs at the same time as sending the TLS ClientHello, and kill the 
> connection setup when/if DANE validation fails. On the off chance that 
> the DNS actually takes longer than TLS, maybe delay sending data via 
> TLS until DNS responds. But I bet this almost never happens.
>
Correct. Better: you can do the TLSA request at the same time as the 
A/AAAA request speculatively. Plus if you've ever had a TLSA record for 
that domain, you know it's pretty likely you'll get a fresh one even if 
the last one is expired, so the speculation is minimal.

Mike

---

From: Michael Thomas <[email-masked]>
Date: Mon, 12 Apr 2021 08:25:04 -0700

On 4/12/21 8:22 AM, Phillip Hallam-Baker wrote:
> On Mon, Apr 12, 2021 at 11:14 AM Michael Thomas <[email-masked] 
> If you want to get this deployed, you are far more likely to make 
> progress by working out a way to meet Rich's need than by dismissing him.
>
> The fact that Rich's customers are shredding the DNS to get what they 
> need is itself rather significant. That is clearly a pain point and 
> thus a place where new solutions are likely to be of interest.
>
As I said, if certificates work better for your use case, use them. The 
rest of the world shouldn't be held hostage to somebody else's corner 
case. There is literally nothing that needs to be done to accommodate him.

Mike

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 12 Apr 2021 15:32:51 +0000

>    So the whole world needs to revolve around somebody's corner case

No.  If the whole world wants to modify something they must preserve current semantics that many people are relying on. As PHB said.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 12 Apr 2021 11:33:29 -0400

> the last one is expired, so the speculation is minimal.

Or replace the DNS resolver protocol with a privacy protected one in which
a single request packet can be answered by multiple response packets. This
maintains the 'stateless' nature of DNS queries but allows responses of
1-32 packets.

Then introduce a new DNS query for 'tell me how to connect to protocol X at
name Y'

Then a query to the responder can return the A record, the AAAA record, the
SRV record, any relevant TXT and TLSA records and the entire cert chain for
one particular host chosen by the responder.

Then to fix Rich's issue we introduce a subscription feature so that high
volume DNS resolvers can get push notification of changes in the CDN config.

It is really odd that you keep accusing me of being wedged on X.509v3
certificates when I have designed three other PKIs from scratch that don't
use ASN.1 at all, one of which is very widely used and another that I am
working on right now. X.509 is the only PKI I have worked on, the only
protocol I have worked on that I was not 1.0 on. I was 1.0 on applying it
to create the WebPKI.

---

From: Michael Thomas <[email-masked]>
Date: Mon, 12 Apr 2021 08:34:28 -0700

> No.  If the whole world wants to modify something they must preserve current semantics that many people are relying on. As PHB said.

Nobody is saying that there would be a breaking change. You are free to 
use certificates for now and evermore.

Mike

---

From: Michael Thomas <[email-masked]>
Date: Mon, 12 Apr 2021 08:37:57 -0700

On 4/12/21 8:33 AM, Phillip Hallam-Baker wrote:
>
>
> On Mon, Apr 12, 2021 at 11:22 AM Michael Thomas <[email-masked] 
> Or replace the DNS resolver protocol with a privacy protected one in 
> which a single request packet can be answered by multiple response 
> packets. This maintains the 'stateless' nature of DNS queries but 
> allows responses of 1-32 packets.
>
> Then introduce a new DNS query for 'tell me how to connect to protocol 
> X at name Y'
>
> Then a query to the responder can return the A record, the AAAA 
> record, the SRV record, any relevant TXT and TLSA records and the 
> entire cert chain for one particular host chosen by the responder.
>
I really have no desire to boil the ocean. My post was something that is 
actually achievable with existing protocols with and achievable by way 
of many browser vendors having the capability of implementing those 
protocols on their front and backends. That was its entire point: it's 
achievable in the here and now.

Mike

---

From: Nico Williams <[email-masked]>
Date: Mon, 12 Apr 2021 10:51:22 -0500

> maintains the 'stateless' nature of DNS queries but allows responses of

As long as it's not over UDP, or otherwise first has a return
routability check.

> SRV record, any relevant TXT and TLSA records [...]

Kinda like "any" queries.

>                                         [...] and the entire cert chain for

You get better security properties (w.r.t. possible compromised root or
ccTLD/TLD keys) if the resolver finds the DNSSEC chain on its own using
qname minimization than you get with stapling, but I agree that stapling
is a performance win.  We'll really want transparency for DNSSEC if we
do any kind of full chain stapling.

Nico
--

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 12 Apr 2021 11:54:10 -0400

> Sure, if you're never going to switch CDN's.

No, to *each* CDN.  Each one can publish the appropriate TLSA RRs for
its service.

> time.  Web-search "Cdn switch" will find them, for example.

What do you mean by "in real-time"?

> Sure, if there's one CDN.

It also works for multiple CDNs, provided they don't keep switching back
and forth, or proving some modest set of trust-anchors is known to cover
them all.

> If millions of dollars of commerce are happening per minute, then yes.
> Or the head of state dies and the official news source is overloaded.

And do they keep switching back and forth, or is a one time switch
stable for some days or longer?

-- 
    Viktor.

---

From: Nico Williams <[email-masked]>
Date: Mon, 12 Apr 2021 10:54:04 -0500

On Mon, Apr 12, 2021 at 12:54:20PM +0000, Salz, Rich wrote:
> The TTL is already a small number of seconds so that in the standard
> DNS case, they can switch within five seconds.
> 

No.  TTL != notAfter.

You do not have to re-sign any RRs every N seconds just because their
TTL is N seconds.

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 12 Apr 2021 11:58:29 -0400

On Mon, Apr 12, 2021 at 10:44:12AM -0400, Phillip Hallam-Baker wrote:

> have no plans to do so.

Not surprising, none of the browsers support TLSA records, so there's
little point in publishing them for web services.

> And there are tens of thousands of other similar businesses that have
> no plans to implement TLSA because doing so is simply going to take
> revenue out of their pocket.

There's no revenue loss, but whatever, since there's no point at
present.

> They sell domains at cost and they only make profits from added value
> services, the biggest of which is selling SSL certificates.

Which Let's Encrypt sells for $0.  Their customers will eventually
figure this out.

-- 
    Viktor.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 12 Apr 2021 11:59:58 -0400

On Mon, Apr 12, 2021 at 11:51 AM Nico Williams <[email-masked]>
wrote:

> which

I don't follow.

> Kinda like "any" queries.

Not quite because of 1) the interaction of prefixes and 2) you only need
data for the one host you connect to.

> do any kind of full chain stapling.

SCVP introduced a distinction between path discovery and path validation.
Both can be very useful.

If you have a low level IoT device, you are probably better off doing path
math properly in one trusted device in your network than relying on
whatever embedded code is running in your toaster.

For other cases, it is much easier to check path math than to work out a
valid chain. All you need to do to check is to pull the signature record
out of each cert in the chain, pull the key record out of the previous
record and check the sig over the toBeSigned block, then check for any
constraints. Discovery requires backtracking and constraints are really
hard.

---

From: Michael Thomas <[email-masked]>
Date: Mon, 12 Apr 2021 09:02:57 -0700

> do any kind of full chain stapling.

Can somebody explain what "stapling" is?

thx, Mike

---

From: Nico Williams <[email-masked]>
Date: Mon, 12 Apr 2021 11:10:10 -0500

On Mon, Apr 12, 2021 at 11:59:58AM -0400, Phillip Hallam-Baker wrote:
> > > Or replace the DNS resolver protocol with a privacy protected one
> > > in which a single request packet can be answered by multiple
> > > response packets.  This maintains the 'stateless' nature of DNS
> > > queries but allows responses of 1-32 packets.
> >

"No magnification DDoS please"

> > > record, the SRV record, any relevant TXT and TLSA records [...]
> >
> Not quite because of 1) the interaction of prefixes and 2) you only
> need data for the one host you connect to.

Thus "kinda" :)

> > >                                         [...] and the entire cert
> > > chain for one particular host chosen by the responder.
> >
> > You get better security properties (w.r.t. possible compromised root
> > or ccTLD/TLD keys) if the resolver finds the DNSSEC chain on its own
> > using qname minimization than you get with stapling, but I agree
> > that stapling is a performance win.  We'll really want transparency
> > for DNSSEC if we do any kind of full chain stapling.
> 
> SCVP introduced a distinction between path discovery and path
> validation.  Both can be very useful.

Yes, exactly.  But for PKIX path discovery is not possible without
directories, but DNS _is_ a directory, so you get to do path discovery.
And unlike PKIX, there is only one possible path (well, at most as many
paths as there are labels in the domainname, minus 1, plus any sub-paths
due to CNAME RR chasing).

> If you have a low level IoT device, you are probably better off doing
> path math properly in one trusted device in your network than relying
> on whatever embedded code is running in your toaster.

Absolutely.  There is a trade-off to make.  Low-power && low-value RPs
should prefer stapling, or even a local caching recursive resolver to do
all the lookups and signature verification too.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Mon, 12 Apr 2021 11:14:32 -0500

> Can somebody explain what "stapling" is?

In general "stapling" means sending all the ancilliary things that the
peer would otherwise have to lookup on its own to save it the bother.
So:

 - "OCSP" == RP sends request to OCSP Responder

 - "stapled OCSP" == supplicant sends its EE cert and chain and cached
   OCSPResponse to the RP so the RP need not go talk to an OCSP
   Responder

 - "DANE" == RP looks up all the relevant RRs needed to validate
   supplican't certificate

 - "stapled DANE" == supplicant sends TLSA RRs and DNSSEC chain along
   with its certificate so that the RP need not perform those lookups
   separately

(RP == relying party)
(supplicant == the entity authenticated by the end-endity certificate it
 presents to the RP)

Nico
--

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 12 Apr 2021 12:16:03 -0400

> You do not have to re-sign any RRs every N seconds just because their

Indeed, RRSIGs have inception and expiration fields that typically
differ by O(30 days).  My zone has 14 day RRSIG lifetimes, and 1 hour
TTLs, but with sufficient automation, it could be lower, thus IIRC Route
53 DNSSEC has 10 hour RRSIGs (!) and the hosted zones are resigned every
few hours.

Of course one might simply also sign each query on the fly, as done
by Cloudflare.

-- 
    Viktor.

---

From: Michael Thomas <[email-masked]>
Date: Mon, 12 Apr 2021 09:17:55 -0700

> (supplicant == the entity authenticated by the end-endity certificate it
Ah, thanks. I was guessing it might be that. I assume it goes into the 
Additional RR's like SoA records. Are there rules on what a can be 
supplied as additional RR's? Is the client allowed to supply hints or 
does the DNS server have to just guess?

Mike

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 12 Apr 2021 16:20:47 +0000

I don't know what those other products consider, but I know five seconds happens.

The CDN's are generally part of the WebPKI because browsers connect to them.

I've seen both short-term shifts (an hour or two), and long-term shifts (measured in days).

I am sorry I cannot provide specifics, naming our customers for example.

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 12 Apr 2021 12:37:08 -0400

> I don't know what those other products consider, but I know five seconds happens.

In that case one may need short TTLs for the CNAMEs from the customer's
zone to the CDN zone, though this trades worse performance (higher
average latency) all the time, for faster cutover in rare situations.
One should weigh the tradeoffs with care.

> shifts (measured in days).

That does not sound like rapid back and worth (same ~5s timescale).
The new TTL for the retargetted temporary CDN can be shorter than
default).

> I am sorry I cannot provide specifics, naming our customers for example.

No worries, I wasn't asking for anything nearly that specific.

Bottom line, if DANE/TLSA were adopted for HTTPS, it can be made to work
also with CDNs as described in this thread.

I would in fact recommed DNAME rather than CNAME in this case, because
it in one swoop aliases a subtree of the DNS to the CDN, which includes
both the address records and the TLSA records:

    www.example.com. IN DNAME www.somecdn.example.

The main limitation is that this only works for "leaf" names,
redirecting the zone apex is a separate problem, for which we're
inventing "HTTPS" records, ... and in the meantime some folks
are violating specs and publishing zone-apex CNAMEs, ...

--
    Viktor.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 12 Apr 2021 12:48:28 -0400

> "No magnification DDoS please"

Oh, I have that built into the key exchange phase.

> all the lookups and signature verification too.

If I was still doing PKIX, my long term plan would be to get rid of OCSP
and move to short lived certs created using thresholded techniques. But I
am not and nobody is paying me to think about that world any more.

---

From: Nico Williams <[email-masked]>
Date: Mon, 12 Apr 2021 12:25:37 -0500

> Oh, I have that built into the key exchange phase.

Sure.  We've talked about this before.  The DNS data model can't really
change, but the protocol can.  We're already seeing the protocol change
with DoT and DoH.

> am not and nobody is paying me to think about that world any more.

Forget the details of x.509/PKIX/ASN.1 and all of that.  A lot of the
concepts remain the same.  PKIX, for all its warts, got some things
right that must not get lost in the shuffle.  First of all, naming must
be "typed" (I don't mean structured, but that you have to know if
"name@domain" is an email address or a Kerberos principal name).
Second, you need to be able name more than one name.  Third (really,
first), name constraints!  And so on.  Ultimately, certificates need to
be signed big bags of extensions, and in a post-PKIX world those things
should all be strings.

Nico
--

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 12 Apr 2021 18:07:40 +0000

I am not so sanguine.  I am not a DNS expert.  I know many, some of whom also work at my employer and who have not commented on this.

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 12 Apr 2021 14:12:44 -0400

On Mon, Apr 12, 2021 at 06:07:40PM +0000, Salz, Rich wrote:
> I am not so sanguine.  I am not a DNS expert.  I know many, some of
> whom also work at my employer and who have not commented on this.

I'm open to an off-list discussion to uncover the obstacles, we could
then summarise back to the list.  There is perhaps some work remaining
to be done, but I haven't seen any fundamental obstacles as yet.

-- 
    Viktor.

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 12 Apr 2021 18:19:39 +0000

On 4/12/21, 2:13 PM, "Viktor Dukhovni" <[email-masked]> wrote:

I will let some folks know.

---

From: Michael Thomas <[email-masked]>
Date: Mon, 12 Apr 2021 15:04:32 -0700

> https://dnssec-analyzer.verisignlabs.com/textprotocol.net
One of the interesting revelations is that:

1) Google implemented DANE at one point in Chrome

2) Google doesn't currently sign their zone

The implication being that it wasn't a very serious effort to see what 
would happen if they don't even sign their own domain.

Mike

---

From: Nico Williams <[email-masked]>
Date: Mon, 12 Apr 2021 17:14:36 -0500

On Mon, Apr 12, 2021 at 03:04:32PM -0700, Michael Thomas wrote:
> The implication being that it wasn't a very serious effort to see what would
> happen if they don't even sign their own domain.

(1) may have been because of (2), and I believe (2) was because of
internal technical and political issues.  I.e., I would not consider it
dispositive that Google seemed to like DANE then gave up on it, though
that and why they did certainly is germane.

Nico
--

---

From: Michael Thomas <[email-masked]>
Date: Mon, 12 Apr 2021 15:17:32 -0700

> that and why they did certainly is germane.

Yes, that's what I would assume as well. Build it and they will come has 
a sterling track record of failure in IETF.

Mike

---

From: Nico Williams <[email-masked]>
Date: Mon, 12 Apr 2021 17:27:49 -0500

On Mon, Apr 12, 2021 at 03:17:32PM -0700, Michael Thomas wrote:
> Yes, that's what I would assume as well. Build it and they will come has a
> sterling track record of failure in IETF.

Building a technical spec is not enough, indeed.  DANE hasn't succeeded
yet, and neither has DNSSEC.  But DANE is starting to gather steam (in
no small part due to Viktor's efforts) in the realm of SMTP.  The fact
that DANE was early for its time doesn't mean that the single root and
unyielding name constraints aren't appealing or appealing enough to make
a more serious try now.

As noted, the tooling for DNSSEC has been substantially improved in
recent years.  Implementations of DANE do exist now.  There are a number
of missing elements, such as a TLS extension to staple DANE that
supports authenticated denial of existence.  We're making progress
though.  It may seem slow, but there may be a preference cascade at some
point.  It may only take enough user-agent, and registrar / domain
hosting services to provide this functionality to make it popular.

Nico
--

---

From: Michael Thomas <[email-masked]>
Date: Mon, 12 Apr 2021 15:43:31 -0700

> hosting services to provide this functionality to make it popular.

Of course it wouldn't necessarily take http to eek out some interesting 
stats. But web stuff is extremely bursty so it's pretty much its own 
thing. I made an update to my flow to show that the TLSA record could be 
speculatively fetched at address resolution time which could be done for 
DNSKEY and DS records too, especially if you know from previous 
interaction that they were there before. All of those considerations are 
going to interact with how it performs in reality.

The one thing that bugs me about DANE is its use of a native RR type. 
This is a well trodden argument of doing it proper and doing it in a 
deployable way. We know what happens when you do it the "right way" 
which is usually nothing at all. If it started to get popular, we could 
gin up a TXT record alternative though, I suppose. When we were doing 
DKIM at Cisco, our IT folks were incredibly accommodating, but 
implementing a new RR type in their infrastructure would have probably 
been a bridge too far. Heck, I wouldn't be surprised if Mark at Y! got 
told the same thing :)

Mike, slowly getting up to speed on a bunch of the details of the 
underlying protocols

---

From: Nico Williams <[email-masked]>
Date: Mon, 12 Apr 2021 18:18:51 -0500

On Mon, Apr 12, 2021 at 03:43:31PM -0700, Michael Thomas wrote:
> The one thing that bugs me about DANE is its use of a native RR type. This
> is a well trodden argument of doing it proper and doing it in a deployable
> way. We know what happens when you do it the "right way" which is usually
> nothing at all. If it started to get popular, we could gin up a TXT record
> alternative though, I suppose. When we were doing DKIM at Cisco, our IT
> folks were incredibly accommodating, but implementing a new RR type in their
> infrastructure would have probably been a bridge too far. Heck, I wouldn't
> be surprised if Mark at Y! got told the same thing :)

Hmm, well, as they say, "new RR types are cheap", though more
importantly document authors get forced to use new RR types rather than
use TXT RRs.  But tooling for hosting sites and such is a problem, yes,
even if it isn't for servers and clients.  But this is water under the
bridge now.  And if anything, the IETF is tripling down on more new RR
types.

Nico
--

---

From: Michael Thomas <[email-masked]>
Date: Mon, 12 Apr 2021 16:21:39 -0700

> bridge now.  And if anything, the IETF is tripling down on more new RR

Maybe somebody should take score of the new RR's vs. deployment. Data is 
our friend.

Mike

---

From: John C Klensin <[email-masked]>
Date: Mon, 12 Apr 2021 20:42:54 -0400

--On Monday, April 12, 2021 15:43 -0700 Michael Thomas
<[email-masked]> wrote:

> The one thing that bugs me about DANE is its use of a native
> RR type. This is a well trodden argument of doing it proper
> and doing it in a deployable way. We know what happens when
> you do it the "right way" which is usually nothing at all. If
> it started to get popular, we could gin up a TXT record
> alternative though, I suppose. When we were doing DKIM at
> Cisco, our IT folks were incredibly accommodating, but
> implementing a new RR type in their infrastructure would have
> probably been a bridge too far. Heck, I wouldn't be surprised
> if Mark at Y! got told the same thing :)

And I don't want to reopen that argument, but part of it is that
the original plan for TXT RR was essentially as a comment field
that anyone could put anything into that they wanted to convey
to another human.  So, if it is used to express protocol
information, figuring out which protocol and whether the data
field is correct for that protocol is basically a matter for
heuristics, no matter how good one can make them.  If there is a
choice, that is not a really good idea.  Also, it has been years
since I was involved in large-scale DNS operations (and, by
today's standards for "large", I never have been),  but it seems
to me that, if a particular implementation or operational setup
makes it as hard to deal with a new RR type as your comment
above suggests, there is something seriously wrong with that
setup.   And I think the language in 1034/1035 is consistent
with that view.

    john

---

From: Keith Moore <[email-masked]>
Date: Mon, 12 Apr 2021 20:45:00 -0400

On 4/12/21 8:42 PM, John C Klensin wrote:

> Also, it has been years

+1.

Keith

---

From: Michael Thomas <[email-masked]>
Date: Mon, 12 Apr 2021 17:48:48 -0700

> setup.   And I think the language in 1034/1035 is consistent

Oh, don't get me wrong: using TXT records is a colossal hack. But 
operational considerations are like stubborn facts. We had to bite the 
bullet and accept NAT's too. You feel unclean and want to wash your 
hands repeatedly, but you do what you have to do.

Mike

---

From: Michael Thomas <[email-masked]>
Date: Mon, 12 Apr 2021 17:50:53 -0700

>> setup.   And I think the language in 1034/1035 is consistent
The problem is that it's not this simple. Software needs to change to 
implement new RR types which inevitably begs the question "what's in it 
for me?"

Mike

---

From: Keith Moore <[email-masked]>
Date: Mon, 12 Apr 2021 21:03:05 -0400

On 4/12/21 8:50 PM, Michael Thomas wrote:

> implement new RR types which inevitably begs the question "what's in 
> it for me?" 

Well of course software has to change to implement new RR types, because 
old software wasn't going to query for those RRs and if it got those RRs 
back in a response it would have to ignore them.

But DNS itself shouldn't have to change to implement new RR types, more 
than (perhaps) adding a line to a table that says RR type NN has ASCII 
name XX and the following types of parameters. And that table should be 
globally and securely accessible. Encode the table in DNS somehow, put 
it in the root zone or other zone managed by the root, give it a very 
long TTL, and sign it with DNSSEC.

---

From: Nico Williams <[email-masked]>
Date: Mon, 12 Apr 2021 20:04:12 -0500

On Mon, Apr 12, 2021 at 05:50:53PM -0700, Michael Thomas wrote:
> implement new RR types which inevitably begs the question "what's in it for
> me?"

Only presentation software needs to change at all, and that can always
have a fallback mode where RDATA are presented in hex and can be entered
in hex.  Yes, not user-friendly.  Maybe a little IETF-maintained, open
source library of JS for encoding/decoding RDATA of all RR types would
help.

---

From: Michael Thomas <[email-masked]>
Date: Mon, 12 Apr 2021 18:08:20 -0700

On 4/12/21 6:03 PM, Keith Moore wrote:
> Well of course software has to change to implement new RR types, 
> because old software wasn't going to query for those RRs and if it got 
> those RRs back in a response it would have to ignore them.
>
> But DNS itself shouldn't have to change to implement new RR types, 
> more than (perhaps) adding a line to a table that says RR type NN has 
> ASCII name XX and the following types of parameters. And that table 
> should be globally and securely accessible. Encode the table in DNS 
> somehow, put it in the root zone or other zone managed by the root, 
> give it a very long TTL, and sign it with DNSSEC.
>
>
Uh, think the long tail of UI's. Even $megacorps use them. And they 
don't look kindly to monkey patches either.

Mike

---

From: John C Klensin <[email-masked]>
Date: Mon, 12 Apr 2021 21:16:17 -0400

>...
>> And I don't want to reopen that argument, but part of it is
>> that the original plan for TXT RR was essentially as a
>> comment field that anyone could put anything into that they
>> wanted to convey to another human.  So, if it is used to
>> express protocol information, figuring out which protocol and
>> whether the data field is correct for that protocol is
>> basically a matter for heuristics, no matter how good one can
>> make them.  If there is a choice, that is not a really good
>> idea.  Also, it has been years since I was involved in
>> large-scale DNS operations (and, by today's standards for
>> "large", I never have been),  but it seems to me that, if a
>> particular implementation or operational setup makes it as
>> hard to deal with a new RR type as your comment above
>> suggests, there is something seriously wrong with that setup.
>> And I think the language in 1034/1035 is consistent with that
>> view.
> 
> Oh, don't get me wrong: using TXT records is a colossal hack.
> But operational considerations are like stubborn facts. We had
> to bite the bullet and accept NAT's too. You feel unclean and
> want to wash your hands repeatedly, but you do what you have
> to do.

An interesting analogy.  The difference is that it was widely
perceived that there was no alternative to NATs other than
conversion to IPv6 and that, unless everyone converted to IPv6
on the same day, NATs would be needed to allow interoperability
between IPv6 systems and the remaining IPv4 ones.  If there were
good alternatives, the IETF didn't do a good job of explaining
them and why they were better.

You also wrote:

> The problem is that it's not this simple. Software needs to
> change to implement new RR types which inevitably begs the
> question "what's in it for me?"

Sure.  But (different) software also has to change to implement
(to use the comments that started us down this thread) DANE.
Those changes are to mail software, systems, and configurations,
not DNS support, but they are changes nonetheless.  Yes, other
changes are needed for anything that requires that
authentication or authorization information be stored in the
DNS, but that raises the question of whether DANE's designers
could have put that information somewhere else and whether that
would have been worth it (my guess is that the answer to the
former is "probably" and, to the latter, "probably not", but
that is what gets us to the rant in RFC 8324).

So the answer to your question is "The enterprise has decided
DANE is useful and DNS updates are as much part of the price as
email changes" and, if that is not enough, then either DANE is
not actually needed or the second part of the answer is "want to
keep your job?".

    john

---

From: Keith Moore <[email-masked]>
Date: Mon, 12 Apr 2021 21:17:15 -0400

> don't look kindly to monkey patches either.
Oh, I know.  But wiring RR names into UIs always was a mistake. It will 
take many years to update the UIs (and it should) but there's no reason 
to perpetuate the old way of doing things indefinitely.

Keith

---

From: Michael Thomas <[email-masked]>
Date: Mon, 12 Apr 2021 18:28:23 -0700

> not actually needed or the second part of the answer is "want to
I think part of the key of success with new protocols is how few players 
need buy-in. The fewer the better. Had we had to get buy in from the 
folks that maintained our DNS with DKIM too, our likelihood of failure 
would have been a *lot* higher. It wasn't even a given that they'd give 
us TXT. The overarching point of my initial blog post is that when you 
have an opportunity to route around fiefdoms to get something done, you 
have a much higher chance of success. That is really the lesson we 
should take away with Google re: Quic. That's why I think it's a 
realistic opportunity for quic+dane. But finding out that Google doesn't 
sign their zones is disappointing.

Mike

---

From: Nico Williams <[email-masked]>
Date: Mon, 12 Apr 2021 20:41:02 -0500

On Mon, Apr 12, 2021 at 06:28:23PM -0700, Michael Thomas wrote:
>           [...]. That's why I think it's a realistic opportunity for
> quic+dane. [...]

I think DANE has great reasons to exist and get deployed.  Critical
pieces could come into place this year of three years from now, though
sooner is better (and, really, before we have a crisis of some sort with
WebPKI).

>     [...]. But finding out that Google doesn't sign their zones is
> disappointing.

Again, that has to do with issues that may have passed now, and it may
be possible to nudge them to sign their zones now.

---

From: "John Levine" <[email-masked]>
Date: 12 Apr 2021 21:49:59 -0400

>> give it a very long TTL, and sign it with DNSSEC.

Hey, what a good idea.  Oh, look someone wrote it up as an I-D starting ten years ago:

https://datatracker.ietf.org/doc/draft-levine-dnsextlang/

And here's a python library to implement it with encoder, decoder, and
a dictionary of field types you can use to create and decode web forms:

https://pypi.org/project/dnsextlang/

For perl users, it's built into recent versions of Net::DNS.

>don't look kindly to monkey patches either.

No kidding. You extend the UI once to use the extesion language to
create and parse forms for rrtypes, then fetch the rrtype descriptions from the
DNS. It really works, I use it in my own DNS provisioning crudware.

But as far as I can tell, nobody else does.

R's,
John

---

From: Mark Andrews <[email-masked]>
Date: Tue, 13 Apr 2021 13:03:22 +1000

John,
	please show how this would be used to parse a HTTPS record
without extending the format?

HTTPS:65 HTTPS Record
     I2:SvcPriority
     N:TargetName
     Z[SvcParm,M0]:SvcParams

The problem with the draft is that you are hiding the complexity in
"Miscellaneous fields” section of the draft which would need to be
updated for many new RR types.  SVCB/HTTPS is just a case in point.

Mark

> On 13 Apr 2021, at 11:49, John Levine <[email-masked]> wrote:
> 

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: [email-masked]

---

From: Petite Abeille <[email-masked]>
Date: Tue, 13 Apr 2021 09:43:53 +0200

> On Apr 13, 2021, at 01:21, Michael Thomas <[email-masked]> wrote:
> 
> Maybe somebody should take score of the new RR's vs. deployment. Data is our friend.

Sure — data could be our friend. But data on its own doesn't make decisions. We do. By our actions. Or lack thereof.

---

From: Petite Abeille <[email-masked]>
Date: Tue, 13 Apr 2021 09:55:34 +0200

> On Apr 13, 2021, at 02:48, Michael Thomas <[email-masked]> wrote:
> 

Perhaps. But a practical one. Perfect is the enemy of good.

FWIW, text:// uses them to store a multiaddr [1][2] describing how to connect to a given service:

/dns/textprotocol.org/tcp/1961
/dns/textprotocol.org/tcp/1965/tls
/dns/textprotocol.org/udp/1968/quic

[1] https://github.com/multiformats/multiaddr
[2] https://multiformats.io

---

From: "Andrew McConachie" <[email-masked]>
Date: Tue, 13 Apr 2021 10:46:24 +0200

> hosting services to provide this functionality to make it popular.

There’s been too much focus on getting browsers to implement 
HTTPS/DANE. These days HTTPS is used for all kinds of stuff that has 
nothing to do with the web. Take the Fediverse for example. ActivityPub 
uses HTTPS for server-server communication in a manner similar to how 
MTAs use SMTP. There are plenty of other examples.

My point is that if people want to see HTTPS/DANE deployments grow they 
should start hacking HTTPS/DANE validation into the numerous open source 
projects that act as HTTPS clients. Find communities of geeks to act as 
early adopters, and simply ignore the politics of large browser vendors 
as they’re obviously a lost cause.

—Andrew

---

From: "Patrik Fältström" <[email-masked]>
Date: Tue, 13 Apr 2021 10:58:19 +0200

On 13 Apr 2021, at 10:46, Andrew McConachie wrote:

> My point is that if people want to see HTTPS/DANE deployments grow they should start hacking HTTPS/DANE validation into the numerous open source projects that act as HTTPS clients.

I see two issues with HTTPS/DANE (and DNSSEC):

1. People in the community have too much focused on getting zones signed instead of getting validation deployed. In Sweden we focused in validation, and as validation is happening basically everywhere, it is worth it to get their zones signed.

My conclusion: Continue to talk about _validation_.

2. libCurl is used basically everywhere and some efforts have been done to add DANE, but nothing really finished. <https://curl.se/docs/todo.html#Support_DANE>

My conclusion: Convince someone with more time than me to actually finish the work.

    Patrik

---

From: Eliot Lear <[email-masked]>
Date: Tue, 13 Apr 2021 11:56:44 +0200

Hi Patrik,

> On 13 Apr 2021, at 10:58, Patrik Fältström <paf=[email-masked]> wrote:
> 

Yes.  The opendnssec team did a phenomenal job, only to be thwarted by secondary servers and amplification attack concerns.  My conclusion: why choose?  Both validation AND signing is a problem, especially if we do not want to encourage market concentration.

Eliot

---

From: "Patrik Fältström" <[email-masked]>
Date: Tue, 13 Apr 2021 12:16:29 +0200

On 13 Apr 2021, at 11:56, Eliot Lear wrote:

> My conclusion: why choose?  Both validation AND signing is a problem, especially if we do not want to encourage market concentration.

Because doing signing is viewed as a cost, and there must be a benefit in doing the signing. This is why validation must come first. The cost is low, and you have to do it in relatively few places (the large access providers). So easier to convince them than the ones that are to start signing zones (which is more work).

   Patrik

---

From: "Patrik Fältström" <[email-masked]>
Date: Tue, 13 Apr 2021 12:20:39 +0200

On 13 Apr 2021, at 11:56, Eliot Lear wrote:

> The opendnssec team did a phenomenal job, only to be thwarted by secondary servers and amplification attack concerns.

One more thing....the OpenDNSSEC design did not really take key rollover and the need for interaction and/or integration in the registrar/registry (epp) flow of data. So actual deployment in operational environments was not trivial.

Today, with better support for management of DS inbound in a signed zone, this is not as big as a problem as it was. Specifically as the need for rolling KSK is also questioned. As long as you CAN roll the KSK.

   Patrik

---

From: "John R Levine" <[email-masked]>
Date: 13 Apr 2021 11:27:55 -0400

> without extending the format?

It doesn't.  If an RRTYPE uses a new field type, you need to write code. 
But if you look at the list of RRTYPEs in the library I wrote, only seven 
of them need unique field types and the rest use regular fields.

Also keep in mind that typical provisioning crudware currently handles 
about six RRTYPEs, and this is a way to at least catch up with the past 
several decades.  It's not a panacea but it lessens the pain a lot.

R's,
John

PS: I expect that if HTTPS and SVCB are standardized, people will pretend 
to be surprised that nobody uses them because there's no way to provision 
them through registrar crudware.

---

From: Nico Williams <[email-masked]>
Date: Tue, 13 Apr 2021 10:58:39 -0500

On Tue, Apr 13, 2021 at 10:46:24AM +0200, Andrew McConachie wrote:
> There’s been too much focus on getting browsers to implement HTTPS/DANE.

Or not enough.

> These days HTTPS is used for all kinds of stuff that has nothing to do with
> the web. Take the Fediverse for example. ActivityPub uses HTTPS for
> server-server communication in a manner similar to how MTAs use SMTP. There
> are plenty of other examples.

Thus there is now a DANISH mailing list, and who knows, we might end up
with a BoF and even a WG.

> early adopters, and simply ignore the politics of large browser vendors as
> they’re obviously a lost cause.

That's certainly an option.

I think OpenSSL and other TLS implementations could have better DANE
ergonomics, for sure -- that may be a better place to start.

But SMTP has been a very good base for now because the application
exists, is widely deployed, greatly benefits from DANE, has significant
gubernamental support in Europe, etc.

---

From: Nico Williams <[email-masked]>
Date: Tue, 13 Apr 2021 10:55:31 -0500

> Perhaps. But a practical one. Perfect is the enemy of good.

The TXT RR thing is a distraction.  I'm all for pragmatism, but the
problem with using TXT RRs for anything other than commentary is that
the form of the name of the RRset is the only TXT RDATA payload type
identification available, which increases the number of distinct
domainnames one has to query, which complicates any concepts like
combining related answers or profiling queries.  Not a fatal problem,
but a very annoying one.

Since TLSA shipped (and SSHFP, and URI, and soon HTTPS and SVCB, and...)
I suspect this sub-thread can only be unproductive.  (Except in so far
as we might end up with something like J. Levine's I-D on RDATA schemas
published.

Nico
--

---

From: "Jim Fenton" <[email-masked]>
Date: Tue, 13 Apr 2021 17:19:16 -0700

On 13 Apr 2021, at 1:58, Patrik Fältström wrote:

> 1. People in the community have too much focused on getting zones 
> signed instead of getting validation deployed. In Sweden we focused in 
> validation, and as validation is happening basically everywhere, it is 
> worth it to get their zones signed.
>

Agreed, but a lot of administrators are focused on compliance with 
mandates (such as 
https://www.whitehouse.gov/sites/whitehouse.gov/files/omb/memoranda/2008/m08-23.pdf 
) and it’s easy to audit signing of zones. It’s much harder to audit 
validation, resulting in lower deployment that is unfortunate because 
validation is what would benefit their own users.

-Jim

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 14 Apr 2021 18:07:33 +0900

Patrik Faltstrom wrote:

> Because doing signing is viewed as a cost, and there must be a benefit in doing the signing.

True.

As PKIs, including TLS and DNSSEC, rely on CAs as untrustworthy
TTPs, they are, as was demonstrated by diginotar and google,
subject to MitM attacks on CAs.

That is, PKIs are only as secure as plain Internet with ISPs
as untrustworthy TTPs.

As such, there is no point to waste the signing cost.

 > This is why validation must come first. The cost is low,

But, there is no true security for the cost.

						Masataka Ohta

PS

It may still be a good idea to use Diffie Hellman key exchange,
because it is secure against passive attacks.

---

From: Petite Abeille <[email-masked]>
Date: Wed, 14 Apr 2021 11:26:38 +0200

> On Apr 14, 2021, at 11:07, Masataka Ohta <[email-masked]> wrote:
> 

As an alternative narrative — text:// uses saltpack + keys.pub to provide signing & encryption. Entirely bypassing the present PKI infrastructure altogether.  [1][2][3]

Claiming a host boils down to publishing one's handle over dns:

# dig +short _text._tcp.txt.textprotocol.org txt
"textprotocol@github" 

[1] https://saltpack.org
[2] https://keys.pub
[3] https://gist.github.com/textprotocol

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 14 Apr 2021 12:48:05 -0400

> several decades.  It's not a panacea but it lessens the pain a lot.

Some people being surprised that there are gatekeepers that require a fee
seem to be unsurprised that their own employer charges a fee for access to
their
app store.

I did propose a TXT record that could be used for unstructured config and
the
DNS folk rejected it (as they always do). So I really don't care how upset
they
get about the uses their comment field is being put to.

If indeed there is a need for comments in DNS config files, the obvious way
to support that at this stage is to introduce a new RRTYPE for that purpose.
Call it the REM record type. Anyone who really needs comments in the DNS can
use REM. The rest of us can follow the use that has been made of TXT for
over 20+ years: providing config info.

Specification irredentism is not a good look. When the world takes a
different
path to the one you would have prefered, try to roll with it. That's what I
do. I don't spend my time saying people should undo past decisions they made
against their advice, I just spend the next 40 years reminding them they are
responsible for the goof.

As some of you are aware, I am currently working on a scheme that allows a
rather different approach to DNS. Its not exactly an alt.root and its not
exactly
name coin. Imagine what you would get if you removed the ideological
commitments from both...

The parts I don't like in DNS are the root and the need to rent your name
for
$10/yr. What if the cost was $0.10 for life?

---

From: Nico Williams <[email-masked]>
Date: Wed, 14 Apr 2021 13:26:44 -0500

On Wed, Apr 14, 2021 at 12:48:05PM -0400, Phillip Hallam-Baker wrote:
> I did propose a TXT record that could be used for unstructured config
> and the DNS folk rejected it (as they always do). So I really don't
> care how upset they get about the uses their comment field is being
> put to.

If we were starting from scratch we might well not bother with
non-textual RDATA, or domainname compression (we'd zlib-compress all
message payloads).

As tempting as just-one-last-new-RRtype would be, a TXT-like RR with a
sub-type prefix of its textual RDATA, the fact that there would be no
easy way to select for RRs of this type and with a particular sub-type
prefix means we'd probably end up being unhappy with it.  Knowing little
else about this, I'm inclined to believe that that "the DNS folk
rejected it" with good reason.

Nico
--

---

From: Donald Eastlake <[email-masked]>
Date: Wed, 14 Apr 2021 14:57:50 -0400

> rejected it" with good reason.

Hey, as long as you are going with a sub-type, and the like, might as
well revive this RR, which already has type 40 allocated:

https://tools.ietf.org/html/draft-eastlake-kitchen-sink-02

Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 [email-masked]

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 14 Apr 2021 15:26:40 -0400

> rejected it" with good reason.

So your argument is that you don't know what my proposal was so you will
invent your own proposal which is stupid and then conclude that it was
rightfully dismissed as stupid. If you don't understand someone's proposal,
better to ask them rather than making up stories.

It isn't that difficult to make prefixed records delegate correctly either.
I proposed a way to do that. But folk would much rather insist that their
way of doing things is right and that everyone else is in the wrong for
ignoring them.

TXT records are a means of publishing policy information in the DNS. The
principled approach is to use a prefixed record. That this breaks
wildcarding in DNSSEC is a DNSSEC issue, not a DNS policy issue.

If as John Klensin claims, there is a need for comments in the DNS, create
a REM RRType for that purpose. The lack of selectors is irrelevant as they
are merely comments.

Why not just do the job in a scalable fashion? The reason DNS names cost
$10/yr is that the protocol is broken and requires the TLDs to be published
by means of an interactive query protocol even though the data being
published almost never changes. Push that task out to the party providing
authoritative query service for the zone and over 99% of the costs of
running the registry disappear:

Mathematical Mesh 3.0 Part VII: Mesh Callsign Service (ietf.org)
<https://www.ietf.org/archive/id/draft-hallambaker-mesh-callsign-00.html>

Building out a PKI to validate names already assigned is a really hard
problem. Building out a PKI as the names are assigned is a very different
matter.

But of course, nobody will read my proposal, you will just complain
afterwards that I did it all wrong.

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 14 Apr 2021 15:39:42 -0400

On Wed, Apr 14, 2021 at 12:48:05PM -0400, Phillip Hallam-Baker wrote:

> The parts I don't like in DNS are the root and the need to rent your
> name for $10/yr. What if the cost was $0.10 for life?

Then on a modest budget for many folks on this list, one could buy up
and squat on the likely most popular 50,000 to 100,000 names.

So it would seem that either the names are memorable mnemonics, and thus
some much more valuable than others, or they're less valuable by being
less usable.  The $0.10 for life does not sound realistic, unless all
the names are essentially high-entropy random serial numbers.

-- 
    Viktor.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 14 Apr 2021 15:57:39 -0400

> the names are essentially high-entropy random serial numbers.

Well I did predict that nobody would read the draft.

The cost of providing service is less than $0.10

I propose to sell names of 9 characters or more for $0.10, increasing by a
factor of 10x for each character less than 9.

So @a is $10 million, @alice is $1,000, @bob is $100,000 and so on. (or
would be only @alice and @bob are reserved names for examples.) The best
names tend to be shorter names and so the cost would be quite a bit higher
but that is just making sure that we don't leave too much money on the
table while giving people incentive to market Mesh names (and thus the
Mesh).

Yes, this does leave money on the table but I reckon that there Mesh
foundation needs an income of about $10 million /year to do what I want it
to achieve. Running the registry should cost less than a million. The rest
will go to funding open source specs and reference code, funding
conferences, etc. etc.

No, as they put it in the Godfather, I am not a communist. The not for
profit registry is separate from my for-profit Mesh Service Provider and
apps businesses.

The tricky part here will be to make sure that certain names with valid IPR
claims end up in the right place. Obviously, @microsoft, @apple, @cisco
etc. have to go to the right place or there is a security issue. But again,
read the draft.

---

From: Vittorio Bertola <[email-masked]>
Date: Thu, 15 Apr 2021 12:11:13 +0200 (CEST)

>     Il 14/04/2021 21:57 Phillip Hallam-Baker <[email-masked]> ha scritto:
> 
>     I propose to sell names of 9 characters or more for $0.10, increasing by a factor of 10x for each character less than 9.
> 
>     So @a is $10 million, @alice is $1,000, @bob is $100,000 and so on. (or would be only @alice and @bob are reserved names for examples.) The best names tend to be shorter names and so the cost would be quite a bit higher but that is just making sure that we don't leave too much money on the table while giving people incentive to market Mesh names (and thus the Mesh).
> 
>     Yes, this does leave money on the table but I reckon that there Mesh foundation needs an income of about $10 million /year to do what I want it to achieve. Running the registry should cost less than a million. The rest will go to funding open source specs and reference code, funding conferences, etc. etc.
> 
And the IETF. I mean, the IETF, through several indirection layers, gets a big chunk of its funding from the fact that ISOC runs .org. If this dries up in favour of your foundation, I'm sure that you will be willing to pick up the sponsorship of the IETF - and also of all other events and organizations that currently get sponsored by a gTLD registry.

But wait, there's more: in many countries, ccTLD registries are a significant source of funding for all sorts of national Internet projects - research, localization of technology, education, events, industry standardization, governance discussions, content policy enforcement, you name it. You would of course need to spread your funds evenly throughout the planet.

> 
>     No, as they put it in the Godfather, I am not a communist. The not for profit registry is separate from my for-profit Mesh Service Provider and apps businesses. 
> 
>     The tricky part here will be to make sure that certain names with valid IPR claims end up in the right place. Obviously, @microsoft, @apple, @cisco etc. have to go to the right place or there is a security issue. But again, read the draft.
> 
Well, it took seven years for ICANN to decide whether ".amazon" should go to Amazon the company or to Amazon the geographic region as represented by ACTO ( https://en.wikipedia.org/wiki/Amazon_Cooperation_Treaty_Organization) and by the sovereign countries that formed it, and even after the decision was taken, the concerns and the complaints have not ended yet. Perhaps you can come up with a better, more fair solution that will not create international tensions and will not just award politically, socially or religiously relevant names to those that show up with the biggest pile of money (speaking of diversity and inclusiveness...). However, your draft seems silent on this kind of problems, which are also part of the reason why domain names have a price way higher than their operational cost.

I do not necessarily disagree with your idea, but it looks to me that you are underestimating its non-technical impact if it ever succeded - or, if you prefer, the amount of pushback against implementation for non-technical reasons.

--

Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
[email-masked] mailto:[email-masked] 
Office @ Via Treviso 12, 10144 Torino, Italy

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 15 Apr 2021 10:34:30 -0400

On Thu, Apr 15, 2021 at 6:11 AM Vittorio Bertola <
[email-masked]> wrote:

> And the IETF. I mean, the IETF, through several indirection layers, gets a
> big chunk of its funding from the fact that ISOC runs .org. If this dries
> up in favour of your foundation, I'm sure that you will be willing to pick
> up the sponsorship of the IETF - and also of all other events and
> organizations that currently get sponsored by a gTLD registry.
>

That is not my concern and should not be the concern of the IETF. A member
of ISOC told me the potential conflict of interest was one of the
motivations for the sale. It is a real pity that the EFF decided to stab us
in the back with their own fund raising effort.

I am not the guy who is creating the conflict of interest here, that is for
ISOC to sort out. Of course, the fact I am putting a proposal on the table
that makes the conflict relevant might well give them the ability to submit
a new proposal. I would suggest that the jack up the prices first so that
concern is also neutralized.

At this point I have been a part in starting or making major changes in
direction to two other standards bodies and played a leading role in
forming two industry associations. I am using IETF to provide the Note Well
IPR cover, I am not asking anyone for permission, that is not how I work.

But wait, there's more: in many countries, ccTLD registries are a
> significant source of funding for all sorts of national Internet projects -
> research, localization of technology, education, events, industry
> standardization, governance discussions, content policy enforcement, you
> name it. You would of course need to spread your funds evenly throughout
> the planet.
>

Not my problem to replace other people's rents. even if they give a
pittance back in charity.

In case you hadn't noticed, the mail system and the telephone numbering
system are both in widespread use today despite the underlying technologies
being obsolete. Most people still have fax numbers on their business cards
(!). I think it really unlikely DNS names are going to go away in our
lifetimes. The 'worst' that could happen is the pace of growth slows
somewhat and the speculative activity moves away. I don't think we will
seeing the denizens of ICANN-land selling their yachts.

> The tricky part here will be to make sure that certain names with valid
> IPR claims end up in the right place. Obviously, @microsoft, @apple, @cisco
> Well, it took seven years for ICANN to decide whether ".amazon" should go
> to Amazon the company or to Amazon the geographic region as represented by
> ACTO (
> https://en.wikipedia.org/wiki/Amazon_Cooperation_Treaty_Organization) and
> by the sovereign countries that formed it, and even after the decision was
> taken, the concerns and the complaints have not ended yet. Perhaps you can
> come up with a better, more fair solution that will not create
> international tensions and will not just award politically, socially or
> religiously relevant names to those that show up with the biggest pile of
> money (speaking of diversity and inclusiveness...). However, your draft
> seems silent on this kind of problems, which are also part of the reason
> why domain names have a price way higher than their operational cost.
>

I am sure it doesn't cost a quarter million dollars to do this. In fact I
know that it doesn't. I was Principal Scientist for VeriSign for over a
dozen years. I know these issues at least as well as anyone else. In my
case the answer is very easy: I need Jeff Bezos on my side for the Mesh to
be successful and it is essential that @amazon resolve to the place most
expect. For similar reasons, the claims made for @google by those claiming
to represent the number are not something to worry about.

[Oh and no, I am not so naive as to accept for an instant the premise that
the .amazon bunfight is anything more than an attempt to use indigenous
rights as a pretext to extort a large amount of cash from a party with deep
pockets, absolutely none of which will ever go to the people on behalf of
whom the claim is being made.]

Did they take seven years because it was a difficult problem or because it
was easier to not make a decision? I rather think the latter. What you are
showing is how the ad hoc rentier model failed.

> I do not necessarily disagree with your idea, but it looks to me that you
> are underestimating its non-technical impact if it ever succeded - or, if
> you prefer, the amount of pushback against implementation for non-technical
> reasons.
>

I have done core crypto for over 25 years. That work makes a heck of a lot
of governments unhappy. It is the main reason I live in the US rather than
the UK: the legality of my work was certainly not accepted by HMG when I
started.

The Callsign registry isn't just a name registry, it is the hub of a PKI.
Which is why I believe it has a chance of being successful. Every callsign
registered is bound to a public key by definition. And that binding is
immutable, it can be superseded but never erased. So it provides a
functionality the legacy systems never can.

There will be no such thing as 'callsign validated certificates': The
callsign is the key.

There is a business model for CAs of course. Just not the current model
which Google is trying to dismantle anyway.

Dismissing complex claims by incumbent rent seekers is not 'ignorance', it
is a deliberate design decision taken with full awareness of the
consequences. There are some stakeholders I need, some that can be helpful
and others I choose to ignore.

---

From: Ben Laurie <[email-masked]>
Date: Fri, 23 Apr 2021 15:39:12 +0100

> than CAs do. Also, DNS has the same plethora of authorities with varying

I'm afraid my source is my own experience (Google has a *lot* of domains).

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 23 Apr 2021 15:51:46 -0400

> I'm afraid my source is my own experience (Google has a *lot* of domains).

As if to make the point:

Argentine version of Google falls into “wrong” hands leading to search
engine's temporary collapse — MercoPress
<https://en.mercopress.com/2021/04/22/argentine-version-of-google-falls-into-wrong-hands-leading-to-search-engine-s-temporary-collapse>

Expiring names is a daft idea. People should be able to buy a name and hold
it for life. The only circumstance in which a name should be reassigned is
if there is a valid IPR dispute over the use of the name.

The reason DNS names have to be rented not owned is that the design of the
DNS requires that the registry provide query service for the entire net
without any effective defenses against DoS except to spend bucketloads of
cash on gear.

Since suggesting replacement of the industry I helped create, the WebPKI is
considered to be a viable goal, I think it only fair to return the favor
and propose a replacement for the DNS:

The callsign service began as simply asking myself, 'how would we have
designed the MIT PGP Key Servers in the 1990s if the Haber Stornetta patent
(i.e. blockchain) hadn't got in the way'.

We would have a registry maintaining an append only log from PGP
fingerprints to the account/service currently servicing the holder's email.

Then I asked, 'we have portability for telephone numbers, why not for
email?' This was rejected by many incumbents when they saw 'stickiness' to
their advantage. But as anyone who has used a comcast or an ATT broadband
connection and moved knows, stickiness works both ways. Anyone who has had
to change their email address because of a move is not going to go back to
using an email tied to a service in that way.

It turns out that the infrastructure required to support fingerprint
mapping can support a name system at no extra cost - less than $0.10 per
registered name for life to provide a really industrial level of
reliability etc when operating at scale.