Re: [dns-privacy] [Ext] Revised opportunistic encryption draft

[Brian Dickson]

On Wed, Nov 18, 2020 at 6:29 PM Shumon Huque  wrote:

> On Wed, Nov 18, 2020 at 3:42 PM Peter van Dijk <
> peter.van.d...@powerdns.com> wrote:
>
>> On Tue, 2020-11-17 at 23:30 +, Tony Finch wrote:
>> [...]
>> > If (big if) we think it's worth upgrading the DNS delegation model (and
>> > EPP, and all the registries and registrars, and all the IPAM databases
>> and
>> > user interfaces, and documentation and textbooks), can we also tackle
>> the
>> > scalability problem? By "scalability" I mean the need for a hosting
>> > provider to update N delegations when a server cert changes. And
>> there
>> > are decades old problems keeping delegation NS and glue and DS records
>> > correct. (A large chunk of the "it's always DNS" meme comes from how
>> hard
>> > it is to understand delegations and update them correctly.) This whole
>> > area is a massive pain in the arse sorely in need of universal
>> automation.
>>
>> +100. I've referred to this in other threads - if CloudFlare had gotten
>> anywhere with their attempts to solve the operator / registrant /
>> registrar / registry disconnect problem, all of this would be so much
>> easier.
>>
>
> At ICANN69's DNSSEC Workshop last month, Steve Crocker issued a
> challenge to DNS Operators to organize and become an officially
> recognized constituency within ICANN. If that were to happen, then it might
> be able to address and solve some of these issues over time, given
> adequate engagement.
>
> > Any serious attempt at improving delegations needs to deal convincingly
>> > with the quesion of why support for CDS, CDNSKEY, and CSYNC is so
>> > appallingly bad.
>>
>> Yes, or in the broader sense, my previous paragraph.
>>
>
> At the same workshop, Jim Galvin spoke about some of the structural reasons
> why it's challenging for the contracted gTLDs to make progress on
> supporting
> these (and also likely why there has only been adoption at a small number
> of
> ccTLDs, who are non-contracted parties). This was in relation to CDS and
> CDNSKEY. As far as I can tell, no-one has shown any interest in CSYNC to
> date.
>

At the same Workshop, in our presentation I mentioned that we (GoDaddy) are
intent on providing CDS/CDNSKEY support.
This is to work around the logjam which is the RRR system and its
structural limitations.
Specifically, we will support our Registrar customers who are not DNS
customers, by polling them for CDS/CDNSKEY records no matter who hosts
their DNS.
We will then submit those via EPP (which we can do only because we are
their Registrar).

Nothing about this is rocket science, nor is it anything any other
Registrar cannot do.

It's a hack, but it moves the DNSSEC ball forward, and doesn't require any
new DNS "stuff" or Registry changes.

Brian
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] [Ext] Revised opportunistic encryption draft

[Shumon Huque]

On Wed, Nov 18, 2020 at 3:42 PM Peter van Dijk 
wrote:

> On Tue, 2020-11-17 at 23:30 +, Tony Finch wrote:
> [...]
> > If (big if) we think it's worth upgrading the DNS delegation model (and
> > EPP, and all the registries and registrars, and all the IPAM databases
> and
> > user interfaces, and documentation and textbooks), can we also tackle the
> > scalability problem? By "scalability" I mean the need for a hosting
> > provider to update N delegations when a server cert changes. And
> there
> > are decades old problems keeping delegation NS and glue and DS records
> > correct. (A large chunk of the "it's always DNS" meme comes from how hard
> > it is to understand delegations and update them correctly.) This whole
> > area is a massive pain in the arse sorely in need of universal
> automation.
>
> +100. I've referred to this in other threads - if CloudFlare had gotten
> anywhere with their attempts to solve the operator / registrant /
> registrar / registry disconnect problem, all of this would be so much
> easier.
>

At ICANN69's DNSSEC Workshop last month, Steve Crocker issued a
challenge to DNS Operators to organize and become an officially
recognized constituency within ICANN. If that were to happen, then it might
be able to address and solve some of these issues over time, given
adequate engagement.

> Any serious attempt at improving delegations needs to deal convincingly
> > with the quesion of why support for CDS, CDNSKEY, and CSYNC is so
> > appallingly bad.
>
> Yes, or in the broader sense, my previous paragraph.
>

At the same workshop, Jim Galvin spoke about some of the structural reasons
why it's challenging for the contracted gTLDs to make progress on supporting
these (and also likely why there has only been adoption at a small number of
ccTLDs, who are non-contracted parties). This was in relation to CDS and
CDNSKEY. As far as I can tell, no-one has shown any interest in CSYNC to
date.

Shumon.
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] [Ext] Revised opportunistic encryption draft

[Tony Finch]

Peter van Dijk  wrote:

> > https://datatracker.ietf.org/doc/draft-ietf-dnsop-ns-revalidation/
>
> As I understand the draft, the revalidation can happen in parallel to
> the actual query the user is waiting for. Any setup/discovery of secure
> transports would have to happen before that, so I'm not sure we can say
> 'on top of delegation revalidation, TLSA lookups are basically free'.

Yes, this still needs to be thought through more carefully, and measured
in the real world. There are at least a couple of issues that worry me:

  * Exactly how bad is the extra latency?

  * How bad / avoidable are the lurking interop traps?

Likely at least two flavours of the latter: due to asking for TLSA, or
due to deeper iterative resolution into the nameserver's name's zone.

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
Lough Foyle to Carlingford Lough: Southwest 6 to gale 8, veering northwest 7
to severe gale 9, increasing storm 10 for a time in North Channel, decreasing
3 to 5 later. Moderate or rough, becoming rough or very rough, occasionally
high for a time in north. Squally showers. Moderate or good, occasionally
poor.

___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] [Ext] Revised opportunistic encryption draft

[Peter van Dijk]

On Tue, 2020-11-17 at 23:30 +, Tony Finch wrote:
> Peter van Dijk  wrote:
> > The incremental cost for a resolver (doing a full resolution process
> > for the TLSA records of one or more NS names) is not small, and neither
> > are the latency costs. For 'popular' name servers, this cost can mostly
> > be amortised, leaving the penalty with any domain hosted on a NSset
> > that only has a few domains.
> 
> Yes. However I think the relative cost of TLSA lookups is much less when a
> resolver implements delegation revalidation because then it's fetching
> authoritative A and  anyway, so it can fetch TLSA concurrently.
> 
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-ns-revalidation/

