Re: [dns-privacy] UDP/853 port allocation request for draft-ietf-dprive-dnsoquic

[Eric Rescorla]

On Mon, Nov 29, 2021 at 6:04 AM Eric Vyncke (evyncke)  wrote:

> Just a heads-up to the DPRIVE WG and for the DoQ authors[1]: after some
> discussions within IESG/IAB, I am afraid that UDP/853 won't be allocated to
> DoQ. Nothing definitive yet of course but IAB/IESG have raised the
> following concerns:
>
>
>
>- Lack of real technical motivation (except for 'symmetry' or for
>operational reasons).
>- Moving DoDTLS to historic will not help, as it will simply return
>udp/853 to the pool to be re-used later.
>- The *currently* possible demux between QUIC & DTLS is not something
>carved in stone forever. Hence, a future problem can happen if DTLS v23
>cannot be demuxed from QUIC v19. This would put a heavy constraint on
>the evolution of both QUIC & DTLS, i.e., ossifying both protocols. Not to
>mention that both QUIC & DTLS want to expose as little as possible to
>observers, making demux of future versions quite improbable...
>
>
I don't particularly care whether 853 is assigned to DoQ or not, but these
reasons do not strike me as particularly strong.

In particular, there are at least sets of indicia that allow for demuxing
DTLS and QUIC:

- Bit 0x40, which is 1 in QUIC and 0 in DTLS.
- All QUIC packets are integrity protected (the early ones with a fixed key)

I doubt that this second thing is going to change materially (though of
course the key may change) so it seems likely that it will be possible to
distinguish QUIC from DTLS indefiitely.

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

Re: [dns-privacy] Intermediate proposal (what I was saying at the mic)

[Eric Rescorla]

On Sun, Aug 1, 2021 at 9:22 PM Martin Thomson  wrote:

> On Fri, Jul 30, 2021, at 06:08, Eric Rescorla wrote:
> > - Recursives can attempt to connect to any authoritative by probing
> >   with DoT/DoQ [0]. In this case, they should cleanly fall back to
> >   Do53 on connect failure and not validate the credential (whether
> >   WebPKI or DANE) This allows authoritatives to just turn on TLS
> >   without risk.
>
> I assume that your MUST NOT validate here only exists because of the
> combination of:
>
> 1.  Us not being able to decide between Web PKI and DANE; and
>

Largely, though it also allows for incremental rollout and a new auth
mechanism.

2.  The potential for an unauthenticated mode.
>
> If we decided on a single answer for the first and in the negative for the
> second, would that make authentication viable?  Or is the opportunism a
> feature?
>
> ___
> dns-privacy mailing list
> dns-privacy@ietf.org
> https://www.ietf.org/mailman/listinfo/dns-privacy
>
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] Intermediate proposal (what I was saying at the mic)

[Eric Rescorla]

On Thu, Jul 29, 2021 at 1:19 PM Paul Wouters  wrote:

> On Thu, 29 Jul 2021, Eric Rescorla wrote:
>
> > - Recursives can attempt to connect to any authoritative by probing
> >   with DoT/DoQ [0]. In this case, they should cleanly fall back to
> >   Do53 on connect failure and not validate the credential (whether
> >   WebPKI or DANE) This allows authoritatives to just turn on TLS
> >   without risk.
>
> I agree.
>
> And importantly, they can turn on _credentialed_ TLS without risk. If
> you would allow to continue "unauthenticated", then the DNS operator still
> has a future hard decision to make when to insist on authenticated. They
> again have to make a risky decision. The fact that "unauthenticated"
> works as standalone or fallback is no guarantee whatsoever that adding
> credentials to that setup won't cause complete failure.
>
> > - The SVCB record is used to signal that the authoritative expects to
> >   do TLS and indicates the type of credential (WebPKI, DANE, etc.)
> >   that the authoritative intends to present.  The recursive should
> >   insist on TLS in this case and hard fail if it cannot negotiate.
>
> Yes, I tried to do exactly this with TLSA records 
> And this is what TLSA for SMTP actually does.
>
>
> >   If there is an overlap between the credentials the recursive
> >   supports and the ones the authoritative advertises, then the
> >   recursive should validate the credential and fail if it cannot.  If
> >   there is no overlap, it should not validate the credential.
>
> If there is no overlap, why even try the transport? Just do port 53.
>

The usual 7258 reasons, namely that forcing an active attack is good.


Don't give the user/OS a false sense of privacy if you can't even detect
> a MITM.
>

Can you expand on how someone is getting a false sense of security here?
I mean, we're talking about the recursive, right? So generally, the client
won't know what's happening at all.



> > - (Optional) We should invent some way for the server to say in
> >   SVCB that it doesn't have any valid credential (e.g., a reserved
> >   credential type). This would be a signal you wanted unauthenticated.
>
> Now you are advertising which DNS servers can easilly be MITMed. An
> attacker can live query the DNS to see if it should commence attacking.
>

How is this different from seeing who supports TLS but has an invalid cert?
Anyway, I'm not going to fight about this piece.

-Ekr


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

[dns-privacy] Intermediate proposal (what I was saying at the mic)

[Eric Rescorla]

To recap what I was saying on the list, here's my proposal:

- Recursives can attempt to connect to any authoritative by probing
  with DoT/DoQ [0]. In this case, they should cleanly fall back to
  Do53 on connect failure and not validate the credential (whether
  WebPKI or DANE) This allows authoritatives to just turn on TLS
  without risk.

- The SVCB record is used to signal that the authoritative expects to
  do TLS and indicates the type of credential (WebPKI, DANE, etc.)
  that the authoritative intends to present.  The recursive should
  insist on TLS in this case and hard fail if it cannot negotiate. [1]
  If there is an overlap between the credentials the recursive
  supports and the ones the authoritative advertises, then the
  recursive should validate the credential and fail if it cannot.  If
  there is no overlap, it should not validate the credential.

- (Optional) We should invent some way for the server to say in
  SVCB that it doesn't have any valid credential (e.g., a reserved
  credential type). This would be a signal you wanted unauthenticated.

This would allow for:

- Unauthenticated to work and be discovered.
- An easy upgrade to authenticated after initial contact (a la
  HSTS etc.)
- A path to fully authenticated from initial contact if we
  ever figure out the parent signaling, because you just need
  to propagate the contents of SVCB (or some subset).

-Ekr


[0] As PaulH says, this won't work with DoH because of ambiguity
about the path portion.

[1] This signal should only be accepted over an authenticated
connection, a la HSTS.
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] DPRIVE agenda for IETF 111

[Eric Rescorla]

On Fri, Jul 16, 2021 at 12:43 PM Brian Haberman 
wrote:

> Hi Paul,
>
> On 7/16/21 1:02 PM, Paul Wouters wrote:
> > On Fri, 16 Jul 2021, Brian Haberman wrote:
> >
> >>Here is the preliminary agenda for the DPRIVE session at IETF 111.
> >> If there are no objections or late additions, the chairs will cancel the
> >> second 1-hour slot assigned to DPRIVE.
> >>
> >> https://datatracker.ietf.org/meeting/111/materials/agenda-111-dprive-00
> >
> > As we have two drafts that are assuming that SVCB records for a zone can
> > be served at the parent, I think we need to talk aboutthis at the
> meeting.
> >
>
> None of those draft authors requested agenda time.
>

Yeah, we've been swamped. We would like agende time if it's still available.

-Ekr


> > I've tried to convey that this is an unrealistic reality, and that work
> > should focus on this not happening, eg drafts should not specify
> > "interim" solutions for this to happen. It would be good to get clear
> > working group consensus on this so the draft authors can take that
> > consensus into account for future draft versions.
>
> If you want to lead that discussion, please let the chairs know.
>
> Regards,
> Brian
>
> ___
> dns-privacy mailing list
> dns-privacy@ietf.org
> https://www.ietf.org/mailman/listinfo/dns-privacy
>
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] [Ext] Moving forward on draft-ietf-dprive-unauth-to-authoritative

[Eric Rescorla]

On Sat, Jun 19, 2021 at 6:24 PM Paul Hoffman  wrote:

> On Jun 18, 2021, at 7:43 PM, Eric Rescorla  wrote:
> >
> >
> >
> >> On Wed, Jun 16, 2021 at 10:13 AM Paul Hoffman 
> wrote:
> >> Greetings again. Based on the WG discussion of the last few weeks, we
> can see that the folks with the fully-authenticated use case do not yet
> agree on a signaling mechanism. Given that, we have just published a new
> version of draft-pp-dprive-common-features that lists "SVCB on the client
> side" as one discovery mechanism, and a new version of
> draft-ietf-dprive-unauth-to-authoritative that points to that mechanism.
> When the folks with the fully-authenticated use case do agree on a
> signaling mechanism, that can be added to the -common-features draft.
> >>
> >> We would like the WG chairs to have a formal call for
> draft-pp-dprive-common-features to be a WG document soon so we know how to
> deal with it before the draft cutoff before the next IETF meeting. If the
> WG wants it as a WG document, great; if not, we would pull back all those
> features into draft-ietf-dprive-unauth-to-authoritative and the WG would
> have to decide what to do for the eventual fully-authenticated draft.
> >>
> > I think (unsurprisingly) I am not in favor of this. Let's figure out
> what we are trying to do and roughly the approach we want to follow. Until
> then, adopting drafts is premature.
>
> The WG can work on the already-adopted unauthenticated use case, and the
> fully-authenticated use case can catch up when there are authors interested
> in keeping the discussion on their protocol moving.
>

I don't see any need to personalize this discussion.

In any case, to the extent to which the WG is going to work solely on the
unauthenticated version, it can do so in the existing draft. Having a draft
which purports to contain "common features" between the authenticated and
unauthenticated use cases is not helpful when basic questions remain.

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

Re: [dns-privacy] Moving forward on draft-ietf-dprive-unauth-to-authoritative

[Eric Rescorla]

On Wed, Jun 16, 2021 at 10:13 AM Paul Hoffman 
wrote:

> Greetings again. Based on the WG discussion of the last few weeks, we can
> see that the folks with the fully-authenticated use case do not yet agree
> on a signaling mechanism. Given that, we have just published a new version
> of draft-pp-dprive-common-features that lists "SVCB on the client side" as
> one discovery mechanism, and a new version of
> draft-ietf-dprive-unauth-to-authoritative that points to that mechanism.
> When the folks with the fully-authenticated use case do agree on a
> signaling mechanism, that can be added to the -common-features draft.
>
> We would like the WG chairs to have a formal call for
> draft-pp-dprive-common-features to be a WG document soon so we know how to
> deal with it before the draft cutoff before the next IETF meeting. If the
> WG wants it as a WG document, great; if not, we would pull back all those
> features into draft-ietf-dprive-unauth-to-authoritative and the WG would
> have to decide what to do for the eventual fully-authenticated draft.
>

I think (unsurprisingly) I am not in favor of this. Let's figure out what
we are trying to do and roughly the approach we want to follow. Until then,
adopting drafts is premature.

-Ekr


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

Re: [dns-privacy] Fwd: New draft-ietf-dprive-unauth-to-authoritative and draft-pp-dprive-common-features

[Eric Rescorla]

On Wed, May 26, 2021 at 11:21 AM Vladimír Čunát 
wrote:

> I like it in principle, so I say adopt.
>
> I already see a significant problem, though I expect we can fix it somehow
> after adoption:
>
> After sending out all requests for SVCB records [...]
>
> My understanding of section 3 implies that an implementing resolver MUST
> NOT ask any of the nameservers until *all* their SVCBs have been attempted,
> in the most common case where no encryption is supported by the
> nameserver-set.  That would *not* scale at all.  Even with 13 NSs it's a
> rather bad amplification factor, and it reminds me of the recent NXNS
> attack.
>
> On the whole, if a NS set has (many?) names without encryption support,
> I'm afraid the corresponding zones may have to do without a guarantee of
> getting encryption, though glue might help.
>
>
> On 26/05/2021 15.21, Stephen Farrell wrote:
>
> SVCB in the parent zone will take years to happen
>
> The SVCB glue is just a slight optimization.  I don't think it can even
> save latency, just a packet per NS (and only in cases where the SVCB
> exists).
>
As noted in my presentation, it's more than an optimization. It's an
important security function in cases where the sensitive domain name is the
apex.

-Ekr


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

Re: [dns-privacy] [Ext] Fwd: New draft-ietf-dprive-unauth-to-authoritative and draft-pp-dprive-common-features

[Eric Rescorla]

On Tue, May 25, 2021 at 5:17 PM Paul Hoffman  wrote:

> On May 25, 2021, at 5:09 PM, Eric Rescorla  wrote:
> > The fundamental question here is whether we want to build a mechanism
> for authenticated ADoX or not
>
> It might be better to think of this as "whether we want to build a
> mechanism for fully-authenticated ADoX now, but if not now, allow for it to
> be done easily in the future". Others on the list have already said that
> they are interested in unauthenticated as a stepping stone to later going
> to full authentication.
>
> The purpose of the proposed -common-features draft is to make such
> fully-authenticated mechanism(s) easily definable regardless of when the WG
> wants to do so.
>

I understand your motivation, but I think in this case it is misguided. The
controversial parts of fully authenticated are precisely the signaling
mechanisms in draft-rescorla-dprive-adox that you are attempting to pull
out here. If those are acceptable, then authenticated is comparatively easy.

-Ekr


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

Re: [dns-privacy] Fwd: New draft-ietf-dprive-unauth-to-authoritative and draft-pp-dprive-common-features

[Eric Rescorla]

On Tue, May 25, 2021 at 2:28 PM Paul Wouters  wrote:

> On May 25, 2021, at 17:16, Tim Wicinski  wrote:
> >
> >
> > All
> >
> > The authors took the advice from the working group and extracted the
> more common features
> > into a separate document.   The chairs would like the working group to
> give some comments, as
> > we feel a document like this should be considered for adoption.
>
> I had not responded on purpose. As indicated in the past, I find the gains
> of encrypting but not authenticating authoritative servers not very useful.
>

I agree with this.

The fundamental question here is whether we want to build a mechanism for
authenticated ADoX or not; and if so, whether there are technical
mechanisms that make it possible/practical. I don't believe we have
consensus on this point (indeed, PaulW and I disagree on that), and so just
trying to pull out those mechanisms while avoiding this issue seems not
very productive.

-Ekr

We have an existing authentication mechanism for authenticating
> authoritative servers (DNSSEC) that we should spend our energy on promoting
> instead of writing more RFCs about securing the transport leaving the
> transported data vulnerable to manipulation by an ever more centralized
> resolver farm.
>



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

Re: [dns-privacy] Next steps for draft-rescorla-dprive-adox

[Eric Rescorla]

On Tue, May 11, 2021 at 6:36 PM Paul Wouters  wrote:

> On Tue, 11 May 2021, Eric Rescorla wrote:
>
>
> > 2. Is this proposal a plausible starting point for that?
>
> No it is not. If a TLD that falls under ICANN policues would suggest
> running software that supports this proposed record, it would surely
> trigger an RSTEP review, and wearing my ICANN RSTEP reviewer hat, I
> would strongly advise not reject the TLDs technical proposal.
>
> This has nothing to do with what I want. I _want_ this record or similar
> solution to work, but it just realistically cannot work. That is also why
> people (including me) who are normally very strict against overloading
> have suggested the only way to signal something at the parent is via
> overloading the NS or DS record in some way. And using DS is better
> because it is signed and can be verified at the child.
>

I'd like to make sure I understand your point. Is it simply that this
information should
be encoded in NS or DS? If so, I don't particularly object to that. I don't
have a strong
opinion about how this signal is spelled.

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

[dns-privacy] Next steps for draft-rescorla-dprive-adox

[Eric Rescorla]

Hi all,

Now that we've had some time to let the ideas settle, I'd like to
discuss what would be required in order for the WG to adopt
draft-rescorla-dprive-adox-latest.

>From my perspective, the primary open question is the wisdom of having
some kind of record in the parent domain. For the reasons I indicated
in my presentation and in Section 6, if we are unable to securely
indicate the use of ADoX in the parent, it will not be possible to
protect many queries (i.e., those for the apex). I note that this is
also embodied in:

https://www.ietf.org/archive/id/draft-pp-dprive-common-features-00.txt
and
https://www.ietf.org/archive/id/draft-ietf-dprive-unauth-to-authoritative-00.txt

While I understand that there are people who have reservations about
whether it will be practical to popuate the parent, I think the
analysis cited above suggests that there will be comparatively little
value in attempting to have a non-opportunistic mode without this
feature (regardless of which record it is encoded in).

So, from my perspective, the question is:

1. Do we want a non-opportunistic mode? [My answer, of course, is yes]
2. Is this proposal a plausible starting point for that?

If the answer to both of those question is "yes", then I'd like to
ask for adoption. If not, can we try to dig into each of them?

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

Re: [dns-privacy] [TLS] Martin Duke's No Objection on draft-ietf-dprive-xfr-over-tls-11: (with COMMENT)

[Eric Rescorla]

On Thu, Apr 29, 2021 at 11:38 AM Stephen Farrell 
wrote:

>
>
> On 29/04/2021 19:28, Salz, Rich wrote:
> > To make it obvious (I thought it was): I agree, and think we need to
> > make that fact more widely known.
>
> I think I agree but seems like ECH may add a subtlety - maybe
> what we need to promote is the idea that new protocols should
> define new ALPN strings, but also that intermediaries can't
> depend on those to route connections as the inner and outer
> ALPN values can be independent in the case of ECH (use of
> which might not that visible to the application if a library
> were to default to use of ECH where possible).
>

Correct. The purpose of ALPN in this context is to avoid cross-protocol
attacks on the endpoints. Reliance on them by intermediaries is difficult
absent some fairly strong assumptions about the endpoints.

-Ekr


> Cheers,
> S.
>
> >
> > From: Eric Rescorla  Date: Thursday, April 29, 2021 at
> > 2:24 PM To: Rich Salz  Cc: Martin Thomson
> > , "dns-privacy@ietf.org" ,
> > "t...@ietf.org"  Subject: Re: [dns-privacy] [TLS] Martin
> > Duke's No Objection on draft-ietf-dprive-xfr-over-tls-11: (with
> > COMMENT)
> >
> > Probably not, but I agree with MT.
> >
> > The general idea here is that any given protocol trace should only be
> > interpretable in one way. So, either you need the interior protocol
> > to be self-describing or you need to separate the domains with ALPN.
> > I don't believe that either the IP ACL or mTLS addresses this issue,
> > and in fact arguably mTLS makes the problem worse because it provides
> > authenticated protocol traces which might be usable for
> > cross-protocol attacks.
> >
> > -Ekr
> >
> >
> > On Thu, Apr 29, 2021 at 7:26 AM Salz, Rich
> > mailto:40akamai@dmarc.ietf.org>>
> > wrote:
> >> No new protocol should use TLS without ALPN.  It only opens space
> >> for cross-protocol attacks.  Did the working group consider this
> >> possibility in their discussions?
> >
> > I don't believe that message has been made as public as it should
> > be.
> >
> > ___ dns-privacy mailing
> > list dns-privacy@ietf.org<mailto:dns-privacy@ietf.org>
> > https://www.ietf.org/mailman/listinfo/dns-privacy<
> https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/dns-privacy__;!!GjvTz_vk!EtJaCTiH36U_bsA5vP82lZpBELKgq8908Dnb9MmdFc9M0FfjBeJMg3QwgwSs$
> >
> >
> >
> >
> > ___ TLS mailing list
> > t...@ietf.org https://www.ietf.org/mailman/listinfo/tls
> >
>
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] [TLS] Martin Duke's No Objection on draft-ietf-dprive-xfr-over-tls-11: (with COMMENT)

[Eric Rescorla]

On Thu, Apr 29, 2021 at 11:49 AM Allison Mankin 
wrote:

> Hi Ekr,
>
> As Sara wrote, the spec had ALPN. The WG consensus during the IETF 108
> meeting was very strong to take it out, including quite strong statements
> from you along the lines that distinguishing between XoT and DOT was an
> incorrect usage of ALPN.
>

I don't have the message you are referring to at hand, so I'm not able to
respond to that. However, I don't believe that an ALPN is needed to
distinguish XoT from DoT because there is no confusion between the protocol
traces of XoT and DoT. However there should be an ALPN to distinguish XoT
and DoT from HTTP, SMTP, etc.IOW, this protocol should use ALPN="dot".


I understand that the perspective changed since IETF108 (that WG discussion
> was at the end of July 2020) and that communications were not wide enough
> for us to know about it in March when the WG moved the draft to WGLC,
> Directorates Review, and IETF LC
>

I don't think anyone is saying that the WG somehow did something wrong
procedurally, merely that this is a defect that ought to be corrected prior
to publication.

-Ekr


On Thu, Apr 29, 2021 at 14:25 Eric Rescorla  wrote:
>
>> Probably not, but I agree with MT.
>>
>> The general idea here is that any given protocol trace should only be
>> interpretable in one way. So, either you need the interior protocol to be
>> self-describing or you need to separate the domains with ALPN. I don't
>> believe that either the IP ACL or mTLS addresses this issue, and in fact
>> arguably mTLS makes the problem worse because it provides authenticated
>> protocol traces which might be usable for cross-protocol attacks.
>>
>> -Ekr
>>
>>
>> On Thu, Apr 29, 2021 at 7:26 AM Salz, Rich > 40akamai@dmarc.ietf.org> wrote:
>>
>>> >No new protocol should use TLS without ALPN.  It only opens space
>>> for cross-protocol attacks.  Did the working group consider this
>>> possibility in their discussions?
>>>
>>> I don't believe that message has been made as public as it should be.
>>>
>>> ___
>>> dns-privacy mailing list
>>> dns-privacy@ietf.org
>>> https://www.ietf.org/mailman/listinfo/dns-privacy
>>>
>> ___
>> TLS mailing list
>> t...@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
>>
>
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] [TLS] Martin Duke's No Objection on draft-ietf-dprive-xfr-over-tls-11: (with COMMENT)

[Eric Rescorla]

Probably not, but I agree with MT.

The general idea here is that any given protocol trace should only be
interpretable in one way. So, either you need the interior protocol to be
self-describing or you need to separate the domains with ALPN. I don't
believe that either the IP ACL or mTLS addresses this issue, and in fact
arguably mTLS makes the problem worse because it provides authenticated
protocol traces which might be usable for cross-protocol attacks.

-Ekr


On Thu, Apr 29, 2021 at 7:26 AM Salz, Rich  wrote:

> >No new protocol should use TLS without ALPN.  It only opens space for
> cross-protocol attacks.  Did the working group consider this possibility in
> their discussions?
>
> I don't believe that message has been made as public as it should be.
>
> ___
> dns-privacy mailing list
> dns-privacy@ietf.org
> https://www.ietf.org/mailman/listinfo/dns-privacy
>
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] How do we want to use draft-ietf-dprive-phase2-requirements?

[Eric Rescorla]

I also prefer #4.

On Mon, Apr 26, 2021 at 12:45 PM Brian Haberman 
wrote:

> Does anyone else have an opinion on this?
>
> On 4/19/21 5:13 PM, Brian Haberman wrote:
> > All,
> >  As was raised on the thread discussing suggestions for the
> > requirements draft, there is some question on how the WG wants to use
> > draft-ietf-dprive-phase2-requirements in progressing our
> > recursive-to-authoritative privacy work item. The draft currently has
> > one sub-section that describes requirements (5.1) and another section
> > that describes optional features (5.2), albeit with 2119 SHOULDs.
> >
> >  My question to the WG is how do we want to use this draft? I see
> > four possible approaches, but I am sure someone will point out others.
> >
> > 1. Strictly requirements - these would be MUST-level functions that the
> > WG determines have to be supported by any solutions draft.
> >
> > 2. Strictly design considerations - these would be functional areas that
> > the WG determines need to be considered, but not necessarily included,
> > by any solutions draft.
> >
> > 3. Requirements & design considerations - This is generally where the
> > current draft sits IMO.
> >
> > 4. Drop the draft and let the solutions flow.
> >
> > Let's discuss the focus of the draft and then we can determine what
> > updates are needed/necessary.
> >
> > Regards,
> > Brian
> >
>
> ___
> dns-privacy mailing list
> dns-privacy@ietf.org
> https://www.ietf.org/mailman/listinfo/dns-privacy
>
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] Root Server Operators Statement on DNS Encryption

[Eric Rescorla]

On Tue, Mar 30, 2021 at 5:33 PM Stephen Farrell 
wrote:

>
> Hiya,
>
> On 31/03/2021 01:24, Eric Rescorla wrote:
> > As I said earlier, this seems overly conservative given our experience
> with
> > large scale TLS-based services.
>
> For the root servers, I don't get why QNAME minimisation
> isn't enough? If it is enough, that'd imply to me that the
> root server operators statement is fine, so long as it
> is only read to apply to root servers and not TLDs.
>
> >
> > With that said, this doesn't seem to me to present a severe problem:
> there
> > are a relatively small number of TLD servers, so we could probably
> create a
> > lookaside list of which ones support TLS as suggested in
> > draft-rescorla-dprive-adox-latest-00 Section 3,
>
> I agree that the privacy issues with TLD servers are more
> worthy of attention and I guess require encryption if we are
> to improve things. I'm not saying the above draft is a good
> way to handle that, but the problem in querying TLDs is real,
> whereas for root servers it seems to me way less of a deal.
>
> Or... am I confused? (That happens often:-)


As Erik indicates, it's possible that the the TLD is sensitive, though it's
a bit hard to evaluate that risk.

However, recall that the TLS connection to the parent is what protects the
NS records for the child, as they are not DNSSEC signed. Thus, one has a
somewhat fragile situation if one has to store a lookaside list of the TLS
status (and at some level the nameservers!) for the TLDs. I'm not saying
it's unmanageable, but it's not amazing.

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

Re: [dns-privacy] Root Server Operators Statement on DNS Encryption

[Eric Rescorla]

On Tue, Mar 30, 2021 at 5:08 PM Erik Kline  wrote:

>
> On Tue, Mar 30, 2021 at 5:01 PM Rob Sayre  wrote:
>
>> On Tue, Mar 30, 2021 at 7:49 AM Hollenbeck, Scott > 40verisign@dmarc.ietf.org> wrote:
>>
>>> This is worth reading:
>>>
>>> https://root-servers.org/media/news/Statement_on_DNS_Encryption.pdf
>>
>>
>> I am not sure I agree it is worth reading.
>>
>> Why can't "The Root Server Operators" run QUIC etc as well as their
>> existing UDP methods?
>>
>> thanks,
>> Rob
>>
>
> (no hats)
>
> >From my reading the answer, and the whole document, seems to be
> summarizable in this one excerpt:
>
> "Root Server Operators do not feel comfortable being the early
> adopters of authoritative DNS encryption and would like to first see
> increased deployment in other parts of the DNS hierarchy."
>
> Seems fair to me, for the time being.
>

As I said earlier, this seems overly conservative given our experience with
large scale TLS-based services.

With that said, this doesn't seem to me to present a severe problem: there
are a relatively small number of TLD servers, so we could probably create a
lookaside list of which ones support TLS as suggested in
draft-rescorla-dprive-adox-latest-00 Section 3,

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

Re: [dns-privacy] [Ext] next steps for draft-opportunistic-adotq

[Eric Rescorla]

On Wed, Mar 24, 2021 at 7:56 AM Jim Reid  wrote:

>
>
> > On 24 Mar 2021, at 14:10, Bill Woodcock  wrote:
> >
> > How many mqps are necessary to have a voice in your vision of
> multistakeholderism?
>
> I don’t know.
>
> I think/hope we have the same vision of multistakeholderism. If not,
> that’s a conversation for another time and place.
>
> > Or, viewed from the other end of the spectrum, are you suggesting that
> only the two or three largest TLDs out of two thousand, count?
>
> No, of course not. Any TLD or authoritiev server is welcome to do whatever
> it wants here. Even if I think it’s a bad idea. Which could very well be an
> incentive for others to deploy.
>
> What I am saying is this WG needs to think more about the impacts* of
> Do[TH] on busy authoritative servers (not just TLDs). And maybe for busy
> recursive servers too. Some of us were talking about that just over an hour
> ago in the RIPE DNS WG:
>
>
> https://www.ripe.net/participate/ripe/wg/active-wg/dns/remote-sessions/2021-03-24-ripe-dns-wg-hollenbeck-balanced-dns-information-protection-strategy.pdf
>
> AFAICT the WG hasn’t yet considered any of the risk analysis issues
> identified in Scott’s presentation.
>


