Re: [dns-privacy] how can we ADoT?

[Tony Finch]

Peter van Dijk  wrote:
>
> What I think I mean to say there is 'if an auth NS responds on port 853,
> it had better offer me all the data it also has to offer on 53'.

Yes, I think that makes the most sense.

> >   * Authenticate the server by `subjectAltName` `iPAddress`. [snip]
>
> For DOTPIN, Ralph Dolmans had the bright insight to suggest not sending
> a server name at all (which matches what I said earlier - name servers
> have IPs, not really names).

Do you mean not sending in TLS SNI? Yes, that would make sense if we're
not doing name-based auth.

(I have not really thought about SNI in this context; might be useful for
operators who like to use glueful delegations with alternate nameserver
names per zone, though I expect that will end up causing sadness if they
don't control all the zones.)

Even with RFC 8738 acme ip, there's the wrinkle that you can't use acme
dns-01 challenges to get the cert - ironic :-)

> >   * Ignore certificate name mismatches, and authenticate just the public
> > key. [snip]
>
> As above. (Not saying that it is the only way, but 'a name server has
> no name' has a lot of convenient properties.)

There's another downside to this case: with IP-based or name-based auth,
you can put the CA's public key in the TLSA rather than the server key, so
there's less rollover churn, but that doesn't make sense for key-based
auth.

> >   * Use the presence of a DNS record associated with the nameserver name
> > to indicate that the server's certificate will match the name.
>
> First thought: yes. Second thought: what if the owner of the 'vanity
> name' 'aliased' to the NS just copies the TLSAs? At sufficient
> deployment, the failure mode is immediate and clear, of course.

That should lead to a certificate name mismatch. If we aren't doing
name-based auth then there won't be an immediate failure; instead it's
likely to go wrong when the server operator rolls their keys or switches
CA, and that delayed failure will be HORRIBLE to debug.

I think there are significant (albeit woolly) advantages to staying as
close as possible to normal webPKI for DoT: much lower congnitive load for
operators who can reuse their https knowledge; deveopers don't have to
write code that's too weirdly different from https; very straightforward
parallel deployment for DoT, DoH, DoQ (if we ever want to support more
transports).

On the other hand you are right that IP address auth is much closer to the
way the DNS works now. I think the other most plausible design for ADoT is
in-band signalling with a strict transport security option and ip-based
auth. (As Ekr said)
https://mailarchive.ietf.org/arch/msg/dns-privacy/Qhn62UWBclwNXjlMaUNoT6M9sMU/

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
Thames, Dover: Southwest veering northwest later, 6 to gale 8, perhaps severe
gale 9 later, decreasing 4 to 6 later. Moderate or rough. 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

[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

[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

[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

[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] Amortization techniques for less popular name server names

[Tony Finch]

Brian Dickson  wrote:

> Attempting to do XFR for many name servers which are infrequently used
> would have scalability issues from any resolver, if the server names are
> in a large number of zones. One approach to reducing this issue is
> aggregating server names inside many fewer zones. Doing this aggregation
> creates trust issues, however.

Summarizing brutally :-) this sounds a bit like a combination between DLV
and hyperlocal root zones?

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
Thames, Dover: Southwest 5 to 7. Moderate or rough, occasionally slight later.
Rain or drizzle at first. Moderate or good, occasionally poor.

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

Re: [dns-privacy] how can we ADoT?

[Tony Finch]

Thanks for reading and providing feedback!

Peter van Dijk  wrote:

> On Wed, 2020-11-11 at 19:07 +0000, Tony Finch wrote:
> >
> >   * Encryption would apply to the server as a whole, whereas the
> > working group consensus is that it should be possible for
> > different zones on the same server to use encrypted and
> > unencrypted transports.
>
> (plus, in another email, Tony wrote: "A nice thing about TLSA records
> is they also tell the client what name to look for in the server's
> cert.")
>
> This looks like a mistake to me, or at least, a choice that would have
> to be made very deliberately.

My point above mostly relates to section 5.1 points 7 and 9 of
https://tools.ietf.org/html/draft-ietf-dprive-phase2-requirements-02

I agree that this is very arguable but I think it's hard to avoid.

> Today, the name through which I reach an NS does not matter - it is not
> part of the protocol exchange like the HTTP Host header is. This
> simplifies a lot of things, and allows some leeway for mismatches in
> names between parents, childs, etc., as long as they reach the same IP.

Right. I need to write more about this issue of nameserver aliases,
something like the text below. (Er but I need to avoid the term "alias"
because that's tied up with CNAMEs which are not allowed for
nameservers...)

> It also seems that any 'split' between which zones on a certain IP
> support encryption and which zones do not, would make any opportunistic
> proposal obsolete immediately.

I'm not sure what you mean here because "opportunistic" has multiple
meanings, and they have different implications for how a client might
authenticate a server.


... and now the text below ...


## TLS certificate authentication

The DNS does not currently depend on the name that appears in an NS
target, provided it resolves to the IP address(es) of the intended server.
In particular the NS name does not have to be the server operator's
preferred name. Zone operators sometimes use different nameserver names
because they prefer to avoid glueless delegations, for example.

The widespread use of unofficial nameserver names means it is impossible
for a nameserver to present a certificate that always matches the
`subjectAltName` `dNSName` [RFC 6125] expected by the client. There are a
number of ways to avoid this problem:

  * Authenticate the server by `subjectAltName` `iPAddress`. Unfortunately
IP address certificates are hard to obtain (though this is likely to
become easier after [RFC 8738] is deployed). This is only an advantage
when there is no signal associated with the nameserver's name (such as
TLSA records) indicating support for encrypted transports, because if
there is such a signal the client knows what name to expect in the
certificate.

  * Use the syntax of the name, such as a `dot--` prefix, to indicate that
the name will match the certificate. This has the disadvantage of
requiring all delegations to be updated.

  * Ignore certificate name mismatches, and authenticate just the public
key. This raises the question of how the client can find out the right
public key: if it can find out the right key why can't it also
find out the right name? It has the disadvantage that public key
pinning has a poor operational track record.

  * Use the presence of a DNS record associated with the nameserver name
to indicate that the server's certificate will match the name. For
example, TLSA records alongside the nameserver's address records;
other possible kinds of records for doing this job are discussed in
the following subsections.


## Nameservers with multiple names

This proposal involves four kinds of name that a nameserver operator needs
to consider:

  * A nameserver's official name, which is used in the vast majority of NS
records pointing at this server. The presence or absence of a TLSA
record associated with this name controls whether transport encryption
is used for the owners of these NS records.

  * A `dot--` tagged name, which can provide better privacy when the NS
target name is below its own zone cut, and is not necessary in other
cases.

  * Unofficial names that differ from the server operator's preferred
name. Zones using unoffical nameserver names are likely to have
problems using an encrypted transport, for example because of the need
to keep TLSA records in sync. The server operator can (in principle)
determine the extent of this problem by auditing all the server's
zones' apex and delegation NS records.

  * Alternative names that advertise different encrypted transports than
the official name. A nameserver operator can use different names for
the same nameserver to support encryption for a subset of zones. This
might be useful for testing or phased rollout.

A nameserver's support 

Re: [dns-privacy] how can we ADoT? (with github url)

[Tony Finch]

Manu Bretelle  wrote:

> The "cloud provider" case, e.g few name servers for many zones is also
> tricky.

I prefer to think of this as the normal common case, since I'm not a cloud
provider and I have many more zones than servers :-)

> I think in those cases, TLSA may be the best bet as this is under
> control of the nameserver, not the zone operator. Then there  may be issue
> with being able to opt people in/out. I think in any cases, if you want to
> be able to gradually enroll your customers while giving the the choice to
> not be enrolled, you essentially need to provide them with a new NS that
> supports ADoT and have them move over.

Yes. It can be just different aliases for the same server, where the
aliases differ in whether they have associated TLSA records or not. (I
need to write more about nameserver aliases.)

> That hint could be downgraded, but if not, can be used to fetch the TLSA
> record over an unauthenticated TLS connection and then validating it. I
> suppose it just obfuscate the  zone, which may be useful *if* multiple name
> server names are behind the same IP and/or name server name matches the
> zone name (because TLSA record would be against name server name, not zone).
> Unless the query to the parent zone was using ADoT, that information may
> already be known from someone on-path.

Yes. (I think I covered all those points in my notes.)

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
Fair Isle: South 6 to gale 8. Rough or very rough, occasionally high in
northwest. Rain or squally showers. Good, occasionally poor.

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

Re: [dns-privacy] how can we ADoT? (with github url)

[Tony Finch]

Manu Bretelle  wrote:
>
> Totally fair, pretty sure there were no speaker notes ;) . The
> presentation is available at https://youtu.be/MIapQ6UXrdg?t=5387 .
> Originally, there was this draft
> https://tools.ietf.org/html/draft-bretelle-dprive-dot-for-insecure-delegations-01
> and the solutions in the slide deck were compiled from feedback/ideas that
> came up while talking with other folks.

Ooh, that video has lots of ideas, thanks! I think most of them are
slightly different angles on approaches that I rejected in my notes. (how
do I do a wry emoticon?) I'll try to summarise - please forgive me if I
have misunderstood...

  * DSPKI: vaguely dnscurve flavoured delegations, but putting an X.509
SPKI into a new delegation RRtype. Comes under my "new kind of
delegation" heading.

(There's a twist that DSPKI seems to have an authenticator per zone,
so all servers are expected to share the same private key?)

  * Do9: per-server encryption hint without authenticator inside DS
records. Most of the badness under my "new DS algorithm" heading,
but with less key rollover churn. WebPKI authentication.

Joe Abley emphasized what I called the scalability issue. Wes Hardaker
made a slightly different point about correctness and synchronization of
apex and delegation records. Wes's point kind of strengthens the
scalability issue: a design that avoids per-zone configuration of any
kind for scalability reasons also avoids delegation mismatch problems.

Watson Ladd made a good point about decoupling signalling from
authentication. My prejudice was that if you are publishing a 1 bit ADoT
signal in the DNS you might as well publish a 256 bit authenticator; now
that I have gone through the options in detail I still think that is true.
And I think it implies that any approach to ADoT based on in-band
signalling should avoid relying on any records published in the DNS,
because then the in-band signal no longer does anything useful.

[ I've been very bad at looking for and citing previous work, sorry
everyone... I belatedly realise the datatracker doesn't list expired
drafts, oops ]

> Speaking of which, I think Brian Dickson did a good job of describing an
> "hybrid" approach which I had notes of, but never got to write down
> properly. Here is the link:
> https://mailarchive.ietf.org/arch/msg/dns-privacy/FdUhMUGNR-CybLrTBQfgGjq0ZY0/

Yes, I think Brian's description is basically the same as what I have in
mind. On top of that I've added a little complication, `dot--` hints so
that when a delegation requires glue, a resolver can still connect
directly over TLS without first getting the TLSA records. I am unsure if
these hints are really needed...

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
Channel Islands: South to southeast 6 to 7, locally gale 8 with gusts to 50kt,
veering west to southwest 5 to 7 before midnight, decreasing 4 to 5 around
dawn, locally 6 mid-channel, backing southwest to south in the afternoon.
Rather rough to rough, occasionally moderate in the south and east, becoming
slight in the south to rather rough in the north by midday, perhaps locally
rough mid-channel, with a low swell throughout. Rain, locally heavy, clearing
before midnight to isolated showers. Good, occasionally moderate to poor this
evening.

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

Re: [dns-privacy] how can we ADoT?

[Tony Finch]

Eric Rescorla  wrote:
> On Wed, Nov 11, 2020 at 11:07 AM Tony Finch  wrote:
>
> >   2. Signal in an EDNS [@?RFC6891] or DSO [@?RFC8490] option: the
> > resolver starts by connecting in the clear, and upgrades to an
> > encrypted connection if the authoritative server supports it.
> >
> > This is vulnerable to downgrade attacks. The initial cleartext
> > connection adds latency, and would need to be specified carefully
> > to avoid privacy leaks.
>
> It's worth noting that one could add an HSTS-like mechanism here. Given
> that a lot of requests are probably return customers, this would likely
> result in quite a lot of lift.

Good point, thanks! I haven't thought about this option enough.

One thing that will make it more tricky is nameserver aliases: it's
relatively common for NS records to refer to servers by names that the
server operator does not know. So I expect that an in-band upgrade to TLS
will have to use IP-address-based authentication, if any.

A nice thing about TLSA records is they also tell the client what name to
look for in the server's cert. (I need to make that more explicit in my
notes.)

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
Trafalgar: In southeast, easterly 4 to 6. In northwest, southwesterly 5 to 7,
becoming cyclonic 4 or 5 later. In southeast, moderate. in northwest, moderate
becoming rough. In southeast, fair. In northwest, showers. Good.

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