As I understand the draft, the revalidation can happen in parallel to
the actual query the user is waiting for. Any setup/discovery of secure
transports would have to happen before that, so I'm not sure we can say
'on top of delegation revalidation, TLSA lookups are basically free'.

> > > Using TLSA records at _853._tcp. in a signed zone provides an
> > > unambiguous signal to use optionally TLSA, in a downgrade-resistant
> > > manner.
> > 
> > Not downgrade-resistant, until NS names in delegations become signed.
> 
> Or until the parent nameservers support authenticated encrypted
> transports.

The design choice that DNSSEC did not make, a long time ago.

> Even so I think delegations should be signed.

It would solve a *lot* of problems.

> A (the?) major issue with this whole ADoT effort is the bad trade-off
> between a delegation-centric design (where the DoT signal is in the parent
> zone) which has really formidable deployment obstacles, and really
> troublesome scalability issues; or a DNS-hosting-provider-centric design
> which has poor performance and downgrade weaknesses.

I know DOTPIN has been rejected/shelved/not-adopted for the
deployment/scalability reasons you mention, and also because the
problem space was not mapped out well enough yet, but I still wonder if
perhaps it makes sense to have two solutions to the DPRIVE charter -
one with short paths, few extra queries (like DOTPIN), and one that
works well with '500k domains delegated to one party' - with
delegations signed, or a non-pinning signal (that does not take part in
key rollovers) on the 500k domains, etc.

> If (big if) we think it's worth upgrading the DNS delegation model (and
> EPP, and all the registries and registrars, and all the IPAM databases and
> user interfaces, and documentation and textbooks), can we also tackle the
> scalability problem? By "scalability" I mean the need for a hosting
> provider to update N delegations when a server cert changes. And there
> are decades old problems keeping delegation NS and glue and DS records
> correct. (A large chunk of the "it's always DNS" meme comes from how hard
> it is to understand delegations and update them correctly.) This whole
> area is a massive pain in the arse sorely in need of universal automation.

+100. I've referred to this in other threads - if CloudFlare had gotten
anywhere with their attempts to solve the operator / registrant /
registrar / registry disconnect problem, all of this would be so much
easier.

> Any serious attempt at improving delegations needs to deal convincingly
> with the quesion of why support for CDS, CDNSKEY, and CSYNC is so
> appallingly bad.

Yes, or in the broader sense, my previous paragraph.

Kind regards,
-- 
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/

___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] [Ext] Revised opportunistic encryption draft

[Peter van Dijk]

On Wed, 2020-11-18 at 10:14 -0500, Paul Wouters wrote:
> On Mon, 16 Nov 2020, Brian Dickson wrote:
> 
> > Yes, this is a huge gap in the fundamentals for any privacy architecture 
> > (ADoT), which is rooted in the unsigned nature of
> > NS records regardless of the security state of a delegation (DNSSEC or not).
> 
> The IP connection to (small) nameservers will always leak information,
> even if perfectly encrypted and obtained without privacy. Just by
> connecting to say ns1.nohats.ca, any observer knows you are connecting
> to either "nohats.ca" or "libreswan.org".

But not what subdomain, if any, of those you are visiting. I do
recognise that this is on the long tail of things we can try to
protect.

> The only way out of that is a distributed decentralized DNS cache.

I always imagined that, given DNSSEC, we could bittorrent our way out
of this. Then later people imagined we could blockchain our way out of
this - but it hasn't happened yet.

> > Downgrade resistant only if the delegation information is protected (NS 
> > names in particular). 
> > Protecting the delegation NS records against an on-path adversary (between 
> > resolver and TLD) does not have any nice
> > solutions.
> 
> This is basically the same problem as ESNI. Except ESNI fixed it by
> pulling information from (encrypted) DNS :)

That's "protecting the NS records against snooping", if I understand you 
correctly. The other problem is protecting the delegation NS records against 
meddling, for which various partial solutions have been provided but we have 
zero standardised today.
 
Kind regards,
-- 
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/

___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] [Ext] Revised opportunistic encryption draft

[Tony Finch]

Brian Dickson  wrote:
> On Tue, Nov 17, 2020 at 3:30 PM Tony Finch  wrote:
> >
> > Even so I think delegations should be signed.
>
> So, the parental NS records are not authoritative, and thus not supposed to
> be signed.

Yes, that was the logic, but it was a mistake :-)

> The signer field would differ between the delegation RRSIG and the apex
> RRSIG (on what would otherwise be very similar RRSETs).

Yes, like RRSIG(NSEC).

A change of this kind would need an algorithm bump to indicate support for
the new semantics, like the bump from 5 to 7 to indicate support for
NSEC3. This has the caveat that a signer will want to wait for a large
enough proportion of validators to upgrade to support the new algorithms
before the signer bumps its algorithm, because old validators will treat
the new algorithms as insecure.

> And I'm not sure whether the DPRIVE use case is enough of a "new
> requirement" to justify changing the spec. But I think that is open to
> consideration at least.

Yes, that's why I'm talking about it :-)

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
Tyne, Dogger, Fisher, German Bight, Humber: Southwest 6 to gale 8, veering
north 7 to severe gale 9. Rough or very rough, occasionally high for a time.
Rain or showers. Moderate or good.

___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] [Ext] Revised opportunistic encryption draft

[Brian Dickson]

On Tue, Nov 17, 2020 at 3:30 PM Tony Finch  wrote:

> Peter van Dijk  wrote:
> > On Sat, 2020-10-31 at 13:52 -0700, Brian Dickson wrote:
>
> > > Using TLSA records at _853._tcp. in a signed zone provides an
> > > unambiguous signal to use optionally TLSA, in a downgrade-resistant
> > > manner.
> >
> > Not downgrade-resistant, until NS names in delegations become signed.
>
> Or until the parent nameservers support authenticated encrypted
> transports.
>
> Even so I think delegations should be signed.
>

So, the parental NS records are not authoritative, and thus not supposed to
be signed.

Has anyone ever experimented with how a signed delegation NS would be
handled by resolvers? (This might vary by resolver software and possibly
version.)