Right. I've read this and I think it's interesting but not really
dispositive. It seems to me that there are two arguments here:

- The combination of QMIN and aggregation/caching around the recursive
  decreases the need for TLS to the root and the TLD

- There are operational risks to running TLS on the root and TLD
  servers

WRT the first point, I don't think QMIN helps as much as you might
like for two reasons:

1. In a very large number of cases, it's the SLD which is sensitive.
   This means that QMIN at the TLD doesn't really help at all.
   And by extension, because you need to protect the NS record
   for the TLD (and they're not DNSSEC signed at the parent),
   not having TLS to the root means that you don't adequately
   protect the TLS connection to the TLD server either.

2. It's true that caching by the recursive helps some -- especially
   for large resolvers -- but there is still some information
   leakage if the cache is cold and you can observe both sides.
   Moreover, this just seems like an argument against ADoX entirely,
   because it applies as much to the connection to the SLD server.
   And given that ADoX is a charter item, it seems like there is a
   presumption that we should be working on this.

WRT the operational risk (slide 3), it's likely true that it's
somewhat harder to run a DoX server than a Do53 server. However, given
that we have plenty of worked examples of TLS servers of comparable if
not greater scale being operated with high reliability (e.g., Google,
Fastly, Cloudflare, etc.), I think there's pretty strong evidence that
this is an operational issue that can be addressed.

Of course, the IETF can't make the TLD servers run ADoX, but as
long as some TLDs are willing to, it seems odd not to specify it,
especially as the mechanisms are mostly the same at every level
of the hierarchy.

-Ekr


>
> * Those impacts BTW go beyond query rates or TLS session management.
> ___
> dns-privacy mailing list
> dns-privacy@ietf.org
> https://www.ietf.org/mailman/listinfo/dns-privacy
>
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] WG Call for Adoption: draft-pauly-dprive-oblivious-doh

[Eric Rescorla]

On Thu, Mar 18, 2021 at 5:02 AM Tomas Krizek  wrote:

> I oppose adoption.
>
> The draft introduces huge amount of additional complexity, both for
> implementors and operators of DoH. This raises the bar for both smaller
> vendors and operators, thus leading to more centralization.
>

This seems like an odd argument. We shouldn't do something that's
a manifest increase in privacy (even as experimental!) because it's
work to implement?

-Ekr





> Additionally, the problem it attempts to solve is not DoH-specific, or
> even DNS-specific, yet it only provides a solution for DoH.
>
> On 17/03/2021 14.00, Brian Haberman wrote:
> > All,
> >  This starts a DPRIVE WG call for adoption for
> > draft-pauly-dprive-oblivious-doh
> > (https://datatracker.ietf.org/doc/draft-pauly-dprive-oblivious-doh/).
> > Please reply to the mailing list with your views (positive or negative)
> > on the WG adopting the document and your supporting arguments.
> >
> >  This call will end on March 31, 2021 at 11:59pm UTC.
> >
> > Regards,
> > Brian & Tim
> >
> > ___
> > dns-privacy mailing list
> > dns-privacy@ietf.org
> > https://www.ietf.org/mailman/listinfo/dns-privacy
> >
>
> --
> Tomas Krizek
> PGP: 4A8B A48C 2AED 933B D495  C509 A1FB A5F7 EF8C 4869
>
> ___
> dns-privacy mailing list
> dns-privacy@ietf.org
> https://www.ietf.org/mailman/listinfo/dns-privacy
>
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] WG Call for Adoption: draft-pauly-dprive-oblivious-doh

[Eric Rescorla]

On Wed, Mar 17, 2021 at 4:48 PM Martin Thomson  wrote:

> On Thu, Mar 18, 2021, at 00:00, Brian Haberman wrote:
> >  This starts a DPRIVE WG call for adoption for
> > draft-pauly-dprive-oblivious-doh
> > (https://datatracker.ietf.org/doc/draft-pauly-dprive-oblivious-doh/).
> > Please reply to the mailing list with your views (positive or negative)
> > on the WG adopting the document and your supporting arguments.
>
> Adopt.  I will then encourage the working group to adopt oblivious HTTP
> (which we're in the process of chartering) rather than build a parallel
> design.
>
> Unlike ekr, I think that aiming for Proposed Standard is better than
> Experimental.  There is nothing wrong with a narrow scope of applicability,
> though in this case that narrow scope might still provide benefit for a
> great many people.
>

To clarify my position: i would favor a proposed standard based on O-HTTP.
I just think it's unfortunate to have something that is approximately
O-HTTP but not precisely as PS at the same time as we are also
standardizing O-HTTP

-Ekr

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

Re: [dns-privacy] WG Call for Adoption: draft-pauly-dprive-oblivious-doh

[Eric Rescorla]

I believe this document should be adopted with a target status of
Experimental

On Wed, Mar 17, 2021 at 6:00 AM Brian Haberman 
wrote:

> All,
>  This starts a DPRIVE WG call for adoption for
> draft-pauly-dprive-oblivious-doh
> (https://datatracker.ietf.org/doc/draft-pauly-dprive-oblivious-doh/).
> Please reply to the mailing list with your views (positive or negative)
> on the WG adopting the document and your supporting arguments.
>
>  This call will end on March 31, 2021 at 11:59pm UTC.
>
> Regards,
> Brian & Tim
>
> ___
> dns-privacy mailing list
> dns-privacy@ietf.org
> https://www.ietf.org/mailman/listinfo/dns-privacy
>
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] New draft on authenticated recursive <-> authoritative

[Eric Rescorla]

On Mon, Mar 8, 2021 at 6:00 PM Puneet Sood  wrote:

> [late to the discussion, so putting my responses here instead of as
> replies to various threads]
>
> * Use of SVCB vs TLSA for signaling secure transport support.
> Preference for SVCB since it is specifically meant to represent
> transport endpoints and could be extended to new transports,
> additional info in the future (DoQ or others).
>
> * Publishing SVCB records in the parent zone in addition to the child zone.
> The example used in the draft, shows an out-of-bailiwick SVCB record
> returned by the parent nameserver in a response to the resolver. The
> benefit of this is saving 1RTT to query the child zone and the
> information being more trustworthy w/o depending DNSSEC in the child
> zone.
>
> - This is the kind of record that a resolver will discard since it is
> out-of-bailiwick. Best reference I could find is the description of
> bailiwick in https://datatracker.ietf.org/doc/html/rfc8499.

- Ignoring this issue, if the resolver were to accept the SVCB record
> in glue from the parent zone, the information to be saved per zone ->
> name server mapping will go up significantly since there is now an
> SVCB record in addition to the NS record. If the SVCB information is
> tied to the nameserver name, then it needs to be saved only once per
> name server or name server set.
>

Yes, I would it expect it to use it for this request but not cache it.



> * Use of DNSSEC vs WebPKI for authentication.
> No opinion on this matter - leave it to experts on this topic.
>
> Clarification question for Eric: You have mentioned elsewhere in this
> thread that you expect the protocol will allow both/either DNSSEC and
> WebPKI to be used by an operator. Is the expectation that recursive
> resolvers will support *both* mechanisms early on? Otherwise if a
> resolver supported DNSSEC authentication only while the nameserver for
> a zone supported WebPKI only, the two won't be able to communicate
> securely.
>

I think we'd need to sort this out. The minimum requirement, I think,
is to allow the SVCB record to indicate what the authoritative supports,
so you don't get downgrade. If you have that, then both sides can
vote with their feet and we can see what is most deployable.

-Ekr


> * Authenticating data from root.
> For operators willing to do it, running a local root server
> (https://www.rfc-editor.org/rfc/rfc8806.html) is a possible solution
> to this problem.
>
> -Puneet
>
> On Tue, Feb 23, 2021 at 7:21 PM Eric Rescorla  wrote:
> >
> > Hi folks,
> >
> > I wanted to point people to a new draft by Tommy Pauly, David
> > Schinazi, Chris Wood, and myself that defines a mechanism
> > for authenticated resolver<->authoritative communication.
> >
> > At a high level, the design is to use SVCB to indicate that
> > a given server supports ADo[THQ]. The expectation is that
> > the SVCB record would be supplied in additional_data along
> > with the NS records, allowing you to bootstrap to encrypted
> > transport without incurring additional transport. More details
> > in the draft, but a few points might be worth fleshing out
> > here:
> >
> > - The basic assumption is that the transport to the parent [0]
> >   is encrypted, thus preventing attackers from substituting
> >   NS or SVCB [1].
> >
> > - The draft is agnostic on how the authorative server, and
> >   is compatible with either TLSA or WebPKI, though there
> >   are some details to be worked out if we don't mandate
> >   one or the other.
> >
> > We missed the draft deadline, so in the meantime the draft can be
> > found at:
> >
> >
> https://ekr.github.io/draft-rescorla-dprive-adox/draft-rescorla-dprive-adox.html
> >
> https://ekr.github.io/draft-rescorla-dprive-adox/draft-rescorla-dprive-adox.txt
> >
> > Comments welcome, etc.
> >
> > -Ekr
> >
> > [0] The root may be somewhat tricky here, but there are
> > some thoughts in the draft.
> > [1] For reasons laid out in the draft, if this isn't the
> > case, I'm not sure it's possible to avoid leaking the name
> > you are resolving, even with DNSSEC.
> > ___
> > dns-privacy mailing list
> > dns-privacy@ietf.org
> > https://www.ietf.org/mailman/listinfo/dns-privacy
>
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] [Ext] New draft on authenticated recursive <-> authoritative

[Eric Rescorla]

On Mon, Mar 1, 2021 at 8:32 AM Paul Wouters  wrote:

> On Mon, 1 Mar 2021, Eric Rescorla wrote:
>
> > Rephrased: TLSA might work, but given that SVCB is designed for this
> purpose,
> > my prior is to favor it.
>
> Thanks, that clarified it for me.
>
> >   > +1. I used TLSA because PaulW had proposed it and no one
> objected to the proposal, but a new purpose-built
> >   signal seems fine.
> >
> >   Note that I did not object to TLSA. I prefer it over SVCB. I don't
> think
> >   it is realistiv for any new kind of glue record to be invented and
> that
> >   seemed to have been the reason in the proposal to use SVCB? To
> serve
> >   it at the parent side of the zone cut?
> >
> > I do think serving this at the parent side of the zone cut is a good
> idea,
> > but that's not the reason for SVCB.
>
> You would need to write an RFC for the EPP extension. You would need to
> wait
> for most TLD's EPP systems to support this new record. Then you need to
> wait for Registrars to update their EPP software. Then you need to wait
> for Resellers like OpenSRS to update their software to resellers.
>

> Then you need to write an RFC on adding SVCB records to a parent zone so
> that current DNS software doesn't immediately reject it as out-of-zone
> data. Then you need to push opensource implementors. Then you need to
> push TLDs to deploy, and the big DNS appliance vendors. Then you have to
> wait for old DNS products to be updated or replaced at the enterprise.
>
> That's a 5-10 year time line. You would need an interim solution. If you
> have such a solution, there is even less incentive to get this work done.
>

This seems like something to discuss live in the session, but at a high
level,
one doesn't need universal deployment to get value here. Given the relative
concentration of both a small number of high value TLDs and large-scale
authoritative nameservers, we should be able to get *some* encryption
fairly quickly even if the long tail takes a while.


> > As has been discussed extensively, the general feeling among people who
> work with
> > the WebPKI is that pinning has turned out to be a bad idea. For this
> reason, it's
> > important to be able to have an available way to say "just use the
> WebPKI", even
> > if it's also possible to be more specific.
>
> DNS is not the web. DNSSEC already "pins" via the DS record in a
> hierarchical way with DNSKEYs. Adding another public key here is
> not that different.
>

Given the low rate of DNSSEC deployment and the high rate of
misconfiguration
(https://dl.acm.org/doi/pdf/10.1145/3131365.3131373) I don't find this
particularly
encouraging.



> Reducing the hierarchical security of DNS (with or without DNSSEC) by
> replacing it with what is defacto the LetsEncrypt Root CA seems a bad
> idea. If you plan to use this new sentinel without any kind of public
> key, then this proposal is yet another workaround to hack WwebPKI into
> somewhere where it doesn't belong or fit, and I must object.
>

Sounds like a good discussion to have in the meeting.

I'm not sure why this has to be a war between WebPKI and DNSSEC.
Our for this draft is to give the nameserver the choice of how to
authenticate,
I appreciate that you feel that it would be better to root the security of
ADoT
in DNSSEC, but given that we effectively have no ADoT now, ISTM that our
first priority should be to get some. If that turns out to be substantially
easier to deploy with WebPKI, then that's what we should do. If on the
other hand, rooting it in the DNSSEC turns out to be better, then we should
do that. Specifying a mechanism which allows people to do both will
let us find out, rather than letting the best be the enemy of the good.

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

Re: [dns-privacy] [Ext] New draft on authenticated recursive <-> authoritative

[Eric Rescorla]

On Mon, Mar 1, 2021 at 7:47 AM Paul Wouters  wrote:

> On Mon, 1 Mar 2021, Paul Hoffman wrote:
>
> > On Mar 1, 2021, at 5:36 AM, Eric Rescorla  wrote:
> >> I don't necessarily object to having this be TLSA, but given that we
> are standardizing
> >> a record whose precise purpose is to signal what services are available
> at a given
> >> location, it seems to me natural to use that.
>
> I can't fully parse the sentence.
>

Rephrased: TLSA might work, but given that SVCB is designed for this
purpose,
my prior is to favor it.


> > +1. I used TLSA because PaulW had proposed it and no one objected to the
> proposal, but a new purpose-built signal seems fine.
>
> Note that I did not object to TLSA. I prefer it over SVCB. I don't think
> it is realistiv for any new kind of glue record to be invented and that
> seemed to have been the reason in the proposal to use SVCB? To serve
> it at the parent side of the zone cut?
>

I do think serving this at the parent side of the zone cut is a good idea,
but that's not the reason for SVCB.


> Another reason for SVCB was that you can define the transports in one
> place, instead of having them _prefix'ed at different places for TLSA.
> And as a method to specify DoH. I don't think these are an issue because
> DoH is a bad fit for this solution anyway as previously discussed.


I don't necessarily agree that DoH is a bad fit. I just don't see any point
in arguing
about it, because I think SVCB is better for other reasons.


> Having said that, I'm a bit hesitant if that new signal also recreates
> TLSA semantics for the public key, given how hard it was for the DANE WG to
> settle on those, but maybe it won't be so rough this time (or maybe we can
> use TLSA for the public key info).
>
> If the DNSSEC PKI is used, I think the semantics for Usage and Selector
> are obvious. In the case of WebPKI, it can be as weak as people want? Eg
> putting a TLSA record there for the LetsEncrypt CA. I wouldn't limit it
> to enforce it to be the Selector for SBKI.
>

As has been discussed extensively, the general feeling among people who
work with
the WebPKI is that pinning has turned out to be a bad idea. For this
reason, it's
important to be able to have an available way to say "just use the WebPKI",
even
if it's also possible to be more specific.

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

Re: [dns-privacy] [Ext] New draft on authenticated recursive <-> authoritative

[Eric Rescorla]

On Sun, Feb 28, 2021 at 7:09 PM Paul Wouters  wrote:

> On Thu, 25 Feb 2021, Eric Rescorla wrote:
>
> > There are (at least) three reasons:
> > 1. Semantically, TLSA does not mean "I support TLS", but rather "if you
> are to do TLS, do it this way. SVCB means something
> > different.
>
> We tried hard to make it mean "You should only use TLS", but the webpki
> people freaked out and blocked the DANE WG until this compromise was
> reached. In my opinion, any client that publishes TLSA records for a
> service means that you should reach it over TLS and hard-fail. No
> one really means "you may do TLS but if insecure cleartext is your cup
> of tea, that's fine with me too".
>

ISTM that these are the precise common semantics of the Web. I.e., it's
quite common
for hosts to be reachable over both HTTP and HTTPS, with the method of
connection
being defined by the referring URL. Indeed, they're different origins and
sometimes the
servers serve different content depending on the access method. This is one
of the things
that makes it somewhat difficult to build systems like HTTPS Everywhere.

HSTS allows the host to override this, but the basic semantic of "I offer
TLS" is
not "you must reach me over TLS"


> > No, because there are existing deployments, so we can't just retcon the
> meaning.
>
> That would be the retcon of "If you can do TLS, please prefer TLS over
> insecure cleartext" instead of the original meaning "This is my TLS. It
> is secure but you are welcome to use this completely insecure
> version instead - I claim no preference"
>

I'm not quite sure what you mean by "original" meaning, but the relevant
meaning
is what's encoded in the specifications.

I don't necessarily object to having this be TLSA, but given that we are
standardizing
a record whose precise purpose is to signal what services are available at
a given
location, it seems to me natural to use that.

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

Re: [dns-privacy] [Ext] New draft on authenticated recursive <-> authoritative

[Eric Rescorla]

On Thu, Feb 25, 2021 at 1:10 PM Paul Hoffman  wrote:

> On Feb 25, 2021, at 12:44 PM, Eric Rescorla  wrote:
>
>
>
>
> On Thu, Feb 25, 2021 at 12:15 PM Paul Hoffman 
> wrote:
>
>> The idea of doing discovery in a new type of glue in the parent seems
>> interesting. For the unauthenticated use case, it potentially removes a
>> round trip, and doing so is quite valuable. If the WG likes the idea of
>> new-glue-type-in-parent, Peter and I can add it to the draft covering
>> unauthenticated ADoT to keep the two use cases in sync.
>>
>> Question: why does this draft use an SVCB record instead of a TLSA record
>> for that new glue? The only advantage I see is that SVCB can indicate the
>> DoH template, but the WG has so far not shown interest in DoH over DoT.
>
>
> There are (at least) three reasons:
> 1. Semantically, TLSA does not mean "I support TLS", but rather "if you
> are to do TLS, do it this way. SVCB means something different.
>
>
> Fair point. However, given that we get to say what a particular usage of a
> particular RRtype is, that is not fatal.
>

No, because there are existing deployments, so we can't just retcon the
meaning.


> 2. It's not clear that the certificate binding properties of TLSA are
> desirable in the glue in this case, for a number of reasons, including the
> "getting out of sync" problem that Ben Schwartz pointed out, and the
> possibility that  we will want to use WebPKI.
>
>
> OK. From the wording about authentication in the draft, I figured you
> would actually want DNS-based public keys, even with the general problem of
> TLSA and getting out of sync.
>

The document is intended to be agnostic about WebPKI versus TLSA. Can you
point out what makes you think it favors it?

In any case, it's quite different to have the TLSA records in the parent
and in the server, because the server can ensure they don't get out of sync
with itself in a way that is harder than with the parent.


> 2. SVCB does not just let you signal DoH versus DoT it also allows you to
> signal DoQ, which has obvious advantages.
>
>
> TLSA also lets you signal DoQ. If it didn't, we would have rejected it out
> of hand.
>

I think it depends what you mean by "signal". TLSA can signal the
certificate which is to be expected for a QUIC connection, but AFAICT it
has no way to indicate that the server supports QUIC, whereas with SVCB you
can do this with ALPN (h3, doq). Your draft has a TODO here, so I'm not
sure what you have in mind.



> In addition, if it becomes necessary to signal what kind of credentials
> the server has. SVCB has a natural way to add that.
>
>
> Well, you said that in your draft, but I don't see that as a possibility
> in Ben's draft. It could be added, but there is no extension mechanism
> there.
>

Huh? You just define a new SvcParamKey:
https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-svcb-https-03#section-14.3

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

Re: [dns-privacy] [Ext] New draft on authenticated recursive <-> authoritative

[Eric Rescorla]

On Thu, Feb 25, 2021 at 12:15 PM Paul Hoffman 
wrote:

> The idea of doing discovery in a new type of glue in the parent seems
> interesting. For the unauthenticated use case, it potentially removes a
> round trip, and doing so is quite valuable. If the WG likes the idea of
> new-glue-type-in-parent, Peter and I can add it to the draft covering
> unauthenticated ADoT to keep the two use cases in sync.
>
> Question: why does this draft use an SVCB record instead of a TLSA record
> for that new glue? The only advantage I see is that SVCB can indicate the
> DoH template, but the WG has so far not shown interest in DoH over DoT.


There are (at least) three reasons:
1. Semantically, TLSA does not mean "I support TLS", but rather "if you are
to do TLS, do it this way. SVCB means something different.
2. It's not clear that the certificate binding properties of TLSA are
desirable in the glue in this case, for a number of reasons, including the
"getting out of sync" problem that Ben Schwartz pointed out, and the
possibility that  we will want to use WebPKI.
2. SVCB does not just let you signal DoH versus DoT it also allows you to
signal DoQ, which has obvious advantages. In addition, if it becomes
necessary to signal what kind of credentials the server has. SVCB has a
natural way to add that.


A deeper question for the WG is the draft's elevation of unsigned records
> received in authenticated TLS as trustworthy. This WG has gone back and
> forth on this idea over the years, and I thought we ended up with no such
> elevation. If I'm wrong, or if the the WG shifts back to wanting that,
> that's great.


I don't think it's a matter of "trustworthy" or "untrustworthy", but rather
that if the referring server is untrustworthy than in many if not most
cases there will be marginal privacy benefit to establishing encrypted
transport. The reasons for this are laid out in the security considerations
(
https://ekr.github.io/draft-rescorla-dprive-adox/draft-rescorla-dprive-adox.html#name-security-considerations)
but briefly  in a great number of cases the resolver just wants to resolve
the A//CNAME for the child domain or a trivial subdomain (e.g., "www")
so (1) a malicious referring domain already has this information before it
even responds and (2) the malicious server can still lie about the unsigned
NS records, which one needs to use in order to get the signed NS records,
by which time you've again revealed the child name.

Peter and I could then make the draft that now covers just unauthenticated
> DNS actually be about opportunistic DNS (optional authentication).


I think trying to figure out what edits to make to which drafts is
premature. Let's first decide what we are trying to do and how.

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

Re: [dns-privacy] New draft on authenticated recursive <-> authoritative

[Eric Rescorla]

On Wed, Feb 24, 2021 at 7:26 AM Paul Wouters  wrote:

> On Tue, 23 Feb 2021, Eric Rescorla wrote:
>
> > I wanted to point people to a new draft by Tommy Pauly, David
> > Schinazi, Chris Wood, and myself that defines a mechanism
> > for authenticated resolver<->authoritative communication.
> >
> > At a high level, the design is to use SVCB to indicate that
> > a given server supports ADo[THQ]. The expectation is that
> > the SVCB record would be supplied in additional_data along
> > with the NS records, allowing you to bootstrap to encrypted
> > transport without incurring additional transport. More details
> > in the draft, but a few points might be worth fleshing out
> > here:
>
> >
> https://ekr.github.io/draft-rescorla-dprive-adox/draft-rescorla-dprive-adox.html
>
> The idea seems fine. I guess the advantage of SVCB over TLSA is
> that you can define the transport, which is a clear advantage
> over trying to figure out which transport to try first, or trying
> them all at once.
>
> The disadvantage of using SVCB is that, at least for DNSSEC, you
> would need to use another lookup to get the TLSA record. But that
> is mitigated when using the TLS tls-dnssec extension.
>

Right. That is my assumption.



> You talk about adding SVCB to the additional data, but in practise
> authoritative prefer small lean answers these days to avoid
> amplification attacks, so I'm not sure if this is a reasonable
> assumption of the future.


A basic assumption here is that you are doing TLS to the referring
authoritative. Otherwise things kind of fall apart for reasons laid
out in the security considerations. So in this case I would assume
that amplification is much less of an issue.



> > - The basic assumption is that the transport to the parent [0]
> >   is encrypted, thus preventing attackers from substituting
> >   NS or SVCB [1].
>
> SVCB is not served by the parent right? You mean the substitution
> would be in a second step after substituting the NS records?
>

I was assuming SVCB was served by the parent in additional_data.
But as a practical matter, substituting NS works as well.


> Although an attacker with those powers can probably more easilly
> just redirect IP that the NS records point to, so it does not need
> to sit in the middle of the connection to the parent.
>

Agreed.


> And the defense against this is of course verifying any NS record
> using the signed DS record at the parent and confirming the records at
> the child.  This costs an extra lookup but gains you security.


Does that work for this case? My reasoning was that it was too late.
For instance, you're looking up example.com and you receive
NS=ns.attacker.example.
At this point (1) the attacker knows you want example.com and (2) you then
have
to query ns.attacker.com for the signed NS records, so ns.attacker.com
learns
it (even if you didn't already know). So this is useful for concealing
whether
you want a.example.com or b.example.com, but not if the only domains anyone
wants are www.example.com and example.com, right?

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

[dns-privacy] New draft on authenticated recursive <-> authoritative

[Eric Rescorla]

Hi folks,

I wanted to point people to a new draft by Tommy Pauly, David
Schinazi, Chris Wood, and myself that defines a mechanism
for authenticated resolver<->authoritative communication.

At a high level, the design is to use SVCB to indicate that
a given server supports ADo[THQ]. The expectation is that
the SVCB record would be supplied in additional_data along
with the NS records, allowing you to bootstrap to encrypted
transport without incurring additional transport. More details
in the draft, but a few points might be worth fleshing out
here:

- The basic assumption is that the transport to the parent [0]
  is encrypted, thus preventing attackers from substituting
  NS or SVCB [1].

- The draft is agnostic on how the authorative server, and
  is compatible with either TLSA or WebPKI, though there
  are some details to be worked out if we don't mandate
  one or the other.

We missed the draft deadline, so in the meantime the draft can be
found at:

https://ekr.github.io/draft-rescorla-dprive-adox/draft-rescorla-dprive-adox.html
https://ekr.github.io/draft-rescorla-dprive-adox/draft-rescorla-dprive-adox.txt

Comments welcome, etc.

-Ekr

[0] The root may be somewhat tricky here, but there are
some thoughts in the draft.
[1] For reasons laid out in the draft, if this isn't the
case, I'm not sure it's possible to avoid leaking the name
you are resolving, even with DNSSEC.
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] Authentication in draft-ietf-dprive-opportunistic-adotq

[Eric Rescorla]

On Tue, Feb 16, 2021 at 9:01 AM Ben Schwartz  wrote:

>
>
> I think the scary part is that an authenticated TLS failure (due to
> misconfiguration, bug, overload, or rollback) results in an outage
>

Why is this scary? We have ample evidence that it's possible to run high
availability services using TLS at much larger scale than pretty much any
authoritative server.  I realize that this is outside of the experience of
some [0] DNS operators, but it's not like the knowledge isn't out there.

-Ekr

[0] Though not all. Cloudflare, for instance, runs an authoritative service.
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] Authentication in draft-ietf-dprive-opportunistic-adotq

[Eric Rescorla]

On Mon, Feb 15, 2021 at 3:23 PM Paul Wouters  wrote:

> On Mon, 15 Feb 2021, Stephen Farrell wrote:
>
> >>  - We invent some mechanism that allows you to specify in an NS record
> that
> >>  the server takes TLS (as a hacky example, "servers have to be named
> >>  .example.com").
> >
> > Wasn't exactly that proposed but shot down already (for
> > DNS, not crypto, reasons)? Maybe I'm recalling wrong. I did
> > kinda like it mind - the hackiness appeals a bit to me:-)
>
> I think it was shot for many reasons. One of them being that a signal
> for encrypted transport is not a per-domain property but a per-ns
> property.
>

I agree that in principle this is true, but ISTM that one could make the
same argument about Web servers, but as a practical matter we've
gotten pretty far with the reference containing the security indicator.
In any case, one could imagine using some HSTS-like mechanism
once you have connected, right?




> Here is a different sentinel:
>
> _53._dns.ns0.example.com. IN TLSA x y z 
>
> Then do (D)TLS
>
> Now you can choose:
>
> 1) Use DNS(SEC) for validation
> 2) Use WebPKI[*] for validation
> 3) TOFU
> 4) Take at face value
>
> Of course, this runs into issues we talked about before. Revealing a
> query for ns0.nohats.ca already loses privacy unless you are centralized
> at godaddy. But even if you didn't leak anything, doing encrypted "stuff"
> to the IP of ns0.nohats.ca itself already gives all of that away too.
>