Re: [dns-privacy] how can we ADoT?

[Tony Finch]

Hollenbeck, Scott  wrote:
>
> It's not an EPP limitation. We can always define an EPP extension to add
> information to the parent zone. The issue is if the zone administrator
> can/will publish that information in the zone and if EPP clients are able and
> willing to provide it.

True! I am using "EPP" as a grossly unfair and simplified shorthand for
the whole registry/registrar ecosystem. TBH I think most of the
difficulties are in registrar user interfaces and APIs, rather than EPP. I
would be very grateful if someone could write a more informed and accurate
description of the registr* aspects of how feasible it might be to change
the domain delegation model.

If it's worth revising these notes I will change this part to be less
lazy. Thanks for reading and it and giving feedback!

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
Rockall: Northwest 3 to 5 backing south 7 to severe gale 9, perhaps storm 10
later. Rough, becoming very rough or high. Rain. Moderate becoming poor.

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

[dns-privacy] how can we ADoT?

[Tony Finch]

I haven't seen anything written down that explains why it is difficult to
do DoT to authoritative servers. There was a good discussion earlier this
year about draft-vandijk-dprive-ds-dot-signal-and-pin which covered some
of the issues. I have done a braindump that attempts to cover all the
angles reasonably systematically. I expect I haven't quite reached that
goal though, so I hope this will provoke some informative comments :-)
Since draft submission is closed, I'll paste it here for your delectation.


## Explicit encryption support signal

How can a resolver know an authoritative server supports encryption?
There are three basic alternatives:

 1. No explicit signal: the resolver tries to make an encrypted
connection, and falls back to cleartext if it gets an ICMP
unreachable error or connection timeout.

This is problematic because connection timeouts can be very slow,
especially if the resolver tries multiple encrypted transports.
This is also is vulnerable to downgrade attacks.

The working group consensus is that an explicit signal is
required.

 2. Signal in an EDNS [@?RFC6891] or DSO [@?RFC8490] option: the
resolver starts by connecting in the clear, and upgrades to an
encrypted connection if the authoritative server supports it.

This is vulnerable to downgrade attacks. The initial cleartext
connection adds latency, and would need to be specified carefully
to avoid privacy leaks.

 3. Signal in DNS records: the resolver makes extra queries during
iterative resolution to find out whether an authoritative server
supports encryption, before the resolver connects to it.

The extra queries add latency, though that can be mitigated by
querying concurrently, and by placing the new records on the
existing resolution path.

DNSSEC can provide authentication and downgrade protection.

This specification takes the last option, since it is best for
security and not too bad for performance.


## Where can nameserver encryption records go?

Where can we put the new DNS records to signal that a nameserver
supports encryption? There are a number of issues to consider:

  1. Performance: we don't want the extra queries to slow down
 resolution too much;

  2. Scalability: is encryption configured per nameserver? per zone?

  3. Authentication: DNSSEC does not protect delegation NS records or
 glue address records;

  4. DNS data model: we ought to re-use existing RRtypes according to
 their intended purpose;

  5. DNS extensibility: make use of well-oiled upgrade points and
 avoid changes that have a track record of very slow deployment;

  6. EPP compatibility: a zone's delegation is usually managed via the
 Extensible Provisioning Protocol [@?RFC5730] [@?RFC5731]
 [@?RFC5732] so any changes need to work with EPP.

The following subsections discuss the possible locations, and explain
why most of them have been rejected.


## In the reverse DNS?

Given a nameserver's IP address, a resolver might make a query like

_853._tcp.1.2.0.192.in-addr.arpa.TLSA?

This possibility is rejected because:

  * It would be very slow: after receiving a referral, a resolver
would have to iterate down the reverse DNS, instead of immediately
following the referral.

  * At the moment the reverse DNS refers to the forward DNS for NS
records; this would also make the forward DNS refer to the reverse
DNS for TLSA records. Dependency loops are best avoided.

  * It's often difficult to put arbitrary records in the reverse DNS.

  * Encryption would apply to the server as a whole, whereas the
working group consensus is that it should be possible for
different zones on the same server to use encrypted and
unencrypted transports.


## A new kind of delegation?

In theory, DNSSEC provides a way to update the DNS data model, along
the lines of the way NSEC3 was introduced [@?RFC5155]. The rough idea
is to introduce new DNSSEC algorithm types which indicate that a zone can
include new types of records that need special validation logic.
Existing validators will be able to resolve names in the zone, but
will treat it as insecure.

We might use this upgrade strategy to introduce new delegation records
that indicate support for transport encryption. However, it would
require a very long deployment timeline. It would also require a
corresponding upgrade to EPP.

This is much too difficult.


## Non-delegation records in the parent zone?

Although it's extremely difficult to change which DNS records can
appear at a delegation, in principle the parent zone could contain
information about a delegation in a separate subdomain, like

zone.example.NSns1.zone.example.
zone.example.NSns2.zone.example.
_853._tcp.ns1.zone._dot.example.TLSA (...)
_853._tcp.ns2.zone._dot.example.TLSA (...)

The `_dot` tag makes the TLSA records into authoritative data in the
parent 

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] Revised opportunistic encryption draft

[Tony Finch]

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.

+1

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
South Utsire: Northwesterly 4 to 6, becoming variable 2 to 4 later. Moderate
or rough. Rain or drizzle. Moderate or good, occasionally poor.

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

[dns-privacy] the rec/auth dot problem, was Re: Call for adoption: draft-vandijk-dprive-ds-dot-signal-and-pin

[Tony Finch]

Peter van Dijk  wrote:
>
> (and I agree with Paul Hoffman and others that we have plenty of
> proposals, fully worked out or not, but not a lot of agreement on what
> the actual shape is of the problem we are solving.)

At what level of detail is it not clear? The problem I see is that none of
the plausible ways to a solution are particularly attractive. The overall
shape of the problem has always seemed to me to be straightforward to map
out. Here's a quick sketch, not going into too much detail and with plenty
of gaps.


Problem: given a referral, how can a resolver find out which (if any)
authoritative servers support DoT (or some other private transport)
without leaking any of the query (especially the qname)?

Solution 1: no signalling

Solution 2: signalling in the DNS message protocol

Solution 3: signalling in the DNS zone data tree

Solution 4: signalling outside the DNS