The signer field would differ between the delegation RRSIG and the apex
RRSIG (on what would otherwise be very similar RRSETs).
I.e. if you had zone.example.net NS ns1.something.example.com (and
friends), the apex RRSIG would have signer name zone.example.net, and the
non-apex delegation RRSIG would have a different (shorter) signer name.

Actually doing this as a protocol spec change would probably require that
the delegation RRSIGs would need to be cached differently (in the same way
the NS records are cached differently), and used accordingly.

The standardization of DNSSEC was before my time, so I don't know to what
degree this was discussed back then.
As much as making changes to those RFCs would be difficult and potentially
controversial, this might be the path of least implementation difficulty.
The big thing would be the signing overhead on large authoritative
(delegation-mostly) zones.

And I'm not sure whether the DPRIVE use case is enough of a "new
requirement" to justify changing the spec. But I think that is open to
consideration at least.

Fodder for discussion rather than a serious proposal, at least at this
point.

Brian
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] [Ext] Revised opportunistic encryption draft

[Tony Finch]

Paul Wouters  wrote:
> On Tue, 17 Nov 2020, Tony Finch wrote:
>
> > Any serious attempt at improving delegations needs to deal convincingly
> > with the quesion of why support for CDS, CDNSKEY, and CSYNC is so
> > appallingly bad.
>
> Because IETF does not enforce sunsets of old stuff. The market has no
> strong reason to move to support this new stuff, as there is a first
> mover disadvantage with too many players. Look at Cloudflare, who is
> very willing to do all these new things, and they are stuck with old
> software/people at (sub)Registrars and Registries.
>
> This is also why DNSSEC is not ubiquitous.

Yes, but I don't mean answer the question of what the difficulties are (we
know the answers, I hope), I mean "deal with", counteract or avoid the
difficulties. Any new work needs to be deployable: the IETF is supposed to
be about running code, after all. If a proposal is heading in a direction
that we know from past experience is not likely to be successful, then it
needs a really solid argument why this time will be different.

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
Sole, Lundy, Fastnet: West or northwest 6 to gale 8, occasionally severe gale
9 in Lundy and Fastnet, decreasing 3 to 5 later. Rough or very rough,
occasionally moderate later. Showers. Moderate or good.

___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] [Ext] Revised opportunistic encryption draft

[Paul Wouters]

On Mon, 16 Nov 2020, Brian Dickson wrote:


Yes, this is a huge gap in the fundamentals for any privacy architecture 
(ADoT), which is rooted in the unsigned nature of
NS records regardless of the security state of a delegation (DNSSEC or not).


The IP connection to (small) nameservers will always leak information,
even if perfectly encrypted and obtained without privacy. Just by
connecting to say ns1.nohats.ca, any observer knows you are connecting
to either "nohats.ca" or "libreswan.org".

The only way out of that is a distributed decentralized DNS cache. We
have those, but they are under control of commercial enterprises, and
most of them fall under 1 country's government.



I stand corrected.
Downgrade resistant only if the delegation information is protected (NS names 
in particular). 



Protecting the delegation NS records against an on-path adversary (between 
resolver and TLD) does not have any nice
solutions.


This is basically the same problem as ESNI. Except ESNI fixed it by
pulling information from (encrypted) DNS :)

Paul

___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] [Ext] Revised opportunistic encryption draft

[Paul Wouters]

On Tue, 17 Nov 2020, Tony Finch wrote:


Any serious attempt at improving delegations needs to deal convincingly
with the quesion of why support for CDS, CDNSKEY, and CSYNC is so
appallingly bad.


Because IETF does not enforce sunsets of old stuff. The market has no
strong reason to move to support this new stuff, as there is a first
mover disadvantage with too many players. Look at Cloudflare, who is
very willing to do all these new things, and they are stuck with old
software/people at (sub)Registrars and Registries.

This is also why DNSSEC is not ubiquitous.

Paul

___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] [Ext] Revised opportunistic encryption draft

[Tony Finch]

Peter van Dijk  wrote:
> On Sat, 2020-10-31 at 13:52 -0700, Brian Dickson wrote:
>
> > Using NS names in a separate zone or zones (for each DNS operator) is
> > scalable, and facilitates DNSSEC signing, at little to no incremental
> > cost and little to no operational complexity
>
> The incremental cost for a resolver (doing a full resolution process
> for the TLSA records of one or more NS names) is not small, and neither
> are the latency costs. For 'popular' name servers, this cost can mostly
> be amortised, leaving the penalty with any domain hosted on a NSset
> that only has a few domains.

Yes. However I think the relative cost of TLSA lookups is much less when a
resolver implements delegation revalidation because then it's fetching
authoritative A and  anyway, so it can fetch TLSA concurrently.

https://datatracker.ietf.org/doc/draft-ietf-dnsop-ns-revalidation/

> > Using TLSA records at _853._tcp. in a signed zone provides an
> > unambiguous signal to use optionally TLSA, in a downgrade-resistant
> > manner.
>
> Not downgrade-resistant, until NS names in delegations become signed.

Or until the parent nameservers support authenticated encrypted
transports.

Even so I think delegations should be signed.

A (the?) major issue with this whole ADoT effort is the bad trade-off
between a delegation-centric design (where the DoT signal is in the parent
zone) which has really formidable deployment obstacles, and really
troublesome scalability issues; or a DNS-hosting-provider-centric design
which has poor performance and downgrade weaknesses.

If (big if) we think it's worth upgrading the DNS delegation model (and
EPP, and all the registries and registrars, and all the IPAM databases and
user interfaces, and documentation and textbooks), can we also tackle the
scalability problem? By "scalability" I mean the need for a hosting
provider to update N delegations when a server cert changes. And there
are decades old problems keeping delegation NS and glue and DS records
correct. (A large chunk of the "it's always DNS" meme comes from how hard
it is to understand delegations and update them correctly.) This whole
area is a massive pain in the arse sorely in need of universal automation.

Any serious attempt at improving delegations needs to deal convincingly
with the quesion of why support for CDS, CDNSKEY, and CSYNC is so
appallingly bad.

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
North Utsire, South Utsire: Southwesterly 5 to 7. Rough, occasionally very
rough later. Occasional rain. Good, occasionally poor.

___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] [Ext] Revised opportunistic encryption draft

[Peter van Dijk]