Right. This seems like an inherent property, no? I.e., if an authoritative
only serves example.com, then encryption doesn't help much here.
The thing to avoid seems to be where ns.atlanta.example,
ns.biloxi.example, and ns.charlottesville.example all point to the same
server.

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

Re: [dns-privacy] Authentication in draft-ietf-dprive-opportunistic-adotq

[Eric Rescorla]

On Mon, Feb 15, 2021 at 3:15 PM Stephen Farrell 
wrote:

>
>
> On 15/02/2021 23:05, Eric Rescorla wrote:
> > Sure, I can believe that. I'm not any kind of DNS expert, but it's hard
> to
> > believe we can't invent*some*  signal that you use to ask whoever served
> > you the NS records.
>
> Yep. I think someone had a presentation a while back about
> how all the approaches considered so far were dead ends or
> impractical and why.
>

If someone could point me at that, I would be appreciative.

-Ekr


> So it may be that a new RRTYPE is needed, in which case, I
> gotta ask why that has a better chance than DNSSEC+DANE, as
> those seem similarly challenging to me.
>
> Of course, if there were something that strongly motivated
> DNS actors (registrars, TLDs, server operators) that'd be
> different but I don't think I've heard of anything that's
> attractive like that and that meets this requirement. (So
> there's no equivalent of the HTTPS RRTYPE here that's been
> suggested so far and that appeals to almost all actors.)
>
> Cheers,
> S.
>
>
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] [Ext] Authentication in draft-ietf-dprive-opportunistic-adotq

[Eric Rescorla]

On Mon, Feb 15, 2021 at 2:59 PM Paul Hoffman  wrote:

> On Feb 15, 2021, at 2:49 PM, Eric Rescorla  wrote:
> > The reason we have WGs is to work out such matters in detail, no? And in
> particular, I think the WG should try to figure out the problem space
> before designing.
>
> Yes, please.
>
> > However, it seems like there's a relatively obvious strawman proposal
> here:
> >
> > - We invent some mechanism that allows you to specify in an NS record
> that the server takes TLS (as a hacky example, "servers have to be named
> .example.com").
> > - Servers are authenticated via the WebPKI, with the name as listed
> above.
>
> That addresses just one part of the problem space, the authentication of
> the authoritative server. Another part, which people have brought up a few
> times, is discovery (which is part of the first of those proposals, but not
> the second).


Yes, I agree there are two problems. This is one proposal in two pieces,
one for each problem.


Yet another is how a client of the resolver would determine if a lookup
> error means "the name doesn't exist" or "the name exists but the resolver
> was not able to get an authenticated answer".
>

I agree this has to be solved somehow, but I'm not really following why
it's that complicated. I'm not any kind of DNS expert, but I assume we can
invent a suitable error (SERVFAIL + extended error perhaps?).


> I'm sure there are plenty of things that people won't like about this
> (e.g., I imagine that some people would like to use DNSSEC), and the signal
> I just invented is gross. Maybe in the process of deciding what people
> don't like about this, we can understand the problem space better.
>
> The biggest one: which group of Internet users would want to use a
> resolver that will refuse to give useful answers if the answers aren't
> authenticated? Without understanding those users (as compared to a few
> people who would want to set up such a resolver), we can't evaluate such a
> design.
>

I'm not sure I follow. There are two situations here:

1. The server ostensibly offers DoX but I couldn't connect.
2. The server doesn't offer DoX at all.

In case (2) I would expect the resolver to proceed as normal. I.e., you
would get an answer. In case (1) I would expect it to return an error (see
above). I'm not aware of any particular reason to expect that users would
find these behaviors objectionable. After all, we already had a transition
in which the recursives decided to DNSSEC enforcement and that seems to
have gone reasonably OK.

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

Re: [dns-privacy] Authentication in draft-ietf-dprive-opportunistic-adotq

[Eric Rescorla]

On Mon, Feb 15, 2021 at 3:04 PM Stephen Farrell 
wrote:

>
>
> On 15/02/2021 22:58, Eric Rescorla wrote:
> > I don't recall. My sense was that people didn't like it being WebPKI
> rather
> > than DNSSEC, but maybe there's some more fatal reason? If so, I'd
> certainly
> > appreciate a link to that shooting down.
>
> Forget, sorry. Can look tomorrow or maybe someone'll beat
> me to it - best I recall is maybe that renaming loadsa NSes
> is a non-starter, and getting that into the parent zone is
> a double non-starter. Even if you somehow did it alongside
> the current NS names for a while, load-balancing may break
> whenever a non-supporting recursive randomly lands on the
> .example.org instance.
>
> Something like that anyway IIRC.
>

Sure, I can believe that. I'm not any kind of DNS expert, but it's hard to
believe we can't invent *some* signal that you use to ask whoever served
you the NS records.

-Ekr


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

Re: [dns-privacy] Authentication in draft-ietf-dprive-opportunistic-adotq

[Eric Rescorla]

On Mon, Feb 15, 2021 at 2:57 PM Stephen Farrell 
wrote:

>
> Hiya,
>
> On 15/02/2021 22:49, Eric Rescorla wrote:
> > On Mon, Feb 15, 2021 at 2:37 PM Stephen Farrell <
> stephen.farr...@cs.tcd.ie>
> > wrote:
> >
> >>
> >> Hiya,
> >>
> >> On 15/02/2021 22:31, Eric Rescorla wrote:
> >>> This doesn't sound like a very good idea to me. IMO we should only
> >> specify
> >>> a protocol that authenticates the server.
> >>
> >> Fair enough that that's your preference. How's that gonna
> >> work and be deployable though?
> >>
> >
> > The reason we have WGs is to work out such matters in detail, no? And in
> > particular, I think the WG should try to figure out the problem space
> > before designing.
> >
> > However, it seems like there's a relatively obvious strawman proposal
> here:
> >
> > - We invent some mechanism that allows you to specify in an NS record
> that
> > the server takes TLS (as a hacky example, "servers have to be named
> > .example.com").
>
> Wasn't exactly that proposed but shot down already (for
> DNS, not crypto, reasons)? Maybe I'm recalling wrong. I did
> kinda like it mind - the hackiness appeals a bit to me:-)
>

I don't recall. My sense was that people didn't like it being WebPKI rather
than DNSSEC, but maybe there's some more fatal reason? If so, I'd certainly
appreciate a link to that shooting down.

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

Re: [dns-privacy] [Ext] Authentication in draft-ietf-dprive-opportunistic-adotq

[Eric Rescorla]

On Mon, Feb 15, 2021 at 2:36 PM Paul Hoffman  wrote:

> On Feb 15, 2021, at 2:31 PM, Eric Rescorla  wrote:
> > The reason is straightforward: if you do not provide authentication for
> the server, then you do not have confidentiality in the face of an active
> attacker. I'm pretty sure I've said this before, so I'm surprised at the
> claim that "no one has given a reason"
>
> You have indeed said it before, and it is indeed essential if having
> confidentiality in the face of an active attacker is required. The draft
> has always said that is not a requirement.
>

Which is one of the reasons I disagree with the draft. However, that's very
different from "no one has given a reason".

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

Re: [dns-privacy] Authentication in draft-ietf-dprive-opportunistic-adotq

[Eric Rescorla]

On Mon, Feb 15, 2021 at 2:37 PM Stephen Farrell 
wrote:

>
> Hiya,
>
> On 15/02/2021 22:31, Eric Rescorla wrote:
> > This doesn't sound like a very good idea to me. IMO we should only
> specify
> > a protocol that authenticates the server.
>
> Fair enough that that's your preference. How's that gonna
> work and be deployable though?
>

The reason we have WGs is to work out such matters in detail, no? And in
particular, I think the WG should try to figure out the problem space
before designing.

However, it seems like there's a relatively obvious strawman proposal here:

- We invent some mechanism that allows you to specify in an NS record that
the server takes TLS (as a hacky example, "servers have to be named
.example.com").
- Servers are authenticated via the WebPKI, with the name as listed above.

I'm sure there are plenty of things that people won't like about this
(e.g., I imagine that some people would like to use DNSSEC), and the signal
I just invented is gross. Maybe in the process of deciding what people
don't like about this, we can understand the problem space better.

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

Re: [dns-privacy] Authentication in draft-ietf-dprive-opportunistic-adotq

[Eric Rescorla]

On Mon, Feb 15, 2021 at 2:25 PM Paul Hoffman  wrote:

> Greetings again. One of the issues that seems to most bother people who
> don't like the idea of opportunistic ADoT(Q) is the handwaviness of "but
> authenticate if you can". That comes from RFC 7435, which is the
> informational RFC that defines opportunistic security (OS). To quote from
> section 1.2 of that document:
>To achieve widespread adoption, OS must support incremental
>deployment.  Incremental deployment implies that security
>capabilities will vary from peer to peer, perhaps for a very long
>time.  OS protocols will attempt to establish encrypted communication
>whenever both parties are capable of such, and authenticated
>communication if that is also possible.  Thus, use of an OS protocol
>may yield communication that is authenticated and encrypted,
>unauthenticated but encrypted, or cleartext.  This last outcome will
>occur if not all parties to a communication support encryption (or if
>an active attack makes it appear that this is the case).
>
> So far, the proposals for opportunistic ADoT(Q) in this WG have followed
> that by talking about authentication, but so far no one has given a reason
> to require authenticated transport given the presence of DNSSEC in the DNS
> protocol.


The reason is straightforward: if you do not provide authentication for the
server, then you do not have confidentiality in the face of an active
attacker. I'm pretty sure I've said this before, so I'm surprised at the
claim that "no one has given a reason"


I propose a way forward: make the two protocols obviously different so that
> they don't affect each other. For those who want opportunistic ADoT(Q),
> change the current design so that deploying it would not make creating and
> deploying a fully-authenticated protocol more difficult; for those who want
> a fully-authenticated protocol, design it so that it does not make
> designing and deploying opportunistic ADoT(Q) more difficult.
>
> Does this sound like a good approach going forward. It gives those
> supporting fully-authenticated protocol as much time as they need to come
> up with a working protocol design, without stopping progress on the
> proposal that has already gotten a fair amount of support in the WG.
>

This doesn't sound like a very good idea to me. IMO we should only specify
a protocol that authenticates the server.

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

Re: [dns-privacy] WG Call for Adoption: draft-pp-recursive-authoritative-opportunistic

[Eric Rescorla]

I do not believe we should adopt this document.

While I think it would be useful to have a mechanism for auto-upgrading
recursive-to-authoritative resolution to TLS, and that may involve some
level of insecure discovery, the whole emphasis on opportunistic in this
draft goes in the wrong direction. The intent should be to get to the state
where you are secure from active attack as soon as possible. In particular,
I'm not aware of any valid reason why we should endorse the use of
unverifiable certificates as described in S 5.

-Ekr




On Fri, Jan 29, 2021 at 5:24 AM Brian Haberman 
wrote:

> All,
>  This starts a DPRIVE WG call for adoption for
> draft-pp-recursive-authoritative-opportunistic
> (
> https://datatracker.ietf.org/doc/draft-pp-recursive-authoritative-opportunistic/
> ).
> The focus of the call is the protocol defined in the draft. Please reply
> to the mailing list with your views on the WG adopting the document and
> your supporting arguments.
>
>  This call will end on February 12, 2021 at 11:59pm UTC.
>
> Regards,
> Brian & Tim
>
> ___
> dns-privacy mailing list
> dns-privacy@ietf.org
> https://www.ietf.org/mailman/listinfo/dns-privacy
>
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

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

[Eric Rescorla]

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.

-Ekr




>  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 zone, rather than non-authoritative glue-like records. To
> improve performance, the parent zone's nameservers could include these
> records in referrals as additional data. The resolver could
> authenticate them with DNSSEC and immediately use an encrypted
> connection to the child zone's nameservers.
>
> Although this idea would be secure and fast and compatible with the
> DNS, it is incompatible with EPP, so it is not realistically
> deployable.
>
>
> ## New DS record algorithm?
>
> The basic idea is to introduce a special DNSSEC algorithm number that
> can be used in DS records to indicate support for encryption. This
> runs into a number of problems, ultimately because it's 

Re: [dns-privacy] [Ext] Requirements for authoritative server preferences

[Eric Rescorla]

On Wed, Nov 4, 2020 at 9:41 AM Paul Hoffman  wrote:

> On Nov 4, 2020, at 9:18 AM, Eric Rescorla  wrote:
> > On Wed, Nov 4, 2020 at 7:11 AM Paul Hoffman 
> wrote:
> >> The prevention of downgrade attacks is not needed for the use case that
> has been described so far (opportunistic encryption). It is only needed for
> the use case that has not been described (failed DNS resolution when
> authentication is not possible).
> >>
> > What do you mean by "has been described"? You basically just described
> both of these.
>
> Only basically. So far on the list, only part of the mechanism (do
> authentication) has been described. The rest of the mechanism (what to do
> when authentication for the first server tried fails)


Sure, one would need to define the mechanism.


and the use case (why you would want to fail DNS resolution) has not.
>

It's not that one wants to fail DNS resolution but rather that one does not
want to send one's query in the clear. I'm not sure what more needs to be
said there.

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

Re: [dns-privacy] [Ext] Requirements for authoritative server preferences

[Eric Rescorla]

On Wed, Nov 4, 2020 at 7:11 AM Paul Hoffman  wrote:

> The prevention of downgrade attacks is not needed for the use case that
> has been described so far (opportunistic encryption). It is only needed for
> the use case that has not been described (failed DNS resolution when
> authentication is not possible).
>

What do you mean by "has been described"? You basically just described both
of these.

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

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

[Eric Rescorla]

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

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


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


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

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



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

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

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

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

[Eric Rescorla]

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

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

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

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

Re: [dns-privacy] [Ext] Fwd: Opportunistic encryption between recursive and authoritative servers

[Eric Rescorla]

I think I largely agree with Paul Wouters here.

>From my perspective, in order to enable non-opportunistic
recursive-to-authoritative DNS we need two things:

1. A way to indicate that the server ought to have TLS.
2. A way to authenticate the server when you get there.

As Paul says (2) is a solved problem, either via WebPKI or TLSA
records.

(2) seems slightly more difficult, and I defer to DNS experts, but
I've seen a number of proposals here ranging from the principled to
the unprincipled (naming the server ns-i-speak-tls.example.com), so I
imagine the problem is soluble.

If you use TLSA records, you obviously need DNSSEC validation, but
that doesn't seem like that big a deal if you're already running a DNS
recursive.

If you use WebPKI, DNSSEC *does* help here in that it prevents whoever
served you the NS records for the authoritative from lying to you, but
it's not essential. For instance, if you do TLS to the authoritative
for .com and it refers you to ns-i-speak-tls.example.com, then an
on-path attacker cannot force you to not speak TLS, so this is a strict
improvement.

I don't deny that opportunistic TLS is of *some* benefit, but given
that non-opportunist is much stronger and doesn't seem much harder,
I don't think we should proceed with it. I especially do not think
that we should proceed with a version where both discovery of TLS
support *and* authenticating the server are optional. If we somehow
find that TLS discovery is difficult, then the right thing to do
is something HSTS-like, where the server has to have a valid cert
(or TLSA) but the client may discover that TLS is required through
an insecure path.

-Ekr

On Sat, Sep 12, 2020 at 9:34 AM Paul Hoffman  wrote:

> On Sep 12, 2020, at 6:19 AM, James  wrote:
> >
> > 1. The absence of protocol agility bothers me - whilst I do not think
> the use case described in this document lends to DoH in particular being
> suitable, DoQUIC and not-yet-existent protocols could also be applicable.
>
> There is nothing in the current proposal that specifies the protocol that
> the two sides use. Additional protocol discovery methods can be added; we
> just didn't have any other desired protocols at this time.
>
> > Is there any reason besides simplicity you didn't consider using the
> ALPN as identifier?
>
> Simplicity counts. :-) However, if you want to use an ALPN method, this
> document certainly does nothing to prevent that.
>
> > 2. I disagree on the points around authentication and section 2 could be
> updated to better encourage adopters to implement matching TLSA records for
> the certificate they present during the TLS handshake - with a clear
> statement that recursives are not required to query this record type before
> TLS negotiation, nor explicitly fail if it mismatches.
>
> There is no value in opportunistic encryption to use DANE or any other way
> of authenticating the TLS server. Paul Wouters has said that he does not
> support encrypting more DNS traffic using opportunistic encryption, but so
> far has not written up his use case for regular (authenticated) encryption
> where some DNS lookups would be blocked due to inability to authenticate.
> Maybe you could write up such a use case and send it to this WG so they can
> compare use cases?
>
> --Paul Hoffman___
> dns-privacy mailing list
> dns-privacy@ietf.org
> https://www.ietf.org/mailman/listinfo/dns-privacy
>
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

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

[Eric Rescorla]

On Thu, May 28, 2020 at 11:28 AM Paul Wouters  wrote:

> Where would we gain much by using RFC 7901 Query Chains or
> tls-dnssec-chain?
>

FWIW, I have no opinion on this. I was just trying to help move the process
piece along.

-Ekr



Paul
>
> > On Thu, May 28, 2020 at 9:44 AM Shumon Huque  wrote:
> >   On Thu, May 28, 2020 at 5:33 AM Stephen Farrell <
> stephen.farr...@cs.tcd.ie> wrote:
> >
> >   On 28/05/2020 02:55, Paul Wouters wrote:
> >   > But we are unfortunately waiting on the ISE :/
> >
> >   I hope not for too long, given the TLS WG more
> >   or less sent this to the ISE.
> >
> >
> > I haven't read the draft that is the original topic of this thread yet,
> but a quick comment on the tls-dnssec-chain draft.
> > It was submitted to the ISE on December 17th, and acknowledged as
> received and processing a month later. No updates since
> > then. I'll ping the ISE to see what the current status is.
> >
> > Shumon.
> >
> > ___
> > dns-privacy mailing list
> > dns-privacy@ietf.org
> > https://www.ietf.org/mailman/listinfo/dns-privacy
> >
> >
> >
>
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

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

[Eric Rescorla]

If you want to use tls-dnssec-chain, there's no reason you have to wait for
the ISE. The code points can be assigned today based on the existence of
the draft.

On Thu, May 28, 2020 at 9:44 AM Shumon Huque  wrote:

> On Thu, May 28, 2020 at 5:33 AM Stephen Farrell 
> wrote:
>
>>
>> On 28/05/2020 02:55, Paul Wouters wrote:
>> > But we are unfortunately waiting on the ISE :/
>>
>> I hope not for too long, given the TLS WG more
>> or less sent this to the ISE.
>>
>
> I haven't read the draft that is the original topic of this thread yet,
> but a quick comment on the tls-dnssec-chain draft. It was submitted to the
> ISE on December 17th, and acknowledged as received and processing a month
> later. No updates since then. I'll ping the ISE to see what the current
> status is.
>
> Shumon.
>
> ___
> dns-privacy mailing list
> dns-privacy@ietf.org
> https://www.ietf.org/mailman/listinfo/dns-privacy
>
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

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

[Eric Rescorla]

On Mon, May 11, 2020 at 5:34 AM Sara Dickinson  wrote:

>
>
> > On 7 May 2020, at 17:41, Eric Rescorla  wrote:
> >
> > Extensively trimming:
> >
> > To be honest, this thread has gotten so long that I've lost
> > track of the various changes being proposed, so here's
> > my comments on the text as a whole.
> >
>
> To be honest, I really thought we had pretty much converged on some text
> that had consensus for this section...
>

As I said at the beginning, i think it's generally problematic, for the
reasons below, but as you insist on keeping it, I'm giving it a close read,
and in that context, this framing is problematic.