(I'll unpack these below)


Observation: if there is an authenticated signal then authenticated
encryption and unauthenticated encryption are equally difficicult, so
there's no benefit and significant loss of security to do DoT without
authentication.


Observation: a lot of these solution sketches add multiple round trips to
the query time (even if you don't count TLS connection setup), so I won't
mention it as a problem every time, even though latency is important for
choosing between them. (this is just a sketchy map not a michelin guide)


Solution 1.1: just try DoT

Problem 1.1.1: Trying the connection is likely to be slow because SYN
packets to unexpected ports are often silently dropped.

Problem 1.1.2: There isn't a reliable way to authenticate the server:
many delegations use non-canonical authoritative server names so even
if the server supports DoT its certificate is likely to have the wrong
name.

Problem 1.1.3: TOFU authentication doesn't support rollover.


Solution 1.?: any others under the "no signalling" header?


Problem 2: in-protocol upgrades are subject to downgrade attacks


Solution 2.1: use RFC 8490 DSO to do STARTTLS

Problem 2.1.1: everyone hates STARTTLS

Problems 1.1.2 and 1.1.3 apply to solution 2.1 (and also 1.1.1 unless
you are very optimistic)


Solution 2.2: send a preflight request to ask about DoT support

Problem 2.2: if the request goes over UDP it might not always go to
the same server, so this solution implicitly requires clustered
servers to have very tightly matching configurations.

Question 2.2: does it look like a normal query and if so what is the
qname?


Solution 2.2.1: qname is a special-use name something.arpa

Problem 2.2.1.1: can't be authenticated so 1.1.2 and 1.1.4 apply


Solution 2.2.2: qname is the server name

can be authenticated

Problem 2.2.2.1: requires server to be authoritative for its name

Problem 2.2.2.2: leaks the zone name for in-bailiwick delegations


Solution 2.2.3: qname is the zone name

can be authenticated

Problem 2.2.3.1: not very private, is it?

Problem 2.2.3.2: awkward to put information about the server in every
zone it serves - co-ordination problem between server operators and
zone owners


Solution 2.?: any other in-protocol upgrades?


Solution 3.1: signalling in the delegation

can be authenticated

Problem 3.1.1: EPP

Problem 3.1.2: instead of being O(servers) the provisioning problem is
at least O(zones) and maybe O(zones*servers)

Problem 3.1.3: operator vs registrant vs registrar communications


Solution 3.2: signalling at the server name (or TLSA-style prefixed
server name)

can be authenticated

Problem 3.2.1: leaks the zone name for in-bailiwick delegations


Solution 3.3: signalling at the server IP address reverse DNS (or
TLSA-style prefixed reverse DNS)

can be authenticated

Problem 3.3.1: might have awkward dependency loops between forward and
reverse DNS

Note 3.3.2: need to explain why this is OK for DoT when we thought it was
not for ACME


Solution 3.4: DoT lookaside zones (think DLV)

Problem 3.4.1: relies on more third parties for authentication

Problem 3.4.2: where does the data come from and how do we know it is
correct?


Solution 3.5: signalling in the parent zone separate from the
delegation (like example._dot.com)

Problem 3.5.*: similar to 3.1.*


Solution 3.?: surely I have covered all the plausible options for
putting this in normal DNS data?!


Problem 4.1: difficult to do out-of-DNS signalling and avoid
centralization

Problem 4.2: these generally rely on a third party (outside the zone's
delegation path) for authentication

Problem 4.3: can these options scale big enough?

Problem 4.4: where does the data come from and how do we know it is
correct?

Solution 4.1: distribute a big public DoT server list (think public
suffix list)

Solution 4.2: rather than distributing a big list, use k-anonymity
like Troy Hunt's pwned passwords query API

Solution 4.3: parent zone has a pointer to a non-DNS DoT server list
and/or non-DNS query API server

Solution 4.?: any others?


Tony.
-- 
f.anthony.n.finchhttp://dotat.at/

Re: [dns-privacy] Possible use case: Opportunistic encryption for recursive to authoritative

[Tony Finch]

Paul Wouters  wrote:
>
> At the IETF, we have done a REALLY bad job at keeping secure DNS as an
> optional feature. The more we treat it that way, the more others will
> treat it that way. We should really do the opposite. DNS without DNSSEC
> is legacy. It's irresponsible. It's vulnerable. It's being actively
> abused. Upgrade your DNS.
>
> Then, you automatically get to AUTH servers having a DNSSEC based PKI.
> You can give them a public key record type like TLSA, and do encryption.
> You allow plaintext, and in 10-20 years we turn off plaintext.

+1

(and to the rest of the message too)

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
Isle of Man: North or northwest, veering northeast for a time, 3 or 4,
occasionally 5. Slight. Thundery showers, becoming mainly fair. Moderate or
good, occasionally poor.

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

Re: [dns-privacy] I-D Action: draft-ietf-dprive-xfr-over-tls-02.txt

[Tony Finch]

Sara Dickinson  wrote:
> > On 13 Jul 2020, at 23:35, Tony Finch  wrote:
> >
> > 7 authentication
>
> Belated responses on this topic!

And a few more thoughts from me, pruned for length ...

> Well the goal was to compare and contrast the set of existing control
> methods - they do all have different properties and we wanted to explain
> where TLS fits in with these and be clear it can’t directly replace
> them…
>
> Perhaps authentication is too broad a term for this whole set of
> mechanisms. Maybe the split here should be transport independent
> verification mechanisms vs TLS…?

What I would expect to get from reading this section is how TSIG and X.509
authentication interact (and maybe SIG(0) too), i.e. what the implications
are for configuring server ACLs and client credentials.

ZONEMD doesn't fit in that context, I think.

> We use a v. broad definition of ‘data auth’:  “Authentication that the
> DNS message data is signed by the party with whom credentials were
> shared”, but given your comment I believe better term would be something
> like ‘data origin auth’ or ’transfer entity auth'.

Right, that's the distinction I was making. But I think this draft only
needs to care about the peer authentication because data authentication is
unaffected by TLS. (And doesn't affect privacy.)

> TSIG gives entity authentication but not guaranteed confidentiality. The
> specific threat here is that in principle without authentication a MitM
> attack is possible on the TLS connection….. that attack can see not only
> the zone transfer requests but more importantly the responses, which is
> what we are trying to avoid.

Ah, I understand now, thanks. Given that I think you are right to leave
out unauthenticated-but-required TLS as an option since it doesn't make
much sense. I have not read RFC 8310 properly yet, but if it doesn't
discuss why this middle option doesn't provide much extra privacy, then
perhaps this draft should have a few words.

Otherwise, it all sounds good. Thanks for working on this draft!

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
South Utsire: Northwest 4 or 5, becoming variable 3, then southeast 5 or 6
later. Slight or moderate. Fair. Good.___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] Registry framework for draft-ietf-dprive-early-data

[Tony Finch]

Ilari Liusvaara  wrote:
>
> Then there is RRSIG, which seems bit alarming. While direct queries
> should not do anything special, I noticed two troublesome properties:
>
> 1) The answers can be pretty large (amplification hazard with UDP).
> 2) The queries can be really slow compared to other types.

Yes. From an implementation perspective, RRSIG queries work in a very
similar way to ANY queries. They have the advantage that no-one is likely
to think an RRSIG query is useful, so it's reasonable to NOTIMP them.
If QTYPE=ANY is forbidden for early data then QTYPE=RRSIG should be too.

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
Plymouth: Variable 4 or less, becoming east 3 to 5 for a time. Smooth or
slight becoming slight or moderate. Fair. Good.

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

Re: [dns-privacy] I-D Action: draft-ietf-dprive-xfr-over-tls-02.txt

[Tony Finch]

Sara Dickinson  wrote:
>
> Hi Tony,
>
> Many thanks for the detailed review!

You're welcome! Your changes sound good, so I'll just answer a few
quesions...

> > Is there a reason for allowing concurrent AXFRs of the same zone?
> > Actually, thinking about this more generally, I can't see a way in RFC
> > 5936 for the server to impose backpressure to limit the number of
> > concurrent AXFRs. And there isn't an extended error code for concurrency
> > control or backpressure. If the server had a suitable response, that would
> > allow it to control xfer resources in general, as well as to choose
> > whether or not it wants to allow multiple AXFRs for the same zone at the
> > same time.
>
> I don’t believe RFC5936 says anything expliclty about concurrent
> transfer behaviour, and while there may not be a use case for it do you
> think we should actually prohibit it?
>
> Of course a server can error any AXFR if it chooses [RFC5936]:
>
> "To indicate an error in an AXFR response, the AXFR server sends a
>single DNS message when the error condition is detected, with the
>response code set to the appropriate value for the condition
>encountered.  Such a message terminates the AXFR session;…”
>
> so it _could_ already answer SERVFAIL if it didn’t have the resources?,
> or REFUSED if a transfer is already underway and it doesn’t want to do
> another one? I’m not actually sure what existing implementations do in
> this case? (will double check)
>
> I suppose the advantage of adding an extended error code would be so
> that well behaved clients didn’t continue to request transfers that were
> going to be refused.

BIND at least has had quotas for controlling zone transfer concurrency for
aaages, so the answer to this question is out there. I was thinking out
loud a bit when I wrote that paragraph, mainly because I was surprised the
specs did not AFAICT describe a fairly well-known xfer feature.

> > Re pipelining, I can't see in RFC 5936 whether concurrent AXFRs are just
> > concurrent outstanding queries, with all the response messages for one
> > zone sent back-to-back, or whether response messages for different
> > concurrent AXFRs can be interleaved.
>
> No, you are right - that behaviour isn’t explicitly specified there but
> the discussion around using message IDs to match responses at the end of
> section 4.1.1. suggests/implies intermingling should work. Our draft
> doesn’t update RFC5936 at all (at the moment)… I hadn’t thought it
> necessary but perhaps we should actually make the normative statements
> around the updates to RFC1995 apply to RFC5936 as well for consistency?