On Mon, 2020-11-16 at 10:22 -0800, Brian Dickson wrote:
> > > That's a moot point.
> > > TLSA records MUST be signed, and the TLSA RFC makes this very clear: RFC 
> > > 6698 section 4.1 (Determining whether a TLSA RRSet can be used MUST be 
> > > based on the
> > >DNSSEC validation state (as defined in [RFC4033]).
> > 
> > Which buys you very little if the name you are looking up is from an
> > unauthenticated source - like NS names in delegations.
> > 
> 
> Ah, okay, now I understand.
> 
> Yes, this is a huge gap in the fundamentals for any privacy architecture 
> (ADoT), which is rooted in the unsigned nature of NS records regardless of 
> the security state of a delegation (DNSSEC or not).

Indeed. That's why we designed DOTPIN (whose shortcomings pretty much
come from not being NS-centric!) to not rely on those names.

> This pretty much impacts any solution that relies on either the names or IP 
> addresses of authoritative servers (the latter served as glue from the TLD).
> An on-path active adversary (between recursive and TLD authoritative server) 
> would be able to modify these unsigned values.

Exactly. A TLSA-authenticated ns1.evil.org does you no good.

> Without any way to obtain them with some degree of protection (transport or 
> data), there is no path to connecting to the correct server initially over 
> TLS.

We could twist this into saying that we can solve the problem by also
doing DoT on the root and the TLDs! (But you also mention that below.)

> If the domain in question (the delegated domain, not the nameserver 
> namespace) is DNSSEC signed, it is possible to detect a discrepancy between 
> the delegation and apex NS records, assuming DNSSEC responses are not blocked 
> or tampered with.

Yes - but by then you've already leaked yourdirtysecrets.com to
ns1.evil.org!

> If the domain in question is not DNSSEC signed, there is no defense against 
> such an attacker, if the query to the TLD is not protected by transport or 
> data security.

> However, even in the signed zone case, confirming the apex NS records does 
> require a query to the authoritative server to verify things,
> If the IP address used operates on port 853, there is no guarantee the server 
> responding is the actual authoritative server rather than an attacker's 
> server, since the name/IP could have been tampered with initially.

Yes (examples given above).

> This leads to a few possible conclusions:
> * With no changes to the DNSSEC management of TLDs (protocol and 
> implementations), and with no availability of ADoT to TLD servers, an on-path 
> active adversary :
> * * Can defeat any attempt at privacy (ADoT) for unsigned zones
> * * Can at most DOS any privacy mechanism for signed zones

Yes and yes.

> * The following techniques can alter the prerequisite conditions, each of 
> which has deployment/operation concerns:
> * * Changes to DNSSEC signing of (at minimum TLD) delegation data (NS records 
> and glue A/ records)

I mentioned 'hash of NSSET into DS' in a dprive thread earlier. 
https://datatracker.ietf.org/doc/draft-fujiwara-dnsop-delegation-information-signer/
does something like this (including glue, which we don't need for our
problem).

> * * * Many large hurdles to overcome, including standardization, 
> implementation, and deployment
> * * * May not be offered by all (or even any) TLDs

I believe DOTPIN (again, with all its shortcomings) has very few
hurdles in this area.

> * * Availability of ADoT at TLD servers
> * * * Protects traffic via TLS
> * * * May not be offered by all (or even any) TLDs

It's DNSSEC all over again.

> * * Eliminating the on-path possibility, by obtaining the TLD zone via 
> AXFR/IXFR
> * * * Protecting the TLD zone transfer is possible by either ZONEMD 
> signature, or by doing AXFR over TLS
> * * * May not be offered by all (or even any) TLDs

Last time I checked, TLD operators where not very eager to drop whole
zone dumps on the world. Also, some zones are simply too large for
this. Ignoring those issues, yes, ZONEMD and/or XoT would solve the on-
path problem.

> > > So, downgrade-resistant, period.
> > 
> > No.
> 
> I stand corrected.
> Downgrade resistant only if the delegation information is protected (NS names 
> in particular). 

Indeed, and the privacy properties then still depend on what the NS
names (and their IPs) tell you. (Some of that goes for DOTPIN as well,
of course).

> Protecting the delegation NS records against an on-path adversary (between 
> resolver and TLD) does not have any nice solutions.

I like 'hash of NSSET [in DS]'.

Now perhaps you see why I offered these possibly-useful puzzle pieces earlier:

* https://tools.ietf.org/id/draft-vandijk-dnsop-ds-digest-verbatim-00.txt
* https://tools.ietf.org/id/draft-peetterr-dnsop-parent-side-auth-types-00.txt

Both of these make room for non-hashing variants of 'authenticate data that is 
unsigned today'.

:-)