> > > "An increasing number of applications are offering
> > > application-specific encrypted DNS resolution settings, rather than
> > > defaulting to using only the system resolver.  A variety of heuristics
> > > and resolvers are available in different applications including
> > > hard-coded lists of recognized DoH/DoT servers.
> >
> > As I said earlier, I think this text is highly misleading.
> > There are at least two major loci of filtering via DNS:
> >
> > 1. In the operating system itself via the system resolver
> >or hooks into that resolver.
> >
> > 2. In the network via (a) the selected resolver or (b) on-path
> >filtering of the traffic to/from that resolver.
> >
> > There are least three major application resolution technologies that
> > render one or more of these techniques ineffective:
> >
> > 1. Using an application-level resolver which uses the system settings
> >[what Chrome currently does] bypasses (1)
> >
> > 2. Using an application-level resolver which uses DoH/DoT to the
> >system configured resolver [what Edge and Chrome are experimenting
> >with] bypasses (1) and maybe 2(b) if the network config gets out of
> >sync (i.e., you don't want your system configured resolver to do
> >DoH/DoT if you use network-level filtering, but it's easy to see
> >how this can happen if (for instance) you just offer the the user
> >the ISP resolver and they start supporting DoH/DoT
> >
> > 3. Using an application-level resolver which uses DoH/DoT to
> >an application-selected resolver [as in the Firefox TRR
> >system] bypasses all of these.
> >
> > The key point is that a lot of filtering is broken by reasons
> > that have nothing to do with encrypted transport, and so
> > this text is misleading.
>
> Somewhat confused here.. the text you quote above does not mention
> filtering at all, was added in version -04 published in January and wasn’t
> referenced at all in your first review of -04. Are you now saying you want
> this specific text reworked?
>

The problem isn't this text specifically, it's that it's used in context
for a section talking about how DoH and DoT interfere with filtering, but,
as detailed above, that's only part of the story.



> > > For users to have the ability to manage the DNS resolver settings for
> > > each individual application in a similar fashion to the OS DNS
> > > settings, each application would need to expose the default settings
> > > to the user, provide a configuration interface to change them, and
> > > support configuration of user specified resolvers.
> >
> > This seems sort of true, though of course in some systems (I don't
> > know how common this is in the world of mostly single-user computers)
> > users actually can't change the system resolver settings.
>
> We previously agreed text in section 6.1.1 that says both:
>
> “ All major OS's expose the system DNS settings and allow users to
>manually override them if desired."
>

Yes, this is true as well.

>
> “The vast majority of users do not change their default system DNS
>settings and so implicitly accept the network settings for DNS."
>

Yes, I think this is true.


Getting into user specific authorisations around this isn’t something that
> has been proposed in any comment before and I’m not sure how useful it is
> at this point?
>

Well, the issue is that this text is being used to contrast
application-specific settings to OS ones, so I'm not sure how not to get
into it.



> > > The system resolver resolution path is sometimes used to configure
> > > additional DNS controls e.g. query logging, domain based query
> > > re-direction or filtering.
> >
> > This conflates the network and in-OS filtering discussed above,
> > which I really think needs expansion.
>
> Suggest:
>
> “The system resolver resolution path is sometimes used to co

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

[Eric Rescorla]

Extensively trimming:

To be honest, this thread has gotten so long that I've lost
track of the various changes being proposed, so here's
my comments on the text as a whole.


> "An increasing number of applications are offering
> application-specific encrypted DNS resolution settings, rather than
> defaulting to using only the system resolver.  A variety of heuristics
> and resolvers are available in different applications including
> hard-coded lists of recognized DoH/DoT servers.

As I said earlier, I think this text is highly misleading.
There are at least two major loci of filtering via DNS:

1. In the operating system itself via the system resolver
   or hooks into that resolver.

2. In the network via (a) the selected resolver or (b) on-path
   filtering of the traffic to/from that resolver.

There are least three major application resolution technologies that
render one or more of these techniques ineffective:

1. Using an application-level resolver which uses the system settings
   [what Chrome currently does] bypasses (1)

2. Using an application-level resolver which uses DoH/DoT to the
   system configured resolver [what Edge and Chrome are experimenting
   with] bypasses (1) and maybe 2(b) if the network config gets out of
   sync (i.e., you don't want your system configured resolver to do
   DoH/DoT if you use network-level filtering, but it's easy to see
   how this can happen if (for instance) you just offer the the user
   the ISP resolver and they start supporting DoH/DoT

3. Using an application-level resolver which uses DoH/DoT to
   an application-selected resolver [as in the Firefox TRR
   system] bypasses all of these.

The key point is that a lot of filtering is broken by reasons
that have nothing to do with encrypted transport, and so
this text is misleading.


> For users to have the ability to manage the DNS resolver settings for
> each individual application in a similar fashion to the OS DNS
> settings, each application would need to expose the default settings
> to the user, provide a configuration interface to change them, and
> support configuration of user specified resolvers.

This seems sort of true, though of course in some systems (I don't
know how common this is in the world of mostly single-user computers)
users actually can't change the system resolver settings.


> The system resolver resolution path is sometimes used to configure
> additional DNS controls e.g. query logging, domain based query
> re-direction or filtering.

This conflates the network and in-OS filtering discussed above,
which I really think needs expansion.


> If all of the applications used on a given device can be configured to
> use the system resolver, such controls need only be configured on the
> system resolver resolution path. However if applications offer neither
> the option to use the system resolver nor equivalent
> application-specific DNS controls then users should take note that for
> queries generated by such an application they may not be able to
>
> * directly inspect the DNS queries (e.g. if they are encrypted), or
>
> * manage them to set DNS controls across the device which are
>   consistent with the system resolver controls.

OK.


> Note that if a client device is compromised by a malicious
> application, the attacker can use application-specific DNS resolvers,
> transport and controls of its own choosing. »

This seems opaque. Why not say "then any DNS-based controls may be
ineffective."

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

Re: [dns-privacy] Call for Adoption: draft-ghedini-dprive-early-data

[Eric Rescorla]

+1

On Sat, Apr 11, 2020 at 7:24 PM Sean Turner  wrote:

> Let’s adopt this draft. I think we need to be a bit more formal than DKG’s
> email from years ago to answer the what if we did DNS and TLS 1.3 early
> data.
>
> I’ll definitely review it and provide text if need be.
>
> spt
>
> > On Apr 8, 2020, at 13:27, Tim Wicinski  wrote:
> >
> >
> > This starts a Call for Adoption for draft-ghedini-dprive-early-data
> >
> > The draft is available here:
> https://datatracker.ietf.org/doc/draft-ghedini-dprive-early-data/
> >
> > Please review this draft to see if you think it is suitable for adoption
> > by DPRIVE, and comments to the list, clearly stating your view.
> >
> > Please also indicate if you are willing to contribute text, review, etc..
> >
> > This call for adoption ends: 22 April 2020
> >
> > Thanks,
> > ___
> > dns-privacy mailing list
> > dns-privacy@ietf.org
> > https://www.ietf.org/mailman/listinfo/dns-privacy
>
> ___
> dns-privacy mailing list
> dns-privacy@ietf.org
> https://www.ietf.org/mailman/listinfo/dns-privacy
>
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

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

[Eric Rescorla]

On Thu, Apr 9, 2020 at 6:36 AM Sara Dickinson  wrote:

>
>
> On 9 Apr 2020, at 14:24, Eric Rescorla  wrote:
>
>
> 
>
>
>>> How about making the last sentence a little more specific instead:
>>>
>>> If not, then (depending on the application and transport used for DNS
>>> queries) users should take note that they may not be able to inspect the
>>> DNS queries generated by such applications, or manage them to set
>>> consistent application-level controls across the device for e.g. domain
>>> based query re-direction or filtering. “
>>>
>>
>> If the feeling is that it is really needed then I would suggest text that
>> is consistent with that used in section 3.5.2.1, for example:
>>
>> “ In addition, if a client device is compromised by a malicious
>> application, the attacker can
>>   use application-specific DNS resolvers, transport and settings of its
>> own choosing.”
>>
>
> Sort of. This seems like it still buries the lede.
>
> "Note that if a client device is compromised by a malicious application,
> the attacker can use application-specific DNS resolvers, transport and
> settings of its own choosing and thus will not be affected by these
> controls.”
>
>
> By 'these controls’ do you mean any controls that the malicious
> application appears to offer to the user? If so, then does this capture
> your point:
>
> "Note that if a client device is compromised by a malicious application,
> the attacker can use application-specific DNS resolvers, transport and
> settings of its own choosing regardless of what DNS configuration the
> malicious application may appear to offer the user (if any).”
>

No. My point is that the platform level DNS controls that you are trying to
use don't work in this case.

-Ekr


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

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

[Eric Rescorla]

On Thu, Apr 9, 2020 at 4:00 AM Sara Dickinson  wrote:

>
>
> On 7 Apr 2020, at 17:22, Eric Orth  wrote:
>
> "consistent application-level controls across the device"
>
> Right there is where followers of the misunderstanding will read this text
> incorrectly.  Browsers and other non-malicious applications allowing
> control does not guarantee consistent application control.
>
> On Tue, Apr 7, 2020 at 12:13 PM Sara Dickinson  wrote:
>
>>
>>
>> On 7 Apr 2020, at 16:47, Eric Rescorla  wrote:
>>
>>
>>
>> On Tue, Apr 7, 2020 at 8:40 AM Vittorio Bertola <
>> vittorio.bert...@open-xchange.com> wrote:
>>
>>>
>>> Il 07/04/2020 17:23 Eric Rescorla  ha scritto:
>>>
>>>
>>>
>>> On Tue, Apr 7, 2020 at 7:38 AM Sara Dickinson < s...@sinodun.com>
>>> wrote:
>>>
>>> The goal of this text is to enumerate for the end user the privacy
>>> considerations of using such an application so I propose this text:
>>>
>>> "For users to have the ability to manage the application-specific DNS
>>> settings in a similar fashion to the OS DNS settings, each application also
>>> needs to expose the default settings to the user, provide a configuration
>>> interface to change them, and support configuration of user specified
>>> resolvers.
>>>
>>> If all of the applications used on a given device also provide a setting
>>> to use the system resolver, then the device can be reverted to a single
>>> point of control for all DNS queries. If not, then (depending on the
>>> application and transport used for DNS queries) users should take note that
>>> they may not be able to inspect all their DNS queries or manage them to set
>>> device wide controls e.g. domain based query re-direction or filtering. “
>>>
>>>
>>> I don't think this addresses my concern, because "revert" implies that
>>> this is somehow the default situation, which, as I said, is not clearly the
>>> case because applications have been doing their own resolution for some
>>> time.
>>>
>>> In the interest of moving forward, i suggest you change the term
>>> "reverted" to "configured" and add at the end "Note that this does not
>>> guarantee controlling malware name resolution as it can simply ignore
>>> whatever the system resolver and any user configuration settings.."
>>>
>>> I don't understand where in the proposed text there was a reference to
>>> malware that prompted further discussion of the effectiveness of using DNS
>>> to counter it. In any case, if we think that we need to discuss this topic
>>> at that point in the draft, one should also note that there also are ways
>>> to prevent malware from reaching a different resolver, though they are less
>>> likely to work once connections are encrypted, etc. But I think that this
>>> would make reaching consensus even harder, so perhaps we could avoid doing
>>> so and just focus on suggestions related to application configuration.
>>>
>>
>> Well, I would be happy to strike this text entirely. However, the text
>> speaks of "control" and if we're going to say that, we should acknowledge
>> that the system DNS is not going to let you control malicious applications
>> because malware can just do its own resolution. As it is, I think the text
>> gives a false impression
>>
>>
>> How about making the last sentence a little more specific instead:
>>
>> If not, then (depending on the application and transport used for DNS
>> queries) users should take note that they may not be able to inspect the
>> DNS queries generated by such applications, or manage them to set
>> consistent application-level controls across the device for e.g. domain
>> based query re-direction or filtering. “
>>
>
> If the feeling is that it is really needed then I would suggest text that
> is consistent with that used in section 3.5.2.1, for example:
>
> “ In addition, if a client device is compromised by a malicious
> application, the attacker can
>   use application-specific DNS resolvers, transport and settings of its
> own choosing.”
>

Sort of. This seems like it still buries the lede.

"Note that if a client device is compromised by a malicious application,
the attacker can use application-specific DNS resolvers, transport and
settings of its own choosing and thus will not be affected by these
controls."


> Sara.
>
>
>
>> Sara.
>>
>>
>> -Ekr
>>
>> --
>>>
>>> Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
>>> vittorio.bert...@open-xchange.com
>>> Office @ Via Treviso 12, 10144 Torino, Italy
>>>
>>>
>> ___
>> dns-privacy mailing list
>> dns-privacy@ietf.org
>> https://www.ietf.org/mailman/listinfo/dns-privacy
>>
>
>
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

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

[Eric Rescorla]

On Tue, Apr 7, 2020 at 8:40 AM Vittorio Bertola <
vittorio.bert...@open-xchange.com> wrote:

>
> Il 07/04/2020 17:23 Eric Rescorla  ha scritto:
>
>
>
> On Tue, Apr 7, 2020 at 7:38 AM Sara Dickinson < s...@sinodun.com> wrote:
>
> The goal of this text is to enumerate for the end user the privacy
> considerations of using such an application so I propose this text:
>
> "For users to have the ability to manage the application-specific DNS
> settings in a similar fashion to the OS DNS settings, each application also
> needs to expose the default settings to the user, provide a configuration
> interface to change them, and support configuration of user specified
> resolvers.
>
> If all of the applications used on a given device also provide a setting
> to use the system resolver, then the device can be reverted to a single
> point of control for all DNS queries. If not, then (depending on the
> application and transport used for DNS queries) users should take note that
> they may not be able to inspect all their DNS queries or manage them to set
> device wide controls e.g. domain based query re-direction or filtering. “
>
>
> I don't think this addresses my concern, because "revert" implies that
> this is somehow the default situation, which, as I said, is not clearly the
> case because applications have been doing their own resolution for some
> time.
>
> In the interest of moving forward, i suggest you change the term
> "reverted" to "configured" and add at the end "Note that this does not
> guarantee controlling malware name resolution as it can simply ignore
> whatever the system resolver and any user configuration settings.."
>
> I don't understand where in the proposed text there was a reference to
> malware that prompted further discussion of the effectiveness of using DNS
> to counter it. In any case, if we think that we need to discuss this topic
> at that point in the draft, one should also note that there also are ways
> to prevent malware from reaching a different resolver, though they are less
> likely to work once connections are encrypted, etc. But I think that this
> would make reaching consensus even harder, so perhaps we could avoid doing
> so and just focus on suggestions related to application configuration.
>

Well, I would be happy to strike this text entirely. However, the text
speaks of "control" and if we're going to say that, we should acknowledge
that the system DNS is not going to let you control malicious applications
because malware can just do its own resolution. As it is, I think the text
gives a false impression

-Ekr

-- 
>
> Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
> vittorio.bert...@open-xchange.com
> Office @ Via Treviso 12, 10144 Torino, Italy
>
>
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

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

[Eric Rescorla]

On Tue, Apr 7, 2020 at 7:38 AM Sara Dickinson  wrote:

>
>
> Begin forwarded message:
>
> *From: *Eric Rescorla 
> *Subject: **Re: [dns-privacy] Datatracker State Update Notice:
> *
> *Date: *9 March 2020 at 15:01:09 GMT
> *To: *Sara Dickinson 
> *Cc: *Brian Dickson , "Eric Vyncke
> (evyncke)" , "dprive-cha...@ietf.org" <
> dprive-cha...@ietf.org>, "dns-privacy@ietf.org" , "
> draft-ietf-dprive-rfc7626-...@ietf.org" <
> draft-ietf-dprive-rfc7626-...@ietf.org>
>
>
>
> On Mon, Mar 9, 2020 at 3:55 AM Sara Dickinson  wrote:
>
>
> Reviewing this thread after several weeks I realised we had one final
> comment to still resolve so trimming the reponse to focus on that….
>
> 
>
>
>>>>>
>>>>> The vast majority of users do not change default application-specific
>>>>>> settings and so implicitly accept the application-specific settings for
>>>>>> DNS. As with network resolvers, these resolvers may have strong, medium, 
>>>>>> or
>>>>>> weak privacy policies depending on the application.  Privacy policies for
>>>>>> these servers may or may not be available and users need to be aware that
>>>>>> privacy guarantees will vary with each application.
>>>>>>
>>>>>> For users to have the ability to inspect and control the
>>>>>> application-specific DNS settings in a similar fashion to the OS DNS
>>>>>> settings, each application must also:
>>>>>>
>>>>>>o  expose the default settings to the user
>>>>>>
>>>>>>o  provide configuration options to manually override the default
>>>>>> settings
>>>>>>
>>>>>>o  provide configuration options to always use the system resolver"
>>>>>>
>>>>>
>>>>> This last point is wrong. The parallel here would be to use the
>>>>> *network provided* resolver, not the system resolver. I would suggest that
>>>>> you be less prescriptive about this and just say "applications will need 
>>>>> to
>>>>> provide user-visible options to configure the resolver." I would avoid
>>>>> "must" (even in lower case) because this is a statement of fact, not a
>>>>> normative one.
>>>>>
>>>>
>>>
>>>> No, system resolver is accurate. In addition to not knowing what
>>>> possible resolver is offered by DHCP, the application can't know if DHCP
>>>> (i.e. network provided) is even being used -- the system could be using a
>>>> static choice of resolver, or even other non-DNS resolution services (e.g.
>>>> NIS+).
>>>>
>>>
>>> It turns out that there are at least three options here:
>>>
>>> - Select your own resolver
>>> - Select the resolver *configured into the system* (AIUI this is what
>>> Chrome does).
>>> - Use the system resolver via the conventional API calls.
>>>
>>>
>>> Suggest:
>>>
>>> "For users to have the ability to inspect and control the
>>> application-specific DNS settings in a similar fashion to the OS DNS
>>> settings, each application also needs to:
>>>
>>>o  expose the default settings to the user
>>>
>>>o  provide configuration options to manually override the default
>>> settings so that resolution is performed via
>>>   * user specified resolvers
>>>   * the resolvers configured into the system settings
>>>   * the system resolver via conventional API calls
>>>
>>> If all such applications are updated to use the system resolver, as
>>> described in the last bullet point, the device reverts to a single point of
>>> control for all DNS queries."
>>>
>>
>> Hmm this seems unduly prescriptive. Perhaps.
>>
>> For users to have the ability to inspect and control the
>> application-specific DNS settings in a similar fashion to the OS DNS
>> settings, each application also needs to expose the default settings
>> to the users and provide a configuration interface to change them.  If
>> this interface includes a setting to use the system resolver, then the
>> device can be reverted to a single point of control for all DNS
>> queries.
>>
>>
>> I think this removes the status quo bias.
>>
>>
>> 

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

[Eric Rescorla]

These all seem to show a broadly similar pattern in which DoH/DoT are
marginally slower in fast settings. Where people have looked at slower
settings, it seems like there is some evidence that

-Ekr



On Fri, Mar 20, 2020 at 10:58 AM Brian Dickson <
brian.peter.dick...@gmail.com> wrote:

>
>
> On Fri, Mar 20, 2020 at 9:10 AM Ted Hardie  wrote:
>
>> On Fri, Mar 20, 2020 at 7:16 AM Ralf Weber  wrote:
>>
>>> Moin!
>>>
>>> If the hardware and the location of the client and server are
>>> identical it is impossible to get more throughput, better latency using
>>> DoT or DoH, then DNS over UDP/53 given two similar written servers.
>>>
>>
>> Hi Ralf,
>>
>> A trivial example in which this is not true is in the case where one or
>> more routers in the network path maintain different queues for UDP and TCP
>> traffic.  When this is the case, a robust queue for TCP and a meager one
>> for UDP can easily mean that the end-to-end performance for the client is
>> better for DoT (or DNS over TCP/53), simply because the loss on the UDP
>> path is high.  This is especially true if you measure over a flight of
>> queries (say, all the DNS queries a web page needs to resolve) and DoT
>> keeps an open session for the whole flight.  To put this another way,
>> if what you are measuring is the DNS component of page load time,  DNS
>> timeouts for the lost UDP packets  in a queue-starved path can kill the
>> performance.
>>
>> As Eric points out, we have to be careful to describe what we're
>> measuring here, and there are definitely different views of what we're
>> optimizing for.
>>
>
> What may have been overlooked and/or erroneously given too much weight, is
> the single report being used to compare performance.
> (I don't have the original report URI handy, but I'm sure many
> participants here do.)
>
> IIRC, the measurements were done exclusively from AWS locations, and
> further cherry-picked by AWS location.
>

I don't believe this is a singly report. To my knowledge there are at least
three separate measurements that have been taken here:

- The Hounsel et. al measurements which were taken from a single vantage
point.
- The measurements by B\"{o}ttger et al. published at IMC'19, which also
appear to be from a single vantage point.
- The measurements we published which were taken from a sample of Firefox
users

I believe there is also some new work using SamKnows but I don't think the
results have been published yet.

These seem to all show roughly comparable results of DoH/DoT being slightly
slower in fast settings. Both our results and Hounsels suggest that in bad
network conditions, DoH and DoT can be faster.


IMNSHO, that report would be better characterized as anecdotal rather than
> statistically representative of the real world.
>
> I'm definitely not against productive discussions, but we should get good
> data first.
>
> An example of good data, are the experiments conducted by Geoff Huston and
> George Michaelson from APNIC.
>

Certainly the type of measurements conducted by APNIC are useful, but I
don't believe that their techniques can actually measure this because they
are unable to cleanly access the DNS API via an advertisement. However, our
experimental design (sampling Fx users) offers a broadly similar type of
measurement, and, as I said above, shows that DoH is slightly -- but not
materially --slower than the system resolver up to about the 80th
percentile at which point DoH outperforms the system resolver [0].


-Ekr

[0]
https://blog.nightly.mozilla.org/2018/08/28/firefox-nightly-secure-dns-experimental-results/
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

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

[Eric Rescorla]

On Fri, Mar 20, 2020 at 7:15 AM Ralf Weber  wrote:

> Moin!
>
> On 20 Mar 2020, at 14:57, Paul Hoffman wrote:
>
> > On Mar 20, 2020, at 12:42 AM, Ralf Weber  wrote:
>


something else (mostly network latency and cache behaviour), where stuff
> is up for discussion, but for the performance case I described, which
> matters to people who have to buy and operate these servers, I don’t
> see how we can get the same bang for the buck for DoT/DoH.
>

I think this is the key point: there are multiple constituencies here and
they each have a different view of performance. As you say, server
operators are very concerned with CPU on the server [0], however,
what users are principally concerned with is end-to-end performance,
which is generally not dominated by server CPU. This seems especially
true for servers which are run by entities which already have high
performance TLS (or QUIC) serving capacity.

I think it's clear that the latter is the kind of performance that this
draft
is talking about. However, as I said initially, agreeing with Rob, I think
it would probably be easier to drop this text.

-Ekr

[0] It's worth noting that CPU performance used to be a big concern for
encrypted Web traffic, but that's become a much smaller concern due
to a variety of technical improvements.
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

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

[Eric Rescorla]

n Fri, Mar 20, 2020 at 12:43 AM Ralf Weber  wrote:

> Moin!
>
> On 20 Mar 2020, at 1:13, Rob Sayre wrote:
> >  The introduction says:
> >
> >  "DNS over QUIC (DoQ) has privacy
> >   properties similar to DNS over TLS (DoT) specified in RFC7858, and
> >   performance characteristics similar to classic DNS over UDP."
> >
> > I think you might want to drop this text on performance
> > characteristics,
> > since it seems to imply DNS over UDP has better performance
> > characteristics.
> Well DNS over UDP has better performance characteristics than DoT and
> DoH.
> That is not up for discussion. That is a fact.


It turns out that there is more than one way to measure performance.

The performance you are talking about is the performance of the server, but
the performance this document is talking about is the network performance
of the protocol when the server is not the bottleneck.


You can get way above
> a million of DNS queries using regular DNS on a vanilla box, which is
> simply impossible with DoH/DoT no matter how good you tune your test or
> box. Latency in lab tests of DNS server usually is measured in
> microseconds
> and not milliseconds.
>

Yes, but measurements in the field are what matter to users.



> > At least for DoH, some data seems to show that it vastly outperforms
> > DNS
> > over UDP after the 80th percentile of latency, while being just
> > slightly
> > slower below the 80th percentile.
> All that this shows is network latency to different service providers,
> and
> the cache implementation of those (DNS cached answers will always be
> faster
> the non cached). This has nothing to do with protocol performance.
>

Actually, it's not clear what the source of the difference is. The Princeton
study by Hounsel et al. found a similar effect in bad network conditions,
even when controlling for the server. IIRC their theory was that TCP
retransmission
was more aggressive and therefore handled loss better. In reality, it's
probably
a combination of things.

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

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

[Eric Rescorla]

As Rob says, the DoH versus DoT performance situation is complicated, and I
don't think that this text is a great summary of the situation. There are a
lot of factors to consider here (connection setup time, retransmission
algorithms, etc.) but I would not expect DoQ to have performance
characteristics much like Do53 at all.
-Ekr








On Thu, Mar 19, 2020 at 5:15 PM Rob Sayre  wrote:

> On Thu, Mar 19, 2020 at 3:53 PM Christian Huitema 
> wrote:
>
>> On 3/6/2020 7:30 AM, Paul Hoffman wrote:
>>
>> > Thank you for continuing this interesting work. However, a reader might
>> not realize that many other folks would prefer DNS/HTTPS/QUIC until the get
>> all the way to Section 3.4. Also, the title of that section seems a bit
>> unbalanced, given that the text says that people might prefer
>> DNS/HTTPS/QUIC for reasons other than hiding from firewalls.
>> >
>> > For a future version of this draft, please consider moving the
>> comparison to DNS/HTTPS/QUIC, and the discussion of not knowing which one
>> folks will prefer, up to the Introduction. That would leave Section 3.4
>> just about the stated design goal.
>>
>> Yes. I would like to end up with just a spec, and leave the discussion
>> about DoT vs DoQ vs DoH vs DoH3 to some other document...
>>
>
>  The introduction says:
>
>  "DNS over QUIC (DoQ) has privacy
>   properties similar to DNS over TLS (DoT) specified in RFC7858, and
>   performance characteristics similar to classic DNS over UDP."
>
> I think you might want to drop this text on performance characteristics,
> since it seems to imply DNS over UDP has better performance characteristics.
>
> At least for DoH, some data seems to show that it vastly outperforms DNS
> over UDP after the 80th percentile of latency, while being just slightly
> slower below the 80th percentile.
>
> Source: https://youtu.be/_ZoyxE0bLp8?t=4839 (Ekr talk at DNS-OARC).
>
> thanks,
> Rob
>
>
>
> ___
> dns-privacy mailing list
> dns-privacy@ietf.org
> https://www.ietf.org/mailman/listinfo/dns-privacy
>
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

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

[Eric Rescorla]

On Mon, Mar 9, 2020 at 2:14 PM Brian Dickson 
wrote:

>
>
> On Mon, Mar 9, 2020 at 1:14 PM Eric Rescorla  wrote:
>
>>
>> As I said, Chrome does its own name resolution and has for quite some
>> time, using the resolvers configured into the system and then sending its
>> own DNS packets. This used to be common practice in SIP softphones, but I
>> haven't worked on one in quite some time.  I'm not sure on what basis you
>> claim iOS doesn't support this, as that's not my understanding. Can you
>> provide a citation here?
>>
>
> Sure.
>
> From
> https://developer.apple.com/documentation/networkextension/dns_proxy_provider
>
> DNS proxy providers are only supported on supervised iOS devices.
>
>
> (And the latter is described here:
> https://support.apple.com/guide/apple-configurator-2/supervised-devices-apd9e4f64088/mac
>  )
>
> So basically, the ability to use third party DNS is limited to managed
> devices, corporate or education.
> The only other exception is the one done via VPN services, which is a
> different set of frameworks, IIUC.
> (That's why 1.1.1.1 is a VPN app rather than just a resolver, I believe.)
>

Ah. I think we are talking about different things:

- Yes, it seems like iOS does not officially support an app which provides
DNS services for other apps (though apparently there is an unofficial way
to do it via the VPN hooks)
- Individual apps, however, are able to do their own DNS resolution via the
obvious mechanism of sending their own UDP packets to port 53.

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

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

[Eric Rescorla]

On Mon, Mar 9, 2020 at 12:18 PM Brian Dickson 
wrote:

>
>
> On Mon, Mar 9, 2020 at 8:01 AM Eric Rescorla  wrote:
>
>>
>>
>> On Mon, Mar 9, 2020 at 3:55 AM Sara Dickinson  wrote:
>>
>>>
>>>
>>> On 6 Mar 2020, at 13:32, Eric Rescorla  wrote:
>>>
>>>
>>>
>>> On Mon, Mar 2, 2020 at 7:16 AM Sara Dickinson  wrote:
>>>
>>>>
>>>>
>>>> On 29 Feb 2020, at 02:03, Eric Rescorla  wrote:
>>>>
>>>>
>>>>
>>>> On Fri, Feb 28, 2020 at 4:50 PM Brian Dickson <
>>>> brian.peter.dick...@gmail.com> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Fri, Feb 28, 2020 at 3:15 PM Eric Rescorla  wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On Wed, Feb 26, 2020 at 6:19 AM Sara Dickinson 
>>>>>> wrote:
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 23 Jan 2020, at 13:53, Eric Rescorla  wrote:
>>>>>>>
>>>>>>> On Thu, Jan 23, 2020 at 5:08 AM Sara Dickinson 
>>>>>>> wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 20 Jan 2020, at 22:37, Eric Rescorla  wrote:
>>>>>>>
>>>>>>> Review comments attached:
>>>>>>>
>>>>>>>
>>>>>>> COMMENTS
>>>>>>>> S 3.1.
>>>>>>>> >  described above, and may not have any confidentiality
>>>>>>>> requirements.
>>>>>>>> >  However, the same is not true of a single transaction or a
>>>>>>>> sequence
>>>>>>>> >  of transactions; that transaction is not / should not be
>>>>>>>> public.  A
>>>>>>>> >  typical example from outside the DNS world is: the web site
>>>>>>>> of
>>>>>>>> >  Alcoholics Anonymous is public; the fact that you visit it
>>>>>>>> should not
>>>>>>>> >  be.
>>>>>>>>
>>>>>>>> Well, technically what you want to conceal is the origin of the
>>>>>>>> transaction or its linkage to other transactions. The existence of
>>>>>>>> the
>>>>>>>> query for that A record isn't secret.
>>>>>>>>
>>>>>>>>
>>>>>>>> Suggest:
>>>>>>>>
>>>>>>>> “that transaction (and specifically the origin of that transaction)
>>>>>>>> is not / should not be public."
>>>>>>>>
>>>>>>>
>>>>>>> The parenthetical swallows the main sentence. The accurate thing to
>>>>>>> say is:
>>>>>>>
>>>>>>> In general, the existence of a single query is not sensitive --
>>>>>>> though there may be exceptions
>>>>>>> for some very low use domains. However, the origin of a given query
>>>>>>> may leak information
>>>>>>> about specific users and the ability to link queries reveals
>>>>>>> information about individual use
>>>>>>> patterns.
>>>>>>>
>>>>>>>
>>>>>>> To fit with existing text suggest:
>>>>>>>
>>>>>>>  However, the same is not true of a single transaction or a sequence
>>>>>>>  of transactions; those transaction are not / should not be public.
>>>>>>> A single
>>>>>>>  transactions reveals both the originator of the query and the query
>>>>>>>  contents which potentially leaks sensitive information about a
>>>>>>> specific user. A
>>>>>>>  typical example from outside the DNS world is: the web site of
>>>>>>>  Alcoholics Anonymous is public; the fact that you visit it should
>>>>>>> not
>>>>>>>  be.
>>>>>>>
>>>>>>
>>>>>> I find this text a bit clumsy, but OK.
>>>>>>
>>>>>>
>>>>>> Furthermore, the ability to link queries reveals information about
>>>>>>

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

[Eric Rescorla]

On Mon, Mar 9, 2020 at 3:55 AM Sara Dickinson  wrote:

>
>
> On 6 Mar 2020, at 13:32, Eric Rescorla  wrote:
>
>
>
> On Mon, Mar 2, 2020 at 7:16 AM Sara Dickinson  wrote:
>
>>
>>
>> On 29 Feb 2020, at 02:03, Eric Rescorla  wrote:
>>
>>
>>
>> On Fri, Feb 28, 2020 at 4:50 PM Brian Dickson <
>> brian.peter.dick...@gmail.com> wrote:
>>
>>>
>>>
>>> On Fri, Feb 28, 2020 at 3:15 PM Eric Rescorla  wrote:
>>>
>>>>
>>>>
>>>> On Wed, Feb 26, 2020 at 6:19 AM Sara Dickinson 
>>>> wrote:
>>>>
>>>>>
>>>>>
>>>>> On 23 Jan 2020, at 13:53, Eric Rescorla  wrote:
>>>>>
>>>>> On Thu, Jan 23, 2020 at 5:08 AM Sara Dickinson 
>>>>> wrote:
>>>>>
>>>>>
>>>>>
>>>>> On 20 Jan 2020, at 22:37, Eric Rescorla  wrote:
>>>>>
>>>>> Review comments attached:
>>>>>
>>>>>
>>>>> COMMENTS
>>>>>> S 3.1.
>>>>>> >  described above, and may not have any confidentiality
>>>>>> requirements.
>>>>>> >  However, the same is not true of a single transaction or a
>>>>>> sequence
>>>>>> >  of transactions; that transaction is not / should not be
>>>>>> public.  A
>>>>>> >  typical example from outside the DNS world is: the web site of
>>>>>> >  Alcoholics Anonymous is public; the fact that you visit it
>>>>>> should not
>>>>>> >  be.
>>>>>>
>>>>>> Well, technically what you want to conceal is the origin of the
>>>>>> transaction or its linkage to other transactions. The existence of the
>>>>>> query for that A record isn't secret.
>>>>>>
>>>>>>
>>>>>> Suggest:
>>>>>>
>>>>>> “that transaction (and specifically the origin of that transaction)
>>>>>> is not / should not be public."
>>>>>>
>>>>>
>>>>> The parenthetical swallows the main sentence. The accurate thing to
>>>>> say is:
>>>>>
>>>>> In general, the existence of a single query is not sensitive -- though
>>>>> there may be exceptions
>>>>> for some very low use domains. However, the origin of a given query
>>>>> may leak information
>>>>> about specific users and the ability to link queries reveals
>>>>> information about individual use
>>>>> patterns.
>>>>>
>>>>>
>>>>> To fit with existing text suggest:
>>>>>
>>>>>  However, the same is not true of a single transaction or a sequence
>>>>>  of transactions; those transaction are not / should not be public. A
>>>>> single
>>>>>  transactions reveals both the originator of the query and the query
>>>>>  contents which potentially leaks sensitive information about a
>>>>> specific user. A
>>>>>  typical example from outside the DNS world is: the web site of
>>>>>  Alcoholics Anonymous is public; the fact that you visit it should not
>>>>>  be.
>>>>>
>>>>
>>>> I find this text a bit clumsy, but OK.
>>>>
>>>>
>>>> Furthermore, the ability to link queries reveals information about
>>>>> individual use patterns.
>>>>>
>>>>
>>>> The key thing is "link queries as being from the same user”
>>>>
>>>
>> OK - will include that.
>>
>>
>>
>>>>
>>>>> 
>>>>>
>>>>>
>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> S 3.4.2.
>>>>>> >  services available.  Given this, the choice of a user to
>>>>>> configure a
>>>>>> >  single resolver (or a fixed set of resolvers) and an encrypted
>>>>>> >  transport to use in all network environments can actually
>>>>>> serve to
>>>>>> >  identify the user as one that desires privacy and can provide
>>>>>> an
>>>>>> >  added mechanism to tra

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

[Eric Rescorla]

On Mon, Mar 2, 2020 at 7:16 AM Sara Dickinson  wrote:

>
>
> On 29 Feb 2020, at 02:03, Eric Rescorla  wrote:
>
>
>
> On Fri, Feb 28, 2020 at 4:50 PM Brian Dickson <
> brian.peter.dick...@gmail.com> wrote:
>
>>
>>
>> On Fri, Feb 28, 2020 at 3:15 PM Eric Rescorla  wrote:
>>
>>>
>>>
>>> On Wed, Feb 26, 2020 at 6:19 AM Sara Dickinson  wrote:
>>>
>>>>
>>>>
>>>> On 23 Jan 2020, at 13:53, Eric Rescorla  wrote:
>>>>
>>>> On Thu, Jan 23, 2020 at 5:08 AM Sara Dickinson 
>>>> wrote:
>>>>
>>>>
>>>>
>>>> On 20 Jan 2020, at 22:37, Eric Rescorla  wrote:
>>>>
>>>> Review comments attached:
>>>>
>>>>
>>>> COMMENTS
>>>>> S 3.1.
>>>>> >  described above, and may not have any confidentiality
>>>>> requirements.
>>>>> >  However, the same is not true of a single transaction or a
>>>>> sequence
>>>>> >  of transactions; that transaction is not / should not be
>>>>> public.  A
>>>>> >  typical example from outside the DNS world is: the web site of
>>>>> >  Alcoholics Anonymous is public; the fact that you visit it
>>>>> should not
>>>>> >  be.
>>>>>
>>>>> Well, technically what you want to conceal is the origin of the
>>>>> transaction or its linkage to other transactions. The existence of the
>>>>> query for that A record isn't secret.
>>>>>
>>>>>
>>>>> Suggest:
>>>>>
>>>>> “that transaction (and specifically the origin of that transaction) is
>>>>> not / should not be public."
>>>>>
>>>>
>>>> The parenthetical swallows the main sentence. The accurate thing to say
>>>> is:
>>>>
>>>> In general, the existence of a single query is not sensitive -- though
>>>> there may be exceptions
>>>> for some very low use domains. However, the origin of a given query may
>>>> leak information
>>>> about specific users and the ability to link queries reveals
>>>> information about individual use
>>>> patterns.
>>>>
>>>>
>>>> To fit with existing text suggest:
>>>>
>>>>  However, the same is not true of a single transaction or a sequence
>>>>  of transactions; those transaction are not / should not be public. A
>>>> single
>>>>  transactions reveals both the originator of the query and the query
>>>>  contents which potentially leaks sensitive information about a
>>>> specific user. A
>>>>  typical example from outside the DNS world is: the web site of
>>>>  Alcoholics Anonymous is public; the fact that you visit it should not
>>>>  be.
>>>>
>>>
>>> I find this text a bit clumsy, but OK.
>>>
>>>
>>> Furthermore, the ability to link queries reveals information about
>>>> individual use patterns.
>>>>
>>>
>>> The key thing is "link queries as being from the same user”
>>>
>>
> OK - will include that.
>
>
>
>>>
>>>> 
>>>>
>>>>
>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> S 3.4.2.
>>>>> >  services available.  Given this, the choice of a user to
>>>>> configure a
>>>>> >  single resolver (or a fixed set of resolvers) and an encrypted
>>>>> >  transport to use in all network environments can actually serve
>>>>> to
>>>>> >  identify the user as one that desires privacy and can provide an
>>>>> >  added mechanism to track them as they move across network
>>>>> >  environments.
>>>>>
>>>>> I don't understand this paragraph. It's not the choice of specific
>>>>> resolvers that leaks data, but the choice to turn on encryption, In
>>>>> fact, from an identification purpose, the more resolvers that support
>>>>> encrypted transport, the better signal this is.
>>>>>
>>>>>
>>>>> This was driven by an observation that many early adopters set up
>>>>> their own DoT server and used that from all thei

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

[Eric Rescorla]

On Fri, Feb 28, 2020 at 4:50 PM Brian Dickson 
wrote:

>
>
> On Fri, Feb 28, 2020 at 3:15 PM Eric Rescorla  wrote:
>
>>
>>
>> On Wed, Feb 26, 2020 at 6:19 AM Sara Dickinson  wrote:
>>
>>>
>>>
>>> On 23 Jan 2020, at 13:53, Eric Rescorla  wrote:
>>>
>>> On Thu, Jan 23, 2020 at 5:08 AM Sara Dickinson  wrote:
>>>
>>>
>>>
>>> On 20 Jan 2020, at 22:37, Eric Rescorla  wrote:
>>>
>>> Review comments attached:
>>>
>>>
>>> COMMENTS
>>>> S 3.1.
>>>> >  described above, and may not have any confidentiality
>>>> requirements.
>>>> >  However, the same is not true of a single transaction or a
>>>> sequence
>>>> >  of transactions; that transaction is not / should not be public..
>>>>  A
>>>> >  typical example from outside the DNS world is: the web site of
>>>> >  Alcoholics Anonymous is public; the fact that you visit it
>>>> should not
>>>> >  be.
>>>>
>>>> Well, technically what you want to conceal is the origin of the
>>>> transaction or its linkage to other transactions. The existence of the
>>>> query for that A record isn't secret.
>>>>
>>>>
>>>> Suggest:
>>>>
>>>> “that transaction (and specifically the origin of that transaction) is
>>>> not / should not be public."
>>>>
>>>
>>> The parenthetical swallows the main sentence. The accurate thing to say
>>> is:
>>>
>>> In general, the existence of a single query is not sensitive -- though
>>> there may be exceptions
>>> for some very low use domains. However, the origin of a given query may
>>> leak information
>>> about specific users and the ability to link queries reveals information
>>> about individual use
>>> patterns.
>>>
>>>
>>> To fit with existing text suggest:
>>>
>>>  However, the same is not true of a single transaction or a sequence
>>>  of transactions; those transaction are not / should not be public. A
>>> single
>>>  transactions reveals both the originator of the query and the query
>>>  contents which potentially leaks sensitive information about a specific
>>> user. A
>>>  typical example from outside the DNS world is: the web site of
>>>  Alcoholics Anonymous is public; the fact that you visit it should not
>>>  be.
>>>
>>
>> I find this text a bit clumsy, but OK.
>>
>>
>> Furthermore, the ability to link queries reveals information about
>>> individual use patterns.
>>>
>>
>> The key thing is "link queries as being from the same user"
>>
>>
>>> 
>>>
>>>
>>>
>>>>
>>>>
>>>>
>>>>
>>>> S 3.4.2.
>>>> >  services available.  Given this, the choice of a user to
>>>> configure a
>>>> >  single resolver (or a fixed set of resolvers) and an encrypted
>>>> >  transport to use in all network environments can actually serve
>>>> to
>>>> >  identify the user as one that desires privacy and can provide an
>>>> >  added mechanism to track them as they move across network
>>>> >  environments.
>>>>
>>>> I don't understand this paragraph. It's not the choice of specific
>>>> resolvers that leaks data, but the choice to turn on encryption, In
>>>> fact, from an identification purpose, the more resolvers that support
>>>> encrypted transport, the better signal this is.
>>>>
>>>>
>>>> This was driven by an observation that many early adopters set up their
>>>> own DoT server and used that from all their devices, which could act as a
>>>> way to identify that user.
>>>>
>>>
>>> 1. This seems like an edge case.
>>> 2. We already have plenty of people running their own unencrypted
>>> resolvers for other reasons.
>>>
>>>
>>> I can live with removing this text, but it does seem there is something
>>> to say about the fact configuring a single resolver for a device could
>>> differentiate a user….
>>>
>>
>> Sure, but this has nothing to do with DoH or DoT.
>>
>>
> I think the text might be clearer if the bit "as one that de

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

[Eric Rescorla]

On Wed, Feb 26, 2020 at 6:19 AM Sara Dickinson  wrote:

>
>
> On 23 Jan 2020, at 13:53, Eric Rescorla  wrote:
>
> On Thu, Jan 23, 2020 at 5:08 AM Sara Dickinson  wrote:
>
>
>
> On 20 Jan 2020, at 22:37, Eric Rescorla  wrote:
>
> Review comments attached:
>
>
> COMMENTS
>> S 3.1.
>> >  described above, and may not have any confidentiality requirements.
>> >  However, the same is not true of a single transaction or a sequence
>> >  of transactions; that transaction is not / should not be public.  A
>> >  typical example from outside the DNS world is: the web site of
>> >  Alcoholics Anonymous is public; the fact that you visit it should
>> not
>> >  be.
>>
>> Well, technically what you want to conceal is the origin of the
>> transaction or its linkage to other transactions. The existence of the
>> query for that A record isn't secret.
>>
>>
>> Suggest:
>>
>> “that transaction (and specifically the origin of that transaction) is
>> not / should not be public."
>>
>
> The parenthetical swallows the main sentence. The accurate thing to say is:
>
> In general, the existence of a single query is not sensitive -- though
> there may be exceptions
> for some very low use domains. However, the origin of a given query may
> leak information
> about specific users and the ability to link queries reveals information
> about individual use
> patterns.
>
>
> To fit with existing text suggest:
>
>  However, the same is not true of a single transaction or a sequence
>  of transactions; those transaction are not / should not be public. A
> single
>  transactions reveals both the originator of the query and the query
>  contents which potentially leaks sensitive information about a specific
> user. A
>  typical example from outside the DNS world is: the web site of
>  Alcoholics Anonymous is public; the fact that you visit it should not
>  be.
>

I find this text a bit clumsy, but OK.


Furthermore, the ability to link queries reveals information about
> individual use patterns.
>

The key thing is "link queries as being from the same user"


> 
>
>
>
>>
>>
>>
>>
>> S 3.4.2.
>> >  services available.  Given this, the choice of a user to configure
>> a
>> >  single resolver (or a fixed set of resolvers) and an encrypted
>> >  transport to use in all network environments can actually serve to
>> >  identify the user as one that desires privacy and can provide an
>> >  added mechanism to track them as they move across network
>> >  environments.
>>
>> I don't understand this paragraph. It's not the choice of specific
>> resolvers that leaks data, but the choice to turn on encryption, In
>> fact, from an identification purpose, the more resolvers that support
>> encrypted transport, the better signal this is.
>>
>>
>> This was driven by an observation that many early adopters set up their
>> own DoT server and used that from all their devices, which could act as a
>> way to identify that user.
>>
>
> 1. This seems like an edge case.
> 2. We already have plenty of people running their own unencrypted
> resolvers for other reasons.
>
>
> I can live with removing this text, but it does seem there is something to
> say about the fact configuring a single resolver for a device could
> differentiate a user….
>

Sure, but this has nothing to do with DoH or DoT.



>
>
>>
>> S 3.5.1..1.2.
>> >
>> >  o  communicate clearly the change in default to users
>> >
>> >  o  provide configuration options to change the default
>> >
>> >  o  provide configuration options to always use the system resolver
>>
>> I get that you think this is neutral, but all of this is equally true
>> about dynamic discovery via DHCP, it's just that that's the status
>> quo, so you don't notice it. In this context, this text is tendentious.
>>
>>
>> The first paragraph of section 3.5.1.1 talks about the variability of DNS
>> resolution privacy with network (assuming DHCP). I can add some text there
>> to better explain the status quo if you think it is needed. Suggest:
>>
>> “Typically joining a new network requires some form of user action (e.g
>> physically plugging in a cable or selecting a network in a OS dialogue) and
>> so a user is also implicitly choosing to use the DHCP-provided resolver via
>> this action too."
>>
>
> The user has no idea that such a DHCP res

Re: [dns-privacy] Genart last call review of draft-ietf-dprive-bcp-op-07

[Eric Rescorla]

On Mon, Feb 10, 2020 at 11:44 AM Mohit Sethi M 
wrote:

>
> On 2/10/20 9:18 PM, Eric Rescorla wrote:
>
>
>
> On Mon, Feb 10, 2020 at 8:14 AM Mohit Sethi M  40ericsson@dmarc.ietf.org> wrote:
>
>> Hi Sara,
>>
>> I understand the desire to get this done with. However, I have some
>> further comments in-line:
>> On 1/24/20 5:29 PM, Sara Dickinson wrote:
>>
>> Mohit,
>>
>> I’m out of the office next week so in order to try to move the draft
>> along I have published an -08 version which I think addresses most of your
>> comments (there were a few questions in my response below). Please let me
>> know if any are still outstanding.
>>
>> Best regards
>>
>> Sara.
>>
>> On 17 Jan 2020, at 15:33, Sara Dickinson  wrote:
>>
>>
>> On 29 Dec 2019, at 13:50, Mohit Sethi via Datatracker 
>> wrote:
>>
>> Reviewer: Mohit Sethi
>> Review result: On the Right Track
>>
>> I am the assigned Gen-ART reviewer for this draft. The General Area
>> Review Team (Gen-ART) reviews all IETF documents being processed
>> by the IESG for the IETF Chair.  Please treat these comments just
>> like any other last call comments.
>>
>> For more information, please see the FAQ at
>>
>> <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.
>>
>> Document: draft-ietf-dprive-bcp-op-07
>> Reviewer: Mohit Sethi
>> Review Date: 2019-12-29
>> IETF LC End Date: 2020-01-02
>> IESG Telechat date: Not scheduled for a telechat
>>
>> Summary:
>> This draft discusses privacy challenges for recursive DNS resolvers. It
>> then
>> describes policy and security considerations that DNS service providers
>> can use
>> for enhanced user privacy. The draft is 'On the Right Track' but not yet
>> ready.
>>
>>
>> Many thanks for the detailed review! Ben, Rob I hope theses fixes also
>> address your comments.
>>
>>
>> Major issues:
>>
>> I wonder if section 5.1.2.1/5.1.3.1
>> <https://protect2.fireeye.com/v1/url?k=91d59bed-cd5e90d7-91d5db76-86925ec6fd56-2a24500b228246a8=1=f2be251d-f590-4578-b7a9-ac8390a7396e=http%3A%2F%2F5.1.2.1%2F5.1.3.1>
>> should also talk about recommending OCSP
>> stapling (RFC 6066)? I looked at RFC 8310 and it mentions RFC 7525. Do
>> you want
>> to mention it here in section 5.1.2.1/5.1.3.1
>> <https://protect2.fireeye.com/v1/url?k=5f5ab97a-03d1b240-5f5af9e1-86925ec6fd56-8fb25ccf521d98d2=1=f2be251d-f590-4578-b7a9-ac8390a7396e=http%3A%2F%2F5.1.2.1%2F5.1.3.1>
>> ?
>>
>>
>> What exactly are you thinking of here - something that just says “Server
>> operators should also follow the best practices with regard to OCSP as
>> described in RFC7525”? If something more could you please suggest text?
>>
>> I was hoping that the text would be more precise rather than a cursory
>> reference to another RFC. You could say something along the lines: 'The TLS
>> client and server MUST use Certificate Status Requests [RFC6066] for the
>> server's certificate chain and the client MUST treat a CertificateEntry
>> (except the trust anchor) without a valid CertificateStatus extension as
>> invalid and abort the handshake with an appropriate alert.'. In the same
>> vein, I would expect that you would strongly mandate the use of TLS 1.3
>> with DoH and DNS over TLS?
>>
> Mohit: I actually don't think we should require OCSP at all. For instance,
> most browsers are moving away from it. We should require or at least
> strongly encourage revocation checking.
>
> And what is it being replaced with? i found this blog on OCSP stapling in
> firefox:
> https://blog.mozilla.org/security/2013/07/29/ocsp-stapling-in-firefox/.
> Is there an updated blog post about new techniques for revocation checking?
>

https://blog.mozilla.org/security/2020/01/21/crlite-part-3-speeding-up-secure-browsing/

-Ekr

--Mohit
>
>
> -Ekr
>
>
>
>>
>> In section 5.1.2.1, what is meant by 'authentication domain names'?
>> Later, the
>> text says 'authentication name for the service'. I guess you are implying
>> the
>> authentic domain name of the DNS resolver service that the client software
>> should verify through the common name (CN) in the certificate? Some more
>> explanation here would be beneficial.
>>
>>
>> It is defined in the terminology section of RFC8310:
>>
>> "Authentication domain name: A domain name that can be used to
>> authenticate a privacy-enabling DNS server.  Sources of authentication
>> domain names are discussed in Section 7."
>&g

Re: [dns-privacy] Genart last call review of draft-ietf-dprive-bcp-op-07

[Eric Rescorla]

On Mon, Feb 10, 2020 at 8:14 AM Mohit Sethi M  wrote:

> Hi Sara,
>
> I understand the desire to get this done with. However, I have some
> further comments in-line:
> On 1/24/20 5:29 PM, Sara Dickinson wrote:
>
> Mohit,
>
> I’m out of the office next week so in order to try to move the draft along
> I have published an -08 version which I think addresses most of your
> comments (there were a few questions in my response below). Please let me
> know if any are still outstanding.
>
> Best regards
>
> Sara.
>
> On 17 Jan 2020, at 15:33, Sara Dickinson  wrote:
>
>
> On 29 Dec 2019, at 13:50, Mohit Sethi via Datatracker 
> wrote:
>
> Reviewer: Mohit Sethi
> Review result: On the Right Track
>
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF Chair.  Please treat these comments just
> like any other last call comments.
>
> For more information, please see the FAQ at
>
> .
>
> Document: draft-ietf-dprive-bcp-op-07
> Reviewer: Mohit Sethi
> Review Date: 2019-12-29
> IETF LC End Date: 2020-01-02
> IESG Telechat date: Not scheduled for a telechat
>
> Summary:
> This draft discusses privacy challenges for recursive DNS resolvers. It
> then
> describes policy and security considerations that DNS service providers
> can use
> for enhanced user privacy. The draft is 'On the Right Track' but not yet
> ready.
>
>
> Many thanks for the detailed review! Ben, Rob I hope theses fixes also
> address your comments.
>
>
> Major issues:
>
> I wonder if section 5.1.2.1/5.1.3.1 should also talk about recommending
> OCSP
> stapling (RFC 6066)? I looked at RFC 8310 and it mentions RFC 7525. Do you
> want
> to mention it here in section 5.1.2.1/5.1.3.1?
>
>
> What exactly are you thinking of here - something that just says “Server
> operators should also follow the best practices with regard to OCSP as
> described in RFC7525”? If something more could you please suggest text?
>
> I was hoping that the text would be more precise rather than a cursory
> reference to another RFC. You could say something along the lines: 'The TLS
> client and server MUST use Certificate Status Requests [RFC6066] for the
> server's certificate chain and the client MUST treat a CertificateEntry
> (except the trust anchor) without a valid CertificateStatus extension as
> invalid and abort the handshake with an appropriate alert.'. In the same
> vein, I would expect that you would strongly mandate the use of TLS 1.3
> with DoH and DNS over TLS?
>
Mohit: I actually don't think we should require OCSP at all. For instance,
most browsers are moving away from it. We should require or at least
strongly encourage revocation checking.

-Ekr



>
> In section 5.1.2.1, what is meant by 'authentication domain names'? Later,
> the
> text says 'authentication name for the service'. I guess you are implying
> the
> authentic domain name of the DNS resolver service that the client software
> should verify through the common name (CN) in the certificate? Some more
> explanation here would be beneficial.
>
>
> It is defined in the terminology section of RFC8310:
>
> "Authentication domain name: A domain name that can be used to
> authenticate a privacy-enabling DNS server.  Sources of authentication
> domain names are discussed in Section 7."
>
> I have added a reference for RFC8310 after the first use of
> ‘authentication domain name’ and made sure every instance of
> 'authentication name' is updated to 'authentication domain name' for
> clarity.
>
> Personally, I find the phrase 'Authentication domain name' very unclear.
> From the phrase, it doesn't look like it has anything to do with DNS? On
> first reading, I interpreted it as the domain name where I should
> authenticate. Since the IESG let this through for RFC 8310, I guess we will
> have to live with this (poor) choice.
>
>
>
> In section 5.1.4, should 'DNS Roadblock avoidance' be 'DNSSEC Roadblock
> avoidance'? And please add a reference to RFC 8027 here if that is the
> case.
>
>
> Yes, good catch - will do.
>
>
> Section 5.1.7 says "discussion on the use of Bloom Filters in Appendix A"..
> It
> is pointing to the wrong appendix.
>
>
> Fixed - thanks.
>
> Also, this section talks about implementing
> traffic monitoring by the DNS service provider. I would argue that in most
> deployments, the traffic monitoring is required (and implemented) by a
> different entity. Think of a home network router that has a parental
> control.
> Or an enterprise restricting employees from visiting certain sites (to
> prevent
> insider attacks)? The impact of encryption is more serious for them and
> less so
> for a DNS service provider. What is the BCP advice for them?
>
>
> You are correct that the there are differing concerns but I don’t believe
> this document should tackle that - the audience of the document is
> specifically operators of DNS privacy services, typically 

Re: [dns-privacy] Adam Roach's No Objection on draft-ietf-dprive-bcp-op-08: (with COMMENT)

[Eric Rescorla]

On Fri, Feb 7, 2020 at 12:19 AM Brian Dickson 
wrote:

>
>
> On Thu, Feb 6, 2020 at 9:39 PM Eric Rescorla  wrote:
>
>>
>>
>> On Thu, Feb 6, 2020 at 5:14 PM Benjamin Kaduk  wrote:
>>
>>>
>>> but given that the recursive has no way of knowing what the
>>> DNS client is planning to do (and that some ~20% of web traffic does not
>>> use TLS), it's hard for me to argue that this document is making the
>>> wrong
>>> recommendation about DNSSEC validation.
>>>
>>
>> The question at hand is not about whether it ought to recommend DNSSEC
>> validation but rather whether the text around that, which implies that
>> failure to do so has a high risk of sending your sensitive *web* traffic to
>> the attacker, is accurate given the high fraction of Web traffic that is
>> protected with TLS and the likely even higher fraction of sensitive traffic
>> that is.
>>
>
> The issue around implied risk, is a longitudinal one.
>
> For sake of argument, let's assume 100.0% of web traffic is TLS protected.
> Let's also assume that of the privacy resolver operators, there is at
> least one that does not do DNSSEC.
>
> If an attacker obtains the private key for *some* certificate for a web
> site, what is the risk for the customers of the two groups of resolver
> operators?
>
> The risk for the DNSSEC validating operators' clients is zero if the web
> site is in a DNSSEC signed domain.
>
The risk for the non-DNSSEC validating operators' clients is non-zero if
> the web site is in a DNSSEC signed domain.
>

I don't think we're getting anywhere particularly useful here, so I'll
probably make this my last response unless something particularly new
emerges.

The ability of an attacker to compromise a given connection depends on (1)
the ability to intercept the wire traffic and (2) the ability to compromise
the TLS connection. A successful attack (as a general matter) requires both
of these abilities. Because there are a number of environments in which the
ability to intercept wire traffic is trivial (e.g., an open WiFi hotspot)
TLS is designed under the assumption that the attacker has ability (1), in
which case, the security rests on ability (2), which it might achieve in a
number of ways, with key compromise being one of them.

It is certainly true that defense in depth is a good thing and that
measures which strengthen the user's wire traffic against interception by
the attacker will generally increase security. However, it is neither the
case that DNSSEC validation is sufficient to guarantee this protection
(contra your statement above state above) nor that in the absence of DNSSEC
validation compromise of the user's data is a generally anticipated
consequence (as implied by the text in question). It is not sufficient
because (1) the attacker may be on-path, in which case it is irrelevant
whether the client is able to resolve the right IP address or (2) the
DNSSEC signing key is itself uncompromised [usually we just assume that
keys are secure, but given that the scenario you are positing for WebPKI
failure is key compromise, DNSSEC signing key compromise needs also to be
in scope]. It is not necessary because, as has been noted already, we
generally assume that the WebPKI provides a reasonable level of security on
its own, although, as Adam observes, nothing is perfect.

-Ekr


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

Re: [dns-privacy] Adam Roach's No Objection on draft-ietf-dprive-bcp-op-08: (with COMMENT)

[Eric Rescorla]

On Thu, Feb 6, 2020 at 5:14 PM Benjamin Kaduk  wrote:

> On Thu, Feb 06, 2020 at 12:51:21PM -0800, Eric Rescorla wrote:
> > On Thu, Feb 6, 2020 at 12:44 PM Brian Dickson <
> brian.peter.dick...@gmail.com>
> > wrote:
> >
> > >
> > >
> > > On Thu, Feb 6, 2020 at 12:08 PM Eric Rescorla  wrote:
> > >
> > >>
> > >>
> > >> On Thu, Feb 6, 2020 at 12:04 PM Brian Dickson <
> > >> brian.peter.dick...@gmail.com> wrote:
> > >>
> > >>> Top-top-top reply:
> > >>> The Internet Threat Model you are using for web client-server is
> fine.
> > >>> However, for DNS, that is the wrong threat model, for several
> reasons.
> > >>>
> > >>>- The threat for DNS cache poisoning is
> recursive-to-authoritative,
> > >>>not client-recursive(resolver)
> > >>>- The DNS path will not generally be related to the data path, and
> > >>>for any parent zone, almost certainly will be totally unrelated
> > >>>- DNS recursive-to-authoritative is UDP
> > >>>- UDP DNS does not require that the attacker be on-path
> > >>>- Compromise of DNS caches via poisoning (by potentially off-path
> > >>>attackers) leading to compromise of user data is not exaggerated.
> > >>>- The compromise risk is per-cache, as well as
> per-authority-server
> > >>>and/or per-DNS record.
> > >>>
> > >>>
> > >> First, all of these are just consequences of the 3552 "attacker
> > >> completely controls the network" threat model.
> > >>
> > >
> > > Sorry, I'm not clear on what this statement means in this context, or
> what
> > > the implication of this should be inferred as being.
> > >
> > > Are you saying:
> > >
> > >- It should be assumed (per the threat model) that any/every
> attacker
> > >completely controls every network segment everywhere?
> > >- or, that only attackers who DO control some specific network
> segment
> > >are a threat?
> > >
> > > These have vastly different implications, clearly.
> > > If the first one is the case, are you conceding the precondition, that
> > > attackers can poison DNS caches arbitrarily, by manipulating all DNS
> > > traffic? If so, that argues in favor of DNSSEC validation by the
> resolver
> > > in all cases, as that is the only way the attack can be blocked.
> > >
> > > If the second one is the case, the bullet points you quote, contradict
> > > that assertion. Specifically, that off-path attackers do not need to
> > > control any network segment (let alone all network segments), to
> > > successfully poison a DNS cache. This also argues in favor of DNSSEC
> > > validation.
> > >
> > > If you mean something else, could you explain what you mean?
> > >
> >
> > I'm saying that TLS assumes a Dolev-Yao threat model in which the
> attacker
> > is on-path between the client and the server and therefore can manipulate
> > the traffic regardless of whether the client correctly knows the server's
> > IP.
>
> TLS also punts the key-management story to be out of scope.
> We have a lot of worked examples of the Web PKI failing (and also have lots
> of people working really hard to get it to improve, which I greatly
> appreciate),


I hear this argument a lot, but those examples are orders of magnitude
lower than the fraction of domains which aren't even DNSSEC protected.



> but given that the recursive has no way of knowing what the
> DNS client is planning to do (and that some ~20% of web traffic does not
> use TLS), it's hard for me to argue that this document is making the wrong
> recommendation about DNSSEC validation.
>

The question at hand is not about whether it ought to recommend DNSSEC
validation but rather whether the text around that, which implies that
failure to do so has a high risk of sending your sensitive *web* traffic to
the attacker, is accurate given the high fraction of Web traffic that is
protected with TLS and the likely even higher fraction of sensitive traffic
that is.

-Ekr


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

Re: [dns-privacy] Adam Roach's No Objection on draft-ietf-dprive-bcp-op-08: (with COMMENT)

[Eric Rescorla]

On Thu, Feb 6, 2020 at 12:44 PM Brian Dickson 
wrote:

>
>
> On Thu, Feb 6, 2020 at 12:08 PM Eric Rescorla  wrote:
>
>>
>>
>> On Thu, Feb 6, 2020 at 12:04 PM Brian Dickson <
>> brian.peter.dick...@gmail.com> wrote:
>>
>>> Top-top-top reply:
>>> The Internet Threat Model you are using for web client-server is fine.
>>> However, for DNS, that is the wrong threat model, for several reasons.
>>>
>>>- The threat for DNS cache poisoning is recursive-to-authoritative,
>>>not client-recursive(resolver)
>>>- The DNS path will not generally be related to the data path, and
>>>for any parent zone, almost certainly will be totally unrelated
>>>- DNS recursive-to-authoritative is UDP
>>>- UDP DNS does not require that the attacker be on-path
>>>- Compromise of DNS caches via poisoning (by potentially off-path
>>>attackers) leading to compromise of user data is not exaggerated.
>>>- The compromise risk is per-cache, as well as per-authority-server
>>>and/or per-DNS record.
>>>
>>>
>> First, all of these are just consequences of the 3552 "attacker
>> completely controls the network" threat model.
>>
>
> Sorry, I'm not clear on what this statement means in this context, or what
> the implication of this should be inferred as being.
>
> Are you saying:
>
>- It should be assumed (per the threat model) that any/every attacker
>completely controls every network segment everywhere?
>- or, that only attackers who DO control some specific network segment
>are a threat?
>
> These have vastly different implications, clearly.
> If the first one is the case, are you conceding the precondition, that
> attackers can poison DNS caches arbitrarily, by manipulating all DNS
> traffic? If so, that argues in favor of DNSSEC validation by the resolver
> in all cases, as that is the only way the attack can be blocked.
>
> If the second one is the case, the bullet points you quote, contradict
> that assertion. Specifically, that off-path attackers do not need to
> control any network segment (let alone all network segments), to
> successfully poison a DNS cache. This also argues in favor of DNSSEC
> validation.
>
> If you mean something else, could you explain what you mean?
>

I'm saying that TLS assumes a Dolev-Yao threat model in which the attacker
is on-path between the client and the server and therefore can manipulate
the traffic regardless of whether the client correctly knows the server's
IP.

-Ekr





>> Second, the text in question is about the effect of attacks on DNS on the
>> Web "Users may be directed to bogus IP addresses for e.g. websites where
>> they might reveal personal information to attackers."
>>
>>
> Correct, and I don't see anything you say here refuting the concern over
> DNS cache poisoning attacks, which result in bogus IP addresses directing
> users to malicious servers, etc.
>
> If users are sent to the wrong IP address, this substantially weakens the
> argument that WebPKI is sufficient protection.
>
> Why are CLR and/or OCSP needed, if not to respond to compromised
> certificates (meaning leaked private keys)?
>
> Am I missing something about WebPKI, beyond the private key proof of
> possession model?
> (Everything else about WebPKI is about validating the requestor's
> authority and identity, but that is all orthogonal to key control.)
>
> A web server using a compromised key is only ever going to be visible to a
> (potential) victim, and never to third parties including the legitimate
> certificate holder, except incidentally to operation of the rogue server.
>
> Brian
>
>
>> -Ekr
>>
>>
>> I haven't written up the details of the more effective cache poisoning
>>> attacks, but have been sharing summary information for several years now.
>>> (The underlying issue is IP fragmentation of UDP packets. This is one of
>>> the contributing factors that the DNS Flag Day for 2020 will include
>>> recommendations/requirements to not fragment.)
>>>
>>> I'd be willing to write up those more effective attacks, including a
>>> PoC, but that won't likely happen for a few months.
>>>
>>> Brian
>>>
>>> On Thu, Feb 6, 2020 at 11:22 AM Eric Rescorla  wrote:
>>>
>>>> Thanks. I am just looking at this text, and I think it's inappropriate.
>>>> To recap something I seem to be saying a lot lately, the Internet Threat
>>>> Model assumes a Dolev-Yao-style attacker who controls the network between
>>>&g

Re: [dns-privacy] Adam Roach's No Objection on draft-ietf-dprive-bcp-op-08: (with COMMENT)

[Eric Rescorla]

On Thu, Feb 6, 2020 at 12:04 PM Brian Dickson 
wrote:

> Top-top-top reply:
> The Internet Threat Model you are using for web client-server is fine.
> However, for DNS, that is the wrong threat model, for several reasons.
>
>- The threat for DNS cache poisoning is recursive-to-authoritative,
>not client-recursive(resolver)
>- The DNS path will not generally be related to the data path, and for
>any parent zone, almost certainly will be totally unrelated
>- DNS recursive-to-authoritative is UDP
>- UDP DNS does not require that the attacker be on-path
>- Compromise of DNS caches via poisoning (by potentially off-path
>attackers) leading to compromise of user data is not exaggerated.
>- The compromise risk is per-cache, as well as per-authority-server
>and/or per-DNS record.
>
>
First, all of these are just consequences of the 3552 "attacker completely
controls the network" threat model.

Second, the text in question is about the effect of attacks on DNS on the
Web "Users may be directed to bogus IP addresses for e.g. websites where
they might reveal personal information to attackers."

-Ekr


I haven't written up the details of the more effective cache poisoning
> attacks, but have been sharing summary information for several years now.
> (The underlying issue is IP fragmentation of UDP packets. This is one of
> the contributing factors that the DNS Flag Day for 2020 will include
> recommendations/requirements to not fragment.)
>
> I'd be willing to write up those more effective attacks, including a PoC,
> but that won't likely happen for a few months.
>
> Brian
>
> On Thu, Feb 6, 2020 at 11:22 AM Eric Rescorla  wrote:
>
>> Thanks. I am just looking at this text, and I think it's inappropriate.
>> To recap something I seem to be saying a lot lately, the Internet Threat
>> Model assumes a Dolev-Yao-style attacker who controls the network between
>> the client and the server. TLS is designed to be secure in this
>> environment, and while the WebPKi is imperfect, suggesting that compromise
>> of local DNS lookups leads to compromise of user data seems exaggerated, at
>> least in the case of Web traffic.
>>
>> -Ekr
>>
>>
>> On Thu, Feb 6, 2020 at 10:22 AM Adam Roach  wrote:
>>
>>> Top-posting because I agree with the facts as you present them. I just
>>> reach a different conclusion based on these facts. To be clear, I think a
>>> belt-and-suspenders approach is generally preferable. I am merely
>>> suggesting that the "must" statement I cite may be stronger than is
>>> actually advisable given that such an approach is merely a small increment
>>> of security for protocols that are otherwise secured (e.g., HTTP, which is
>>> the example the document chooses), rather than the sole defense, as may be
>>> the case with other protocols.
>>>
>>> My top-line suggestion here is to choose a different example than HTTP.
>>>
>>> Secondary to that is a suggestion that the "must" statement really only
>>> makes sense when it is a sole counter-measure, and that a softer
>>> recommendation ("should") makes more sense otherwise.
>>>
>>> These are non-blocking comments, so I'm going to reiterate that the WG
>>> can ignore them -- I just wanted to make sure they were considered. It
>>> would be nice to hear from other folks on the topic as well.
>>>
>>> /a
>>>
>>> On 2/6/20 11:57, Brian Dickson wrote:
>>>
>>>
>>>
>>> On Thu, Feb 6, 2020 at 9:31 AM Adam Roach  wrote:
>>>
>>>> On 2/6/20 09:08, Adam Roach wrote:
>>>> >
>>>> > For the specific example chosen, it's been made pretty clear over the
>>>> > years that at least the clients for the specific service you cite
>>>> have
>>>> > no interest in incurring this additional cost. If that's the working
>>>> > group consensus, then I have no interest in over-riding it. But
>>>> > ignoring operational realities seems kind of ivory tower-ish, which
>>>> > feels like the kind of thing that undermines the general credibility
>>>> > of the rest of the document.
>>>> >
>>>>
>>>
>>> Could you please be more specific?
>>>
>>> When you say "for the specific service", do you mean DNSSEC?
>>>
>>> And do you mean the signing of DNS zones using DNSSEC, when you refer to
>>> clients of that service?
>>>
>>> Perhaps you missed my microphone comments a

Re: [dns-privacy] Adam Roach's No Objection on draft-ietf-dprive-bcp-op-08: (with COMMENT)

[Eric Rescorla]

Thanks. I am just looking at this text, and I think it's inappropriate. To
recap something I seem to be saying a lot lately, the Internet Threat Model
assumes a Dolev-Yao-style attacker who controls the network between the
client and the server. TLS is designed to be secure in this environment,
and while the WebPKi is imperfect, suggesting that compromise of local DNS
lookups leads to compromise of user data seems exaggerated, at least in the
case of Web traffic.

-Ekr


On Thu, Feb 6, 2020 at 10:22 AM Adam Roach  wrote:

> Top-posting because I agree with the facts as you present them. I just
> reach a different conclusion based on these facts. To be clear, I think a
> belt-and-suspenders approach is generally preferable. I am merely
> suggesting that the "must" statement I cite may be stronger than is
> actually advisable given that such an approach is merely a small increment
> of security for protocols that are otherwise secured (e.g., HTTP, which is
> the example the document chooses), rather than the sole defense, as may be
> the case with other protocols.
>
> My top-line suggestion here is to choose a different example than HTTP.
>
> Secondary to that is a suggestion that the "must" statement really only
> makes sense when it is a sole counter-measure, and that a softer
> recommendation ("should") makes more sense otherwise.
>
> These are non-blocking comments, so I'm going to reiterate that the WG can
> ignore them -- I just wanted to make sure they were considered. It would be
> nice to hear from other folks on the topic as well.
>
> /a
>
> On 2/6/20 11:57, Brian Dickson wrote:
>
>
>
> On Thu, Feb 6, 2020 at 9:31 AM Adam Roach  wrote:
>
>> On 2/6/20 09:08, Adam Roach wrote:
>> >
>> > For the specific example chosen, it's been made pretty clear over the
>> > years that at least the clients for the specific service you cite have
>> > no interest in incurring this additional cost. If that's the working
>> > group consensus, then I have no interest in over-riding it. But
>> > ignoring operational realities seems kind of ivory tower-ish, which
>> > feels like the kind of thing that undermines the general credibility
>> > of the rest of the document.
>> >
>>
>
> Could you please be more specific?
>
> When you say "for the specific service", do you mean DNSSEC?
>
> And do you mean the signing of DNS zones using DNSSEC, when you refer to
> clients of that service?
>
> Perhaps you missed my microphone comments at the last IETF?
>
> Specifically that GoDaddy will be turning on DNSSEC for the vast majority
> of its DNS hosting customers?
>
> This represents about 40% of the DNS zones on the Internet.
> (The exact time frame is not set in stone, but we expect this to be done
> in the first half of 2020.)
>
> Given that this significantly alters the calculus, I don't think that is a
> good enough reason to object in and of itself anymore.
>
> The other aspect of this is the asymmetry involved in the defenses against
> impersonation:
>
>- The choice to sign a DNS zone is under control of the zone owner
>- The choice to deploy RPKI on routes (to protect against BGP
>hijacking) is under control of the IP prefix holder
>- Both methods rely on third parties to cooperate to achieve the
>protections offered
>- RPKI routing filters are now widely deployed, and RPKI registrations
>are substantial
>- The remaining issue is DNSSEC validation; many (most?) of the public
>recursive operators do this already
>
> The logic should be, defend against all feasible attacks, rather than
> justifying the non-defense in one area (DNSSEC for DNS) based on the
> assertion that another area is not being defended (RPKI for BGP).
>
> Brian
>
>
>>
>> I realize that my editing made one of the pronoun antecedents here go
>> away. The second sentence should have said something more like "If
>> keeping the current text is the working group consensus..."
>>
>> /a
>>
>>
> ___
> dns-privacy mailing list
> dns-privacy@ietf.org
> https://www.ietf.org/mailman/listinfo/dns-privacy
>
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

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

[Eric Rescorla]

On Thu, Jan 23, 2020 at 5:08 AM Sara Dickinson  wrote:

>
>
> On 20 Jan 2020, at 22:37, Eric Rescorla  wrote:
>
> Review comments attached:
>
>
> COMMENTS
> S 3.1.
> >  described above, and may not have any confidentiality requirements..
> >  However, the same is not true of a single transaction or a sequence
> >  of transactions; that transaction is not / should not be public.  A
> >  typical example from outside the DNS world is: the web site of
> >  Alcoholics Anonymous is public; the fact that you visit it should
> not
> >  be.
>
> Well, technically what you want to conceal is the origin of the
> transaction or its linkage to other transactions. The existence of the
> query for that A record isn't secret.
>
>
> Suggest:
>
> “that transaction (and specifically the origin of that transaction) is not
> / should not be public."
>

The parenthetical swallows the main sentence. The accurate thing to say is:

In general, the existence of a single query is not sensitive -- though
there may be exceptions
for some very low use domains. However, the origin of a given query may
leak information
about specific users and the ability to link queries reveals information
about individual use
patterns.


>
>
>
>
> S 3.4.2.
> >  fingerprint [2] values can be used to fingerprint client OS's or
> that
> >  various techniques can be used to de-NAT DNS queries dns-de-nat [3].
> >
> >  Note that even when using encrypted transports the use of clear text
> >  transport options to decrease latency can provide correlation of a
> >  users' connections e.g.  using TCP Fast Open [RFC7413] with TLS 1.2.
>
> Why does this say TLS 1.2? Any use of TFO will have the same
> properties.
>
> Perhaps you are thinking of TLS session tickets here?
>
>
> Sorry - hangover from earlier text, will remove. The last previously
> agreed text was (in email of 31 Dec):
>
> “Note that even when using encrypted transports the use of clear text
> transport options to decrease latency can provide correlation of a users'
> connections e.g. using TCP Fast Open [RFC7413]."
>

Yes, I think that's fine.



>
>
>
>
> S 3.4.2.
> >  services available.  Given this, the choice of a user to configure a
> >  single resolver (or a fixed set of resolvers) and an encrypted
> >  transport to use in all network environments can actually serve to
> >  identify the user as one that desires privacy and can provide an
> >  added mechanism to track them as they move across network
> >  environments.
>
> I don't understand this paragraph. It's not the choice of specific
> resolvers that leaks data, but the choice to turn on encryption, In
> fact, from an identification purpose, the more resolvers that support
> encrypted transport, the better signal this is.
>
>
> This was driven by an observation that many early adopters set up their
> own DoT server and used that from all their devices, which could act as a
> way to identify that user.
>

1. This seems like an edge case.
2. We already have plenty of people running their own unencrypted resolvers
for other reasons.


>
> S 3.5.1.1.2.
> >
> >  o  communicate clearly the change in default to users
> >
> >  o  provide configuration options to change the default
> >
> >  o  provide configuration options to always use the system resolver
>
> I get that you think this is neutral, but all of this is equally true
> about dynamic discovery via DHCP, it's just that that's the status
> quo, so you don't notice it. In this context, this text is tendentious.
>
>
> The first paragraph of section 3.5.1.1 talks about the variability of DNS
> resolution privacy with network (assuming DHCP). I can add some text there
> to better explain the status quo if you think it is needed. Suggest:
>
> “Typically joining a new network requires some form of user action (e.g
> physically plugging in a cable or selecting a network in a OS dialogue) and
> so a user is also implicitly choosing to use the DHCP-provided resolver via
> this action too."
>

The user has no idea that such a DHCP resolver even exists. And you could
say the same thing about the user's choice to install an application with
its own resolver selection logic.


> I can’t think of a mobile or desktop OS that doesn’t allow users to
> override the DHCP provided DNS settings…. but I could text about that in
> section 5.1.1. if you really think it is needed?
>

This isn't about that. AFAICT most major applications also allow you to use
the system resolver choices. Rather, the issue here is the repeated
arguments in this d

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

[Eric Rescorla]

On Tue, Jan 21, 2020 at 6:46 AM Vittorio Bertola  wrote:

>
> > Il 20/01/2020 22:45 Eric Vyncke (evyncke)  ha
> scritto:
> >
> > But, as section 3.5.1 ("in the recursive resolvers") raised a lot of
> discussions during the first IETF Last Call, and as the authors reacted to
> those comments by deep changes in the text, let's have a new IETF Last Call
> before proceeding with IESG evaluation.
>
> First of all, I'd like to thank Sara for all the effort in rewriting a lot
> of text yet another time to address all the comments. I think the result is
> good, even if I would have preferred other text on certain things.
>
> There is only a minor comment that I still have on 3.5.1. The new version
> has a part about DNS centralization risks, but it only addresses the risks
> deriving from the ISP market, not the newer ones coming from
> "application-specific resolver selection", which were mentioned in -03. I
> have two alternative text proposals to cover this:
>
> 1) in the bullet list in 3.5.1.1, add another bullet:
>
> "* popular applications directing DNS traffic by default to specific
> dominant resolvers"
>
> or
>
> 2) in 3.5.1.1.2., last paragraph, just after "increase or decrease user
> privacy" and before the hyphen, add:
>
> "and promote or counter centralization"
>
> Given Eric's (not Éric's :-) ) comment on the requirements for user
> control in 3.5.1.1.2, i.e. that they also apply to the selection of
> non-encrypted resolvers today, it would be fine for me if they were
> extended to device/OS resolver configuration in general. In that case, I
> would plead for the addition of a point regarding the fact that the user
> should be enabled to configure the resolver for the OS and all the
> applications at once, in a single place.
>