I thought when reading the draft that it might be a bit clearer if there
were sections on stuff applying to xfers in general (connection
management, concurrency, etc.) and particular details for axfr and for
ixfr.

This spec probably does need to update RFC 5936 because 5936 doesn't say
anything about IXFR even though there are important details in how IXFR
and AXFR interact.

> Are you thinking of some text clarifying that servers can send AXoT
> responses for different zones intermingled with each other and with IXoT
> responses and clients have to handle them? I guess I thought that was
> implicit in the RFC7766 model but we could add some clarifying text.
> Again though, that would (I think) apply equally for AXFR and IXFR
> sharing a connection so perhaps it needs to appear earlier when they are
> discussed…. Do you have any error/problem cases in mind, or just
> clarifying what needs to be supported?

Yes, I was just unsure what degree of intermingling is supposed to be
allowed; I don't know enough about this part of the innards of existing
implementations to say what the right clarification is, though :-)

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
disperse power, foster diversity, and nurture creativity___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] I-D Action: draft-ietf-dprive-xfr-over-tls-02.txt

[Tony Finch]

I've had a read through and here are a few, er, I mean several things that
caught my eye:

In the intro, I think it's too strong to say that RFC 5155 was "to
prevent" zone enumeration - its abstract says it "provides measures
against" which is a more accurate guide to NSEC3's effectiveness. Also the
same paragraph could probably be more clear that NSEC5 is not a practical
thing (yet? or likely ever?). I.e., neither of them are really useful
privacy mechanisms.

4.2 IXFR - RFC 1995 doesn't use RFC 1123-style requirements keywords (and
obviously it predates RFC 2119) so I don't think you can say the
lower-case "should" is non-normative. Spelling "forth" -> "fourth" :-)

The last paragraph in this section should have a cross-reference to the
section that describes the new IXFR requirements in detail. If these
requirements are supposed to apply to pure TCP as well as IXoT then it's
probably worth promoting them to a top-level section to make it more
obvious that they exist, independent of TLS. Apart from this paragraph,
section 4 looks more like a non-normative summary of existing
specifications, which is useful background information, but I think it's
helpful to clearly separate normative and informative sections.

4.3 Is it worth discussing information leakage about which zones are
present on a secondary? i.e. is that part of the threat model?

5.3 I'm not sure I understand what this section is getting at. Is it
saying that a client can have either an XoTCP or an XoTLS connection, but
not both? Because it should try to limit itself to one connection of any
kind for zone transfers?

5.4 What is the base DNS RCODE for non-XoT traffic on an XoT connection?
(extended errors do not have a fixed association with RCODEs)
What about non-EDNS queries?

5.6.2 AXoT

In the keepalive discussion, is the intention that a server can use a
timeout of 0 to abort a connection in the middle of a transfer, or is it
supposed to indicate that there can be no more transfers on the
connection, but existing transfers in progress are allowed to finish?

Is there a reason for allowing concurrent AXFRs of the same zone?
Actually, thinking about this more generally, I can't see a way in RFC
5936 for the server to impose backpressure to limit the number of
concurrent AXFRs. And there isn't an extended error code for concurrency
control or backpressure. If the server had a suitable response, that would
allow it to control xfer resources in general, as well as to choose
whether or not it wants to allow multiple AXFRs for the same zone at the
same time.

Still 5.6.2

The connection re-use requirements seem to be restating 5.3 in more
detail. Would it be more clear to put these related requierments in the
same section?

Re pipelining, I can't see in RFC 5936 whether concurrent AXFRs are just
concurrent outstanding queries, with all the response messages for one
zone sent back-to-back, or whether response messages for different
concurrent AXFRs can be interleaved.

5.6.3 padding

Why would empty response messages be needed? Isn't it enough to pad the
regular response messages that contain RRs? (Or maybe reduce the number of
RRs per message and increase the padding if more obfuscation is needed?)
Servers need to keep track of zone sizes in order to mitigate
CVE-2016-6170 (DoS attack by sending an excessively huge AXFR response) so
I would expect servers to be able to use that accounting to decide how to
spread padding between AXFR response messages, without the need for extra
padding-only messages.

5.7 IXoT

Looking back and comparing with section 4.2, it looks like the concurrency
requirements in section 5.7 only apply to TLS. Are they supposed to apply
to TCP as well?

I think it would help to have some more explicit discussion of how IXoT
and AXoT share a connection, wrt concurrency, interleaving of response
messages (or not), and so forth. Perhaps as a subsection beween 5.5 and
5.6? Or maybe as an expanded 5.3? Also covering other things that are
common to IXot and AXoT like keepalive timeouts, concurrency backpressure,
presence or absence of EDNS, padding, and anything else I've missed.

7 authentication

It seems weird to mix up channel auth and data auth, since they are quite
different things. As I understand it, ZONEMD isn't really authentication,
it's just an integrity check (unless it is used in a signed zone). And if
you are talking about data authentication it seems odd to leave out
RRSIGs.

TSIG doesn't provide data authentication. It provides mutual
authentication of the endpoints, and data integrity, but the server can
lie to the client about the zone contents. (The server is not necessarily
the ultimate authority for the zone.)

It would be useful to have terminology to distinguish between TLS where
the client software tries on its own initiative, with fallback to TCP
(which is what I think of when I read "opportunistic"); as opposed to TLS
configured by the admin without fallback to TCP and without any client or
server 

Re: [dns-privacy] [Fwd: New Version Notification for draft-vandijk-dprive-ds-dot-signal-and-pin-00.txt]

[Tony Finch]

Peter van Dijk  wrote:
> On Thu, 2020-05-28 at 00:43 +0100, Tony Finch wrote:
> >
> > This made me wonder if this pseudorecord should be a KEY instead, and then
> > I wondered how hard it would be to persuade existing code to generate a DS
> > from a KEY.
>
> That could make semantic sense, but would muddle the connection to
> 'DNSKEY in EPP' and 'CDNSKEY sync from child to parent'; I think it
> would add more confusion than the semantic correctness is worth.

Right, good point. EPP and CDNSKEY are crucial.

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
Fisher: Variable becoming northeast, 2 to 4. Smooth or slight. Mainly fair.
Moderate or good, occasionally poor.

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

Re: [dns-privacy] [Fwd: New Version Notification for draft-vandijk-dprive-ds-dot-signal-and-pin-00.txt]

[Tony Finch]

Peter van Dijk  wrote:
> On Tue, 2020-05-26 at 09:10 +0200, Ondřej Surý wrote:
> >
> > 1. Bit 7 of the Flags fields needs to be 0.
>
> Definitely [...] I noted earlier that whatever flags we might need, it's
> definitely *not* ZONE and SEP.
>
> > 2. This needs a new Protocol number
>
> I understand why you would say that, but I'd love to avoid doing that.
> I wonder how much 'IETF' pain specifying another protocol number would
> be, but what worries me more, ironically, is how it changes the format
> away from normal DNSSEC. The draft was written such that a lot of
> existing software needs no changes at all - I don't know if changing
> the protocol number is compatible with that goal.

This made me wonder if this pseudorecord should be a KEY instead, and then
I wondered how hard it would be to persuade existing code to generate a DS
from a KEY.

But anyway, this signalling and verification scheme sounds clever and neat.

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
Southeast Iceland: Southwesterly 5 to 7 at first in north, otherwise southerly
3 to 5. Moderate or rough, becoming moderate later. Drizzle and fog patches
later. Moderate or good, occasionally very poor later.___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] Datatracker State Update Notice:

[Tony Finch]

Jim Reid  wrote:

> Could the people on this thread *please* trim their postings?

Yes, more RFC 1855, please!

Tony.
-- 
   .-_|\f.anthony.n.finch
  / \  
McQuary ->*.--._/http://dotat.at/
   v

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

Re: [dns-privacy] Fwd: New Version Notification for draft-huitema-dprive-dnsoquic-00.txt

[Tony Finch]

Christian Huitema  wrote:

> We just resubmitted the DNS over QUIC draft to DPRIVE. Thanks in advance
> for the feedback!

Looks promising! I have a few comments:

Is the ALPN "dq" or "doq"? 4.1 and 4.1.1 appear to disagree. 8.1 seems to
disagree with itself.

Section 4.3 (idle timeouts): it's clearly better to use QUIC's facilities
for this, but there could potentially be a conflict with DNS stateful
timeouts (RFC48490) so maybe there needs to be a bit more discussion about
how to resolve disagreements between two protocol layers.

Section 5.4 (response size): there was a HUGE discussion about this in the
context of DoH and the consensus was to retain the 65535 byte message
size limit. DoQ should do the same.

https://mailarchive.ietf.org/arch/msg/doh/fpJSGWI1YtHeTFvmrS7pvB7ZnDA/

The EDNS payload size limit only applies to Do53 UDP and should be ignored
in other transports.

Sections 5.7 and 4.3 seem to be restating the same things in different
ways. They should probably be merged into one.

Section 5.7.1 (connection reuse): possibly also worth stating that servers
should not send responses in order. Maybe refer to RFC7766 which has
similar requirements for TCP.

An editorial suggestion: when referring to RFCs, can you please make it
clear what the reference is about (e.g. the subject of the RFC or name of
protocol) in the paragraph containing the reference, so that readers
can understand the paragraph without having to bounce back and forth to
the references section.

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
Dover, Wight: Northwest backing west 3 to 5. Slight or moderate. Showers at
first. Good.

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

Re: [dns-privacy] [Ext] Threat Model

[Tony Finch]

John Levine  wrote:
> In article  you write:
> >> That's per-zone, though, whereas DoT support is per-server.
> >
> >Maybe that's ideal, but one would expect that a zone only rolls this
> >out once all their nameservers support it.
>
> Most of my zones have a secondary run by somebody else, whose software
> is never in sync with mine.