(If you'd like to have more puzzle pieces, 

Re: [dns-privacy] [Ext] Revised opportunistic encryption draft

[Brian Dickson]

On Mon, Nov 16, 2020 at 2:02 AM Peter van Dijk 
wrote:

> On Sun, 2020-11-15 at 12:40 -0800, Brian Dickson wrote:
> >
> > > > Using TLSA records at _853._tcp. in a signed zone provides
> an unambiguous signal to use optionally TLSA, in a downgrade-resistant
> manner.
> > >
> > > Not downgrade-resistant, until NS names in delegations become signed.
> >
> > That's a moot point.
> > TLSA records MUST be signed, and the TLSA RFC makes this very clear: RFC
> 6698 section 4.1 (Determining whether a TLSA RRSet can be used MUST be
> based on the
> >DNSSEC validation state (as defined in [RFC4033]).
>
> Which buys you very little if the name you are looking up is from an
> unauthenticated source - like NS names in delegations.
>
>
Ah, okay, now I understand.

Yes, this is a huge gap in the fundamentals for any privacy architecture
(ADoT), which is rooted in the unsigned nature of NS records regardless of
the security state of a delegation (DNSSEC or not).

This pretty much impacts any solution that relies on either the names or IP
addresses of authoritative servers (the latter served as glue from the TLD).
An on-path active adversary (between recursive and TLD authoritative
server) would be able to modify these unsigned values.
Without any way to obtain them with some degree of protection (transport or
data), there is no path to connecting to the correct server initially over
TLS.

If the domain in question (the delegated domain, not the nameserver
namespace) is DNSSEC signed, it is possible to detect a discrepancy between
the delegation and apex NS records, assuming DNSSEC responses are not
blocked or tampered with.

If the domain in question is not DNSSEC signed, there is no defense against
such an attacker, if the query to the TLD is not protected by transport or
data security.

However, even in the signed zone case, confirming the apex NS records does
require a query to the authoritative server to verify things,
If the IP address used operates on port 853, there is no guarantee the
server responding is the actual authoritative server rather than an
attacker's server, since the name/IP could have been tampered with
initially.

This leads to a few possible conclusions:

   - With no changes to the DNSSEC management of TLDs (protocol and
   implementations), and with no availability of ADoT to TLD servers, an
   on-path active adversary :
  - Can defeat any attempt at privacy (ADoT) for unsigned zones
  - Can at most DOS any privacy mechanism for signed zones
   - The following techniques can alter the prerequisite conditions, each
   of which has deployment/operation concerns:
  - Changes to DNSSEC signing of (at minimum TLD) delegation data (NS
  records and glue A/ records)
 - Many large hurdles to overcome, including standardization,
 implementation, and deployment
 - May not be offered by all (or even any) TLDs
 - Availability of ADoT at TLD servers
 - Protects traffic via TLS
 - May not be offered by all (or even any) TLDs
  - Eliminating the on-path possibility, by obtaining the TLD zone via
  AXFR/IXFR
 - Protecting the TLD zone transfer is possible by either ZONEMD
 signature, or by doing AXFR over TLS
 - May not be offered by all (or even any) TLDs




> > So, downgrade-resistant, period.
>
> No.
>

I stand corrected.
Downgrade resistant only if the delegation information is protected (NS
names in particular).

Protecting the delegation NS records against an on-path adversary (between
resolver and TLD) does not have any nice solutions.

Brian
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] [Ext] Revised opportunistic encryption draft

[Peter van Dijk]

On Sun, 2020-11-15 at 12:40 -0800, Brian Dickson wrote:
> 
> > > Using TLSA records at _853._tcp. in a signed zone provides an 
> > > unambiguous signal to use optionally TLSA, in a downgrade-resistant 
> > > manner.
> > 
> > Not downgrade-resistant, until NS names in delegations become signed.
> 
> That's a moot point.
> TLSA records MUST be signed, and the TLSA RFC makes this very clear: RFC 6698 
> section 4.1 (Determining whether a TLSA RRSet can be used MUST be based on the
>DNSSEC validation state (as defined in [RFC4033]).

Which buys you very little if the name you are looking up is from an
unauthenticated source - like NS names in delegations.

> So, downgrade-resistant, period.

No.
 
Kind regards,
-- 
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/

___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] [Ext] Revised opportunistic encryption draft

[Brian Dickson]

On Sun, Nov 15, 2020 at 6:08 AM Peter van Dijk 
wrote:

> On Sat, 2020-10-31 at 13:52 -0700, Brian Dickson wrote:
> > The most unambiguous signal possible, is the presence of a TLSA record
> on _853._tcp..
>
> That's quite a far reaching statement, and I believe it likely to be
> wrong.
>
>
I think we can move this part of the discussion to the larger
thread/document started by Tony Finch.


> > Using NS names in a separate zone or zones (for each DNS operator) is
> scalable, and facilitates DNSSEC signing, at little to no incremental cost
> and little to no operational complexity
>
> The incremental cost for a resolver (doing a full resolution process
> for the TLSA records of one or more NS names) is not small, and neither
> are the latency costs. For 'popular' name servers, this cost can mostly
> be amortised, leaving the penalty with any domain hosted on a NSset
> that only has a few domains.
>

Okay, so my statement implied "to the operator of the name server(s)", not
the resolvers.

Resolver operators need to make their own decisions on whether to offer
privacy services, including whether there are any limits on which authority
servers they implement those privacy services towards.

I don't believe anyone has stated that there would not be any latency cost
or other cost (e.g. compute) for privacy services.

So, IMHO, any discussion on those costs needs to be done in relation to the
other attributes, such as "correctness" of the proposal.
Correctness would involve things like:

   - accommodating multiple server operators with different privacy
   settings (yes/no)
   - anycast dns server addresses where specific anycast instances may have
   different privacy settings (yes/no)
   - ability to differentiate privacy settings at a zone level via some
   mechanism
   - correct source of truth for privacy settings (i.e. must be the dns
   server operator, not the zone owner, to be the actual source of truth)
  - A clear example of the reason this source of truth is required, can
  be seen in the problem with NS records configured by the zone
owner rather
  than the DNS server operator: lame delegations.
   - cost to authoritative server operators (and scalability)

Again, this discussion should proceed in the other thread (Tony Finch's).


>
> > Using TLSA records at _853._tcp. in a signed zone provides an
> unambiguous signal to use optionally TLSA, in a downgrade-resistant manner.
>
> Not downgrade-resistant, until NS names in delegations become signed.
>

That's a moot point.
TLSA records MUST be signed, and the TLSA RFC makes this very clear: RFC
6698 section 4.1 (Determining whether a TLSA RRSet can be used MUST be
based on the

   DNSSEC validation state (as defined in [RFC4033
]).


So, downgrade-resistant, period. (Use of TLSA presupposes signed, in
other words.)



> (I proposed some solutions for that in other threads; Fujiwara has
> [independently, I think] now written a draft resembling one of those
> solutions
>
> https://datatracker.ietf.org/doc/draft-fujiwara-dnsop-delegation-information-signer/?include_text=1
> )
>
> Kind regards,
> --
> Peter van Dijk
> PowerDNS.COM BV - https://www.powerdns.com/
>
> ___
> dns-privacy mailing list
> dns-privacy@ietf.org
> https://www.ietf.org/mailman/listinfo/dns-privacy
>
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] [Ext] Revised opportunistic encryption draft

[Paul Hoffman]

On Nov 15, 2020, at 6:08 AM, Peter van Dijk  wrote:
> 
> On Sat, 2020-10-31 at 13:52 -0700, Brian Dickson wrote:
>> The most unambiguous signal possible, is the presence of a TLSA record on 
>> _853._tcp..
> 
> That's quite a far reaching statement, and I believe it likely to be
> wrong.

+1. The analysis in Tony's draft shows that simple assumptions are probably 
simplistic.

--Paul Hoffman

smime.p7s
Description: S/MIME cryptographic signature
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] [Ext] Revised opportunistic encryption draft

[Peter van Dijk]

On Sat, 2020-10-31 at 13:52 -0700, Brian Dickson wrote:
> The most unambiguous signal possible, is the presence of a TLSA record on 
> _853._tcp..

That's quite a far reaching statement, and I believe it likely to be
wrong.

> Using NS names in a separate zone or zones (for each DNS operator) is 
> scalable, and facilitates DNSSEC signing, at little to no incremental cost 
> and little to no operational complexity

The incremental cost for a resolver (doing a full resolution process
for the TLSA records of one or more NS names) is not small, and neither
are the latency costs. For 'popular' name servers, this cost can mostly
be amortised, leaving the penalty with any domain hosted on a NSset
that only has a few domains.

> Using TLSA records at _853._tcp. in a signed zone provides an 
> unambiguous signal to use optionally TLSA, in a downgrade-resistant manner.

Not downgrade-resistant, until NS names in delegations become signed.
(I proposed some solutions for that in other threads; Fujiwara has
[independently, I think] now written a draft resembling one of those
solutions 
https://datatracker.ietf.org/doc/draft-fujiwara-dnsop-delegation-information-signer/?include_text=1
)

Kind regards,
-- 
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/

___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] [Ext] Revised opportunistic encryption draft