I would not be in favor of this. It's squarely in the zone of controversy.

-Ekr


> I also have an editorial suggestion: to reduce the nesting of sub-sections
> in 3.5, perhaps you could break down section 3 into multiple first-level
> sections and do some renumbering, e.g.
>
> 3. -> 3.
> 3.1, 3.2, 3.3 -> 4.1, 4.2, 4.3 within "4. Risks in the DNS data"
> 3.4 -> "5. Risks on the wire"
> 3.5 -> "6. Risks in the servers"
> 3.6, 3.7 -> 7.1, 7.2 within "7. Other risks"
>
> In any case, I think that we now have a solid document and hope we can
> release it soon.
>
> --
>
> Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
> vittorio.bert...@open-xchange.com
> Office @ Via Treviso 12, 10144 Torino, Italy
>
> ___
> dns-privacy mailing list
> dns-privacy@ietf.org
> https://www.ietf.org/mailman/listinfo/dns-privacy
>
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

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

[Eric Rescorla]

+last-call

On Mon, Jan 20, 2020 at 2:37 PM Eric Rescorla  wrote:

> Review comments attached:
>
>
> COMMENTS
> S 3.1.
> >  described above, and may not have any confidentiality requirements..
> >  However, the same is not true of a single transaction or a sequence
> >  of transactions; that transaction is not / should not be public.  A
> >  typical example from outside the DNS world is: the web site of
> >  Alcoholics Anonymous is public; the fact that you visit it should
> not
> >  be.
>
> Well, technically what you want to conceal is the origin of the
> transaction or its linkage to other transactions. The existence of the
> query for that A record isn't secret.
>
>
>
>
>
> S 3.4.2.
> >  fingerprint [2] values can be used to fingerprint client OS's or
> that
> >  various techniques can be used to de-NAT DNS queries dns-de-nat [3].
> >
> >  Note that even when using encrypted transports the use of clear text
> >  transport options to decrease latency can provide correlation of a
> >  users' connections e.g.  using TCP Fast Open [RFC7413] with TLS 1.2.
>
> Why does this say TLS 1.2? Any use of TFO will have the same
> properties.
>
> Perhaps you are thinking of TLS session tickets here?
>
>
>
>
> S 3.4.2.
> >  services available.  Given this, the choice of a user to configure a
> >  single resolver (or a fixed set of resolvers) and an encrypted
> >  transport to use in all network environments can actually serve to
> >  identify the user as one that desires privacy and can provide an
> >  added mechanism to track them as they move across network
> >  environments.
>
> I don't understand this paragraph. It's not the choice of specific
> resolvers that leaks data, but the choice to turn on encryption, In
> fact, from an identification purpose, the more resolvers that support
> encrypted transport, the better signal this is.
>
>
> S 3.4.2.
> >  identify the user as one that desires privacy and can provide an
> >  added mechanism to track them as they move across network
> >  environments.
> >
> >  Implementations that support encrypted transports also commonly re-
> >  use sessions for multiple DNS queries to optimize performance (e.g..
>
> Note: session is a technical term in TLS that refers to the
> association not the connection. I would say "connection"
>
>
> S 3.5.1.1.2.
> >
> >  o  communicate clearly the change in default to users
> >
> >  o  provide configuration options to change the default
> >
> >  o  provide configuration options to always use the system resolver
>
> I get that you think this is neutral, but all of this is equally true
> about dynamic discovery via DHCP, it's just that that's the status
> quo, so you don't notice it. In this context, this text is tendentious.
>
>
> S 3.5.1.1.2.
> >
> >  Application-specific changes to default destinations for users' DNS
> >  queries might increase or decrease user privacy - it is highly
> >  dependent on the network context and the application-specific
> >  default.  This is an area of active debate and the IETF is working
> on
> >  a number of issues related to application-specific DNS settings.
>
> This, too, could be said about the current situation.
>
> On Mon, Jan 20, 2020 at 1:47 PM Eric Vyncke (evyncke) 
> wrote:
>
>> Thanks to Sara and Stéphane for the -04 revised I-D.
>>
>> After reading the -04, I think that most of the IETF Last Call comments
>> are addressed (and consensus needs to be balanced -- even for informational
>> document) and that the document sticks to facts.
>>
>> But, as section 3.5.1 ("in the recursive resolvers") raised a lot of
>> discussions during the first IETF Last Call, and as the authors reacted to
>> those comments by deep changes in the text, let's have a new IETF Last Call
>> before proceeding with IESG evaluation.
>>
>> Again, thank you to the reviewers and the authors
>>
>> Regards,
>>
>> -éric
>>
>>
>> On 20/01/2020, 22:34, "IETF Secretariat" <
>> ietf-secretariat-re...@ietf.org> wrote:
>>
>> IESG state changed:
>>
>> New State: Last Call Requested
>>
>> (The previous state was Waiting for AD Go-Ahead::AD Followup)
>>
>> The previous last call raised several points. The authors have worked
>> on those points and this new informational IETF draft has substantive
>> changes; enough to go trigger a new IETF Last Call.
>>
>> -éric
>>
>> Datatracker URL:
>> https://datatracker.ietf.org/doc/draft-ietf-dprive-rfc7626-bis/
>>
>>
>>
>> ___
>> dns-privacy mailing list
>> dns-privacy@ietf.org
>> https://www.ietf.org/mailman/listinfo/dns-privacy
>>
>
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

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

[Eric Rescorla]

Review comments attached:


COMMENTS
S 3.1.
>  described above, and may not have any confidentiality requirements.
>  However, the same is not true of a single transaction or a sequence
>  of transactions; that transaction is not / should not be public.  A
>  typical example from outside the DNS world is: the web site of
>  Alcoholics Anonymous is public; the fact that you visit it should not
>  be.

Well, technically what you want to conceal is the origin of the
transaction or its linkage to other transactions. The existence of the
query for that A record isn't secret.





S 3.4.2.
>  fingerprint [2] values can be used to fingerprint client OS's or that
>  various techniques can be used to de-NAT DNS queries dns-de-nat [3].
>
>  Note that even when using encrypted transports the use of clear text
>  transport options to decrease latency can provide correlation of a
>  users' connections e.g.  using TCP Fast Open [RFC7413] with TLS 1.2.

Why does this say TLS 1.2? Any use of TFO will have the same
properties.

Perhaps you are thinking of TLS session tickets here?




S 3.4.2.
>  services available.  Given this, the choice of a user to configure a
>  single resolver (or a fixed set of resolvers) and an encrypted
>  transport to use in all network environments can actually serve to
>  identify the user as one that desires privacy and can provide an
>  added mechanism to track them as they move across network
>  environments.

I don't understand this paragraph. It's not the choice of specific
resolvers that leaks data, but the choice to turn on encryption, In
fact, from an identification purpose, the more resolvers that support
encrypted transport, the better signal this is.


S 3.4.2.
>  identify the user as one that desires privacy and can provide an
>  added mechanism to track them as they move across network
>  environments.
>
>  Implementations that support encrypted transports also commonly re-
>  use sessions for multiple DNS queries to optimize performance (e.g.

Note: session is a technical term in TLS that refers to the
association not the connection. I would say "connection"


S 3.5.1.1.2.
>
>  o  communicate clearly the change in default to users
>
>  o  provide configuration options to change the default
>
>  o  provide configuration options to always use the system resolver

I get that you think this is neutral, but all of this is equally true
about dynamic discovery via DHCP, it's just that that's the status
quo, so you don't notice it. In this context, this text is tendentious.


S 3.5.1.1.2.
>
>  Application-specific changes to default destinations for users' DNS
>  queries might increase or decrease user privacy - it is highly
>  dependent on the network context and the application-specific
>  default.  This is an area of active debate and the IETF is working on
>  a number of issues related to application-specific DNS settings.

This, too, could be said about the current situation.

On Mon, Jan 20, 2020 at 1:47 PM Eric Vyncke (evyncke) 
wrote:

> Thanks to Sara and Stéphane for the -04 revised I-D.
>
> After reading the -04, I think that most of the IETF Last Call comments
> are addressed (and consensus needs to be balanced -- even for informational
> document) and that the document sticks to facts.
>
> But, as section 3.5.1 ("in the recursive resolvers") raised a lot of
> discussions during the first IETF Last Call, and as the authors reacted to
> those comments by deep changes in the text, let's have a new IETF Last Call
> before proceeding with IESG evaluation.
>
> Again, thank you to the reviewers and the authors
>
> Regards,
>
> -éric
>
>
> On 20/01/2020, 22:34, "IETF Secretariat" 
> wrote:
>
> IESG state changed:
>
> New State: Last Call Requested
>
> (The previous state was Waiting for AD Go-Ahead::AD Followup)
>
> The previous last call raised several points. The authors have worked
> on those points and this new informational IETF draft has substantive
> changes; enough to go trigger a new IETF Last Call.
>
> -éric
>
> Datatracker URL:
> https://datatracker.ietf.org/doc/draft-ietf-dprive-rfc7626-bis/
>
>
>
> ___
> dns-privacy mailing list
> dns-privacy@ietf.org
> https://www.ietf.org/mailman/listinfo/dns-privacy
>
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] [Last-Call] last call review of draft-ietf-dprive-rfc7626-bis-03

[Eric Rescorla]

On Fri, Jan 10, 2020 at 8:55 AM Stephane Bortzmeyer 
wrote:

> On Thu, Jan 09, 2020 at 10:29:29AM -0800,
>  Eric Rescorla  wrote
>  a message of 181 lines which said:
>
> > > It means a standards compliant DoT implementation will have no
> > > client identifiers, a standards compliant DoH implementation is
> > > free to (and likely) to include them.
> > >
> >
> > [Citation needed]
>
> I'm not sure I understand your remark. Do you mean that Sara's
> sentence should be backed up with specific references? I mean, since
> DoH is HTTP and HTTP (unlike DNS) has a lot of headers that, together,
> can identify a client, is it enough to reference HTTP RFCs to support
> the claim?
>

1. I don't really know what "client identifiers" means. If it means "things
that identify the implementation" then that isn't really correct, because
the TLS ClientHello is quite characteristic.
2. "quite likely" is just speculation and given that Firefox, at least, is
removing the User-Agent string (
https://bugzilla.mozilla.org/show_bug.cgi?id=1543201), I think the evidence
actually points in the other direction.

If it's

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

Re: [dns-privacy] [Last-Call] [Ext] Review of draft-ietf-dprive-rfc7626-bis-03

[Eric Rescorla]

On Fri, Jan 10, 2020 at 6:50 AM Paul Hoffman  wrote:

> On Jan 9, 2020, at 7:41 PM, Eric Rescorla  wrote:
> >>>> Section 3.5.1.2
> >>>>
> >>>> I admit that I don't understand the purpose of this section.
> Concentrating on minutiae, like the details of DHCP or ARP/NDP spoofing, is
> far too low level. If we were to simply assume the usual threat model
> [RFC3552], then the conclusions here are obvious: if you fail to
> authenticate the server, then you get the server that an attacker chooses..
> >>>>
> >>>> I would remove this section in favour of improving Section 3.5.1.4,
> which addresses the most pertinent question.
> >>>
> >>> RFC7626 included Section 2..5.3
> https://tools.ietf.org/html/rfc7626#section-2.5.3 ‘Rogue Servers’. This
> section is just an update of that text to improve context and remove the
> phrase ’rogue server’.  Since the majority of OS implementations still use
> these mechanisms today it seems to still be relevant.
> >>>
> >>> Well, as MT says, this is just the 3552 threat model.  The basic fact
> is that you need a reference to a server that is (1) securely obtained and
> (2) verifiable against the server itself. Absent that, you are subject to
> attack by the network.
> >>
> >> Suggest adding a sentence at the start of the section “[RFC3552]
> provides guidelines for describing Internet threat models. This section
> specialises the discussion to the case of DNS resolver configuration.”
> >>
> >> Well, that's a start, but the problem is still that it's too low level..
> If you insist on having this section, you should lay out the implications
> of the situation rather than (or at least in advance of) digging into the
> details.
> >
> > The level is detail is entirely comparible to that in the original RFC
> (much of the text is still the same).
> >
> > That doesn't seem like a particularly strong argument. We're revising
> this document and the question is what is good now.
> >
> >
> >
> > As I said to Martin, the section focusses on the impact on the DNS
> resolution path that results from the attack: diversion of traffic and
> traffic capture.. Are there other implications you think should be
> included? Please suggest text.
> >
> > I would replace the entirety of this section with:
> >
> > The Internet Threat model, as described in RFC 3552, assumes that the
> attacker controls the network. Such an attacker can completely control any
> insecure DNS resolution, both passively monitoring the queries and
> responses and substituting their own responses. Even if encrypted DNS such
> as DoH or DoT is used, unless the client has been configured in a secure
> way with the server identity, an active attacker can impersonate the
> server. This implies that opportunistic modes of DoH/DoT as well as modes
> where the client learns of the DoH/DoT server via in-network mechanisms
> such as DHCP are vulnerable to attack. In addition, if the client is
> compromised, the attacker can replace the DNS configuration with one of its
> own choosing.
>
> Given that this topic is one where there is rampant confusion, I think
> brevity and clarity are best for this document. I believe Ekr's words cover
> exactly what is needed here, and agree that the rest of the section should
> be eliminated.
>
> I aslo agree with earlier comments that this document referring to
> draft-arkko-arch-infrastructure-centralisation is a bad idea. We have no
> idea what that document will end up saying when published as an RFC.
>

Or whether it will be published as an RFC at all.

-Ekr


> --Paul Hoffman--
> last-call mailing list
> last-c...@ietf.org
> https://www.ietf.org/mailman/listinfo/last-call
>
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] Review of draft-ietf-dprive-rfc7626-bis-03 - Section 3.5.1.1 Comments

[Eric Rescorla]

On Thu, Jan 9, 2020 at 10:03 AM Sara Dickinson  wrote:

>
>
> On 7 Jan 2020, at 22:47, Eric Rescorla  wrote:
>
>
>
> On Tue, Jan 7, 2020 at 10:37 AM Sara Dickinson  wrote:
>
>>
>>
>> On 19 Dec 2019, at 02:09, Eric Rescorla  wrote:
>>
>>
>>
>> On Wed, Dec 18, 2019 at 7:06 AM Sara Dickinson  wrote:
>>
>>>
>>>
>>> > On 2 Dec 2019, at 00:00, Martin Thomson  wrote:
>>>
>>
>> 
>>
>>
>>> Suggest replacing the last 4 paragraphs of this section with the
>>> following text.
>>>
>>
>> I can't say I like this very much.
>>
>>>
>>> “It has been pointed out that should the trend towards using large
>>> public resolvers increase, an increased centralisation of DNS resolution
>>> services will result.
>>>
>>
>> Well, it's been pointed out, but it's not at all clear that it's true,
>> due to the large amount of centralization of ISPs in certain areas, so no,
>> I don't think this document should make this claim.
>>
>>
>> To address the more general problem I suggest:
>>
>> “Should the trend away from using ISP managed resolvers to using a small
>> set of large public resolvers continue, then an increased proportion of the
>> global DNS resolution traffic will to be served by only a few entities.
>> Some potential impacts of centralisation within the Internet Infrastructure
>> are outlined in [I-D.draft-arkko-arch-infrastructure-centralisation] and
>> include some privacy related considerations. "
>>
>
> Yeah, my point is that I don't agree with this. Right now there is a lot
> of ISP centralization and the move of some of that traffic to public
> resolvers potentially decreases centralization at the margin. I certainly
> don't agree with citing draft-arkko, which is not at all a neutral or
> factual source, so this is just a way of incorporating by reference
> material which doesn't have consensus.
>
>
> There was much follow up on this point, thank to everyone that
> contributed. My summary of those comments seem to be the there is a desire
> to include text covering the fact that centralisation is happening in many
> forms and has a mixed impact.  I suggest the following text
>
> “As with many other protocols issues around centralisation also arise with
> DNS. The picture is fluid with several competing factors contributing which
> can also vary by geographic region. These include:
> * ISP outsourcing, including to third party and public resolvers
> * regional market domination by one or only a few ISPs “
>
> An increased proportion of the global DNS resolution traffic being served
> by only a few entities means that the privacy considerations for end users
> are highly dependant on the privacy policies and practices of those
> entities.”
>
> I also previously proposed referencing
> draft-arkko-iab-internet-consolidation that Stephane mentioned, but Ekr
> objected.
>

I understand that there are a number of people who would like to include
this material, but it isn't actually about DNS privacy in particular, nor
about DoH or DoT, which are just protocols, but about deployment models,
and so isn't really in scope here.

More generally, this document should not be trying to document or argue the
discussions that are happening about ADD.





>
>
> An increasing number of applications are offering application-specific
>>> encrypted DNS resolution settings, rather than defaulting to using only the
>>> system resolver. Due to a lack of a standardized discovery mechanism for
>>> DoH and Strict DoT servers, applications that do so are currently limited
>>> to using hard coded lists of resolvers and a variety of heuristics and
>>> resolvers are available in different applications. At the time of writing,
>>> efforts to provide standardized signalling mechanisms for applications to
>>> also discover the services offered by local resolvers are in progress
>>> [I-D.ietf-dnsop-resolver-information]. Note that an increasing numbers of
>>> ISPs are deploying encrypted DNS, for example see the Encrypted DNS
>>> Deployment Initiative [EDDI].
>>>
>>
>> I'm not sure what the point of this text is, but it seems kind of
>> confusing.. In particular, it's not the case that the primary reason that
>> Firefox uses a hardcoded list is because there is no standardized discovery
>> mechanism.
>>
>>
>> To clarify I suggest:
>>
>> “An increasing number of applications are offering application-specific
>> encrypted DNS resolution settings, rather than defaulting to using only 

Re: [dns-privacy] [Last-Call] Review of draft-ietf-dprive-rfc7626-bis-03

[Eric Rescorla]

On Thu, Jan 9, 2020 at 10:03 AM Sara Dickinson  wrote:

>
>
> On 7 Jan 2020, at 22:51, Eric Rescorla  wrote:
>
>
>
> On Tue, Jan 7, 2020 at 10:38 AM Sara Dickinson  wrote:
>
>>
>>
>> On 31 Dec 2019, at 14:45, Eric Rescorla  wrote:
>>
>>
>>
> 
>
>
>>
>>> Also on linkability and identification:
>>>
>>> Certain configuration options for encrypted transports could also in
>>> principle fingerprint a user or client application.
>>>
>>>
>>> Though there are definitely ways in which the listed options contribute
>>> to fingerprinting, the paragraph talks about session resumption, where the
>>> concern is primarily linkability.  Mixing these concepts only serves to
>>> confuse rather than enlighten.
>>>
>>> When it comes to fingerprinting, it's important to distinguish between
>>> an ability to identify the software in use (Windows vs. Linux, Safari vs.
>>> Chrome) and the ability to distinguish different users.  The text here
>>> conflates these notions in an unhelpful fashion. The fingerprinting
>>> highlighted is a result of characteristics inherent to the software, not
>>> user-specific details.
>>>
>>>
>>> For the most part, we (as protocol designers) accept that distinguishing
>>> software is possible and we don't generally attempt to erase differences
>>> that only serve to reinforce those signals. Suppressing differences in wire
>>> image across implementations generally runs counter to the desire for
>>> diversity in implementation choices.  This text - perhaps unintentionally -
>>> takes the somewhat sensational position that distinguishing between FreeBSD
>>> and Solaris is as relevant as the sort of fingerprinting that might be used
>>> to isolate individuals.  It does that by concentrating on choices that are
>>> usually made by implementations not individuals.
>>>
>>> This is where a clear recognition of the distinction between
>>> implementation choices and how implementations represent (or maybe don't
>>> represent, if that is the way you feel) the choices of individuals requires
>>> a little more care.  I don't know how easy it is to engage on that topic
>>> without also engaging with the current debate though.
>>>
>>>
>>> Suggest:
>>>
>>> OLD:
>>> “Users of encrypted transports are also highly likely to re-use sessions
>>> for multiple DNS queries to optimize performance (e.g. via DNS pipelining
>>> or HTTPS multiplexing). Certain configuration options for encrypted
>>> transports could also in principle fingerprint a user or client
>>> application.  For example: …."
>>>
>>> NEW:
>>> “Implementations that support encrypted transports are also highly
>>> likely to re-use sessions for multiple DNS queries to optimize performance
>>> (e.g. via DNS pipelining or HTTPS multiplexing). Default configuration
>>> options for encrypted transports could in principle fingerprint a specific
>>> client application. For example:…
>>>
>>
>> I don't generally think that documents like this ought to predict how
>> implementers will behave, so I would remove this text entirely.
>>
>>
>> But one of the points of this document is to describe the actual use of
>> DNS so discussing implementation behaviour seems within scope. Given many
>> of the implementations of DoT are done by DNS developers who might be
>> implementing TLS for the first time highlighting potential privacy
>> considerations with such implementation choices also seems relevant.
>>
>
> There are two problems here:
>
> 1. That you are making predictions about what people will do and that
> those preductions are unsupported by evidence. That needs to go.
>
>
> If you are talking about the specific text above - are you saying you
> don’t believe any existing implementations of encrypted DNS transports
> re-use sessions? If so, I can add the list of ones that do to the document.
> Or you believe they all use the same default configuration options?  If not
> what is the specific prediction you mean?
>

Your text says "highly likely". I'm sure that *some* implementation does,
but that doesn't make it highly likely unless you intend to say "it is
highly likely that some implementation will", which seems silly.


> 2. That you are covering material that is already better covered in 8484,
> so why are you duplicating it?
>
>
> Because this is a general overview of all DNS protocols,

Re: [dns-privacy] [Last-Call] last call review of draft-ietf-dprive-rfc7626-bis-03

[Eric Rescorla]

On Thu, Jan 9, 2020 at 10:02 AM Sara Dickinson  wrote:

>
>
> On 7 Jan 2020, at 22:08, Rob Sayre  wrote:
>
> On Tue, Jan 7, 2020 at 10:35 AM Sara Dickinson  wrote:
>
>>
>> >
>> > Secondly, I found the entire section "3.5.1.5.2.  DoH Specific
>> Considerations" to be objectionable, and recommend removing it. It mentions
>> many concerns that are better covered in RFC 8484 and/or HTTP RFCs, and
>> contrasts DoH with DoT in ways that are specious. Both TLS and HTTP allow
>> extension fields and metadata, so there's nothing unique to DoH here
>> (source: I've implemented DoH and ESNI clients). The entire section amounts
>> to a description of fields that privacy conscious DoH clients /might/ send
>> if they were poorly implemented. But it seems strange to stop there..
>> Implementation quality ratholes can go on for a while: for example, the
>> document doesn't mention the numerous problems with today's TLS, PKI, and
>> BGP infrastructure that apply to both DoT and DoH.
>>
>> As mentioned since this document is an analysis of the privacy
>> considerations of actually _using_ DNS (not just the protocol definitions)
>> then privacy considerations raised by poor implementations seem entirely in
>> scope. The document does also discuss such issues with TLS,
>
>
> The document contains the text:
>
>   "DoT, for example, would normally contain no client identifiers above
>the TLS layer and a resolver would see only a stream of DNS query
>payloads originating within one or more connections from a client IP
>address.  Whereas if DoH clients commonly include several headers in
>a DNS message'
>
> Doesn't this just mean "if the DoT client is a good implementation, and
> the DoH client is not...” ?
>
>
> It means a standards compliant DoT implementation will have no client
> identifiers, a standards compliant DoH implementation is free to (and
> likely) to include them.
>

[Citation needed]

-Ekr


>
> I think the Section 8.2 of RFC8484 states this problem better. Why do we
> need this section?
>
> https://tools.ietf.org/html/rfc8484#section-8.2
>
>
> As others have mentioned - this document gives an overall discussion of
> privacy across all DNS protocols, RFC8484 is focussed on the DoH specific
> aspects.
>
>
>
>
>> ones with PKI and PGP are clearly out of scope for this document.
>>
>
> I didn't mention PGP--I was talking about misrouting (BGP). I disagree
> that they are out of scope. Most of the larger TLS use cases rely on PKI.
>
>
> I meant BGP - it was a typo.  Section 2 currently states:
>
> “The privacy risks associated with the use of other protocols, e.g.,
>unencrypted TLS SNI extensions or HTTPS destination IP address
>fingerprinting are not considered here.”
>
> Sara.
>
>
> ___
> dns-privacy mailing list
> dns-privacy@ietf.org
> https://www.ietf.org/mailman/listinfo/dns-privacy
>
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] Last Call: (DNS Privacy Considerations) to Informational RFC

[Eric Rescorla]

On Thu, Jan 9, 2020 at 8:49 AM S Moonesamy  wrote:

>
> >That's a very serious misrepresentation of DoH. Counter-example:
> >Google Chrome did DNS resolution with UDP, a long time ago.
>
> I mentioned web browser and not Google Chrome.  I tested a web
> browser which is not Google Chrome.  The DNS queries were sent to the
> local resolver.  I did another test with Firefox.  The DNS queries
> were also sent to the local resolver.
>

I think you're misunderstanding Stephane.

You wrote:
"The choice of resolvers was previously made by the network on which
the user was connected.  Recently, the Internet Engineering Steering
Group approved the standardization of a mechanism so that the choice
can be made by a web browser. "

This isn't correct. Web browsers have *always* been able to choose their
own resolver because DNS is just UDP packets, which the browser is quite
capable of sending (e.g., QUIC, WebRTC). Historically, browsers have
chosen to use the system resolver which customarily gets its choice of
resolver from the network, however, Chrome, at least, for some time has
done DNS resolution itself, albeit using the same resolver as the system
resolver used. However, they could easily have chosen to use 8.8.8.8
(or some other resolver) instead.

The point here is that DoH is orthogonal to the question of which resolver
you use.

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

Re: [dns-privacy] Review of draft-ietf-dprive-rfc7626-bis-03

[Eric Rescorla]

On Tue, Jan 7, 2020 at 8:28 PM Rob Sayre  wrote:

> On Tue, Jan 7, 2020 at 8:15 PM Martin Thomson  wrote:
>
>> But it is true that HTTP has grown a number (many) of similar features.
>> You could - as this document strong implies - suggest that multitude of
>> options makes it a risky proposition to use HTTP because of the surprising
>> ways in which linkability manifests.  Or, you could recognize that you need
>> a framework from within which to simplify the analysis.
>>
>
> Huh, is there actually a privacy bug in the DoH spec wrt privacy here?
>
> Couldn't servers give out unique URI templates?
>

DoH doesn't specify how the clients get the templates. At least for a
Firefox-style TRR program, what you describe can't happen because there is
a single fixed template.

-Ekr


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

Re: [dns-privacy] [Last-Call] Review of draft-ietf-dprive-rfc7626-bis-03

[Eric Rescorla]

On Tue, Jan 7, 2020 at 10:38 AM Sara Dickinson  wrote:

>
>
> On 31 Dec 2019, at 14:45, Eric Rescorla  wrote:
>
>
> On Wed, Dec 18, 2019 at 7:07 AM Sara Dickinson  wrote:
>
>>
>>
>> On 2 Dec 2019, at 00:00, Martin Thomson  wrote:
>>
>> Prompted by my surprise at seeing Brian Trammell's mention of a
>> '[firefox]' reference in this document, I reviewed the contents of this
>> draft more closely.
>>
>> Summary
>>
>> I found a number of issues with the additions in this -bis document.  Of
>> particular concern is Section 3.5.1 (formerly Section 2.5.1 in RFC 7626),
>> which has been expanded from one paragraph to four pages.  That there is a
>> need for new content here is clear.  One thing that has become very clear
>> is that our understanding of the role of recursive resolvers has evolved a
>> lot in the past year.  However, I don't believe that the current text is a
>> fair representation of the problems we're facing.  Right now, the community
>> is in the middle of highly contentious debate on the general topic, and I
>> don't think that the new content reflects consensus.
>>
>> It does appear as though there is an attempt here to address the
>> invariant technical characteristics without engaging more controversial
>> positions.  I don't believe that has been successful.  The effect is to
>> preempt an active area of contention.
>>
>> I am opposed to the IETF publishing this document in its current form.
>>
>>
>> Martin,
>>
>> To try to separate out the issue with the text in Section 3.5.1.1 I’ll
>> respond to the comments on that in a separate thread and try to address the
>> other issues in this email.
>>
>>
>> Section 2
>>
>> This document does not attempt a comparison of specific privacy
>> protections provided by individual networks or organisations, it makes only
>> general observations about typical current practices.
>>
>>
>> Having been called out here, I would question whether this claim is
>> indeed correct.
>>
>> BTW, what is "HTTPS destination IP address fingerprinting"?  Was the
>> intent of this paragraph to say that this document only examines the DNS
>> protocol independent of the greater context in which it is used?  That is,
>> it looks at DNS without considering how privacy risks might result from the
>> use of DNS in combination with other protocols?
>>
>>
>> It is describing the ability to fingerprint the website a user connects
>> to based just on the IP address of the HTTPS traffic. For example, this
>> paper given at ANRW https://dl.acm.org/authorize?N687437.  Please
>> suggest text if you prefer a different description of this issue.
>>
>
> Ah, well, then I certainly wouldn't call this HTTPS-anything, given that
> it's a feature of basically every protocol. It just comes up more in the
> HTTPS context because we're otherwise encrypting the traffic.
>
> I would say
> "The privacy risks associated with other protocols that make use of DNS
> information are not considered here”
>
>
> That works.
>
>
>
>>
>> Section 3.4.2
>>
>> This section appears to address several related issues around the use of
>> TLS primarily: fingerprinting, identification, and linkability (the
>> document uses the word "correlation" in line with RFC 6973).  There are
>> parts where fingerprinting is equated with identification or linkability in
>> ways that appear confused.
>>
>> For instance,
>>
>> The use of clear text transport options to optimize latency may also
>> identify a user, e.g., using TCP Fast Open with TLS 1.2 [RFC7413].
>>
>>
>> The use of TFO is a linkability issue, not an identification one.  TFO
>> can also be used without encrypted transport.
>>
>> However, this seems overly negative. Resumption and TFO cookies - and
>> therefore any linkability they might provide - is discretionary on the part
>> of clients. You might (as is done later) raise the question here about the
>> competing concerns of individuals and implementations, but that's a
>> meta-level question that I'll get back to.
>>
>> As a minor note here, TLS 1.3 resumption also provides a server with the
>> ability to link sessions.  This document seems to assume that this is a
>> property of TLS 1.2 only, which is incorrect.  There are proposals that
>> might allow for unlinkable resumption, but those are still just proposals.
>>
>>
>> Suggest:
>>
>> OLD:
>> “The use of clear text transport options to 

Re: [dns-privacy] Review of draft-ietf-dprive-rfc7626-bis-03 - Section 3.5.1.1 Comments

[Eric Rescorla]

On Tue, Jan 7, 2020 at 10:37 AM Sara Dickinson  wrote:

>
>
> On 19 Dec 2019, at 02:09, Eric Rescorla  wrote:
>
>
>
> On Wed, Dec 18, 2019 at 7:06 AM Sara Dickinson  wrote:
>
>>
>>
>> > On 2 Dec 2019, at 00:00, Martin Thomson  wrote:
>>
>
> 
>
>
>> Suggest replacing the last 4 paragraphs of this section with the
>> following text.
>>
>
> I can't say I like this very much.
>
>>
>> “It has been pointed out that should the trend towards using large public
>> resolvers increase, an increased centralisation of DNS resolution services
>> will result.
>>
>
> Well, it's been pointed out, but it's not at all clear that it's true, due
> to the large amount of centralization of ISPs in certain areas, so no, I
> don't think this document should make this claim.
>
>
> To address the more general problem I suggest:
>
> “Should the trend away from using ISP managed resolvers to using a small
> set of large public resolvers continue, then an increased proportion of the
> global DNS resolution traffic will to be served by only a few entities.
> Some potential impacts of centralisation within the Internet Infrastructure
> are outlined in [I-D.draft-arkko-arch-infrastructure-centralisation] and
> include some privacy related considerations. "
>

Yeah, my point is that I don't agree with this. Right now there is a lot of
ISP centralization and the move of some of that traffic to public resolvers
potentially decreases centralization at the margin. I certainly don't agree
with citing draft-arkko, which is not at all a neutral or factual source,
so this is just a way of incorporating by reference material which doesn't
have consensus.



An increasing number of applications are offering application-specific
>> encrypted DNS resolution settings, rather than defaulting to using only the
>> system resolver. Due to a lack of a standardized discovery mechanism for
>> DoH and Strict DoT servers, applications that do so are currently limited
>> to using hard coded lists of resolvers and a variety of heuristics and
>> resolvers are available in different applications. At the time of writing,
>> efforts to provide standardized signalling mechanisms for applications to
>> also discover the services offered by local resolvers are in progress
>> [I-D.ietf-dnsop-resolver-information]. Note that an increasing numbers of
>> ISPs are deploying encrypted DNS, for example see the Encrypted DNS
>> Deployment Initiative [EDDI].
>>
>
> I'm not sure what the point of this text is, but it seems kind of
> confusing. In particular, it's not the case that the primary reason that
> Firefox uses a hardcoded list is because there is no standardized discovery
> mechanism.
>
>
> To clarify I suggest:
>
> “An increasing number of applications are offering application-specific
> encrypted DNS resolution settings, rather than defaulting to using only the
> system resolver. A variety of heuristics and resolvers are available in
> different applications including hard-coded lists of recognised DoH/DoT
> servers.
>
> There is currently no standardized discovery mechanism for DoH and Strict
> DoT servers so applications that might want to dynamically discover such
> encrypted services are not able to. At the time of writing, efforts to
> provide standardized signalling mechanisms for applications to also
> discover the services offered by local resolvers are in progress
> [I-D.ietf-dnsop-resolver-information]. Note that an increasing numbers of
> ISPs are deploying encrypted DNS, for example see the Encrypted DNS
> Deployment Initiative [EDDI]."
>

I don't object to this text, but what's the point?


Everything after this just seems to pre-empt discussions that are ongoing
> and haven't reached consensus.
>
>
>> Application-specific changes to default destinations for users' DNS
>> queries might increase or decrease user privacy - it is highly dependant on
>> the network context and the application-specific default. This is an area
>> of active debate.
>>
>> In order that users are aware of and can control such changes it is
>> highly desirable that applications
>> * communicate clearly the change in default to users
>> * provide configuration options to change the default
>> * provide configuration options to always use the network provided
>> resolver
>>
>> The IETF is working on a number of issues related to application-specific
>> DNS settings. For example there have been discussions on the IETF ADD
>> mailing list [ADD] and a proposal for a new ABCD working group [ABCD].”
>>
>
>
> The goal here is to make the readers of the docume

Re: [dns-privacy] [Last-Call] Review of draft-ietf-dprive-rfc7626-bis-03

[Eric Rescorla]

On Tue, Dec 31, 2019 at 8:33 AM Vittorio Bertola <
vittorio.bert...@open-xchange.com> wrote:

>
> Il 31/12/2019 15:45 Eric Rescorla  ha scritto:
>
>
>
>
> On Wed, Dec 18, 2019 at 7:07 AM Sara Dickinson < s...@sinodun.com> wrote:
>
>
> Suggest:
>
> OLD:
> “Users of encrypted transports are also highly likely to re-use sessions
> for multiple DNS queries to optimize performance (e.g. via DNS pipelining
> or HTTPS multiplexing). Certain configuration options for encrypted
> transports could also in principle fingerprint a user or client
> application.  For example: …."
>
> NEW:
> “Implementations that support encrypted transports are also highly likely
> to re-use sessions for multiple DNS queries to optimize performance (e.g.
> via DNS pipelining or HTTPS multiplexing). Default configuration options
> for encrypted transports could in principle fingerprint a specific client
> application. For example:…
>
>
> I don't generally think that documents like this ought to predict how
> implementers will behave, so I would remove this text entirely.
>
> On the surface, this actually seems like quite a good setting for *not*
> using TLS session resumption (or TFO, or 0-RTT). Consider a browser, in
> which you're likely going to want to connect to the DoH server on startup
> and keep that connection open as long as you are doing just about anything
> that would cause DNS resolution. You might disconnect when you go really
> idle, but then you could get warm again quickly when the user re-engages,
> at which point you probably can just accept an extra RT (remember that user
> response is quite slow). This isn't something that we have spent a lot of
> time optimizing, I don't think, so I suspect there's still a fair bit of
> work to do to figure out the best pattern. In any case, making
> recommendations here seems premature.
>
> As I understood it, the purpose of this document is to map possible
> DNS-related privacy issues, and not necessarily to address them with
> recommendations (and in that case you are right that there might be a
> privacy vs performance tradeoff). So the starting point here was to state
> that a privacy risk exists, even if we are not ready to make
> recommendations (which may come in the future in a "7626ter" document) or
> even to assess whether the risk is big enough to even need recommendations
> (which, I agree, will greatly depend on what implementers will do).
>
> On the other hand, I think there is agreement (is there?) that encrypted
> DNS protocols introduce specific tracking opportunities deriving from how
> they open and reuse connections and from other features of the encrypted
> transport mechanism, so it would be weird to omit this risk from the
> analysis.
>

This analysis is already covered extensively in RFC 8484, Section 2. Rather
than trying to rephrase it here, I would recommend linking to that.

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

Re: [dns-privacy] [Last-Call] Review of draft-ietf-dprive-rfc7626-bis-03

[Eric Rescorla]

On Wed, Dec 18, 2019 at 7:07 AM Sara Dickinson  wrote:

>
>
> On 2 Dec 2019, at 00:00, Martin Thomson  wrote:
>
> Prompted by my surprise at seeing Brian Trammell's mention of a
> '[firefox]' reference in this document, I reviewed the contents of this
> draft more closely.
>
> Summary
>
> I found a number of issues with the additions in this -bis document.  Of
> particular concern is Section 3.5.1 (formerly Section 2.5.1 in RFC 7626),
> which has been expanded from one paragraph to four pages.  That there is a
> need for new content here is clear.  One thing that has become very clear
> is that our understanding of the role of recursive resolvers has evolved a
> lot in the past year.  However, I don't believe that the current text is a
> fair representation of the problems we're facing.  Right now, the community
> is in the middle of highly contentious debate on the general topic, and I
> don't think that the new content reflects consensus.
>
> It does appear as though there is an attempt here to address the invariant
> technical characteristics without engaging more controversial positions.  I
> don't believe that has been successful.  The effect is to preempt an active
> area of contention.
>
> I am opposed to the IETF publishing this document in its current form.
>
>
> Martin,
>
> To try to separate out the issue with the text in Section 3.5.1.1 I’ll
> respond to the comments on that in a separate thread and try to address the
> other issues in this email.
>
>
> Section 2
>
> This document does not attempt a comparison of specific privacy
> protections provided by individual networks or organisations, it makes only
> general observations about typical current practices.
>
>
> Having been called out here, I would question whether this claim is indeed
> correct.
>
> BTW, what is "HTTPS destination IP address fingerprinting"?  Was the
> intent of this paragraph to say that this document only examines the DNS
> protocol independent of the greater context in which it is used?  That is,
> it looks at DNS without considering how privacy risks might result from the
> use of DNS in combination with other protocols?
>
>
> It is describing the ability to fingerprint the website a user connects to
> based just on the IP address of the HTTPS traffic. For example, this paper
> given at ANRW https://dl.acm.org/authorize?N687437.  Please suggest text
> if you prefer a different description of this issue.
>

Ah, well, then I certainly wouldn't call this HTTPS-anything, given that
it's a feature of basically every protocol. It just comes up more in the
HTTPS context because we're otherwise encrypting the traffic.

I would say
"The privacy risks associated with other protocols that make use of DNS
information are not considered here"


>
> Section 3.4.2
>
> This section appears to address several related issues around the use of
> TLS primarily: fingerprinting, identification, and linkability (the
> document uses the word "correlation" in line with RFC 6973).  There are
> parts where fingerprinting is equated with identification or linkability in
> ways that appear confused.
>
> For instance,
>
> The use of clear text transport options to optimize latency may also
> identify a user, e.g., using TCP Fast Open with TLS 1.2 [RFC7413].
>
>
> The use of TFO is a linkability issue, not an identification one.  TFO can
> also be used without encrypted transport.
>
> However, this seems overly negative. Resumption and TFO cookies - and
> therefore any linkability they might provide - is discretionary on the part
> of clients. You might (as is done later) raise the question here about the
> competing concerns of individuals and implementations, but that's a
> meta-level question that I'll get back to.
>
> As a minor note here, TLS 1.3 resumption also provides a server with the
> ability to link sessions.  This document seems to assume that this is a
> property of TLS 1.2 only, which is incorrect.  There are proposals that
> might allow for unlinkable resumption, but those are still just proposals..
>
>
> Suggest:
>
> OLD:
> “The use of clear text transport options to decrease latency may also
> identify a user e.g. using TCP Fast Open [RFC7413]."
>
> NEW:
> “Note that even when using encrypted transports the use of clear text
> transport options to decrease latency can provide correlation of a users'
> connections e.g. using TCP Fast Open [RFC7413].”
>

Sure.



> Also on linkability and identification:
>
> Certain configuration options for encrypted transports could also in
> principle fingerprint a user or client application.
>
>
> Though there are definitely ways in which the listed options contribute to
> fingerprinting, the paragraph talks about session resumption, where the
> concern is primarily linkability.  Mixing these concepts only serves to
> confuse rather than enlighten.
>
> When it comes to fingerprinting, it's important to distinguish between an
> ability to identify the software in use (Windows vs. Linux, Safari 

Re: [dns-privacy] Review of draft-ietf-dprive-rfc7626-bis-03 - Section 3.5.1.1 Comments

[Eric Rescorla]

On Wed, Dec 18, 2019 at 7:06 AM Sara Dickinson  wrote:

>
>
> > On 2 Dec 2019, at 00:00, Martin Thomson  wrote:
> >
> > Prompted by my surprise at seeing Brian Trammell's mention of a
> '[firefox]' reference in this document, I reviewed the contents of this
> draft more closely.
> >
> > Summary
> >
> > I found a number of issues with the additions in this -bis document.  Of
> particular concern is Section 3.5.1 (formerly Section 2.5.1 in RFC 7626),
> which has been expanded from one paragraph to four pages.  That there is a
> need for new content here is clear.  One thing that has become very clear
> is that our understanding of the role of recursive resolvers has evolved a
> lot in the past year.  However, I don't believe that the current text is a
> fair representation of the problems we're facing.  Right now, the community
> is in the middle of highly contentious debate on the general topic, and I
> don't think that the new content reflects consensus.
> >
> > It does appear as though there is an attempt here to address the
> invariant technical characteristics without engaging more controversial
> positions.  I don't believe that has been successful.  The effect is to
> preempt an active area of contention.
> >
> > I am opposed to the IETF publishing this document in its current form.
> >
> >
>
> Attempting to address both Martin and Ekr’s comments on section 3..5.1.1.
> here...
>
> >
> >
> > Section 3.5.1.1
> >
> > This section references announcements of product plans that will
> eventually - even by the time that this document is published - be
> outdated.  This is, in my view, the most controversial section of the
> document, and it is all based on somewhat tenuous information.
> >
> > All the "at the time of writing" text in this section would need to be
> removed in order for me to be comfortable with the publication of this
> document.
> >
> > Similarly, I find the following text problematic:
> >
> >> If applications enable application-specific DNS settings without
> properly informing the user of the change (or do not provide an option for
> user configuration of the application's recursive resolver) there is a
> potential privacy issue; depending on the network context and the
> application default, the application might use a recursive server that
> provides less privacy protection than the default network-provided server
> without the user's full knowledge.
> >
> > This text presumes a great deal about the environment into which these
> applications are being deployed.  It appeals to a status quo bias by
> examining an area of a larger change that might have negative consequences
> without regarding the effect in the aggregate. Moreover, it sets
> unrealistic expectations - "the user's full knowledge" - about what might
> an application might need to do in order to make these deployment
> decisions.  In other words, whether it was intended or not, this takes a
> firm stance on the current rather contentious debate.
> >
> > Separately, I appreciate that some people believe that these
> developments signal a move toward greater centralization of the DNS
> service, but that too is the subject of the ongoing debate.
> >
> > Maybe there is a version of this section that the IETF can publish, but
> not until we actually have consensus on these subjects.  I have to most
> strenuously object to any attempt to publish a document if this section
> remains.
>
> Suggest replacing the last 4 paragraphs of this section with the following
> text.
>

I can't say I like this very much.

>
> “It has been pointed out that should the trend towards using large public
> resolvers increase, an increased centralisation of DNS resolution services
> will result.
>

Well, it's been pointed out, but it's not at all clear that it's true, due
to the large amount of centralization of ISPs in certain areas, so no, I
don't think this document should make this claim.


An increasing number of applications are offering application-specific
> encrypted DNS resolution settings, rather than defaulting to using only the
> system resolver. Due to a lack of a standardized discovery mechanism for
> DoH and Strict DoT servers, applications that do so are currently limited
> to using hard coded lists of resolvers and a variety of heuristics and
> resolvers are available in different applications. At the time of writing,
> efforts to provide standardized signalling mechanisms for applications to
> also discover the services offered by local resolvers are in progress
> [I-D.ietf-dnsop-resolver-information]. Note that an increasing numbers of
> ISPs are deploying encrypted DNS, for example see the Encrypted DNS
> Deployment Initiative [EDDI].
>

I'm not sure what the point of this text is, but it seems kind of
confusing. In particular, it's not the case that the primary reason that
Firefox uses a hardcoded list is because there is no standardized discovery
mechanism.

Everything after this just seems to pre-empt discussions that are 

Re: [dns-privacy] Secdir last call review of draft-ietf-dprive-rfc7626-bis-03

[Eric Rescorla]

On Wed, Dec 18, 2019 at 5:45 AM Sara Dickinson  wrote:

>
>
> > On 29 Nov 2019, at 15:39, Stephen Farrell via Datatracker <
> nore...@ietf.org> wrote:
> >
> > Reviewer: Stephen Farrell
> > Review result: Ready
>
> Hi Stephen,
>
> Thanks for reviewing (again)!
>
> >
> > I might not be the best reviewer for this one as I've read it a few times
> > before. But anyway, I scanned the diff [1] with RFC7626 and figure it
> > seems fine.
> >
> > The only thing that occurred to me that seemed missing was to note
> > that while the new privacy analysis in 3.5.1.1 is already complex, many
> > systems are mobile and hence an analysis that ignores that won't be
> > sufficient. For a mobile device one really needs to analyse all of the
> > possible setups, and hence it's even harder to get to a good answer.
> > (It could be that that's elsewhere in the document but since I only
> > read the diff, I didn't see it:-)
>
> There was a bit of discussion about this and the following text in 3.4.1
> was added:
>
> “ It is also noted that typically a device connected _only_ to a modern
>cellular network is
>
>o  directly configured with only the recursive resolvers of the IAP
>   and


>o  all traffic (including DNS) between the device and the cellular
>   network is encrypted following an encryption profile edited by the
>   Third Generation Partnership Project (3GPP [2]).
>
>The attack surface for this specific scenario is not considered here."
>

This seems insufficient. We don't generally assume that the encryption in
mobile access networks is secure, if only for operational complexity
reasons.
So I think this case could do with rather more text.

-Ekr




>
> Which hopefully covers this?
>
> Sara
>
> ___
> dns-privacy mailing list
> dns-privacy@ietf.org
> https://www.ietf.org/mailman/listinfo/dns-privacy
>
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] [Last-Call] Review of draft-ietf-dprive-rfc7626-bis-03

[Eric Rescorla]

Unsurprisingly, I agree with MT here. There is a pile of material
here which is precisely the set of topics failing to achieve
consensus in ADD, so it can hardly be published as having IETF
consensus through dprive.

By example, let's focus on the following two paragraphs in
S 3.5.1.1.

   If applications enable application-specific DNS settings without
   properly informing the user of the change (or do not provide an
   option for user configuration of the application's recursive
   resolver) there is a potential privacy issue; depending on the
   network context and the application default, the application might
   use a recursive server that provides less privacy protection than the
   default network-provided server without the user's full knowledge.
   Users that are fully aware of an application specific DNS setting may
   want to actively override any default in favour of their chosen
   recursive resolver.

This is not really what one would call a neutral framing, as it fails
to acknowledge that in the general case the user has no way of knowing
what the network provided resolver is or what its policies are and
that in many cases the privacy protections offered by application
default resolvers will be superior to those offered by the
network-provided resolver. Moreover, in the current technical
environment, they have no real way of knowing they are even connecting
to the intended network-provided resolver or that their connection
to it is not under attack.

In addition, the context of this paragraph is highly misleading
coming as it does after a discussion of Firefox's plans. However,
Firefox will (1) notify users before changing their resolvers
and (2) allow the users to configure their own resolvers or disable
DoH, despite the implication in this text to the contrary.


   There are also concerns that, should the trend towards using large
   public resolvers increase, this will itself provide a privacy
   concern, due to a small number of operators having visibility of the
   majority of DNS requests globally and the potential for aggregating
   data across services about a user. Additionally the operating
   organisation of the resolver may be in a different legal jurisdiction
   than the user, which creates further privacy concerns around legal
   protections of and access to the data collected by the operator.

This too is a pile of contested statements. In particular, the legal
environment around privacy for a public resolver might be better or
worse than that for the user's network default resolver, depending on
local regulation.

-Ekr





On Sun, Dec 1, 2019 at 4:01 PM Martin Thomson  wrote:

> Prompted by my surprise at seeing Brian Trammell's mention of a
> '[firefox]' reference in this document, I reviewed the contents of this
> draft more closely.
>
> Summary
>
> I found a number of issues with the additions in this -bis document.  Of
> particular concern is Section 3.5.1 (formerly Section 2.5.1 in RFC 7626),
> which has been expanded from one paragraph to four pages.  That there is a
> need for new content here is clear.  One thing that has become very clear
> is that our understanding of the role of recursive resolvers has evolved a
> lot in the past year.  However, I don't believe that the current text is a
> fair representation of the problems we're facing.  Right now, the community
> is in the middle of highly contentious debate on the general topic, and I
> don't think that the new content reflects consensus.
>
> It does appear as though there is an attempt here to address the invariant
> technical characteristics without engaging more controversial positions.  I
> don't believe that has been successful.  The effect is to preempt an active
> area of contention.
>
> I am opposed to the IETF publishing this document in its current form.
>
> Section 2
>
> > This document does not attempt a comparison of specific privacy
> protections provided by individual networks or organisations, it makes only
> general observations about typical current practices.
>
> Having been called out here, I would question whether this claim is indeed
> correct.
>
> BTW, what is "HTTPS destination IP address fingerprinting"?  Was the
> intent of this paragraph to say that this document only examines the DNS
> protocol independent of the greater context in which it is used?  That is,
> it looks at DNS without considering how privacy risks might result from the
> use of DNS in combination with other protocols?
>
> Section 3.4.2
>
> This section appears to address several related issues around the use of
> TLS primarily: fingerprinting, identification, and linkability (the
> document uses the word "correlation" in line with RFC 6973).  There are
> parts where fingerprinting is equated with identification or linkability in
> ways that appear confused.
>
> For instance,
>
> > The use of clear text transport options to optimize latency may also
> identify a user, e.g., using TCP Fast Open with TLS 1.2 

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

[Eric Rescorla]

On Mon, Nov 4, 2019 at 1:56 PM Paul Wouters  wrote:

> On Mon, 4 Nov 2019, Brian Dickson wrote:
>
> > The names of the servers (and certificate management) would be
> orthogonal to the signaling of DoT support. I would expect the TLSA records
> would
> > be per-server and orthogonal to the per-zone signaling of DoT support.
>
> Again, that would be russian roulette. If I get an NS RRset with 3
> nameservers, and only one of these has a TLSA record, what should I
> do ?
>
> 1) Pick the TLSA one
> 2) Pick a random one
>
> For 1) if this protocol is widely deployed, all clients will pick 1) so
> you just shot your redundancy in the foot.
>
> For 2) the clients get reduced privacy for no good reason, so why would a
> client do this?
>
> It is really a per-zone property, not a per-nameserver property.
>