Yes, also it's operationally much less stressful if you can use a canary
deployment to verify a partial roll-out before full deployment.

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
Southeast Iceland: Cyclonic 4 to 6, increasing 7 in far northwest. Moderate or
rough. Wintry showers. Good, occasionally poor.

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

Re: [dns-privacy] [Ext] Threat Model

[Tony Finch]

Paul Wouters  wrote:
>
> The right way to do this is a DNSKEY flag, which is protected by the
> signed DS at the parent. Similar to draft-powerbind for the
> delegation-only domain.

That's per-zone, though, whereas DoT support is per-server.

DS records that somehow encode NS target names in their rdata might
work...

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
partnership and community in all areas of life

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

Re: [dns-privacy] ADoT requirements for authentication?

[Tony Finch]

Some miscellaneous thoughts vaguely related to the discussion ...

## nameserver hostnames in certificates

It's not uncommon for zones to use in-bailiwick aliases for their
nameservers, which avoids transitive configuration dependencies and speeds
up resolution because the resolver gets glue with the referral rather than
having to chase down server addresses.

(see discussion of gluelessness on https://cr.yp.to/djbdns/notes.html)

This is obviously problematic for using hostname authentication. I suppose
a server could provide its IP address(es) and official hostnames in its
cert to allow either for authentication...

## third-party secondary servers

If the ADoT status is in the delegation (special DS records, special NS
records) then that implies a nasty co-ordination cost to any changes.

## glueful bootstrapping

If we rely on TLSA records at the nameserver's hostname then there's a fun
bootstrapping problem for in-bailiwick delegations. If a resolver queries
for the TLSA records in the clear then they'll leak the zone name; if it
speculatively tries TLS then it might be really slow waiting for timeouts.

## reverse dns bootstrapping

If the resolver looks for TLSA records in the reverse DNS there's a fun
case where it has a referral for (say) example.com with glue for
ns1.example.com in 192.0.2.1, but then it finds that ns1.example.com is
also a server for 2.0.192.in-addr.arpa. The resolver needs to be able to
re-use the forward DNS glue to get to the reverse DNS zone.

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
Great Orme Head to the Mull of Galloway: East or southeast 4 to 6. Smooth or
slight, occasionally moderate in west. Fair. Good.

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

Re: [dns-privacy] New Version Notification for draft-zatda-dprive-xfr-using-dso-00.txt

[Tony Finch]

Tom Pusateri  wrote:
>
> In 7.1.1.1, there is mention of efficiently packing stream data into
> TCP segments. This is also in the PUSH draft but I think it should be
> removed from there and from here as well because once the data is
> encoded in a TLS session, it’s much more difficult for the sender to
> have control over the size of TCP segments sent.

I think the right abstraction here is operating system write() or send()
calls, since you can't normally control segmentation in detail except that
short writes usually lead to short packets. e.g. (covering both TCP and
TLS):

   Since SUBSCRIBE-XFR requests are sent
   over TCP, multiple SUBSCRIBE-XFR DSO request messages can be
   concatenated in a single write call to make efficient use of
   the underlying transport.

... but of course this applies to any DNS messages over TCP or TLS ...

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
Shannon: Southwest, veering west or northwest, 4 or 5, occasionally 6 at
first. Moderate, occasionally slight at first in southeast. Occasional rain,
fog patches. Moderate or good, occasionally very poor.___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] Some additional signalling ideas

[Tony Finch]

Ilari Liusvaara  wrote:
>
> Adding another RRtype with needed magic properties would take Standards
> Action (as expert review requires RRtype not to be magic) and then
> updating parent nameservers to be able to deal with the RRtype (since
> it can not be generically handled).

Don't forget the implications for EPP and the zoo of registrar UIs
and APIs.

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
Malin: Southwest veering west, then becoming cyclonic later, 5 to 7. Moderate
or rough, becoming rough or very rough, occasionally high later. Rain then
wintry showers. Good, occasionally poor.

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

Re: [dns-privacy] New Version Notification for draft-bretelle-dprive-dot-for-insecure-delegations-01.txt

[Tony Finch]

> >> This proposal actually reminds me a lot of idea I had that actually
> >> used DS records instead of new record type.
> >>
> >> AFAIK:
> >> - DNSsec ignores any such record (unknown algorithm)
> >>   -> No interference with DNSsec.
> >> - CDS does not ignore such records.
> >>   -> Automated synchnonization.
> >> - Lives on parent side of delegation.
> >>   -> No post-hoc authentication.

There's a problem with CDS and unknown algorithms.

RFC 7344 section 4.1 third bullet requires the parent to verify that the
delegation will not be broken by new DS RRset. This means the parent needs
to check that it is able to validate every algorithm, otherwise it could
open up a downgrade attack. Note that this validation is not just checking
that the DS records have matching DNSKEY records; the parent must also
validate that at least one matching key has signed the DNSKEY RRset
(because that's what normal validators will need to be able to do).

So unknown algorithm hacks will not work with CDS as things currently are.

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
Great Orme Head to the Mull of Galloway: Variable 3 or 4, becoming southwest 4
or 5. Smooth or slight. Fair. Good.

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

Re: [dns-privacy] Fwd: New Version Notification for draft-hzpa-dprive-xfr-over-tls-01.txt

[Tony Finch]

Sara Dickinson  wrote:
>
> A new draft has been submitted outlining using DNS-over-TLS for zone 
> transfers.

I've had a brief skim.

It's entirely driven by zone confidentiality, which is a fine thing, but
from my point of view the interesting possibility is to get transport
integrity (like TSIG) but with much simpler key management.

Single-ended public key authentication of the primary with IP-based
access control for secondaries should be an easy upgrade that do not
currently use TSIG, and really nice for stealth secondaries.

Double-ended public key auth will help reduce the need to break out gpg
for key exchange with oldskool third-party secondarying arrangements.

So I think this is interesting from the dnsop perspective as well as
dprive.

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
an equitable and peaceful international order

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

Re: [dns-privacy] Alternative signalling propsals

[Tony Finch]

Wes Hardaker  wrote:
>
> My list for putting a TLSA or similar record at the reverse zone
> include:
>
> pros:
> - the authoritative server more likely in control of its reverse zone than all
>   the forward zones its serving

Reverse zones plural (v4 + v6) :-)

> - the number of reverse zone records to update on a key change is 1 per ip
>   address.  The number of name server NS records to update per key
>   change is 1 per zone supported, which is very very large for some
>   servers.

For forward DNS it is 1 per name server name (i.e. per alias), which might
be 1 per zone for places that provision zones with in in-bailiwick name
server names, or might be 1 per server if they prefer to provision zones
with canonical name server names.

> - it feels cleaner

> cons:
> - not everyone controls their reverse zone easily, especially for those
>   that don't hold at least a /24 allocation. Ironically, I fall into
>   this camp but still think this is a better solution than a name-based one.
> - requires more lookups
> - requires the reverse tree for that address be fully signed

The "more lookups" thing is interesting.

If the TLSA-like record is in the forward DNS, then you get into a
bootstrapping problem. Assuming we can't add these new records as glue,
a resolver ends up having to:

* query a parent server for delegation; receive NS records and glue
* query a child server publicly for TLSA-like record(s)
* query child server privately for actual question

i.e. in the DNS case we lose the opportunity for concurrent address + TLSA
queries that DANE normally offers.

If the TLSA-like record is in the reverse DNS, and the reverse DNS
nameservers are cached, then the sequence of lookups is the same. The
"more lookups" case happens when there's a cold reverse DNS cache as well
as a cold forward cache.

Putting TLSA-like records in the reverse DNS doesn't solve the bootstrap
problem, in cases where the server you want the TLSA-like record for is
authoritative for its own reverse zones.

I started a thread discussing related things back in September...

https://www.ietf.org/mail-archive/web/dns-privacy/current/msg02124.html

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
public services available on equal terms to all

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

Re: [dns-privacy] Issues with encoding keys in nameserver DNS names

[Tony Finch]

Daniel Kahn Gillmor  wrote:
> On Fri 2018-12-14 19:12:41 +0100, A. Schulze wrote:
> >
> > 5. Encoding a key as DNS name of a nameserver makes key rotation harder.
> >Not impossible, but really much harder.
>
> i agree that it makes it harder, but i'm not convinced that it is *much*
> harder.

In my setup, if server keys are in the server name then rotating them
requires liaison work over email to humans at 8 other organizations.
(And my setup is not big.)

If server keys are alongside then it's easy.

> But maybe it's worth reviewing what we're hoping to gain from the
> keys-in-names approach too:
>
>  a) indication that private queries are expected to work to this
> particular resolver
>
>  b) cryptographic identity material
>
> But what if we cared only about (a) ?  could we signal with a
> special/magic terminal label just that private queries are expected to
> work, without embedding a key there?

That could be a useful approach.

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
Lundy, Fastnet, Irish Sea: South 6 to gale 8, increasing severe gale 9 at
times, perhaps storm 10 later. Moderate at first in Irish Sea, otherwise rough
or very rough, occasionally high except in Irish Sea. Occasional rain. Good,
occasionally poor.

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

Re: [dns-privacy] Implementer Perspective

[Tony Finch]

Brian Haberman  wrote:

>  This week (10/15 - 10/21) let's focus on the implementer's
> perspective on DNS privacy between recursive resolvers and authoritative
> servers.

Olafur's RIPE talk discusses this to some degree, advocating the
advantages of better transport protocol engineering ...
https://ripe77.ripe.net/programme/meeting-plan/bcop-tf/

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
Thames: Variable 3 or 4, becoming southwest 4 or 5 later. Slight. Mainly fair.
Good, occasionally poor.

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