[Tony Finch]

Brian Dickson  wrote:
>
> I think a better comparison (better meaning more relevance and closer
> tracking of the transition and operation) would be the transition of SMTP
> to SMTP using TLS without downgrade susceptibility.

Yes. That was made a lot more difficult because it went through an
intermediate step of unauthenticated TLS, so the protocols and
implementations had to be designed to deal with the fact that a very large
proportion of existing server certificates were wrong. I would prefer not
to have to deal with that again.

> First, a simple assertion: DoTA is only possible/available if it is
> configured by the authoritative DNS operator. Thus, the control of the
> state of whether DoTA is available for zones operated by that operator,
> resides entirely with the operator. This also means that, depending on
> how DoTA availability is signalled or detected, the methods of
> correcting faults in the DoTA operation can vary. Thus, selecting
> signalling/detection mechanisms should take the corrective actions
> available into consideration. IMHO this should actually dominate the
> design.

Yes.

> Third, I'll restate it here: The important characteristic is that whatever
> method(s) are used, they need to be completely downgrade resistant to all
> attack mechanisms, and they need to fail safe.

With the caveat that incremental deployment needs to be possible: If a
zone is hosted by multiple authoritative providers, it should be possible
for one of those providers to deploy DoT without the co-operation of the
zone owner or other providers, and without compromising the availability
of the zone.

That implies a zone only gets a guaranteed private transport if all of its
authoritative providers guarantee a private transport.

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
Sole: East 4 to 6, occasionally 7 at first. Rough. Showers later. Good.

___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] [Ext] Revised opportunistic encryption draft

[Brian Dickson]

On Fri, Oct 30, 2020 at 2:45 PM Eric Rescorla  wrote:

>
>
> On Fri, Oct 30, 2020 at 1:46 PM Paul Hoffman 
> wrote:
>
>> On Oct 30, 2020, at 12:32 PM, Eric Rescorla  wrote:
>> >
>> >
>> >
>> > On Fri, Oct 30, 2020 at 10:03 AM Paul Hoffman 
>> wrote:
>> > On Oct 30, 2020, at 9:11 AM, Paul Wouters  wrote:
>> >> > I still believe the cost of authenticating a DNS(SEC) server is so
>> low
>> >> > these days (with ACME available at no cost and with full automation)
>> >> > that this draft is better not done.
>> >>
>> >> The cost in terms of CPU cycles is indeed low. That is not the cost
>> that is being considered when choosing opportunistic encryption. There is a
>> real cost to the system if entire zones get server failures due to
>> authentication mistakes made by the authoritative servers (not renewing
>> certificates, errors in TLSA records, upstream validation problems that
>> cause TLSA records not to validate, ...) or resolvers (dropping trust
>> anchors that are in use, bad validation logic for TLSA, ...).
>> >>
>> > How is this different from the transition of the Web to HTTPS?
>>
>
I think a better comparison (better meaning more relevance and closer
tracking of the transition and operation) would be the transition of SMTP
to SMTP using TLS without downgrade susceptibility.


>
>> The DNS data is already authenticated if they are using DNSSEC.
>
>
To quote Daffy Duck, "Ha! That's it! Hold it right there! Pronoun trouble."
:-)

The problem with the above statement is who "they" is.

It's actually not a real problem, as I believe the correct "they" is being
referenced. I merely want to put more emphasis on which "they" this is, for
clarity in the rest of the conversation.

In this context, "they" is "whoever is operating the authoritative DNS
servers" for a zone or set of zones.

It should be noted that for a given zone, it is possible that more than one
set of DNS servers, operated by different DNS operators, can serve a given
zone. If there is >1 operator, the failure of one operator to maintain all
the DoTA mechanisms (certs, TLSA records, DNSSEC signatures) does not
impact the zone availability. Thus, the architecture of an optional (I
prefer that over opportunistic) encryption scheme regarding that side of
the connection is not fatally flawed if the mechanism(s) used involving
those mechanisms can fail, so long as they fail safe.

The important characteristic is that whatever method(s) are used, they need
to be completely downgrade resistant to all attack mechanisms, and they
need to fail safe.


>
> I don't see how this is an operational difference. It's a difference in
> value proposition. This whole discussion is predicated on the idea that
> encrypting r2a is valuable; if it's not, we can just go home.
>
>
I agree with EKR. (Try not to be shocked, anyone.)


>
> Also, because the DNS is hierarchical, even a short-lived authentication
>> failure at a particular server will take out the ability to get data for
>> all zones beneath that one; this is not an issue in the web.
>>
>
> As a practical matter, a TLS failure at a site like Google or Facebook has
> a similar kind of impact. But those sites have figured out how to run with
> high availability, and I anticipate that the big DNS servers who have a lot
> of zones beneath them could do so as well.
>
>
I agree with EKR again.

I think the document we're discussing may need to be reworked in terms of
the way the optional ("opportunistic") encryption (DoTA) is controlled,
managed, and signalled. With a re-orientation of the perspective on that, I
think the choices become a lot clearer.