This is a good point, and seems like an argument against all of the
opportunistic versions as well, even those with HSTS-style mechanisms.

Suppose I look up a.example.com and get ns1.nameservers.example and
ns2.nameservers.example, and I have talked to ns1 and know it does Dot but
I don't know about ns2. What then? Or say I can't connect to ns1

-Ekr

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

Re: [dns-privacy] ADoT signalling

[Eric Rescorla]

On Mon, Nov 4, 2019 at 7:32 AM Stephane Bortzmeyer 
wrote:

> On Mon, Nov 04, 2019 at 07:12:46AM -0800,
>  Eric Rescorla  wrote
>  a message of 96 lines which said:
>
> > I'm less worried about the latter because I would expect recursive
> > resolvers to generally be operated by people who are able to
> > establish their port 853 status.
>
> Not all resolvers are big boxes in the central datacenter. I may want
> to run a resolver on a small box at home even if my ISP blocks port
> 853.
>

Yes, I didn't say "control" it, but "establish" it. My point is that you
will generally know which state you are in and not need to do an automatic
fallback.


-Ekr


> > Well, this is why I asked about the threat model. If we care about
> > active attack, then this kind of approach does not work well.
>
> I tend to agree with Stephen Farrell here. If we insist on perfect
> resistance to active attackers, we may never deploy anything. I would
> suggest something more like "probe 853, remember what it was last time
> (to warn the sysadmin about a sudden block), may be allow to whitelist
> auth servers that must have DoT".
>
> For signaling, my personal preference goes to DANE, anyway.
>
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] ADoT signalling