Re: [dns-privacy] Authoritative Server Operator Perspective

[Tony Finch]

Apart from the basic mechanics that we have already mentioned, I think the 
interesting question here is how to manage scalability to lots of zones: if we 
publish encryption/authentication information about nameservers in the DNS:

* is it published per server, associated with the server’s canonical name?

* what about in-bailiwick aliases?

* how important is it to avoid replicating this information in every zone 
hosted on the server?

* does it help to use the reverse DNS instead?

Tony.
-- 
f.anthony.n.finchhttp://dotat.at


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

Re: [dns-privacy] [Ext] Authoritative Server Operator Perspective

[Tony Finch]

Paul Hoffman  wrote:
>
> 1) An interoperable specification for how to encrypt messages
> 1a) If it is layer 4, it is likely to be TLS
> 1b) If it is layer 7, it is likely to be CMS
>
> 2) An interoperable method to tell resolvers who might want encrypted
> responses how to send them.

3) An interoperable method to tell resolvers how to authenticate an
authoritaive server.

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
reject all prejudice and discrimination based upon race, colour,
religion, age, disability, gender, or sexual orientation

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

Re: [dns-privacy] [Ext] Recursive Resolver Operator Perspective

[Tony Finch]

Paul Hoffman  wrote:
>
> If I have a path with authentication and a path without, and I prefer
> (not demand) the path with authentication, I am taking advantage of it.

Right, but is the authenticated path securely authenticated? i.e. can
the client tell that an attacker is monkeying around with the
authenticated path?

This is important because it allows clients to make a meaningful choice
between security and availabilty, while still being opportunistic (i.e.
zero per-server config on the client). If the client can't tell the
difference between no authenticated channel and an attacked authenticated
channel, it has no meaningful choice other than to fall back to
unauthenticated encryption, and the upshot is that the authenticated
channel doesn't actually provide any security improvement, and the only
option clients have is unauthenticated encryption.

> > For protocols like SMTP or DNS there isn't an easy identifier that can
> > be reliably authenticated,
>
> Why not? IP addresses work just fine in both of those cases.

No, for SMTP the relevant identifier is the domain in the recipient email
address. When we started working on DANE the problems were that

(1) the MX target name often doesn't match the server's idea of its
own name

(2) the server's certificate often doesn't match either name

Auth DNS has problem (1) (but not 2 because there's no encryption yet),
and also has the problem that it's more latency sensitive and doesn't have
a fast way to signal that encryption is available.

For authentication to actually be secure, there has to be a signal (e.g.
DANE) that this server has been configured without name mismatches, so the
client can properly authenticate it.

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
Sole, Lundy, Fastnet, Irish Sea: Variable 4, becoming south or southwest 4 or
5, occasionally 6 in Irish Sea. Slight or moderate. Occasional drizzle, fog
patches at first. Moderate or good, occasionally very poor at first.

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

Re: [dns-privacy] [Ext] Recursive Resolver Operator Perspective

[Tony Finch]

Paul Hoffman  wrote:
> On Oct 2, 2018, at 3:12 AM, Tony Finch  wrote:
> > Paul Hoffman  wrote:
> >>
> >> I do not have a scenario where the client (the resolver in this case)
> >> needs downgrade protection for privacy.
> >
> > In that case there's no need to worry about authentication at all.
> > (But I disagree.)
>
> And I disagree that there is "no need to worry". As I said in my initial
> message, a resolver operator might want to take advantage of it if it is
> available.

I don't understand: first you say you don't need downgrade protection,
then you say you want authentication. This isn't consistent. You aren't
taking advantage of authentication if you are vulnerable to a downgrade
attack. In that case the authentication is worthless.

> > More generally, I don't think the term "opportunistic" is very helpful,
>
> but it is the hard-fought agreement of the IETF. See RFC 7435.

Yeah, and the point I am making is that it is important to pick apart the
teo options described in RFC 7435's abstract. They have very different
deployment characteristics and security guarantees. For protocols like
SMTP or DNS there isn't an easy identifier that can be reliably
authenticated, so authenticated encryption needs extra deployment work
(e.g. DANE) to be reliable, and if you do that work you get downgrade
protection as a bonus. If you don't do the extra work you can do
unauthenticated encryption, but you remain vulnerable to active attacks.
If you do the extra work without including downgrade protection then you
might as well not have bothered.

Perhaps I should say that this strict security can only apply if both the
server advertises it and the client looks for it; if either of those don't
apply then you get unauthenticated opportunistic encryption, which is OK,
but we can do better when both ends want to be secure.

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
Biscay: Easterly 5 or 6 in far southwest, otherwise variable 3 or 4. Slight or
moderate. Fair. Good.

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

Re: [dns-privacy] [Ext] Recursive Resolver Operator Perspective

[Tony Finch]

Paul Hoffman  wrote:
>
> I do not have a scenario where the client (the resolver in this case)
> needs downgrade protection for privacy.

In that case there's no need to worry about authentication at all.
(But I disagree.)

More generally, I don't think the term "opportunistic" is very helpful,
because there are several useful levels:

* cleartext

* unauthenticated - the client auto-discovers encryption is available, but
doesn't have any way to reliably authenticate the server; an attacker can
force the client to downgrade to cleartext.

* authenticated - there is an explicit signal (e.g. DANE, STS) that the
server supports properly authenticated encryption; an attacker can deny
service but not force a downgrade to cleartext.

* pre-configured

The end goal we should be aiming for is as much authenticated encryption
as possible, but it's reasonable to allow unuathenticated encryption as an
intermediate step.

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
safeguard the balance of nature and the environment

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

Re: [dns-privacy] [Ext] Recursive Resolver Operator Perspective

[Tony Finch]

Paul Hoffman  wrote:
> On Oct 1, 2018, at 8:50 AM, Tony Finch  wrote:
> >
> > Paul Hoffman  wrote:
> >>
> >> During earlier discussions of opportunistic encryption in the IETF,
> >> attempted-but-not-required authentication was strongly preferred over
> >> "don't even attempt to authenticate".
> >
> > This is only worthwhile if there is downgrade protection, i.e. the client
> > needs to be able to tell if it is supposed to be able to rely on an
> > authentication mechanism (e.g. using DANE). Without downgrade protection
> > it's equivalent to encryption without authentication.
>
> We have to be careful when we are talking about recursive resolvers. By
> "client" above, I think you mean "customer of the recursive resolver"
> and not "the side of the recursive resolver talking to authoritative
> servers".

No, I'm thinking in terms of client = recursive, server = authoritative,
which are the ends of the connection that we want to improve.

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
Hebrides, Bailey, Fair Isle, Faeroes, Southeast Iceland: Variable 3 or 4 at
first in east Fair Isle, otherwise cyclonic or westerly 6 to gale 8,
increasing severe gale 9 for a time, then decreasing 4 at times later.
Moderate or rough, becoming very rough or high for a time. Rain or squally
showers. Good, occasionally poor.

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

Re: [dns-privacy] [Ext] Recursive Resolver Operator Perspective

[Tony Finch]

Paul Hoffman  wrote:
>
> During earlier discussions of opportunistic encryption in the IETF,
> attempted-but-not-required authentication was strongly preferred over
> "don't even attempt to authenticate".

This is only worthwhile if there is downgrade protection, i.e. the client
needs to be able to tell if it is supposed to be able to rely on an
authentication mechanism (e.g. using DANE). Without downgrade protection
it's equivalent to encryption without authentication.

We discussed this a few weeks ago, thread starting at
https://www.ietf.org/mail-archive/web/dns-privacy/current/msg02124.html

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
North Fitzroy, Sole: Variable 4, becoming easterly 4 or 5 in east Sole.
Moderate, occasionally rough at first. Fair. Good.

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

Re: [dns-privacy] User Perspective

[Tony Finch]

Christian Huitema  wrote:
>
> An attacker could replay the 0-RTT packet, and observe whether it
> creates a particular side effect at the server end. For example, replay
> the traffic from client to recursive, and observe whether the resolver
> issues a query to particular DNS server.

Ah, yes, if you can see the upstream queries, even when encrypted they are
quite a lot more leaky than the cache side channel.

I'm now imagining a resolver that sends steganographic chaff queries when
there's a cache miss :-)

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
people involved in running their communities

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

Re: [dns-privacy] User Perspective

[Tony Finch]

Christian Huitema  wrote:
>
> The basic QUIC handshake will be 1-RTT before sending the first query,
> with two exceptions:

Thanks for those details!

> Using 0-RTT is a trade-off between security and performance, because
> 0-RTT packets can be subject to replay attacks. That's true for 0-RTT in
> QUIC and also 0-RTT in TLS. If you are really concerned about privacy,
> the prudent decision is to not use 0-RTT.

Correct me if I'm wrong, but my understanding is that the 0RTT replay
attack is not a privacy problem, but is a problem if the payload has
undesirable side-effects. The 0RTT privacy problem is the same as for TLS
session resumption: the session details can be used to track clients.

For privacy-conscious clients, I think it makes sense to use session
resumption for the lifetime of a particular layer 2/3 network connection,
and drop session tokens when roaming to a different connection. So you
benefit from the improved performance while the server has other ways to
track you, but it's harder for the server to track clients from place to
place.

(this is more of a stub -> recursive concern rather than recursive ->
authoritative)

> If 0-RTT is enabled, QUIC performs better than either UDP or TCP in all
> scenarios; if it is not, QUIC still performs slightly better than TCP or
> TLS, because it does not suffer from head of line blocking.

QUIC is something nice to look forward to :-)

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
Bailey: West 5 to 7, decreasing 4 for a time. Very rough, becoming rough. Rain
then showers. Good occasionally poor.

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