First, a simple assertion: DoTA is only possible/available if it is
configured by the authoritative DNS operator.
Thus, the control of the state of whether DoTA is available for zones
operated by that operator, resides entirely with the operator.
This also means that, depending on how DoTA availability is signalled or
detected, the methods of correcting faults in the DoTA operation can vary.
Thus, selecting signalling/detection mechanisms should take the corrective
actions available into consideration. IMHO this should actually dominate
the design.

Second, some analysis on the DNS operator's NS names, compared to the zone
names, is relevant, regardless of whether the operator is the zone
registrant or some other party.
Understanding this can help motivate elements of the design, or deciding
whether those are reasonable choices.
This includes costs, scaling, and operational practices, particularly for
which zones have (or require) DNSSEC, TLS certificates including TLSA
types, and operational practices.

Third, I'll restate it here: The important characteristic is that whatever
method(s) are used, they need to be completely downgrade resistant to all
attack mechanisms, and they need to fail safe.

Lastly, there is the standards process issue of whether any specification
for DoTA can or should be done without significant input from authoritative
DNS operators and 

Re: [dns-privacy] [Ext] Revised opportunistic encryption draft

[Eric Rescorla]

On Fri, Oct 30, 2020 at 1:46 PM Paul Hoffman  wrote:

> On Oct 30, 2020, at 12:32 PM, Eric Rescorla  wrote:
> >
> >
> >
> > On Fri, Oct 30, 2020 at 10:03 AM Paul Hoffman 
> wrote:
> > On Oct 30, 2020, at 9:11 AM, Paul Wouters  wrote:
> >> > I still believe the cost of authenticating a DNS(SEC) server is so low
> >> > these days (with ACME available at no cost and with full automation)
> >> > that this draft is better not done.
> >>
> >> The cost in terms of CPU cycles is indeed low. That is not the cost
> that is being considered when choosing opportunistic encryption. There is a
> real cost to the system if entire zones get server failures due to
> authentication mistakes made by the authoritative servers (not renewing
> certificates, errors in TLSA records, upstream validation problems that
> cause TLSA records not to validate, ...) or resolvers (dropping trust
> anchors that are in use, bad validation logic for TLSA, ...).
> >>
> > How is this different from the transition of the Web to HTTPS?
>
> The DNS data is already authenticated if they are using DNSSEC.


I don't see how this is an operational difference. It's a difference in
value proposition. This whole discussion is predicated on the idea that
encrypting r2a is valuable; if it's not, we can just go home.


Also, because the DNS is hierarchical, even a short-lived authentication
> failure at a particular server will take out the ability to get data for
> all zones beneath that one; this is not an issue in the web.
>

As a practical matter, a TLS failure at a site like Google or Facebook has
a similar kind of impact. But those sites have figured out how to run with
high availability, and I anticipate that the big DNS servers who have a lot
of zones beneath them could do so as well.



> > Sure, there can be misconfigurations of various kinds, but good
> operational practices can minimize these, and in return you get strong
> security.
>
> What extra value is the "strong security"? Is that value worth the risk of
> inability to get data from a zone? In the web world, the decision that the
> value was greater than the risk was based heavily on being able to
> authenticate the data using TLS. We don't have that same balance in the DNS.
>

The value proposition here is the confidentiality of the query. Defending
that against active attacks requires authenticating the server.

-Ekr
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] [Ext] Revised opportunistic encryption draft

[Hollenbeck, Scott]

> -Original Message-
> From: dns-privacy  On Behalf Of Paul
> Hoffman
> Sent: Friday, October 30, 2020 4:46 PM
> To: Eric Rescorla 
> Cc: dpr...@ietf.org
> Subject: [EXTERNAL] Re: [dns-privacy] [Ext] Revised opportunistic encryption
> draft
>
> On Oct 30, 2020, at 12:32 PM, Eric Rescorla  wrote:
> >
> >
> >
> > On Fri, Oct 30, 2020 at 10:03 AM Paul Hoffman 
> wrote:
> > On Oct 30, 2020, at 9:11 AM, Paul Wouters  wrote:
> >> > I still believe the cost of authenticating a DNS(SEC) server is so
> >> > low these days (with ACME available at no cost and with full
> >> > automation) that this draft is better not done.
> >>
> >> The cost in terms of CPU cycles is indeed low. That is not the cost that is
> being considered when choosing opportunistic encryption. There is a real
> cost to the system if entire zones get server failures due to authentication
> mistakes made by the authoritative servers (not renewing certificates, errors
> in TLSA records, upstream validation problems that cause TLSA records not to
> validate, ...) or resolvers (dropping trust anchors that are in use, bad
> validation logic for TLSA, ...).
> >>
> > How is this different from the transition of the Web to HTTPS?
>
> The DNS data is already authenticated if they are using DNSSEC. Also,
> because the DNS is hierarchical, even a short-lived authentication failure at 
> a
> particular server will take out the ability to get data for all zones beneath 
> that
> one; this is not an issue in the web.
>
> > Sure, there can be misconfigurations of various kinds, but good operational
> practices can minimize these, and in return you get strong security.
>
> What extra value is the "strong security"? Is that value worth the risk of
> inability to get data from a zone? In the web world, the decision that the
> value was greater than the risk was based heavily on being able to
> authenticate the data using TLS. We don't have that same balance in the
> DNS.

This is an important point. Privacy can't increase the risk of a loss of 
availability, especially as we move closer to the DNS root.

Scott

___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] [Ext] Revised opportunistic encryption draft

[John R Levine]

I get the gist of it, caches consult an oracle to see whether to use
DoT, and you have to find your own oracle. That seems uncontroversial,
but I fear it is so uncontroversial that it won't be useful.


And now I'm having trouble following your logic. Which oracle are you 
talking about? The draft only talks about "check on port 853 for DoT 
service".


I mean "oracle" as used in some kinds of mathematical proofs, a conceptual 
external black box that answers questions.  In this case the transport 
cache or perhaps whatever loads the transport cache is the oracle.


Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] [Ext] Revised opportunistic encryption draft

[Paul Hoffman]