[Eric Rescorla]

On Mon, Nov 4, 2019 at 6:26 AM Stephane Bortzmeyer 
wrote:

> On Sun, Nov 03, 2019 at 05:33:34PM -0500,
>  John Levine  wrote
>  a message of 14 lines which said:
>
> > I thought it might be useful to make a list of possible ways to signal
> > that a server offers ADoT:
>
> I would like also a discussion on whether signaling is 1) good 2)
> necessary.
>
> Even if you get a signal, the reality may be out-of-sync with the
> signal, for instance because of a problem on the server side (remember
> s published without checking IPv6 connectivity works) or on the
> client side (port 853 blocked).


I'm less worried about the latter because I would expect recursive
resolvers to generally be operated by people who are able to establish
their port 853 status.

So, in any case, the client has to be
> ready to encounter a problem and to try a fallback.
>
> So, why not an "happy eyeball" (RFC 8305) approach? Check 53 and 853
> more or less in parallel and keep DoT if it works.
>

Well, this is why I asked about the threat model. If we care about active
attack, then this kind of approach does not work well.

-Ekr


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

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

[Eric Rescorla]

On Sat, Nov 2, 2019 at 6:02 PM Warren Kumari  wrote:

> On Sat, Nov 2, 2019 at 3:59 PM Eric Rescorla  wrote:
> >
> >
> >
> > On Sat, Nov 2, 2019 at 11:52 AM Stephen Farrell <
> stephen.farr...@cs.tcd.ie> wrote:
> >>
> >>
> >> Hiya,
> >>
> >> On 02/11/2019 18:33, Eric Rescorla wrote:
> >> > On Sat, Nov 2, 2019 at 7:03 AM Paul Hoffman 
> wrote:
> >> >
> >> >> On 11/2/19 9:58 AM, Eric Rescorla wrote:
> >> >>> Generally, I would expect that a solution which addressed the active
> >> >> threat model would also address the passive one.
> >> >>
> >> >> Of course, but there are many threat models that have different
> solutions.
> >> >> The passive threat models might be addressable more quickly than the
> active
> >> >> threat model.
> >> >>
> >> >
> >> > Yes, that's why I asked the question of whether we are trying to
> solve the
> >> > active attacker case.
> >>
> >> Tackling passive and active attacks are not mutually
> >> exclusive goals.
> >
> >
> > Nor did I say they were.
> >
> >
> >>
> >> Experience from SMTP/TLS (as I interpret it anyway)
> >> was that defence against active attacks only really
> >> became tractable a few years after mitigations against
> >> passive attacks had been deployed and clearly hadn't
> >> broken anything. Note that that transition did not require any changes
> >> to SMTP/TLS, though it may have needed
> >> the mail equivalent of HSTS and reporting to have been
> >> defined (it's hard to tell what really motivated folks
> >> to try mitigate active attacks for sure).
> >>
> >> Whether or not adot is sufficiently similar is (for me)
> >> an unknown at this point but I'd hope we don't rule that
> >> out.
> >
> >
> > I think the primary difference between this case and the TLS case,
> > where, as I note below, defense against active attacks was required from
> > the beginning, is the question of whether or not the reference that
> > the initiator has tells it that it supposed to expect security. In the
> case
> > of TLS you have that with the different URI scheme (https) but in
> > the case of email you do not.
> >
> > Conversely, what made opportunistic style approaches viable for
> > SMTP was that there was an existing protocol handshake that
> > could be conveniently adopted to have upward negotiation (STARTTLS).
> > This was more of a pain with HTTP, though RFC 2817 does in fact
> > specify something.
> >
> > In this case, I think the relevant question is whether there is some
> > viable mechanism (by which I mean one that people might actually
> > use) by which recursive resolvers would, in talking to an authoritative
> > resolver, detect that that resolver supported secure transport and
> > upgrade. If there is, then it's potentially possible to have some kind
> > of opportunistic approach. And conversely, whether it's viable
> > to have the records that point you to the next authoritative convey
> > that you should expect security.. If there is, then it's potentially
> > possible/better to have a non-opportunistic approach
>
> I've suggested a number of times, but haven't actually written up,
> that you could encode this in the nameserver name - this is somewhat
> similar to the dnscrypt idea...
>
> E.g - no DoX expected:
> $ dig ns example.com
> ;; ANSWER SECTION:
> example.com. 42923 IN NS b.iana-servers.net.
> example.com. 42923 IN NS a.iana-servers.net.
>
> Recursive resolvers should expect DoT:
> $ dig ns example.com
> ;; ANSWER SECTION:
> example.com. 42923 IN NS b-dot.iana-servers.net.
> example.com. 42923 IN NS a-dot.iana-servers.net.
>
>
> Yes, I'll be the first to admit that it is hacky, and not it's not
> completely foolproof, but it requires an attacker to do more than just
> block port 853 to force a downgrade, and also means that resolvers
> don't have to probe 853, wait for a timeout and then try 53
> instead
>

Can you expand on this? Is the convention that if I see x-dot.example.com,
then I should expect DoT?

-Ekr


> W
>
>
>
> >
> >
> >>
> >> ISTM that requiring day-1 defence against active attacks was to an
> >> extent responsible for the lack of deployment
> >> of IPsec and DNSSEC,
> >
> >
> > I don't understand what DNSSEC would do if not defend against active
> > attack.
> >
> >
> >> so I hope we keep an eye on that
> >> ball too.
> >
> >
> > OTOH, TLS had day one defense against active attacks.
> >
> > -Ekr
> >
> > ___
> > dns-privacy mailing list
> > dns-privacy@ietf.org
> > https://www.ietf.org/mailman/listinfo/dns-privacy
>
>
>
> --
> I don't think the execution is relevant when it was obviously a bad
> idea in the first place.
> This is like putting rabid weasels in your pants, and later expressing
> regret at having chosen those particular rabid weasels and that pair
> of pants.
>---maf
>
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] what's good enough, or Threat Model

[Eric Rescorla]

On Sat, Nov 2, 2019 at 4:47 PM John Levine  wrote:

> In article  da_xezhkyvru6kzvnd5cmqcmoyriyusdh0r...@mail.gmail.com> you write:
> >Conversely, what made opportunistic style approaches viable for
> >SMTP was that there was an existing protocol handshake that
> >could be conveniently adopted to have upward negotiation (STARTTLS). ...
>
> >In this case, I think the relevant question is whether there is some
> >viable mechanism (by which I mean one that people might actually
> >use) by which recursive resolvers would, in talking to an authoritative
> >resolver, detect that that resolver supported secure transport and
> >upgrade.
>
> It's easy enough to imagine an EDNS option that asks whether a server
> supports ADoT, that the client can use as a signal to try again on
> port 853.


Sure. One reason you might be sad about this is that it has an extra round
trip.



> PS: there's always dnscurve
>

Sure. Dnscurve is a variant of the "have a secure reference" approach.

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

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

[Eric Rescorla]

On Sat, Nov 2, 2019 at 11:52 AM Stephen Farrell 
wrote:

>
> Hiya,
>
> On 02/11/2019 18:33, Eric Rescorla wrote:
> > On Sat, Nov 2, 2019 at 7:03 AM Paul Hoffman 
> wrote:
> >
> >> On 11/2/19 9:58 AM, Eric Rescorla wrote:
> >>> Generally, I would expect that a solution which addressed the active
> >> threat model would also address the passive one.
> >>
> >> Of course, but there are many threat models that have different
> solutions.
> >> The passive threat models might be addressable more quickly than the
> active
> >> threat model.
> >>
> >
> > Yes, that's why I asked the question of whether we are trying to solve
> the
> > active attacker case.
>
> Tackling passive and active attacks are not mutually
> exclusive goals.
>

Nor did I say they were.



> Experience from SMTP/TLS (as I interpret it anyway)
> was that defence against active attacks only really
> became tractable a few years after mitigations against
> passive attacks had been deployed and clearly hadn't
> broken anything. Note that that transition did not require any changes
> to SMTP/TLS, though it may have needed
> the mail equivalent of HSTS and reporting to have been
> defined (it's hard to tell what really motivated folks
> to try mitigate active attacks for sure).
>
> Whether or not adot is sufficiently similar is (for me)
> an unknown at this point but I'd hope we don't rule that
> out.
>

I think the primary difference between this case and the TLS case,
where, as I note below, defense against active attacks was required from
the beginning, is the question of whether or not the reference that
the initiator has tells it that it supposed to expect security. In the case
of TLS you have that with the different URI scheme (https) but in
the case of email you do not.

Conversely, what made opportunistic style approaches viable for
SMTP was that there was an existing protocol handshake that
could be conveniently adopted to have upward negotiation (STARTTLS).
This was more of a pain with HTTP, though RFC 2817 does in fact
specify something.

In this case, I think the relevant question is whether there is some
viable mechanism (by which I mean one that people might actually
use) by which recursive resolvers would, in talking to an authoritative
resolver, detect that that resolver supported secure transport and
upgrade. If there is, then it's potentially possible to have some kind
of opportunistic approach. And conversely, whether it's viable
to have the records that point you to the next authoritative convey
that you should expect security. If there is, then it's potentially
possible/better to have a non-opportunistic approach



> ISTM that requiring day-1 defence against active attacks was to an
> extent responsible for the lack of deployment
> of IPsec and DNSSEC,


I don't understand what DNSSEC would do if not defend against active
attack.


so I hope we keep an eye on that
> ball too.
>

OTOH, TLS had day one defense against active attacks.

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

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

[Eric Rescorla]

On Sat, Nov 2, 2019 at 7:03 AM Paul Hoffman  wrote:

> On 11/2/19 9:58 AM, Eric Rescorla wrote:
> > Generally, I would expect that a solution which addressed the active
> threat model would also address the passive one.
>
> Of course, but there are many threat models that have different solutions.
> The passive threat models might be addressable more quickly than the active
> threat model.
>

Yes, that's why I asked the question of whether we are trying to solve the
active attacker case.

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

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

[Eric Rescorla]

On Sat, Nov 2, 2019 at 6:01 AM Paul Hoffman  wrote:

> On 11/1/19 2:09 PM, Eric Rescorla wrote:
> > It seemed like it might be a good idea to take a step back and talk
> > about threat model to see if we're all on the same page.
> >
> > The set of threats I am concerned with is primarily about an on-path
> > active attacker who learns the query stream (i.e., the domains being
> > queried) coming out of the recursive resolver. It's of course mostly
> > inevitable that the attacker learns which authoritative servers are
> > being queried, but I think we can all agree there's still plenty of
> > information to leak here [0].
> >
> >
> > In the current DNS, such an attacker can of course just perform a
> > passive attack by listening to the DNS query traffic. It's possible to
> > straightforwardly exclude this attack by opportunistically attempting
> > DoT [1] to the authoritative. However, an active attacker can mount a
> > downgrade attack on the negotiation, forcing you back to
> > cleartext. So, unless you have a secure way of:
> >
> > (1) knowing the expected name of the authoritative for a given query
> >  and that it supports DoT
> > (2) verifying that the server you are connecting to actually has
> >  that name
> >
> > Then the attacker can just mount a MITM attack on your connections and
> > collect this data by proxying the traffic to the true authoritative.
> >
> > Do people agree with this assessment of the situation? Is this form
> > of attack something they agree should be in scope?
>
> This is one threat model, definitely. Another is passive snooping, such by
> someone who is watching at a point on the resolver's upstream connection to
> interesting authoritative servers. Another is passive snooping, such by
> someone who is watching at a point near interesting authoritative servers.
>

Generally, I would expect that a solution which addressed the active threat
model would also address the passive one.



> One small modification I would make to your mode is to change #1 from
> "knowing the expected name of the authoritative" to "knowing an expected
> identifier of the authoritative", and #2 to "...actually has that
> identifier". Given the current landscape of resolvers and authoritative
> servers, using long-lived IP addresses for identification might be better;
> that would need to be hashed out during protocol discussion.
>

Sure. Let's say "identity"

=Ekr


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

[dns-privacy] Threat Model

[Eric Rescorla]

It seemed like it might be a good idea to take a step back and talk
about threat model to see if we're all on the same page.

The set of threats I am concerned with is primarily about an on-path
active attacker who learns the query stream (i.e., the domains being
queried) coming out of the recursive resolver. It's of course mostly
inevitable that the attacker learns which authoritative servers are
being queried, but I think we can all agree there's still plenty of
information to leak here [0].


In the current DNS, such an attacker can of course just perform a
passive attack by listening to the DNS query traffic. It's possible to
straightforwardly exclude this attack by opportunistically attempting
DoT [1] to the authoritative. However, an active attacker can mount a
downgrade attack on the negotiation, forcing you back to
cleartext. So, unless you have a secure way of:

(1) knowing the expected name of the authoritative for a given query
and that it supports DoT
(2) verifying that the server you are connecting to actually has
that name

Then the attacker can just mount a MITM attack on your connections and
collect this data by proxying the traffic to the true authoritative.

Do people agree with this assessment of the situation? Is this form
of attack something they agree should be in scope?

-Ekr

[0] There are of course also integrity issues here, but (1) those
are addressed by DNSSEC and (2) if you solved the active attack
problem, that would provide some measure of integrity for the data.

[1] Or any secure transport such as DoH, DoQ, tcpcrypt, etc.
but given the focus of this group, I'll just say DoT.
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

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

[Eric Rescorla]

On Fri, Nov 1, 2019 at 8:16 AM Brian Dickson 
wrote:

>
>
> On Thu, Oct 31, 2019 at 7:38 PM Eric Rescorla  wrote:
>
>>
>>
>> On Thu, Oct 31, 2019 at 2:41 PM Brian Dickson <
>> brian.peter.dick...@gmail.com> wrote:
>>
>>> IMNSHO, ADoT at the leaf + QNAME minimization is all that is required
>>> for privacy.
>>> I.e. No need for ADoT anywhere other than at the leaf zone's name server
>>> (whose NS name might not be in-bailiwick, FYI).
>>>
>>
>> Hmm I think that's only true if you are assuming that the NS record
>> for the leaf is DNSSEC secured, but that doesn't seem like a safe
>> assumption.
>>
>
> Let me re-emphasize this from the original statement: "FOR PRIVACY".
>
> DNSSEC security is orthogonal to privacy, and is not a requirement FOR
> PRIVACY.
>

I don't believe that that's correct in this case. The issue here is that in
order to provide confidentiality for the queries (in this case to the
authoritative) you need to authenticate the resolver. And that means
authentically learning the name of the resolver. So, for instance, if I go
the learn the NS for .com and the attacker gives me www.attacker.com, then
he can learn my queries. The name of the resolver can be authenticated by
DNSSEC or (less strongly) by having each query protected via secure
transport.

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