Re: [dns-privacy] User Perspective

[Tony Finch]

Mukund Sivaraman  wrote:
>
> During the "how-to-achieve-it" phase, attention should be given to not
> adding extra roundtrips (to keep it as close as possible to the RFC 1035
> UDP scenario). Various new facilities such as TCP's fast open, TLS false
> start, etc. should not be taken for granted - considerion should be
> given to the average and worst case scenarios, esp. queries in unseen
> zones to non-anycast-"cloud" nameservers that aren't "known".

Yes, I very much agree.

As I understand it, TLS false start is able to reduce the 2RTT TLS/1.2
handshake to 1.5RTT (same as a session resume). For TLS/1.3 cold starts
and session resume are the same 1.5RTT, and sessions can also be resumed
with 0RTT which is very yummy for the DNS. So if I'm allowed to assume
TLS/1.3 then false start doesn't buy us anything.

The cold start time for DoT is 3RTT.

For DNS-over-QUIC I think that could drop to 2RTT, or maybe 1RTT? I don't
know QUIC's handshake.

The warm start time should soon be 0RTT.

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
champion the freedom, dignity, and well-being of individuals

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

Re: [dns-privacy] User Perspective

[Tony Finch]

Amelia Andersdotter  wrote:
>
> I have difficulties seeing how a user (within the meaning of individual
> internet consumer) has any practical choice to other than to share PII
> with a DNS provider?

Yes, me too.

Since the overall topic is recursive -> authoritative, the questions imply
some mechanism for the user to communicate their privacy policy to the
recursive server, or perhaps it would be more useful for clients to ask
the recursive server what its policies or capabilities are. But what
happens when there is a mismatch?

Specific information leaks that we might care about:

* QNAME minimization or not?

* EDNS client subnet or not?

* Upstream encryption available or not? (asking for it to be required is a
  "break the Internet" switch so it doesn't make sense)

And the points Amelia made about data management which I might recast more
mechanically as:

* Passive DNS logging on the upstream side?

* Query logging on the client side?

Some of this is stuff that a recursive server knows about itself, and
could (reasonably easily) communicate to a client; some of it is about the
deployment and setup around the server which it doesn't necessarily know
(and I don't think it would be realistic to expect operators to configure
their servers to say they are running packet captures on DNS traffic...)

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
Dogger, Fisher, German Bight, Humber: West or northwest 4 backing southwest 5
to 7, occasionally gale 8 later except in Humber. Slight or moderate becoming
moderate or rough, then very rough later in Fisher. Showers. Good.

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

Re: [dns-privacy] Sketchy notes on DNS-over-TLS to authoritative servers

[Tony Finch]

Martin Hoffmann  wrote:
>
> Downgrade seems to be an issue with all proposals.

The tradeoffs seem to revolve around how much you leak before you work out
whether you can use strict DoT, and how much added latency that costs.

If you are talking to a nameserver via its canonical name, then asking for
its TLSA record in the clear is not really leaking anything that isn't
leaked by observing IP addresses and port numbers. And signed TLSA records
prevent downgrade attacks.

The other side of this tradeoff is the whole argument around gluelessness
vs. in-bailiwick namesserver names. If you give your servers non-canonical
in-bailiwick names then cleartext TLSA queries will leak the zone name,
which is not so great. TA hints in the nameserver name can reduce the
leakage to passive surveillance but not downgrade attacks.

> One option is to create a hash over the NS record set and place it in the
> parent zone in the same way as the DS record. This could either be a new
> record type or, devious but possibly deployable right now, (ab)use the DS
> record for the purpose with a new algorithm type.

That's a neat hack and also quite disgusting :-)

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
Fisher, German Bight: South 5 or 6, occasionally 7 later. Slight or moderate.
Showers. Good.

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

Re: [dns-privacy] Sketchy notes on DNS-over-TLS to authoritative servers

[Tony Finch]

Warren Kumari  wrote:
>
> If the NS records / labels were _ta.a.iana-servers.net and _
> ta.b.iana-servers.net, that could be used as a positive signal that the
> resolver (or if the underscore freaks people out,
> dns-o-tls.a.iana-servers.net) is listening on 853 and that an inability
> to connect is a security issue.

Several people seem to quite like this kind of idea, and I think it's a
good way to reduce latency (since we have to assume that better glue
isn't an option). e.g. Willem and Andreas in
https://www.ietf.org/mail-archive/web/dns-privacy/current/msg02137.html

Regarding the specifics, NS targets are hostnames so they have to conform
to RFC 952 syntax (no underscores).

I think signalling in the hostname has to be a hint rather than an
assertion, since it's vulnerable to a downgrade attack because delegation
NS records are unsigned (as Robert pointed out).

Putting the hint in the NS name I think makes the TA bit redundant - it's
really too late to be helpful.

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
Southeast Fitzroy: Southwesterly 5 to 7. Slight or moderate becoming rough or
very rough. Mainly fair. Good, occasionally poor.

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

Re: [dns-privacy] Sketchy notes on DNS-over-TLS to authoritative servers

[Tony Finch]

Paul Wouters  wrote:
> On Wed, 12 Sep 2018, Tony Finch wrote:
> >
> > RFC 7901 doesn't work when asking authoritative servers because they
> > don't have a copy of the chain.
>
> You can set the start of the chain to the zone, so as long as any
> chaining would remain within the zone or delegations on the same
> server it could work. But perhaps that's stretching things too far.

The scenario is that we are querying a parent zone's server, and we want
to get the authenticated TLSA records for the target servers in the
delegation NS records, so we can immediately talk securely to the child
zone's servers.

For chain queries to help, the parent zone auth servers would have to be
willing to serve DNSKEY and TLSA records for all their child zones.

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
sovereignty rests with the people and authority
in a democracy derives from the people

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

Re: [dns-privacy] Sketchy notes on DNS-over-TLS to authoritative servers

[Tony Finch]

Paul Wouters  wrote:
>
> Then use RFC 7901 DNS chain queries (or the hopefully soon
> tls-dnssec-chain TLS extension)

RFC 7901 doesn't work when asking authoritative servers because they
don't have a copy of the chain.

tls-dnssec-chain will not help iterative resolvers because they will
already have obtained the chain in the process of locating the server
they want to authenticate.

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
Rockall, Malin, Hebrides, Bailey, Fair Isle: West or southwest, becoming
cyclonic in Bailey, 5 to 7, increasing gale 8 at times. Rough or very rough,
occasionally moderate. Squally showers, thundery at times except in Rockall
and Malin. Good, occasionally poor except in Rockall and Malin.

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

Re: [dns-privacy] Sketchy notes on DNS-over-TLS to authoritative servers

[Tony Finch]

Erik Kline  wrote:
> On Wed, 12 Sep 2018 at 15:38, Shane Kerr  wrote:
> >
> > Note that we can also use the RTT of this query to set a reasonable
> > timeout for our port 853 traffic. A DNS server administrator may have
> > configured port 853 support, but the network administrator may block
> > this port for portions of the network or may later block this port. So
> > we still need probing and a timeout - but it can be quite low in most cases.

Right, there will need to be some careful client-side engineering.

> One thing a client might do with a positive TA bit and failed
> connections to 853 is present that information to the user and ask for
> confirmation they'd still like to use the network.  That might be
> useful, or might lead to confusion, idk.  Seems worth trying, though.

Yes, the TA bit will (inevitably) sometimes be wrong. My idea is that
during the rollout phase it is probably worth having a TA bit so resolvers
can avoid probing 853 when it is definitely futile. If TA=1 and 853
doesn't work then it'll probably be slower to resolve that server's
domains, which is about the right level of breakage. (TA is a hint not a
security feature.)

> > I don't follow why the registries need to be involved with DANE for
> > DNS-over-TLS any more than they do with HTTP-over-TLS or SMTP-over-TLS.
> > Can you maybe try to explain more?

The reason for wanting to include the NS targets' TLSA records in the glue
is so that the resolver can immediately connect over DoT with
authentication, without having to spend time chasing down TLSA records
from below the zone cut. It would be a performance optimization.

To some extent it also closes a privacy leak since it makes it easier for
the resolver to query the child zone's servers without exposing which
child zone it is asking about.

> Exposing my considerable ignorance here (as usual), but can a TLSA
> record be added for the in-addr.arpa/ip6.arpa name of a given
> nameserver IP?

Possibly... I think it was the DoH session at IETF 101 where a bunch of
people got up to say that it's futile to expect the reverse DNS to be
useful. It is perhaps less of a disaster area for mail server and maybe
DNS server IP addresses. But it's shaky territory.

The advantage in this context is that it might allow us to work around the
problem of authoritative servers with lots of different names in NS
targets. You could authenticate DoT to the server regardless of name by
putting the TLSA record in the reverse DNS.

Another disadvantage is that it might be a bit slow, because you can't
look up the reverse DNS TLSA until after you have got the address records
(rather than being able to look them up concurrently). On the gripping
hand, since we can't include TLSA records in glue, the choice is between
a followup query to get the TLSA records from the child zone, or from the
reverse DNS, so the performance difference boils down to how quickly the
resolver can iterate down the reverse DNS.

Perhaps it makes sense to search for TLSA in both forward and reverse?

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
Fisher: West, backing southwest later, 5 to 7, occasionally gale 8 at first.
Moderate or rough. Showers later. Good.

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

[dns-privacy] Sketchy notes on DNS-over-TLS to authoritative servers

[Tony Finch]

In the most general terms, when upgrading a protocol from cleartext to
TLS, there are a couple of questions the client has to answer:

1. Does this server support TLS?
2. How can I authenticate it?

And there are a couple of approaches to answering them:

A. opportunistic
B. explicit

Opportunistic protocols are easier to set up, but they only answer
question 1 (leaving 2 implicit); whereas explicit protocols are about
publising an answer to question 2, which implies answer 1 is yes.


Opportunistic TLS
-

The only mechanism we have is to probe port 853 and fall back to 53 if
TLS isn't available.

This is fraught with problems since in many cases firewalls will drop
packets to port 853 rather than promptly returning ICMP errors.

It will be useful for resolvers to keep a cache of which auth servers
support TLS (with TLS session resumption data for those that do).


Suggestion: TA flag, "TLS available"


It might be worth adding an EDNS flag to advertise the availability of
TLS (only meaningful in responses, like the RA flag). This might
mitigate the worst auto-probing latency problems. This is kind of by
analogy to SMTP servers advertising STARTTLS in their EHLO response.


Authentication mess
---

If an auth server supporting TLS has a name in its certificate
matching the target name of the NS record that was used to find it,
then the implicit answer to question 2 is "just use PKIX certificate
validation".

However, it's relatively common for NS records to use unofficial
target names. For example, DJB's comments on gluelessness and his
recommendation for delegations to be in-bailiwick with glue:

https://cr.yp.to/djbdns/notes.html

This means that opportunistic DoT for a popular authoritative server
is likely to run into certificate validation problems, so
opportunistic TLS can only be safe against passive snooping not active
interception.


Suggestion: DANE for DoT


This is similar to the SMTP situation, so how far can we get by
applying a similar solution? That is, use DANE TLSA records to
advertise that:

* this nameserver supports TLS, and
* resolvers can authenticate it strictly.

For example,

newton.ac.uk.  NS  auth0.dns.cam.ac.uk.
...

auth0.dns.cam.ac.uk.  A  131.111.8.37
auth0.dns.cam.ac.uk.  A  2a05:b400:d:a0::1

_853._tcp.auth0.dns.cam.ac.uk.  TLSA  1 1 1 ( ... )

(This is basically the same as a SPKI pinset but with a different encoding.)

A nice thing about this is that the resolver can find out the auth
server's DoT details at the same time as it finds out its addresses,
so there's no need for slow protocol negotiation.


Caveats of unusual size
---

Unfortunately, when we consider in-bailwick delegations, we soon
realise that we have strayed into a fire swamp.

Ideally (to minimize latency) when following a referral to a zone with
DoT auth servers, we would get everything we need in one response,
including TLSA records as a new kind of glue record.

I believe there aren't any big obstacles from the DNS protocol point
of view (including AXFR and UPDATE etc.) to adding new kinds of glue
record.

However, to make TLSA glue useful, it also needs to be supported by
registry databases, by EPP, and by registrar user interfaces. That'll
take considerably more than a million times longer than getting out of
the lightning sand.


Glueless DANE
-

If DANE glue isn't available, but TA flags are, then perhaps a
reasonable delegation following process is to make a probe `_853._tcp`
TLSA query in order to get the server's explicit DoT configuration, or
failing that a TA bit suggesting opportunistic DoT. This costs an
extra round trip in the resolution process.


Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
the quest for freedom and justice can never end

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

Re: [dns-privacy] Oblivious DNS

[Tony Finch]

Willem Toorop  wrote:
>
> ODNS queries could be nested.  I.e.
>
> {{{www.foo.bar}k.odns.google.com}k.odns.quad9.net}k.odns.cloudflare.com

OnionDNS :-)

Tony.
-- 
f.anthony.n.finch    http://dotat.at/
West Fitzroy: Northwesterly 7 to severe gale 9, veering northerly 5 to 7. High
or very high, becoming rough or very rough. Rain or thundery showers. Good,
occasionally poor.

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

Re: [dns-privacy] Potential re-charter text

[Tony Finch]

Let's retry the tests with a hot cache, since that's maybe a bit more
fair. I've picked the shortest times I could get, which involved heating
up the resolver until it was no longer waiting 10s or 30s on lame
authoritative servers.

Unbound 1.6.0 TCP 8s
Unbound 1.6.0 UDP 0.4s
BIND 9.11 TCP 0.5s
BIND 9.11 UDP 0.5s
BIND 9.10 TCP 3s
BIND 9.10 UDP 0.5s
1.1.1.1 TCP 0.5s
1.1.1.1 UDP 0.4s
8.8.8.8 TCP 5s # drops connection after 60 queries
8.8.8.8 UDP 220s # it hates me
9.9.9.9 TCP 1s
9.9.9.9 UDP 3s
64.6.64.6 TCP 0.5s
64.6.64.6 UDP 0.5s

Tony.
-- 
f.anthony.n.finch    http://dotat.at/
Trafalgar: Cyclonic gale 7 to severe gale 9, occasionally storm 10 for a time
in northwest, becoming northwesterly 5 to 7 later. Very rough or high,
occasionally very high for a time in west, becoming rough or very rough later.
Rain or showers. Good, occasionally poor.

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

Re: [dns-privacy] I-D Action: draft-ietf-dprive-padding-policy-01.txt

[Tony Finch]

Shane Kerr  wrote:
>
> I'm curious what you mean by this. Do you really mean to propose an
> option to pad every query and response message to 65K bytes?

Reasonable values might be the MTU or the EDNS buffer size.

Tony.
-- 
f.anthony.n.finch    http://dotat.at/  -  I xn--zr8h punycode
Southeast Fitzroy: Northerly or northeasterly, 4 or 5 increasing 6 at times.
Slight or moderate. Occasional rain. Good, occasionally poor.

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

Re: [dns-privacy] Demultiplexing HTTP and DNS on the same listener [New Version Notification for draft-dkg-dprive-demux-dns-http-00.txt]

[Tony Finch]

Section 3.2.2 HTTP/1

Is there a SP missing between the request-target and the HTTP-version in
the diagram of the shortest possible request?

Section 4.3 Opcode / 4.6 ANCOUNT NSCOUNT

Do you want to support UPDATE? If not it should probably be ruled out up
front, since it changes some of the analysis (though not the result,
since octet 5 will be zero for DNS).

Tony.
-- 
f.anthony.n.finch    http://dotat.at/  -  I xn--zr8h punycode
Thames, Dover, Wight, Portland, Plymouth: North or northwest, backing west for
a time, 4 or 5, decreasing 3 at times. Slight or moderate. Showers, then rain
for a time except in Plymouth. Good, occasionally moderate.

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

Re: [dns-privacy] DNS-over-TLS query/answer framing.

[Tony Finch]

Simon Kelley  wrote:

> The current proposal is a huge pain, because 1035 framing only allows
> one query-in-flight per TCP/TLS connection.

No it doesn't. The reason DNS over TCP has query IDs like UDP is to
support pipelined queries and out-of-order responses. You can use adns to
try out query pipelining over TCP, and if you point it at BIND 9.11
(current pre-release git development branch) you will get out-of-order
responses. The performance of adns with one TCP connection to BIND 9.11 is
about the same as UDP.

Tony.
-- 
f.anthony.n.finch    http://dotat.at/
Viking, North Utsire: Easterly 4 or 5, increasing 6 at times. Slight or
moderate, but rough in southwest Viking. Showers later. Good, occasionally
poor later.

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

Re: [dns-privacy] I-D Action: draft-ietf-dprive-start-tls-for-dns-00.txt

[Tony Finch]

Paul Hoffman paul.hoff...@vpnc.org wrote:
 On May 12, 2015, at 11:40 AM, Simon Josefsson si...@josefsson.org wrote:

  For SMTP, IMAP, POP etc the reason for having both port-based and
  upgrade-based is legacy and historic reasons: back in the days the
  STARTTLS approach wasn't invented, so following HTTP(S) footsteps, new
  ports were allocated for secure protocol variants.  Modern protocols
  does not have this issue; compare XMPP.

 That's not accurate for SMTP: during discussion of RFC 2487, there was
 no alternate port for SMTP-over-TLS. It's also not accurate for IMAP and
 POP: both of those got STARTTLS-like extensions because that's how SMTP
 works.

My understanding is that the smtps port was allocated, then in a fit of
panic the IETF decided that allocating N*M ports (N protocols, M security
layers) would be a disaster and cause horrible security layer negotiation
problems, so smtps was un-allocated and STARTTLS was invented. (IANA
doesn't record when imaps and pops ports were allocated but I think it was
before smtps.)

Tony.
-- 
f.anthony.n.finch  d...@dotat.at  http://dotat.at/
Southeast Iceland: Variable 4, becoming southeasterly 5 or 6. Moderate or
rough. Showers. Good.

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

Re: [dns-privacy] DPRIVE over UDP or TCP

[Tony Finch]

Not all: see my message from Friday: 
http://www.ietf.org/mail-archive/web/dns-privacy/current/msg00758.html
I assume other large anycast TLS providers have similar setups to Cloudflare.

Tony.
-- 
f.anthony.n.finch  d...@dotat.at  http://dotat.at

 On 27 Apr 2015, at 21:17, Paul Hoffman paul.hoff...@vpnc.org wrote:
 
 There is a third solution to the anycast problem, which is what is done 
 today in all systems that use anycast: assume that it happens so rarely, that 
 a rare reset is just fine.
 

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

Re: [dns-privacy] [DNSOP] DNS over DTLS (DNSoD)

[Tony Finch]

Tirumaleswar Reddy (tireddy) tire...@cisco.com wrote:

 Any specific reason for the firewalls to permit TCP/53 other than for zone 
 transfer ?

RFC 5966

Tony.
-- 
f.anthony.n.finch  d...@dotat.at  http://dotat.at/
South Utsire, Northeast Forties: Easterly 4 or 5, increasing 6 or 7. Slight or
moderate. Fair. Good.

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