On Oct 30, 2020, at 12:32 PM, Eric Rescorla  wrote:
> 
> 
> 
> On Fri, Oct 30, 2020 at 10:03 AM Paul Hoffman  wrote:
> On Oct 30, 2020, at 9:11 AM, Paul Wouters  wrote:
>> > I still believe the cost of authenticating a DNS(SEC) server is so low
>> > these days (with ACME available at no cost and with full automation)
>> > that this draft is better not done.
>> 
>> The cost in terms of CPU cycles is indeed low. That is not the cost that is 
>> being considered when choosing opportunistic encryption. There is a real 
>> cost to the system if entire zones get server failures due to authentication 
>> mistakes made by the authoritative servers (not renewing certificates, 
>> errors in TLSA records, upstream validation problems that cause TLSA records 
>> not to validate, ...) or resolvers (dropping trust anchors that are in use, 
>> bad validation logic for TLSA, ...).
>> 
> How is this different from the transition of the Web to HTTPS?

The DNS data is already authenticated if they are using DNSSEC. Also, because 
the DNS is hierarchical, even a short-lived authentication failure at a 
particular server will take out the ability to get data for all zones beneath 
that one; this is not an issue in the web.

> Sure, there can be misconfigurations of various kinds, but good operational 
> practices can minimize these, and in return you get strong security.

What extra value is the "strong security"? Is that value worth the risk of 
inability to get data from a zone? In the web world, the decision that the 
value was greater than the risk was based heavily on being able to authenticate 
the data using TLS. We don't have that same balance in the DNS.

Again, some folks might want to take the risk of a hierarchical failure in 
order to get additional authentication of data beyond what DNSSEC gives you. If 
so, a document stating that use case and a protocol to go with it would help 
find who else wants that.

--Paul Hoffman

smime.p7s
Description: S/MIME cryptographic signature
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] [Ext] Revised opportunistic encryption draft

[Paul Hoffman]

On Oct 30, 2020, at 11:55 AM, John Levine  wrote:
> 
> In article  you write:
>> Please see
>>  
>> https://urldefense.com/v3/__https://tools.ietf.org/html/draft-pp-recursive-authoritative-opportunistic-01__;!!PtGJab4!vl19XNUhsMgJI-uBPf9MS755H4n4TwXtgXF2sb1KJaWgGj29kdvUieBrp6OXnpaCZE4BL36jAw$
>>  
>> This isn't a WG document yet, but if the WG wants it, I think it could work 
>> well within the charter, and with the discussion of 
>> draft-ietf-dprive-phase2-requirements.
> 
> I'm having some trouble following this draft since it looks like parts
> of the text got scrambled, e.g.:
> 
>   In the opportunistic encryption described here, there is no need for
>   the recursive resolver to authenticate the authoritative server
>   because any authentication failure does not cause the TLS session
>   from being set up.  
> 
> I get the gist of it, caches consult an oracle to see whether to use
> DoT, and you have to find your own oracle. That seems uncontroversial,
> but I fear it is so uncontroversial that it won't be useful.

And now I'm having trouble following your logic. Which oracle are you talking 
about? The draft only talks about "check on port 853 for DoT service".

> As far as whether to validate the server's certificate, that seems to
> me to be a policy decision based on your threat model. If your threat
> is traffic being snooped in transit, you don't, if it's traffic being
> stolen by hostile servers, you do. 

The latter is not part of the explicit use case for this document. If others 
have that use case and want to write it up, that's great. However, they 
haven't, so we can't evaluate it.

> We leave for later the question of to what extent authenticating the
> authoritative server might be a substitute for DNSSEC (keeping in mind
> we know where to find dnscurve if that's what you want.)

That's for the other use case, yes.

--Paul Hoffman

smime.p7s
Description: S/MIME cryptographic signature
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] [Ext] Revised opportunistic encryption draft

[Eric Rescorla]

On Fri, Oct 30, 2020 at 10:03 AM Paul Hoffman 
wrote:

> On Oct 30, 2020, at 9:11 AM, Paul Wouters  wrote:
> > I still believe the cost of authenticating a DNS(SEC) server is so low
> > these days (with ACME available at no cost and with full automation)
> > that this draft is better not done.
>
> The cost in terms of CPU cycles is indeed low. That is not the cost that
> is being considered when choosing opportunistic encryption. There is a real
> cost to the system if entire zones get server failures due to
> authentication mistakes made by the authoritative servers (not renewing
> certificates, errors in TLSA records, upstream validation problems that
> cause TLSA records not to validate, ...) or resolvers (dropping trust
> anchors that are in use, bad validation logic for TLSA, ...).
>

How is this different from the transition of the Web to HTTPS? Sure, there
can be misconfigurations of various kinds, but good operational practices
can minimize these, and in return you get strong security.

-Ekr
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] [Ext] Revised opportunistic encryption draft

[Paul Hoffman]

On Oct 30, 2020, at 9:11 AM, Paul Wouters  wrote:
> I still believe the cost of authenticating a DNS(SEC) server is so low
> these days (with ACME available at no cost and with full automation)
> that this draft is better not done.

The cost in terms of CPU cycles is indeed low. That is not the cost that is 
being considered when choosing opportunistic encryption. There is a real cost 
to the system if entire zones get server failures due to authentication 
mistakes made by the authoritative servers (not renewing certificates, errors 
in TLSA records, upstream validation problems that cause TLSA records not to 
validate, ...) or resolvers (dropping trust anchors that are in use, bad 
validation logic for TLSA, ...).

> One thing that stands out:
> 
> 
>   The recursive resolver MAY note the
>   authentication failure and act on it (such as by logging it or noting
>   it in the cache), as long as the failure does not prevent the TLS
>   session from completing.
> 
> I believe what is meant here is certificate validation (identity
> authentication) and not (session) authentication.

Arrrgh, you are absolutely correct here. I've even made this mistake before.

> For example, an attack
> modifying the TLS handshake parameters would lead to an authentication
> failure and such a failure MUST NOT be ignored.

Yep, and others. Will fix.

> The Transport Cache section should probably mention negative cache
> too.  That ia,s clarify that the cache is used not only positive TLS
> authentication information but also the lack there of.

Good catch, yes.

> I'm not sure why the AUTHINFO section was removed?

Because you complained that the protocol was too complicated, and I agreed.

--Paul Hoffman

smime.p7s
Description: S/MIME cryptographic signature
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy