Re: [dns-privacy] [Technical Errata Reported] RFC9539 (7832)

[Daniel Kahn Gillmor]

Erratum 7832 in RFC 9539 is correct and should be marked as Verified.  The
"damping" parameter should indeed be characterized by the specific
encrypted transport it is associated with.

A recursive resolver that implements both DoT and DoQ may perfer to use
different `damping` parameters for each encrypted transport, for
example due to concerns about different resource consumption patterns
for each implementation.

Thank you Kevin P. Fleming for the close read of this document.

  --dkg

On Thu 2024-02-29 06:53:40 -0800, RFC Errata System wrote:
> The following errata report has been submitted for RFC9539,
> "Unilateral Opportunistic Deployment of Encrypted Recursive-to-Authoritative 
> DNS".
>
> --
> You may review the report below and at:
> https://www.rfc-editor.org/errata/eid7832
>
> --
> Type: Technical
> Reported by: Kevin P. Fleming 
>
> Section: 4.6.3
>
> Original Text
> -
> *  E-status[X] is either fail or timeout and (T0 - E-completed[X]) >
>   damping, or
>
> Corrected Text
> --
> *  E-status[X] is either fail or timeout and (T0 - E-completed[X]) >
>   E-damping, or
>
> Notes
> -
> The formula should reference the damping value for the protocol in use.
>
> Instructions:
> -
> This erratum is currently posted as "Reported". (If it is spam, it 
> will be removed shortly by the RFC Production Center.) Please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party  
> will log in to change the status and edit the report, if necessary.
>
> --
> RFC9539 (draft-ietf-dprive-unilateral-probing-13)
> --
> Title   : Unilateral Opportunistic Deployment of Encrypted 
> Recursive-to-Authoritative DNS
> Publication Date: February 2024
> Author(s)   : D. K. Gillmor, Ed., J. Salazar, Ed., P. Hoffman, Ed.
> Category: EXPERIMENTAL
> Source  : DNS PRIVate Exchange
> Area: Internet
> Stream  : IETF
> Verifying Party : IESG


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

Re: [dns-privacy] [Technical Errata Reported] RFC9539 (7831)

[Daniel Kahn Gillmor]

Erratum 7831 in RFC 9539 is correct and should be marked as Verified.  The
"persistence" parameter should indeed be characterized by the specific
encrypted transport it is associated with.

A recursive resolver that implements both DoT and DoQ may perfer to use
different `persistence` parameters for each encrypted transport, for
example due to concerns about different resource consumption patterns
for each implementation.

Thank you Kevin P. Fleming for the close read of this document.

  --dkg

On Thu 2024-02-29 06:51:11 -0800, RFC Errata System wrote:
> The following errata report has been submitted for RFC9539,
> "Unilateral Opportunistic Deployment of Encrypted Recursive-to-Authoritative 
> DNS".
>
> --
> You may review the report below and at:
> https://www.rfc-editor.org/errata/eid7831
>
> --
> Type: Technical
> Reported by: Kevin P. Fleming 
>
> Section: 4.6.1
>
> Original Text
> -
> E-status[X] is success and (T0 - E-last-response[X]) < persistence.
>
> Corrected Text
> --
> E-status[X] is success and (T0 - E-last-response[X]) < E-persistence.
>
> Notes
> -
> The formula should reference the persistence value for the protocol in use.
>
> Instructions:
> -
> This erratum is currently posted as "Reported". (If it is spam, it 
> will be removed shortly by the RFC Production Center.) Please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party  
> will log in to change the status and edit the report, if necessary.
>
> --
> RFC9539 (draft-ietf-dprive-unilateral-probing-13)
> --
> Title   : Unilateral Opportunistic Deployment of Encrypted 
> Recursive-to-Authoritative DNS
> Publication Date: February 2024
> Author(s)   : D. K. Gillmor, Ed., J. Salazar, Ed., P. Hoffman, Ed.
> Category: EXPERIMENTAL
> Source  : DNS PRIVate Exchange
> Area: Internet
> Stream  : IETF
> Verifying Party : IESG


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

Re: [dns-privacy] [art] [Ext] Artart last call review of draft-ietf-dprive-unilateral-probing-12

[Daniel Kahn Gillmor]

On Thu 2023-09-07 19:38:01 -0700, Rob Sayre wrote:
> On Thu, Sep 7, 2023 at 7:15 PM Paul Hoffman  wrote:
>
>> On Sep 7, 2023, at 6:58 PM, Bron Gondwana  wrote:
>> >> Are you proposing a shorter value for "damping", or a note saying "1
>> day is just the suggested value, you might choose a shorter one if you
>> want"? Or something else?
>> >
>> > I'm suggesting a backoff algorithm which isn't "single failure gives you
>> N hours of no retry" - particularly, if you have an existing encrypted
>> connection and it has a fault, my reading was that you don't retry at all
>> to form an encrypted connection, even when talking to somewhere that has
>> previously succeeded.  I agree you don't want to try more than once per day
>> against a server that's never supported encryption, but if you have had
>> consistent success encrypting to a server, then a single failure, you don't
>> want to be treating that one the same!  It's definitely worth retrying
>> faster than a full day later.
>>
>> This sounds like you want a smaller value than 1 day for `damping` then.
>> Because those parameters are only suggested defaults, a resolver operator
>> like you could simply change the 1 day to maybe 1 hour, with the risk of
>> slowing down resolution to that one nameserver.
>
> I think you might want to rephrase this part. It seems like you really mean
> retries asymptotically approaching a 1 day timeout. What I've found works
> is exponential backoff that doesn't get too pessimistic, and also contains
> some amount of uncertain time intervals. It seems very dumb at first. But,
> if one piece breaks that may have nothing to do with DNS, you will get a
> stampede. Introducing a little bit of uncertainty can help.

Thanks for all this discussion.  The main purpose of having any sort of
damping in the draft is to encourage operators of authoritative servers
that they will not find themselves in trouble even if they enable
encrypted transport briefly for experimentation or evaluation, and then
turn it off again.

There are two kinds of trouble that such an authoritative server could
find itself in:

 a) It could be flooded with queries on a transport that it no longer
supports.

 b) Queries from recursive resolvers could fail or be substantially
delayed when the encrypted transport is disabled.

The `damping` parameter primarily influences (a), which i'd argue is
likely the less-important of the two, operationally, since it doesn't
cost the authoritative operator that much to send a "port closed" ICMP
response.  ((b) is influenced more by the `timeout` parameter.)

It looks to me like it would be fine to introduce something more
sophisticated than a static `damping` parameter with the aim of
increasing the total amount of encrypted transport happening, but to do
so, you'd need to add to the per-authoritative-IP state held by
recursive resolver.  This would further expand the table "Recursive
resolver state per authoritative IP, per encrypted transport", adding
more complexity to the implementation.

(it looks to me like you could probably do the uncertainty proposal it
without adding to the state if you just applied a randomized offset to
the test that evaluates: `(T0 - E-completed[X]) > damping` though)

If done wrong, it could also increase the risk of (b) happening: in
particular, you'd want make sure any change would *only* affect the
reversion to "happy eyeballs" style dual querying, rather than avoiding
the cleartext queries for too long.  and of course, happy-eyeballs-style
queries will leak information.

From my perspective, the simple approach described in the draft is a
good opportunistic baseline -- minimally complex, works fine
(opportunistically) with a functioning server in the absence of an
active attacker, and fails gracefully in the face of errors on the
server side.

Any subsequent draft that specifies strong (non-opportunistic)
confidentiality for DNS queries should of course be more cautious.  But
i think sticking with the simplest guidance that provides moderate
confidentiality for this case is the right way to go.  If implementers
end up doing something more sophisticated i'd hope they would report
back on what they did and what parameters they chose.  I don't think
more sophistication or complexity needs to be in this particular draft,
though.

--dkg


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

Re: [dns-privacy] [Ext] Restarting the discussion of draft-ietf-dprive-unilateral-probing

[Daniel Kahn Gillmor]

Thanks for addressing these suggestions from Puneet, Paul.

I'm not so sure about this text:

On Mon 2022-09-26 22:32:32 +, Paul Hoffman wrote:
> Puneet wrote:
>
>> Generally any NS IP with working encryption should be preferred over
>> Do53.
>
>All resolvers currently keep NS sets and, in case of encrypted
>transport failures, the sets MAY be checked for other IPs instead
>of falling back to Do53 on the same IP. If there is only one IP
>address with encrypted transport, this means falling back to
>unencrypted DNS. If a nameserver has three IP addresses,
>two of which have encrypted transport and the first of those two
>causes a transport failure, the second of those two will get
>a large load due to encrypted traffic moving from the first. 

Nothing in the draft so far makes any attempt to tell the recursive
resolver how to select between different authoritative IP addresses
derived from an NS set.

Adding this text actually makes the draft more complex than it needs to
be, and there are some potentially subtle consequences that might
discourage adoption of encrypted transport if we encourage the behavior
Paul has hinted at as a MAY here.  (i grant that MAY is not a strong
prescription, but it does appear to be an endorsement)

I'm particularly concerned that wide adoption of this particular
approach by recursive resolvers would make it so that adoption of
encrypted transport by a single authoritative server within an NS set
would cause that authoritative to attract a disproportionately high
fraction of queries for that NS set, leading to problematic resource
consumption that would appear to be the fault of encrypted transport.

It seems possible that this could lead to authoritative server operators
(especially those who operate one part of a larger NS set) declining to
attempt encrypted transport out of fear of this kind of imbalance.

I'd prefer that the unilateral-probing draft not include any guidance
about how to select an IP from the NS set over hinting that a recursive
resolver might want to do it this way.

 --dkg


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

Re: [dns-privacy] I-D Action: draft-ietf-dprive-unilateral-probing-00.txt

[Daniel Kahn Gillmor]

Hi Christian--

On Mon 2022-04-11 15:21:26 -0700, Christian Huitema wrote:
> True. But this is easy to spoof.

right, but it's even easier to spoof an ICMP Port Unreachable, which
will undoubtably have the same effect on an opportunistic recursive
resolver.

> That could work. It would be similar to "ALPN negotiation failed". But I 
> am not sure that's easy to implement, giving different TLS answers to 
> different clients. It is essentially a layer violation. Architecture 
> considerations aside, that requires a pretty tight coupling between TLS 
> and Application implementation. Not always possible. Also, not 
> authenticated. The bad guys recipe book is going to say, "spoof this 
> message if you want to force a client to stop unilateral probing for 24 
> hours."

I really don't think "not authenticated" or "spoofable" is a valid
objection in this particular use case, but i hear you about the
difficulties for an implementation based on different layers of the
stack that are typically accessible to the DNS server implementer.

I'm just wondering what the motivation is for the authoritative server
to emit this response if it can *only* be done at the DNS layer.  Aren't
all the resources you're worried about already being consumed at that
point?

If we define semantics for some future signalled protocol that depends
on proper authentication, and those semantics could tell the recursive
resolver to limit itself somehow (and for some particular reason?), then
that'd definitely be interesting.  But any response from the server that
requires the server to be properly authenticated doesn't seem like it
belongs in this draft, regardless of its semantics.

I'd be happy to include a definition/declaration of a "please back off"
response at the DNS layer into this draft, if we can be clear about:

 - What specifically is the server expecting the client to do -- does it
   differ from the client's response to, for example, an ICMP Port
   Unreachable message?  (no difference is fine, but we should be clear)

   In particular, i'd be reluctant to imply or encourage that such a
   signal would cause the recursive resolver to back off even more
   strongly than it would back off if it received any other error,
   includng ICMP Port Unreachable, a TLS handshake negotiation failure,
   etc.  Given that this signal is guaranteed to be just as spoofable as
   these other network-inflicted failure modes, it would be unfortunate
   if an interfering network attacker could cause *more* cleartext to
   flow over time just because of the layer at which the response
   appeared.

 - What does the authoritative server gain from such a response?  When
   should a reasonable authoritative server deploy this response?

Would you be up for taking a crack at suggesting some text?

Thanks for talking this over!

   --dkg


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

Re: [dns-privacy] I-D Action: draft-ietf-dprive-unilateral-probing-00.txt

[Daniel Kahn Gillmor]

On Sun 2022-04-10 11:57:40 -0700, Christian Huitema wrote:
> But Sara has a point, we should give servers a way to control the
> deployment.

Authoritative servers do have a way to control deployment: they can
simply refuse connections on encrypted transport.

Rather than refusing arbitrary connections haphazardly on the basis of
time of arrival (or some other unrelated feature), though, maybe we
should offer guidance on how to selectively refuse connections on the
basis of the client IP address (to avoid state-flapping on the recursive
resolver side).

I've noted this as
https://gitlab.com/dkg/dprive-unilateral-probing/-/issues/22

> Servers could very well be flooded with queries just after starting to 
> test DoT and DoQ. We should address that by changing the server 
> responses, not the client queries. For example, we might want to define 
> an extended DNS error message rejecting a query because the capacity to 
> process encrypted requests is exceeded. And we might want to specify 
> that clients receiving such messages should stop unilateral attempts to 
> use that server for a while. DoT or DoQ servers could use that to 
> progressively enable the service for a fraction of their clients, maybe 
> using some kind of filter based on the client's IP.

I'd be game to use this document to define such an extended error
message, but i don't understand how its semantics would differ from
merely rejecting the connection attempt with an ICMP Port Unreachable
message (which non-implementing authoritative servers will send anyway).

In a strongly-authenticated protocol, the difference between an extended
DNS error code and ICMP Port Unreachable would be that the client could
rely on the authenticity of the DNS error code (ICMP Port Unreachable is
of course always spoofable by the network path).  But in this
opportunistic deployment, both signals are spoofable.

Maybe the concern is that the authoritative server implementation might
not have control over the full stack enough to respond ICMP Port
Unreachable to a specific subset of client IP addresses.

In that case, i can imagine two distinct modes of operation:

- the server only has the opportunity to respond after the TLS/QUIC
  handshake is complete.  In this case, i don't see why the server
  shouldn't just go ahead and handle the query; some part of the stack
  has already borne the connection setup costs.

- the server can respond early during the TLS/QUIC handshake.  In this
  case, we'd want to define an error at that layer, so that the
  authoritative server can signal failure without incurring any
  additional connection costs.

Does this analysis seem right to you?  Or is there a reason that i'm
missing that an authoritative server would want to have the signal at
the layer where a extended DNS error message would make sense?

 --dkg


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

Re: [dns-privacy] I-D Action: draft-ietf-dprive-unilateral-probing-00.txt

[Daniel Kahn Gillmor]

On Sun 2022-04-10 19:23:21 +0300, Ilari Liusvaara wrote:
> Perhaps there could be separate ALPNs for recursive and authoritative
> DNS service, with no distinction if authoritative service is
> opportunistic or not?

What would be the advantage of that distinction?  would it be
actionable by either party in a communication?

--dkg


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

Re: [dns-privacy] I-D Action: draft-ietf-dprive-unilateral-probing-00.txt

[Daniel Kahn Gillmor]

Hi Sara--

Thanks for this thoughtful and detailed review!  I'm trying to do it
justice, but i haven't gotten through it all yet.  It's triggered a
bunch of changes in the editor's copy, but I've also focused on the easy
stuff first because i'm lazy :P

If anyone wants to offer concrete suggestions for textual changes for
the parts i haven't yet addressed, i'd welcome those suggestions!

Notes below, inline, for things that i haven't tackled yet:

On Thu 2022-04-07 16:47:02 +0100, Sara Dickinson wrote:
> 2) I wonder if some sort of diagram would go a long way to conveying
> the basic guidance proposed here (and enable simplifying some of the
> detailed text)?

This is a great idea.

Thanks for sharing your flowchart sketch, Sara!  I think a flowchart
typically represents a branching-yet-linear workflow, where the choice
points and observations are all initiated by the primary actor.

In this case, we have a lot of events that can happen asynchronously
from outside the primary actor, so a flowchart kind of struggles to
represent it.

i've spent the last day puzzling this over, and of the ideas i've
stumbled onto, the one i like the most is a state transition diagram for
a single  tuple given one encrypted transport and
Do53.

It'd be more accurate to cover state of *both* encrypted transports for
the  tuple (that is, to observe the subtle
interactions between multiple encrypted transports and Do53), but that
diagram seems like it might be more complicated and less clarifying.

Any suggestions for a better kind of visualization?

I've opened https://gitlab.com/dkg/dprive-unilateral-probing/-/issues/20
to track this.

> 3) The issue of signalling… I agree there is still work to do to mange
> this. From this reading:

> - from a client perspective the concept of unilateral probing is
> pretty clear. There is a defined behavior for direct probing, which
> will be different from the behavior if 'external coordination' is
> available.
>
> - however servers can't know for sure how the client discovered them
> or how/if they are authenticating the connection. This document
> doesn't prescribe a way to know that a server is 'only' doing
> unilateral deployment and/or something else, hence the potential
> future issues with signalling.
>
> - given this draft is Informational and is designed to enable
> experiments I can't remember if there has already been discussion of
> using an 'alternative' ALPN for this initial deployment? By that I
> mean, use something like 'doq-p01’(DoQ probing 01) for these kind on
> connections (in the same way I-D tagged ALPNs are used during protocol
> development)? That way each side knows explicitly how to behave and
> statements like "An authoritative DNS server that wants to handle
> unilateral queries' would have clear meaning. Whilst this is taking
> liberties with ALPN and may have already been dismissed as an option,
> it does solve a number of problems in the short term and enable
> negotiation and evolution. Just asking :-)

This is an interesting question: the proposal to play games with ALPN
hasn't yet been raised to my knowledge.

Due to ALPN's transport in the clear for a normal TLS handshake, i'd be
reluctant to endorse that use here.  I don't think we want a network
observer to know which encrypted transports are opportunistic and which
are due to signalled information.

I'm also trying to get my head around what such an indicator would be
useful for.  Presumably the authoritative server would behave
differently based on that indicator, but i'm having a hard time
imagining what the authoritative server should do differently.  Is it
just for statistics/accounting?  Can you explain what you think the
purpose of such an indicator would be?

As a related side note, in the editor's copy i've touched briefly on the
"reporting" aspects that would be useful for an operator deciding
whether to signal:

   
https://dkg.gitlab.io/dprive-unilateral-probing/#name-signalling-mechanism-proper

Maybe the need for such an indicator would depend on the semantics and
syntax of the signal that is ultimately selected?  if so, perhaps that
additional indicator belongs in whatever future signalling work we do,
rather than in this document

> 4) Would it be worth adding an additional section or appendix trying
> to model the likelihood of queries being encrypted for a given
> parameter choice vs authoritative server query interval? Assuming
> successful connections, it seems that for servers queried infrequently
> (interval is longer than the ‘persistence' parameter) their initial
> queries after this period will be cleartext so the choice of that
> parameter compared to the average query interval is quite key and
> likely to be the main parameter tuned? This might allow the fixed
> numbers given in 4.1 to be replaced by numbers relative to the average
> query internal for a given auth (and the resolvers desired level of
> encrypted connections/re-probing actions).

I welcome proposed text for 

Re: [dns-privacy] review of dprive-unilateral-probing

[Daniel Kahn Gillmor]

Hi Alex--

thanks for this thoughtful review!

I've adopted most of the changes you highlighted (until we submit a new
draft to the datatracker, they can be seen in the editor's draft
https://dkg.gitlab.io/dprive-unilateral-probing/), but wanted to note a
few of them that I didn't fully incorporate yet:

On Wed 2022-04-06 17:52:00 +0200, Alexander Mayrhofer wrote:
> - I agree to the prococol choices considerations. Towards publication,
> we should shorten the paragraph about the DoH path problem.

noted, and recorded here so we don't lose it:
https://gitlab.com/dkg/dprive-unilateral-probing/-/issues/16

> - As noted in the WG discussion, the X.509 certificate with common
> names of all the names an authoritative server is known under could be
> problematic, because customers are usually "creating" their own
> nameserver names without necessarily informing the op of the
> nameserver. Side note - this might be an interesting research topic -
> to look at the names requested in SNI to the DoT port of such servers
> ... (once we have deployment!)

> - I guess implementors have more to say about the client-side probing
> strategy proposed, but it does look very reasonable to me. Maybe we
> can get feedback from early implementations on optimizing the
> resource-use of state information required.

I agree with these two comments, but i'm not sure there's anything to
put in the draft about either of them.  if you have text you want to
suggest, and a place to put it, please let me know!

> - The description of the connection state (4.3, first section, and the
> state mangling in 4.5.*) is very close to implementation
> specifications - do we really need that great detail for the protocol
> to be interopable? Given the connection to the requirements in 4.5.1,
> I do admit it's tricky. Maybe we should move that to an Appendix?
> Section 4.3.1, though, is more like an abstract requirement, and
> should be kept in. Maybe re-order? I agree on the 4.4. "per IP
> address" recommendation. It might even be worse for v4/v6 deployments.

This draft is definitely "close to implementation specifications" -- but
that's kind of the goal here.  We're trying to describe what specific
policies each server needs to take to avoid harming resolution and
disincentivizing other players from themselves adopting these
strategies.

I've added a high-level overview to section 4 so that an implementer
gets the general idea before diving into the specifics:
https://dkg.gitlab.io/dprive-unilateral-probing/#name-high-level-overview
but i'm kind of reluctant to move the state tables or the specific
transition steps into an appendix.

If those state tables or transition steps are misguided, incomplete for
the stated purpose, or problematic, i'd like to know about it from
implementers so we can correct them.

I fully expect some implementers to keep *additional* state beyond what
is described here, because they may have additional goals.  And of
course some implementers might use their own data structures that are
the equivalent of the state described here without being named or
indexed in the exact way described in the document.  But i don't see how
to perform the recursive resolver side without keeping something
equivalent to this state.

Would it help to explicitly acknowledge that this description isn't a
requirement for variable names, data structures, etc?  I'm happy to
accept text.

Many of the documents coming out of the WHATWG and W3C offer this level
of implementation guidance or even more. For example:

  https://www.w3.org/TR/webdriver/
  https://encoding.spec.whatwg.org/

They do this to enhance interoperability; when each party knows that the
other conformant party will behave in a certain way, it becomes simpler
to make a decision about how to interact.

I think this is not an unreasonable posture for a document like this in
the IETF too.

> - All the "identifier" strings in the draft should be quoted. (such as
> "early", "unsent", etc..) - maybe personal preference, but I find it
> clearer. Latest, the RFC editors will comment on that anyways.

In the HTML version (which i'm thinking of as the canonical form) all
those identifier strings are set off as  elements so they're
already visually distinct.  Do you (or does the WG) want quotation marks
as well?

Another possibility would be to rely on  in the text/html form,
and quotation marks in the text/plain form, but the xml2rfc tooling
doesn't really permit that.  Here are some links that describe that
decision (i'm not sure i agree with it, but i'm also not sure i have the
capacity to fight it):

   https://github.com/ietf-tools/xml2rfc/issues/600
   https://github.com/ietf-tools/xml2rfc/issues/647
   https://notes.ietf.org/cmt-20210222#

I could do an automated replacement in the source to wrap all literal
strings (`foo`) with quotation marks ("`foo`"), using something like:

   sed -e 's/\([^"]\|^\)`\([^`]*\)`\([^"]\|$\)/\1"`\2`"\3/g'

But i'm not sure whether it improves the 

Re: [dns-privacy] Measurement & Padding Policy document

[Daniel Kahn Gillmor]

On Mon 2022-04-04 11:10:00 +0100, Sara Dickinson wrote:
>> On 25 Mar 2022, at 07:46, Alexander Mayrhofer 
>>  wrote:
>> Daniel, do you still have the paper from the link mentioned above?
>
> (The paper does not seem to be available but for reference a set of slides 
> presented on this work at NDSS 2017 are here: 
> https://drive.google.com/file/d/0B5gNT4RRJ0xPWTNfanYtUFU1bHc/view?resourcekey=0-mo33xmSnmfgc9N412adgvQ)

sorry, this link was down for unrelated reasons, but it's back up now.
i believe it's the same thing that sara posted on the google drive.

  --dkg

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

Re: [dns-privacy] please adopt draft-dkgjsal-dprive-unilateral-probing as a WG work item Re: New Version Notification for draft-dkgjsal-dprive-unilateral-probing-02.txt

[Daniel Kahn Gillmor]

Hi Peter, DPRIVE folks--

On Thu 2022-02-03 11:03:35 +0100, Peter van Dijk wrote:
> Speaking only for myself: some of the parts still seem too prescriptive
> to me (but I know I haven't been clear on what parts!). Examples: 4.3.1
> seems too focused on some specific load balancer implementations, and
> causes a terrible combinatorial state explosion.

§4.3.1 ("Separate State for Each of the Recursive Resolver's Own IP
Addresses") was added specifically in response to concerns raised by
load balancer operators, in coordination with §3.1 (guidance to the pool
operators themselves), with a goal of convincing anyone interested that
the system isn't going to be overwhelming as long as everyone involved
sticks to a few simple and plausible guidelines.

I don't think that there is a combinatorial state explosion here --
every system that queries from a different outbound address just keeps
its own copy of its state, no?  This seems no worse than having to track
established connections based on which local IP address they are
attached to, which is pretty standard.

It's possible that some other set of choices can offer equally
unthreatening system analysis, but if we're proposing an alternative, we
should write it down explicitly so that people can identify potential
problems.  Being able to reason about the system as a whole is an
important part of this kind of description.

> 4.5 could perhaps use some words along the lines of "we describe an
> algorithm here; you could use another algorithm if it fits your
> implementation better, as long as it has similar outcomes". I do like
> that it mentions happy eyeballs without prescribing them.

Thanks, this is useful feedback too.

I think the goal of the draft is to concretely describe a specific
algorithm so that implementers don't have to invent one from scratch.

I'm happy with the terminology you use above, with the slight caveat that
we'd want to be pretty clear about what "similar outcomes" means.  In
particular, i want "similar outcomes" to encompass not only "did the end
user get the right data?" and "did the proportion of
recursive-to-authoritative queries that was served under encrypted
transport actually improve?" but also "does the alternate algorithm
discourage authoritative servers from deploying secure transport?" and
"will you be able to integrate signalling mechanisms for stronger
connections when they become available"?

One reason to be concerned about divergence from the described approach
is if it interacts poorly with someone else's *different* divergence
from approaches described in the draft, for example the guidance around
operating and dealing with pools that we're discussing above ☺

> Speaking for both myself and Paul Hoffman: we are happier with your
> document than with our currently adopted work. We strongly suggest that
> the WG adopts unilateral-probing so we can work out what it would take
> to get some implementation work going.

Thanks for the vote of confidence!  I know that Joey and i would both be
fine with WG adoption of this draft, and I think we'd both be game to
volunteer to continue on as editors were the WG to take over authorship.
We'd also be fine with having an additional editor or two on the draft
if someone is interested in stepping up and game to share the workload.

Joey, please correct me if i'm misrepresenting you on any of this!

   --dkg


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

Re: [dns-privacy] New Version Notification for draft-dkgjsal-dprive-unilateral-probing-02.txt

[Daniel Kahn Gillmor]

Hi folks, just a note explaining what's changed in the
unilateral-probing draft:

On Wed 2022-01-26 08:28:34 -0800, internet-dra...@ietf.org wrote:
> A new version of I-D, draft-dkgjsal-dprive-unilateral-probing-02.txt
> has been successfully submitted by Joey Salazar and posted to the
> IETF repository.
>
> Name: draft-dkgjsal-dprive-unilateral-probing
> Revision: 02
> Title:Unilateral Opportunistic Deployment of Encrypted 
> Recursive-to-Authoritative DNS
> Document date:2022-01-26
> Group:Individual Submission
> Pages:24
> URL:
> https://www.ietf.org/archive/id/draft-dkgjsal-dprive-unilateral-probing-02.txt
> Status: 
> https://datatracker.ietf.org/doc/draft-dkgjsal-dprive-unilateral-probing/
> Html:   
> https://www.ietf.org/archive/id/draft-dkgjsal-dprive-unilateral-probing-02.html
> Htmlized:   
> https://datatracker.ietf.org/doc/html/draft-dkgjsal-dprive-unilateral-probing
> Diff:   
> https://www.ietf.org/rfcdiff?url2=draft-dkgjsal-dprive-unilateral-probing-02
>
> Abstract:
>This draft sets out steps that DNS servers (recursive resolvers and
>authoritative servers) can take unilaterally (without any
>coordination with other peers) to defend DNS query privacy against a
>passive network monitor.  The steps in this draft can be defeated by
>an active attacker, but should be simpler and less risky to deploy
>than more powerful defenses.  The draft also introduces (but does not
>try to specify) the semantics of signalling that would permit defense
>against an active attacker.
>
>The goal of this draft is to simplify and speed deployment of
>opportunistic encrypted transport in the recursive-to-authoritative
>hop of the DNS ecosystem.  With wider easy deployment of the
>underlying transport on an opportunistic basis, we hope to facilitate
>the future specification of stronger cryptographic protections
>against more powerful attacks.

From the changelog:


### Substantive changes from -01 to -02

- Clarify that deployment to a pool does not need to be strictly simultaneous
- Explain why authoritatives need to serve the same records regardless of SNI
- Defer to external, protocol-specific references for resource management
- Clarify that probed connections must not fail due to authentication failure


Joey and I think this represents reasonably clear guidance that is
plausible to implement today.  It should work for both authoritative
server operators and recursive resolvers.

It does *not* solve the harder problem with signalling, but that's a
deliberate choice.  The goal here is just a non-signalled baseline.

There are a few FIXMEs left in the draft, and we'd both welcome review
and suggestions from other WG participants, implementers, operators,
etc.

--dkg


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

Re: [dns-privacy] Tsvart last call review of draft-ietf-dprive-dnsoquic-08

[Daniel Kahn Gillmor]

On Thu 2022-01-27 13:17:39 +, Sara Dickinson wrote:

> I’ve had a first pass at a PR making RFC8467 normative here:
> https://github.com/huitema/dnsoquic/pull/143

Modulo a few minor editorial nits (which i've noted on this PR), i
support this change as well.  Padding defenses are simple, cheap, and a
bare minimum for defending the privacy of encrypted DNS queries.

> preventing traffic analysis from identifying DoQ is a much longer term
> goal (and requires ECH).

I also agree that this kind of defense is currently out of reach; we
don't only need ECH, we would need to think about the IANA UDP port
number registration (853 ≠ 443).  We will at some point need to tackle
these issues so that the network intermediary isn't able to distinguish
categories of network service, but we shouldn't delay this document for
that fix.

On 1/24/2022 5:05 AM, Brian Trammell via Datatracker wrote:

> Further, traffic analysis threats are not limited to packet lengths,
> as section 9.5 acknowledges. Is there any equivalent MUST guidance
> regarding stream frame timing for traffic analysis resistance that
> could be given here?

This is a great question, and i am unaware of any work that this draft
could point to that would address temporal traffic analysis in a DNS
resolution context.

I think the first order traffic analysis concerns that would be worth
tackling are largely from the responder (server) side -- it gets even
more complex if want to address *when* a DNS client should make a given
request.

In particular, if DoQ is used in authoritative deployments, i'd expect
most server responses (served locally from an ingested zonefile) to have
roughly the same temporal delay.  I could imagine some noticeable
temporal differences between "popular" and unpopular records for
authoritative servers that do live DNSSEC signing or NSEC5-style
proof-of-nonexistence that requires cryptographic work on behalf of the
authoritative.

From the client side of authoritative DoQ, it's conceivable that some
temporal traffic analysis resistance could be gained by thinking about
how recursive resolvers can best prefetch to keep their cache hot.

But I suspect this is in the realm of "more research needed", and isn't
appropriate for this draft.

If anyone has any informative pointers that they think are worth
including as a nod toward temporal traffic analysis, i'd be interested
in reviewing them, but I don't think they should block this draft's
progress.

--dkg


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

Re: [dns-privacy] Will unilateral-probing "poison the well"?

[Daniel Kahn Gillmor]

On Sun 2021-12-12 07:58:08 -0500, Robert Evans wrote:
> Yes. It is reasonable to leave room for clients to validate for measurement
> or analysis purposes that have no effect on authoritative operators.
>
> Perhaps you can consider changing the "SHOULD NOT" in that section to "MUST
> NOT".
>
> Or perhaps it would be better to reframe this section as "MUST accept any
> certificate presented" rather than framing this around MAY validate and
> MUST NOT reject invalid certs.

Thanks for this suggestion, Robert.  I'm proposing the attached change
to address it.  Joey and I are trying to push out a draft -02 soon, and
it should be included in that revision.

   --dkg

From 0e05878a7814100a994e38515a33f3dc280b0354 Mon Sep 17 00:00:00 2001
From: Daniel Kahn Gillmor 
Date: Tue, 25 Jan 2022 11:08:11 -0500
Subject: [PATCH] Clarify that failed server authentication MUST NOT cause
 cleartext fallback

Robert Evans suggested clearer text here, thanks!

I also took the opportunity to remove the line about not suggesting
what name to use for authentication, since we do actually offer a
suggestion.
---
 unilateral-probing.md | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/unilateral-probing.md b/unilateral-probing.md
index 8410808..a9b7cb8 100644
--- a/unilateral-probing.md
+++ b/unilateral-probing.md
@@ -356,9 +356,9 @@ If the recursive resolver needs to send SNI to the authoritative for some reason
 A recursive resolver following this guidance MAY attempt to verify the server's identity by X.509 certificate or DANE.
 When doing so, the identity would presumably be based on the NS name used for a given query.
 
-However, since this probing policy is unilateral and opportunistic, the client SHOULD NOT consider it a failure if an encrypted transport handshake that does not authenticate to any particular expected name.
-
-To avoid the complexity of authoritative servers with multiple simultaneous names, or multiple names over time, this draft does not attempt to describe what name a recursive resolver should use when validating an authoritative server, or what the recursive resolver should do with an authentication success.
+However, since this probing policy is unilateral and opportunistic, the client connecting under this policy MUST accept any certificate presented by the server.
+If the client cannot verify the server's identity, it MAY use that information for reporting, logging, or other analysis purposes.
+But it MUST NOT reject the connection due to the authentication failure, as the result would be falling back to cleartext, which would leak the content of the session to a passive network monitor.
 
 ### Establishing an encrypted transport connection
 
-- 
2.34.1



signature.asc
Description: PGP signature
___
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-dkgjsal-dprive-unilateral-probing-01.txt

[Daniel Kahn Gillmor]

On Thu 2021-12-16 10:37:53 -0800, Ben Schwartz wrote:
> In my view, a correct implementation here would simply provide the TLS
> stack with an IP address and no validation identity, so there is no
> way for the TLS stack to retrieve an ECHConfig.

That would be a reasonable implementation, for sure.  But i don't see
why it wouldn't *also* be reasonable to supply a TLS stack with the NS
name and a flag that says not to treat authentication failure as fatal.

> (Unless you're talking about a client stack that deliberately provokes
> the fallback mechanism to retrieve the ECHConfig in-band???)

I don't know of any such stack currently, but if it exists, i wouldn't
see using it as in any way a contradiction to this unilateral probing
strategy for recursive resolvers.

>> Do you want to propose some text that makes this adjustment?
>
> I think it's basically already there.

ok, great :)  if you have any concrete suggestions after chewing it
over, please don't hesitate to propose on the list.

>> Do you have a sense of how to tune such a distinction that wouldn't
>> create that incentive?
>
> How about if the resolver waits for deltaT * damping / timeout after each
> failure?  Then the average delay is the same either way, but returning RST
> reduces tail latency.

I'm not sure i know what deltaT means in the proposal here -- does it
mean time from the connection attempt to the observed failure?

If that's what it means, then a prompt response (RST, ICMP port
unavailable, or other immediate failure indicators) would mean a sooner
retry, right?  This seems like it still creates the negative incentive
that i was concerned about: the admin of an authoritative server that
isn't offering encrypted transport, who wants to reduce the number of
attempts it sees, might then be inclined to *disable* failure
indicators, because it would increase the delay that each unilateral
probing client takes between retries.

Am i misunderstanding your proposal?

  --dkg


signature.asc
Description: PGP signature
___
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-dkgjsal-dprive-unilateral-probing-01.txt

[Daniel Kahn Gillmor]

Hi Ben--

On Mon 2021-12-13 08:34:22 -0800, Ben Schwartz wrote:
> The terminology section says
>
>*  "unilateral" means capable of opportunistic probing deployment
>   without external coordination with any of the other parties
>
> To my eye, that excludes any way of delivering ECHConfigs, whether or not
> SVCB becomes the preferred mechanism for that.
>
> In general, I think this draft should try to be clear that it is restricted
> to the case where no additional DNS queries are performed.

I'd be game for such a clarification, but i'm not sure how to define
what "additional" means here.  Surely this draft is not going to
encourage any draft-specific DNS queries, but it's also not going to
prohibit any DNS queries which might otherwise take place, right?

For example, imagine a TLS client stack that automatically checks for
ECHConfigs (assuming that mechanism has been specified, as i hope it
will be soon).  This draft isn't going to explicitly require that such a
feature be disabled, right?

Do you want to propose some text that makes this adjustment?

>> It might be unrealistic for some pool operators, but it's surely not
>> unrealistic to all pool operators (for some plausibly-fuzzy definition
>> of "simultaneously")
>
> Perhaps "within the span of a few seconds" would be clearer.

Fixed in git, thanks.

>> First, if a pool's load balancer can't reliably map traffic from the
>> client at IP address X to pool member Y at all, then any sort of
>> stream-based protocol (whether that's DoT or DoQ or even Do53 over TCP)
>> is going to fail in pretty terrible ways.
>
> I'm not sure this is true.  A 5-tuple load balancer, for example, would
> preserve stream continuity but fail for the purpose of this section.

right, that's a good point.

> I also don't think IP-based load balancing is technically sufficient.  For
> large resolvers with multiple "exit" IPs, there is (currently) no
> requirement that the state estimate for a given destination IP be
> partitioned by the resolver's exit IP.

The section "Separate State for Each of the Recursive Resolver's Own IP
Addresses" is intended to address this concern.  If you think it's
insufficient, i'd be happy to hear suggestions for improvement!

>> While the consequences will be relatively small (even if the RST or port
>> unreachable messages are swallowed by the network, the default `timeout`
>> parameter for establishing the encrypted transport has fast expiry),
>> clients will still incur at least an extra serialized round-trip on each
>> "flap",
>
> Yes, but this is no worse than the handshake of the encrypted transport we
> are seeking to bootstrap, so it's a performance cost that will be borne
> anyway.

well, it incurs that specific performance cost on each query above and
beyond what would have been done for a cleartext connection, without
gaining any extra defense against a passive monitor.  This seems like
something we'd like to minimize where possible.

>> and if the allocations are truly random they'll be frequently
>> "damped" into not trying encrypted transport for a full day.
>
> This is interesting.  Maybe the long damping should only apply if the
> request timed out, as opposed to being rejected within a few milliseconds.

Maybe there should be two different damping values: a long one when
something times out, and shorter one when there is a rapid failure?

My concern is that if a quick failure (e.g. ICMP Port Unreachable)
results in a more rapid request to reestablish an encrypted session,
then we're encouraging authoritative server operators who *don't* plan
to enable encrypted transport to let attempted encrypted transports time
out, since that will reduce the number of attempts to establish an
encrypted connection.

Do you have a sense of how to tune such a distinction that wouldn't
create that incentive?

  --dkg


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

Re: [dns-privacy] Will unilateral-probing "poison the well"?

[Daniel Kahn Gillmor]

On Fri 2021-12-10 20:11:59 -0500, Robert Evans wrote:
> This should ideally be replaced with "resolvers discovering TLS support
> solely via unilateral probing MUST NOT perform ANY authentication or
> validation whatsoever on the TLS certificate(s) presented by the
> authoritative name server".

This might be a bit excessive -- surely there's no harm in a recursive
resolver trying to validate a given name and then throwing that
information away.  Or, validating a name and sending a report to the
server (via some as-yet-undefined mechanism) if the validation fails.

What the opportunistic unilateral-probing recursive resolver MUST NOT do
is abort the handshake or otherwise delay, penalize, or constrain the
connection due to server authentication failure, right?

> As an example, certificate pinning by resolvers would cause TLS certificate
> auto-rotation to break. Validation might also break "automatic
> opportunistic TLS" where the server self-provisions a self-signed cert for
> its lifetime and throws it away on restart. When used on an anycast
> network, those servers would all have valid certs but every connection
> might present unrelated certs. If the resolver tries to be clever, adding
> more servers might break everything.

I agree that this would be problematic -- we don't want to encourage
that kind of fragility.

--dkg


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

[dns-privacy] Will unilateral-probing "poison the well"?

[Daniel Kahn Gillmor]

One of the concerns raised at IETF 112 about
draft-dkgjsal-dprive-unilateral probing was that unilateral probing by
recrusive resolvers might "poison the well" and discourage authoritative
servers from deploying encrypted transport.

For example, in jabber, Erik Nygren commented: "TOFU has a big "poison
the well" risk here that will prevent operators from enabling."

  https://jabber.ietf.org/jabber/logs/dprive/2021-11-11.html#13:07:33.595176
("TOFU" means "Trust on First Use")

I think this is a legitimate concern: one of the goals of the draft is
to describe how to probe in a way that *doesn't* discourage adoption.

Would folks who have this concern (maybe including Erik, if you're
reading!) take a look at the draft and identify any specific behavior
that you think could be problematic?

I don't think the behavior that Joey and I have specified in
unilateral-probing does TOFU, since it's entirely unconcerned with
authentication.  So there is no "trust on first use" with regards to
choice of server authentication credentials from this perspective.

If an initial attempt at encrypted transport fails, there will be no
penalty, because the cleartext query is ("happy eyeballs"-style) already
in flight.

If an authoritative server never offers an encrypted transport, each
recursive resolver client will check its status at most once a day (see
the `damping` parameter), and will accept a "port closed" message as a
failure, so it's not going to increase costs for cleartext-only
authoritatives in any significant way.  This should also reduce concerns
about runaway retries consuming excessive resources.

And, if an authoritative that has previously offered encrypted transport
stops offering it, there will be at most a one-time very short delay (a
few seconds, see the `timeout` parameter) for each recursive resolver
that had expected encrypted transport, before it falls back to
cleartext.

So i think the probing described here shouldn't scare anyone off from
deploying at the authoritative.  Is this analysis missing something?

--dkg


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

Re: [dns-privacy] Signaling with TLSA records

[Daniel Kahn Gillmor]

On Thu 2021-12-09 19:17:53 -0500, Robert Evans wrote:
> Resolvers can probe for these records today as a signal for
> fully-authenticated ADoT support and fallback to opportunistic TLS via
> unilateral probing or unencrypted transport when not found. (This turns out
> to be exactly the same approach RFC 7672 specifies for SMTP DANE, including
> TLSA as a TLS-is-supported signal.)

I think you're suggesting that the recursive should hard-fail if a TLSA
record is found but it does not successfully authenticate the
authoritative.

TLSA itself doesn't include the following properties that i think we
want from a signal:

 - indication of which encrypted transports (DoT or DoQ) are supported
 - whether to hard-fail or not
 - how to report errors

If i was an authoritative nameserver operator, i'd be concerned that
deploying such a TLSA record would cause my nameserver to become
unreachable.

The way i'd imagine deploying strict TLS safely on an authoritative is:

 - indicate that i want reports about failures of encrypted transport

 - signal that some encrypted transport is available (without requiring 
hardfail)

 - wait a few months (at least long enough for some credential rollover
   to happen, to ensure that this happens smoothly)

 - review any received reports in that window

 - if problems, fix problems and start over

 - if no problems, consider turning on hard-fail



I worry that TLSA alone isn't expressive enough to support that rollout,
and that jumping straight to a hard-fail mechanism will scare people
from deploying.  Maybe those fears are misplaced, though.

 --dkg


signature.asc
Description: PGP signature
___
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-dkgjsal-dprive-unilateral-probing-01.txt

[Daniel Kahn Gillmor]

Hi Ben--

Thanks for the prompt review and feedback!

On Thu 2021-12-09 16:14:36 -0500, Ben Schwartz wrote:
> The SNI guidance looks good to me.
>
> I find it confusing to mention ECH in this draft.  ECH can never be used
> with this specification, because there is (by definition) no SVCB record to
> provide the ECH keys.  (If there is a SVCB record in play, then we are no
> longer in "unilateral probing".)

given that we haven't established what the signalling mechanism
is/should be for authoritative dprive, i'm not entirely sure that we're
out of the realm of unilateral probing here.  (for example, does the
mere presence of SVCB indicate a hard-fail condition?)  I think that's
up to the other draft. ☺

That said, i don't think i'd have an objection to removing the ECH
reference (or at least trimming it down to only be relevant for the
discussion of potential leak due to SNI in the privacy considerations
section)

> I did notice one issue with -01:
>
>   To avoid incurring additional minor timeouts for such a recursive
>> resolver, the pool operator SHOULD either:
>>
>> *  ensure that all members of the pool enable the same encrypted
>>transport(s) simultaneously, or
>>
>> *  ensure that the load balancer maps client requests to pool members
>>based on client IP addresses.
>
> The first option seems a bit unrealistic.

It might be unrealistic for some pool operators, but it's surely not
unrealistic to all pool operators (for some plausibly-fuzzy definition
of "simultaneously")

> I would replace it with "ensure that any members of the pool return an
> explicit rejection packet (e.g. TCP RST) if they do not support the
> encrypted protocol, or".

While this is good guidance in general for authoritative servers (i'd
include "ICMP port unreachable" in list alongside TCP RST, and maybe
some QUIC-specific signalling?), i'm not convinced it belongs in this
section about authoritatives behind a pool.

In particular, i don't think the consequences of this approach would
yield a healthy pool, which is why i didn't include it in the list
initially.

First, if a pool's load balancer can't reliably map traffic from the
client at IP address X to pool member Y at all, then any sort of
stream-based protocol (whether that's DoT or DoQ or even Do53 over TCP)
is going to fail in pretty terrible ways.

If we assume that the load balancer is capable of allocating persistent
stream-like flows (including QUIC sessions if DoQ is in the mix?) to
specific pool members, but randomly allocates stream-initiating packets
from the same client IP address to different pool members, then we'll
have the problem that a client will "learn" that an encrypted transport
is available to that authoritative, and upon the next stream initiation
might land on a pool member that doesn't implement that encrypted
transport.

In effect, the presence of encrypted transport will "flap" for any given
client.

While the consequences will be relatively small (even if the RST or port
unreachable messages are swallowed by the network, the default `timeout`
parameter for establishing the encrypted transport has fast expiry),
clients will still incur at least an extra serialized round-trip on each
"flap", and if the allocations are truly random they'll be frequently
"damped" into not trying encrypted transport for a full day.

How would you feel about adding the guidance you suggested more
generally to the overall guidance for authoritative servers?

 --dkg


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

Re: [dns-privacy] Comments on draft-dkgjsal-dprive-unilateral-probing

[Daniel Kahn Gillmor]

On Mon 2021-11-22 11:27:50 -0500, Ben Schwartz wrote:
> On Fri, Nov 19, 2021 at 6:48 PM Daniel Kahn Gillmor 
> wrote:
> ...
>
>> To avoid incurring additional minor timeouts for such a recursive
>> resolver, the pool operator should either:
>>
>
> Nit: These should not be timeouts.  The non-participating backends are
> expected to return TCP RST or ICMP Destination Unreachable (Port
> Unreachable), leading to immediate fallback after 1 RTT.  Maybe the draft
> needs some guidance to that effect.
>
> A timeout is still possible if the network is misbehaving (e.g. ICMP
> blackhole), but it shouldn't happen otherwise.

Thanks, Ben!

I agree that these shouldn't necessarily be "timeouts" -- but it's not
just network misbehavior that could cause them to be timeouts, there are
some service administrators who believe that having ports in "stealth
mode" (i.e. not responding with a "port closed" ICMP response) is
somehow safer; and, in the event of extreme resource exhaustion, it's
conceivable that TCP RST messages wouldn't get sent.

So "timeout" is there to make sure we handle all of these cases, and we
do still want to minimize the number of places where we risk incurring
them, since neither sender nor receiver can guarantee that the
appropriate signalling makes it through in a timely fashion.

Any concrete proposals for what text to change or add would be welcome!

--dkg


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

Re: [dns-privacy] Comments on draft-dkgjsal-dprive-unilateral-probing

[Daniel Kahn Gillmor]

On Thu 2021-11-11 16:16:24 +, Jim Reid wrote:
>> On 11 Nov 2021, at 15:28, Christian Huitema  wrote:
>> 
>> It is not uncommon to see upgrades being rolled out at different times to 
>> different servers in the farm. Opportunistic strategies and probing 
>> strategies have to deal with that.
>
> This can be complex. Lots of busy domain names (like TLDs) use a combination 
> of DNS servers that are managed and operated by different organisations using 
> different flavours of softwware for the obvious SPoF reasons. Which means 
> upgrades can be like changing a plane's engines in mid-flight. For instance, 
> look at how long it took for all 12 RSOs to be in a position to support 
> DNSSEC and IPv6.

Thanks for this discussion, y'all.

I've tried to capture these thoughts with some additional text in the
draft, which you can see here:

  
https://gitlab.com/dkg/dprive-unilateral-probing/-/commit/477721af91dc517a0696c27a7ae3b6a97f8795a3

In particular, there's a section about how authoritatives can more
safely deploy in a heterogenous pooled or anycasted situation:


## Pooled Authoritative Servers Behind a Single IP Address 
{#authoritative-pools}

Some authoritative DNS servers are structured as a pool of authoritatives 
standing behind a load-balancer that runs on a single IP address, forwarding 
queries to members of the pool.

In such a deployment, individual members of the pool typically get updated 
independently from each other.

A recursive resolver following the guidance in {{recursive-guidance}} that 
interacts with such a pool likely does not know that it is a pool.
If some members of the pool are updated to follow this guidance while others 
are not, the recursive client might see the pool as a single authoritative 
server that sometimes offers and sometimes refuses encrypted transport.

To avoid incurring additional minor timeouts for such a recursive resolver, the 
pool operator should either:

- ensure that all members of the pool enable the same encrypted transport(s) 
simultaenously, or
- ensure that the load balancer maps client requests to pool members based on 
client IP addresses.

Similar concerns apply to authoritative servers responding from an anycast IP 
address.
As long as the pool of servers is in a heterogenous state, any flapping route 
that switches a given client IP address to a different responder risks 
incurring an additional timeout.
Frequent changes of routing for anycast listening IP addresses are also likely 
to cause problems for TLS, TCP, or QUIC connection state as well, so stable 
routes are important to ensure that the service remains available and 
responsive.



and a bit of a reminder for operators of recursive resolvers:


### Separate State for Each of the Recursive Resolver's Own IP Addresses 
{#resolver-binding}

Note that the recursive resolver should record this per-authorititative-IP 
state for each IP address it uses as it sends its queries.
For example, if a recursive resolver can send a packet to authoritative servers 
from IP addresses 192.0.2.100 and 192.0.2.200, it should keep two distinct sets 
of per-authoritative-IP state, one for each source address it uses.
Keeping these state tables distinct for each source address makes it possible 
for a pooled authoritative server behind a load balancer to do a partial 
rollout while minimizing accidental timeouts (see {{authoritative-pools}}).


We'll include something along these lines in draft -01.  If you'd like
to propose fixes or raise concerns, Joey and I would be happy to
incorporate them.

--dkg


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

Re: [dns-privacy] Why MUST EDNS(0) Padding option only appear once?

[Daniel Kahn Gillmor]

On Mon 2021-11-01 18:56:59 +0100, Vladimír Čunát wrote:
> I don't think it's possible to leak more privacy by doing that. Assuming 
> an encrypted channel, only the overall length of the DNS message should 
> matter.

This is my intuition as well, though i haven't done any deep analysis on
it.

> Perhaps if the "surprising" repeat could trigger some bug, I imagine
> the effect might then be observable, but it still doesn't sound
> privacy-risky to me.

I'm also having a hard time imagining what bug would be triggered.  I
imagine that most implementations just ignore all EDNS Padding options
they encounter, not only the first one, but i haven't tested it widely.

 --dkg


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

[dns-privacy] Why MUST EDNS(0) Padding option only appear once?

[Daniel Kahn Gillmor]

Hi DPRIVE folks--

RFC 7830 (The EDNS(0) Padding Option) says:

> The "Padding" option MUST occur at most, once per OPT meta-RR (and
> hence, at most once per message).

Over on https://github.com/PowerDNS/pdns/issues/10884 there's some
discussion of a case where it would be technically advantageous for a
DNS server to include more than one EDNS padding option.  In particular,
a forwarding DNS resolver might want to remove some EDNS option from an
already-padded query or response before forwarding while keeping the DNS
frame the same size.  A very simple way to do this when the cleartext
DNS frame is in memory is to overwrite the undesired EDNS option with
another EDNS padding option, but that would run afoul of the above
"MUST" when the frame is already padded.

Obviously, it's not impossible to shuffle EDNS options around in the
frame to coalesce the padding octets into a single Padding option.  But
in the interest of keeping the "fast path" fast, and of reducing the
opportunity for bugs in the codebase the implementers at the linked
issue are hesitant to do that kind of work.

I reviewed the previous drafts of RFC 7830 all the way back to
https://datatracker.ietf.org/doc/html/draft-mayrhofer-edns0-padding-00
and the "at most once" language appears in all of them -- but i don't
see a justification for it.

RFC 2119 of course says of upper-case keywords:

>   they MUST only be used where it is actually required for
>   interoperation or to limit behavior which has potential for causing
>   harm (e.g., limiting retransmissions).  For example, they must not
>   be used to try to impose a particular method on implementors where
>   the method is not required for interoperability.

Does anyone know the rationale for this "MUST occur at most once" ?  Is
there an additional privacy leak if there were to be more than one EDNS
Padding option?  Are there implementations that would choke if they
received more than one EDNS Padding option?

Has anyone done any experiments to see whether multiple Padding options
do break interoperability?  If not, does anyone have a DNS interop
testing rig that could be easily updated to include such a test?

--dkg


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

[dns-privacy] scope of authoritative signalling [Was: Re: [Ext] Intermediate proposal (what I was saying at the mic)]

[Daniel Kahn Gillmor]

On Thu 2021-08-05 11:06:12 -0700, Brian Dickson wrote:
>- SVCB in the name server name's zone is where the signalling belongs
>(on what transports are supported, per NS name, as well as authenticated or
>not, etc)

I'm agnostic about the mechanism specifically, but i am curious as to
the rationale for the signalling being per-nameserver name.

The plausible options for where to signal, as i see it, are:

 a) signal per authoritative zone ("per zone") [excluding delegated subzones?]
 b) signal per authoritative nameserver name ("per NS name")
 c) signal per authoritative namserver IP address ("per IP")

I think the *information* we're looking to signal, however we do it,
consists of:

 0) what forms of encrypted transport are available
 1) what forms of authentication are available (including what
public keys to expect?)
 2) when and how to report problems with encrypted+authenticated
transport
 3) whether a recursor should hard-fail if the signalled
authenticated+encrypted transport is not accessible (or, viewed
as the inverse, whether fallback to port 53 is acceptable)

It's possible that these four different pieces of data belong to
different scopes.

For example, it's possible that 0 and 1 should be signaled "per NS name"
but 2 and 3 should be signaled "per zone".

Consider the situation where the zone administrator is different from
the NS operator.

Semantically, as a zone administrator, i think i would *want* (2) and
(3) to be "per zone", *not* "per NS name": i would want hardfail to be a
choice *I* make, not the NS operator, and if it's going to be a choice I
make, it needs to be a choice I can choose to gather data about, which
means i need to be able to control reporting.  I can see why (0) and (1)
might make more sense as "per NS name" operationally -- the NS operator
knows what services they can deploy and what authentication mechanisms
they can provide.

Some scenarios for the group to consider:

  I. Consider the case where NS record N1 for zone Z1 points to the same
 IP address X as NS record N2 for zone Z2.  A recursor knows that it
 has had a recent successful encrypted+authenticated connection to X
 as N1 (resolving a name in Z1), but is now looking up a name in
 zone Z2 via N2, and no signalling is available for Z2 or N2.  What
 should the recursor do?  In particular, should it go ahead and use
 the known-good enc+auth connection to X as N1, ignoring the fact
 that it's supposed to be accessed as N2?  should it try an
 encrypted connection to X as N2 but accept if the authentication as
 N2 fails?  Should it just make a cleartext connection to port 53
 instead?

 II. Consider the same circumstance as (I), but where signalling is
 available for N2 that says "DoQ with DANE authentication is
 available; do not fall back to cleartext transport (that is,
 hardfail)".  If authentication fails for N2, what should the
 recursor do?

III. Consider the same circumstance as (II), but where the signalling is
 available for Z2 instead of N2.  If authentication fails for N2,
 what should the recursor do?

 IV. What if the signalling does not indicate hardfail?

  V. What if the signal for Z2 or N2 says DoQ is indicated, but the
 recursor knows (by probing, or by experience) that DoT actually
 works?  What if it knows that DoT works for N1, but it fails to
 complete a DoQ connection to N2?

 VI. What if N2 itself resolves to multiple IP addresses, not merely X?
 Should the resolver treat those different addresses differently
 (e.g., should it prefer X where it knows some form of encrypted
 transport is available)?

There are a *lot* of moving parts here in terms of potential fallback
strategies and risks.  At a minimum, we have a multidimensional space
of:

 - types of transport
 - types of authentication
 - NS names
 - NS IP addresses
 - zones
 - whether to hardfail or not

and we haven't even touched the semantics or mechanics of reporting
problems (i.e., following a model like TLSRPT).

I'm worried that this complexity makes it nearly impossible to analyze
fallback behavior in any reliable way. (not from a security
perspective -- fallback isn't going to offer many guarantees -- but from
an availability/efficiency perspective, how do we evaluate it and figure
out whether there are edge cases that will break nameservice resolution?)

Can we cut this problem into more managable pieces than our current
breakdown?  In particular, can we drop all mention of signalling from
draft-ietf-dprive-unauth-to-authoritative?  Or maybe we need a separate
draft to specify probing-specific, opportunistic behavior for the
recursor without worrying about signalling at all.  If we could do that,
that would be a baseline behavior, and we could specify rules for
signal-handling as a deviation from that baseline.

Note that if opportunistic probing is done to provide maximal protection
against a passive monitor 

Re: [dns-privacy] Alternative signalling propsals

[Daniel Kahn Gillmor]

On Fri 2018-12-14 22:58:09 +, Stephen Farrell wrote:

> I'm probably exposing my lack of DNS-clue, but I wonder if it
> is/isn't possible to embed a "like/want/offer privacy" signal
> in the DNS protocol, rather than in the data carried by the
> protocol? (Regardless of whether the latter might be done via
> funny names or new/additional RRs.).

i think you're suggesting some sort of "starttls"-like mechanism --
start a DNS connection to an authoritative server, and then the server
lets you know "hey you might also want to try me in the future via
private channels"

is that what you're proposing?

if so, it has the unsatisfying aspect common to all starttls-like
proposals: it can be trivially stripped.

it is also unsatisfying in the DNS world because there typically isn't
a handshake -- the first packet contains the sensitive data that you
might want to keep private.

It could certainly help over the longer term against a passive monitor
-- the initial privacy leak could be amortized over many future
communications between the resolver and the authoritative -- but it
still leaves the first connection to that server unprotected even
against passive attack, which is something that signalling in the name
could potentially avoid.

  --dkg


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

Re: [dns-privacy] Alternative signalling propsals

[Daniel Kahn Gillmor]

On Fri 2018-12-14 17:43:44 -0500, Paul Wouters wrote:
> We fixed that with tls-dnssec-chain :P
>
> I'll leave it up to others to wonder why and how this did not move
> forward, and is now going via ISE.
>
> Sorry for the side-track of this discussion.

This isn't sidetrack at all, it was one of the motivating use cases of
tls-dnssec-chain-extension from my perspective, and particularly sad to
see it fail as a result. :(

--dkg

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

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

[Daniel Kahn Gillmor]

On Fri 2018-12-14 19:12:41 +0100, A. Schulze wrote:
> Am 11.12.18 um 06:38 schrieb Mukund Sivaraman:
>> There was some discussion in last night's meeting about encoding keys in
>> the DNS name of a nameserver, similar to DNSCurve. There are at least
>> some issues with it:
>> 1...4
>
> 5. Encoding a key as DNS name of a nameserver makes key rotation harder.
>Not impossible, but really much harder.

i agree that it makes it harder, but i'm not convinced that it is *much*
harder.

Pretty much all TLS stacks today will let you associate different
keys/certificates with different server names, so as long as resolvers
send SNI to their resolvers (should we MUST that?) then it works like
this:

As an authoritative server operator, for rotation, you'd:

 * create a new key
 * create a certificate for it (or just use TLS raw public key)
 * tell the TLS frontend to use both certificates/names
 * add a new NS record
 * remove the old NS record
 * once its TTL has expired, remove the old certificate/name

if you're serving many zones from a single authoritative server, it
would require you to update the NS records for all zones, though -- that
is maybe more of a challenge (especially if they all use different
registrars and you're trying to update glue) than the above process,
which is fairly well-defined.

But maybe it's worth reviewing what we're hoping to gain from the
keys-in-names approach too:

 a) indication that private queries are expected to work to this
particular resolver

 b) cryptographic identity material

If we care about both (a) and (b), then keys-in-names makes sense
(though it has the friction for rotation that you describe).

But what if we cared only about (a) ?  could we signal with a
special/magic terminal label just that private queries are expected to
work, without embedding a key there?

then we could rely on "the usual mechanisms" (the CA system, DANE) to
address the authenticity problem, rather than an embedded key.

For example, maybe the terminal label of your NS record could be
"yes-it-does-dot" :)

@ 1D IN NS yes-it-does-dot.a.ns.example.net.
@ 1D IN NS yes-it-does-dot.b.ns.example.net.

what do folks think about the tradeoffs there?

  --dkg



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

Re: [dns-privacy] Use of separate caches for plain and secure transports

[Daniel Kahn Gillmor]

On Fri 2018-12-14 11:47:58 -0800, Christopher Wood wrote:
> On Dec 14, 2018, 10:47 AM -0800, Wes Hardaker , wrote:
>> [And, no, we shouldn't go down the road of "privacy requires you disable
>> the cache"]
>
> Would you mind elaborating on this comment? As you observe, caches are
> harmful to privacy. Refusal to disable the cache in any (?)
> circumstance therefore seems dismissive of user privacy.  Perhaps you
> mean turning it off for every query is not a viable path forward?

I hope Wes will answer this question on his own, but i wanted to note
that privacy is not only harmed by caches.  it can also be helped by
caches.

A query for any name will typically radiate *less* information into the
world if it's answered from a cache, simply because the resolver in
question doesn't create additional traffic.

In particular, if the cache is already well-populated, and queries are
padded appropriately, and the name is relatively likely to be in-cache,
then the only parties that know what was looked up are the client and
the resolver itself.  No authoritative servers or network observers have
any additional information to distinguish the query from any other
cache-resolved query handled by the resolver.

So i don't think caching itself offers a clear benefit or harm for
privacy.  One advantage of a resolver is that it effectively acts as a
mixing/semi-anonymizing agent on behalf of its users.  Assuming that the
resolver itself is not compromised, it can buffer its users from the
authoritative servers.

  --dkg


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

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

[Daniel Kahn Gillmor]

On Fri 2018-12-14 03:30:29 +0530, Mukund Sivaraman wrote:
> I don't think this way. :) I think it will not support every RFC 1035
> DNS name, but only a subset of it. It should work for every valid name,
> because they are valid names and some application may want it. Why
> settle for hacks when it can be designed elegantly?

It depends on what elegance you're looking for.  There are ugly
real-world systems out there that can't support all kinds of new keys.

Furthermore, if you want a key digest to be bound to a specific name,
then either you incur an extra round trip (find out the name; then find
out the associated key digest) or you expect whoever ships the glue to
know how to ship additional glue cleverly.  not so elegant in terms of
actual delivery.

Stuffing a digest of a key in the name is useful in binding the key to
the server directly, without having to juggle multiple different RRsets.

So i agree -- it looks like a hack, and it does have some size limits.
but i don't think those limits are plausible for anything real-world to
hit, and compared to the other inelegancies, it seems pretty promising
to me.

>> you get the key by connecting to the server and receiving it as part of
>> the server handshake.
>
> Nod. (can't help thinking that's another roundtrip, but perhaps that
> can't be avoided.)

if we're talking about DNS-over-TLS, then the server's key is going to
come down the pipe in the TLS handshake anyway, so it's no significant
extra burden to expect it there.

  --dkg


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

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

[Daniel Kahn Gillmor]

Hi Mukund--

thanks for your prompt followup!

On Fri 2018-12-14 02:22:12 +0530, Mukund Sivaraman wrote:
> The trailing '='s are part of the base32 encoding.
>
> [muks@naina ~]$ echo -n 
> "MFRGGZDFMZTWQ2LKNNWG23TPOBYXE43UOV3HO6DZPI3TQOJQGEZA" | base32 -d
> abcdefghijklmnopqrstuvwxyz789012[muks@naina ~]$ echo -n 
> "MFRGGZDFMZTWQ2LKNNWG23TPOBYXE43UOV3HO6DZPI3TQOJQGEZA" | base32 -d
> abcdefghijklmnopqrstuvwxyz7890base32: invalid input
>
> This will not validate as a hostname label.

ah! good call, thanks.  so a "trailing-=-stripped b32 encoding" would
work OK, right?

I did the generation in python with:


base64.b32encode(hashlib.sha256(rawdata).digest()).decode('us-ascii').strip('=').lower()

it's not hard to re-add the = padding before re-decoding, based on the
length of the string, which will be a fixed length.

> Exhaust all the size of a DNS name except for a few characters and
> imagine a nameserver belongs under that zone. A scheme has to work and
> well for all extremes of DNS, not only a subset.

i think i disagree.  for one thing, we've talked about the ability to do
opportunistic connections even in the absence of a signal.  so for
nameservers located within extremely huge zones, they might just have to
rely on opportunistic connections.  But in practice, even for a
nameserver that *serves* a huge zone, its name doesn't need to be in the
zone.

Let's look at this from another angle: what sorts of limits are we
talking about here?

 https://tools.ietf.org/html/rfc1035#section-2.3.4

establishes the limits, in particular:

labels  63 octets or less
names   255 octets or less

so we're saying that the terminal label will consume 57 octets (52 for
the b32, 4 for "dot-", and 1 for the dot).  this means that the zones
that can contain such a label are limited to 198 octets.

The longest name in the public suffix list (https://publicsuffix.org) is
41 octets (without the trailing dot):
s3.dualstack.ap-northeast-1.amazonaws.com

so even any long-named zone within that longest public suffix still
leaves 157 octets for the intervening sub-zones -- space remains for
more than two full-length 63-octet labels.

So i'm not worried -- there will be other problems with long domain
names long before we hit this one.

> Nod, that may work too (how does one get the key then?)

you get the key by connecting to the server and receiving it as part of
the server handshake.

> If it can be demonstrated to work for near-future algorithms (next 2-3
> decades), then it's fine.

i don't think anyone knows yet what the acceptable algorithms will be in
25 years.  We can guess of course, but as the saying goes: prediction is
hard, especially about the future.

> It is over 13 years since RFC 4035 and DNSSEC is still not in widespread
> use. Features take time to be adopted and so if the proposed protocol
> will need revision to make it support another algorithm, then it'll take
> as many years from that time to be available, so we should future proof
> it a bit.

sure, but i don't want to future-proof it out of existence. :) sometimes
too much complexity added too early on a what-if basis can kill a
protocol as easily as an unforseen change that does eventually happen.

> Maybe.. I am just pointing out the issues. Perhaps there's some benefit
> in signing them and the address glue anyway, to stop resolvers from
> going off on wild chases due to some kinds of poisoning.

I appreciate your enumerating these concerns.  I hope my analysis is
helpful in giving some sort of reassurance that they're not a problem
for this sort of scheme.

--dkg


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

Re: [dns-privacy] Use of separate caches for plain and secure transports

[Daniel Kahn Gillmor]

Hi Mukund--

On Tue 2018-12-11 11:13:39 +0530, Mukund Sivaraman wrote:
> During last night's meeting, there was talk about use of a split-cache -
> one with answers learned from plain transports and another with answers
> learned via secure transports.

I think i was the one that mentioned that there *could* be a security or
privacy issue there.  fwiw, i really want the answer here to be "don't
worry about it, use a single cache", because that makes implementations
significantly easier.

In the long run, there might even be privacy or security tradeoffs here,
and we might decide that they're prices worth paying for the additional
implementation simplicity -- i don't know.

I just want to try to ensure that we've at least thought about some
potential downsides and mapped them out.

The degenerate scenario i'd painted on the call was:

 * consider a DPRIVE-capable DNS resolver; for whatever reason, only a
   single request has been made to it since it booted.

 * a new cleartext (non-private) request comes in for foo.example, and
   it does the lookups it needs to do, all in the clear. (private
   queries to authoritatives would have worked, but they weren't tried
   since the initial request was in the clear anyway).

 * a subsequent private request comes in to the resolver, and the
   resolver responds without doing any upstream lookup.

in this scenario, a passive observer of the resolver's traffic can infer
that the private query was likely also for foo.example (or at least, for
one of the names that needed resolution in order to get an answer for
foo.example, like NS records).

So this is a privacy leak, which could be mitigated by treating the
cache of RRs-accessed-in-the-clear as invalid for retrieval of the
private query unless private authoritative DNS is confirmed to be
unavailable.

There might be other effective mitigation besides a split cache,
though.  for example, preferring private queries upstream in the first
place for every query might offer some mitigation.

what do you think?

  --dkg


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

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

[Daniel Kahn Gillmor]

On Tue 2018-12-11 11:08:06 +0530, Mukund Sivaraman wrote:
> 1. The RDATA of an NS record has to be a hostname, so it would limit the
> amount of data that can be encoded within the NSDNAME. As an example,
> base32 encoding is not possible.

why is base32 encoding not possible for a hostname?

just for fun, i've stood up a new server.  It's not a DoT server, but
its name follows the guidance at:
https://knot-resolver.readthedocs.io/en/latest/modules.html#experimental-dns-over-tls-auto-discovery

https://longname.cmrg.net/
https://dot-fvyrmqvxe2yeialcpsu7xlbs6xefgd5rsa6mjwycewdrpeq2jcaq.nameservers.cmrg.net/

i had no trouble getting a certificate issued for it, and no problem
pointing NS records to the same name either (it's not running an
authoritative DNS server there, so it isn't fully connected, but that
has nothing to do with the name.

So the length of the name, and its ability to contain a base32-encoded
SHA256 digest is not an issue.

> 2. It would have to work for nameservers that are within a domain with a
> very long name already.

what are the length limits that you're concerned about?  if we make a
system that works for all nameservers that are within zones that are up
to (for example) 100 octets, that would be a huge win.

Remember that we're also talking about the nameserver's name itself, not
the zones it can serve.  so even longer zones can still work, as long as
their nameservers aren't in-bailiwick.

> 3. Let's assume it takes about 10 years for resolver->auth privacy
> transport to trickle into widespread operational availability. It is
> expected that quantum computers capable of obsoleting traditional crypto
> will be available in as few as 15-20 years from now. It is unclear if
> the limited length of keys that can be encoded into a subset of a DNS
> name would be sufficient for post-quantum crypto algorithms.

15 years ago, quantum computers were also 15-20 years away :)

I share your concerns about key length and post-quantum resistance, and
i wouldn't want to design a system that can *only* work with short keys.

However, at least one of the weird-naming-proposals on the table (the
knot-resolver experimental work above) is just stuffing a fixed-length
sha256 digest there -- that digest can cover PQ key material too.  If
the concern is an attack on sha256 itself, then we should think about
other ways to plan.

> 4. NS records returned as part of delegations are unsigned, so for a
> resolver to trust key information in the RDATA of such NS records in a
> delegation, it would require the delegation to be returned using secure
> transport to the parent-side nameserver of the zone cut. During last
> night's conversation, there was some talk about fallback to plain
> transports - it will not be useful unless the entire delegation from
> root is followed with secure transports.

I agree with you that there is a security gap here, as with most steps
of indirection.

But i'd temper the "will not be useful" a little bit -- maybe "will not
defend against active attackers on first connection" is more accurate?

At any rate, the NS record could itself be DNSSEC-signed, and a
suitably-cautious client could ask the server for its own NS record and
associated RRSIG (QNAME-minimized, of course) before asking for anything
else.

Does this address your concerns about the feasibility of encoding
(hashes of) keys in nameserver DNS names?

--dkg


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

Re: [dns-privacy] Opsdir last call review of draft-ietf-dprive-padding-policy-04

[Daniel Kahn Gillmor]

On Thu 2018-04-12 10:11:34 +0200, Alexander Mayrhofer wrote:
> I think it totally depends on the viewpoint (operational vs.
> "research-oriented"). Please share your preferred option - keep with
> CURRENT or restructure for NEW.

I prefer NEW (i like having the recommendation up front) but would not
be sad if we stuck with CURRENT either.

   --dkg

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

Re: [dns-privacy] Oblivious DNS

[Daniel Kahn Gillmor]

On Mon 2018-04-09 13:20:28 -0400, Daniel Kahn Gillmor wrote:
> People on this list might be interested in the recent "Oblivious DNS"
> work from Annie Edmundson, Paul Schmitt, and Nick Feamster

gah, i left off Jennifer Rexford from the list of researchers -- no
slight was intended by the oversight.

   --dkg

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

Re: [dns-privacy] Last Call:

[Daniel Kahn Gillmor]

On Wed 2018-03-21 04:11:40 -0700, DraftTracker Mail System wrote:
> Last Call Request has been submitted for
> 
>
> https://datatracker.ietf.org/doc/draft-ietf-dprive-padding-policy/

Yay, i'm glad to see this reach LC!

one NIT to deal with before publication:

in §4.3:

  Disadvantage: This policy requires a good source of (pseudo) which
   can keep up with the required message rates

is missing the word "randomness":

  Disadvantage: This policy requires a good source of (pseudo) randomness
   which can keep up with the required message rates

Sorry i didn't notice this earlier.

Many thanks to Alexander Mayrhofer for driving this through to
completion.

--dkg


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

Re: [dns-privacy] review of draft-ietf-dprive-dtls-and-tls-profiles-11: we should revert DNSSEC validation requirement

[Daniel Kahn Gillmor]

On Tue 2017-11-14 12:04:19 +0100, Sara Dickinson wrote:

> This draft is now ready to progress once a -12 version is available. I
> just want to circle back round to summarise the fact that the only
> proposed difference that will be in the -12 version compared to -11 is
> the following (in section 7.2. Direct configuration of ADN only):
>
> Current text:
>
> “It can then use Opportunistic DNS connections to an untrusted recursive
>DNS resolver to establish the IP address of the intended privacy-
>enabling DNS resolver by doing a lookup of A/ records.  Such
>records SHOULD be DNSSEC validated when using a Strict Usage profile
>and MUST be validated when using Opportunistic Privacy."
>
> New text:
> “It can then use Opportunistic DNS connections to an untrusted recursive
>DNS resolver to establish the IP address of the intended privacy-
>enabling DNS resolver by doing a lookup of A/ records. A 
>DNSSEC validating client SHOULD apply the same validation policy
>   to the A/ meta-query lookups as it does to other queries.
>   A client that does not validate DNSSEC SHOULD apply the same policy (if any)
>   to the A/ meta-query lookups as it does to other queries."
>
> I hope I captured the consensus correctly? Please let me know as I
> intend to put out the -12 (final) version next Monday (20th).

The text looks good to me.  thanks for taking care of this, Sara.

--dkg

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

Re: [dns-privacy] Why is draft-ietf-dprive-dtls-and-tls-profiles still blocked?

[Daniel Kahn Gillmor]

On Fri 2017-10-27 15:55:10 +0200, Stephane Bortzmeyer wrote:
> The datatracker tells us that draft-ietf-dprive-dtls-and-tls-profiles
> has a DISCUSS "This needs to be updated to indicate that the client
> MUST NOT offer 7250 unless it has a preconfigured SPKI, otherwise
> you're going to have interop problems."

I agree that this DISCUSS should be cleared, since draft-10 and draft-11
both state:

A client MUST only indicate support for raw public keys if it has an
SPKI pinset pre-configured (for interoperability reasons).

Regards,

--dkg


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

Re: [dns-privacy] review of draft-ietf-dprive-dtls-and-tls-profiles-11: we should revert DNSSEC validation requirement

[Daniel Kahn Gillmor]

On Mon 2017-10-30 13:11:41 +, Sara Dickinson wrote:
> I really do think a description there of the trade-offs of DNSSEC
> validation are warranted

I agree that a discussion of the tradeoffs involved in DNSSEC validation
of the opportunistic meta-query is warranted.  I just come to a
different conclusion than the requirements in draft-11.

> if it ends up just being a MAY (although I would like to see SHOULD as
> a minimum for opportunistic).

SHOULD validate, but with what failure mode?  are we really saying that
opportunistic SHOULD deliver a DoS instead of a loss of privacy?  I
discuss a few optional responses for failures in opportunistic mode
below.

> I can also recognise the implementation overhead, however this is
> required for only one of the 3 cases of how the client may be
> provisioned:
>
> * IP address only (no meta-query required)
>
> * IP address and ADN (no meta-query required)
>
> * ADN only (meta-query required)
>
> So it is for the case where a client was directly and securely
> configured with just the ADN of a server it expects to provide
> privacy. If a client doesn’t want to implement DNSSEC then it can
> always restrict the opportunistic profile to requiring one of the
> first 2 configurations.

The cheapest and simplest implementation in terms of user experience to
get to verifiable opportunistic profile (that is, a profile that can at
least report that DNS privacy has been achieved, even if it won't be
enforced) seems to be:

  * allow the local administrator to provide a name for the preferred
DNS resolver

Since it's opportunistic, it can even be enabled by default.

But this is the "ADN only" use case.  Saying it's not usable with the
opportunistic profile without DNSSEC validation would be a shame.

>> Choice 0 is the same outcome as the non-DNSSEC-validating scenario for
>> strict clients (no mitigation),
>
> Agreed - DNSSEC validation just provides earlier detection for Strict clients

or, converts success to failure in the case of DNSSEC misconfiguration
(because the connection would otherwise have succeeded) :(

> I’d disagree that connecting to a server for which the meta-query
> response failed DNSSEC validation results in _just_ a loss of privacy
> for Opportunistic in this case. If the answer was BOGUS then it seems
> reasonable to assume the server is not legitimate and so connecting
> also results in the clients' entire DNS service being controlled by
> the attacker.

sure, but this is the case for non-private DNS as well, right?  So the
mitigation in this case is with respect to the features that "private
DNS" is supposed to offer.  Whatever those features are, they are absent
given an attacker-controlled DNS resolver.  So if the DNS-over-TLS
server is intended to also provide integrity protection, yes, that would
also be lost.  I think we're agreeing here, right?  I apologize if "loss
of privacy" is a misleading shorthand.

> Take the case where the DNS server from DHCP really is legitimate. The
> fact that the meta-query answer _could_ be spoofed provides a vector
> for an opportunistic client to be directed to an attackers' DNS
> server. Note that this attack is not possible on a ’normal’ client
> that directly uses the DHCP provided server, the attacker has to
> attack each individual query. My concern here is that without DNSSEC
> validation of the re-direct Opportunistic clients have an additional
> risk of this kind of attack than ’normal’ ones.

ok, i think i understand.  The concern is that a non-network-controlling
attacker who can spoof DNS responses but can't spoof DHCP responses can
now take over full DNS resolution of opportunistic clients just by
racing (and winning) the legitimate metaquery response.

This is true, but the threat model we're worrying now include all of the
following characteristics:

 * attacker does not control the client's network (otherwise, they could
   redirect the port 853 queries anyway)
 
 * attacker cannot (or has failed to) race the client's DHCP connection
   (otherwise, they'd point to a different DNS server anyway)

 * attacker *can* race the legitimate response to the client's
   opportunistic metaquery.

 * client is in opportunistic mode.

So the question is, in this particular corner case, what is the right
mitigation to the scenario where "if DNSSEC validation of the
opportunistic metaquery fails…" ?

if the answer is "…proceed as though it had not failed (trying to
connect to the preferred server's proposed address), but continue
listening for another response to the metaquery; prefer subsequent
metaquery responses that do have DNSSEC validation over those responses
that are not DNSSEC validated." Then i'd be ok with it, but it's not
specified in the draft.

If the answer is "…hard-fail and deny DNS service", then i think that's
incorrect given the goals of opportunistic mode.

If the answer is "…stop trying to use opportunistic DNS privacy
entirely, but fall back to using the DHCP-provided resolver for 

Re: [dns-privacy] review of draft-ietf-dprive-dtls-and-tls-profiles-11: we should revert DNSSEC validation requirement

[Daniel Kahn Gillmor]

On Mon 2017-10-30 07:19:36 -0400, Paul Wouters wrote:
> Just to be clear. DNSSEC provides authentication of data. TLS provides
> privacy of data. Both are needed so I am against this proposed change
> to remove DNSSEC validation as a requirement. DNSSEC is part of the
> core DNS. It's not a cherry.

I'm not claiming that no clients should implement DNSSEC validation.  I
would be happy if every client did so.  Please don't mistake this as a
generic judgement on DNSSEC.  It's about one particular situation where
hard-fail is a bad idea.

In particular, the situation under discussion is what clients should do
in the event of a DNSSEC validation failure of an opportunistic
"meta-query".  As a reminder, the "opportunistic meta-query" is the
best-effort lookup of the IP address(es) of the preferred DNS privacy
resolver, under either Strict or Opportunistic profiles.

In either profile, the meta-query itself is opportunistic -- it's an
attempt to find some channel to the preferred resolver.  But let's look
at the two profiles separately:

 a) under the opportunistic profile, dropping the response to an
opportunistic meta-query in the event of a DNSSEC validation failure
transforms a loss of privacy into a DoS.  This does not meet the
stated goal of the opportunistic profile, "maximum chance of DNS
service".

 b) under the strict profile, dropping the response to an opportunistic
meta-query in the event of a DNSSEC validation failure will result
in the same outcome (DoS) where the response to the meta-query comes
from an attacker, because the attacker couldn't have provided a
valid TLS endpoint in the first place.  But in the scenario where
DNSSEC either isn't available, or is misconfigured, it converts a
successful connection attempt into a DoS.  This is a net loss for
the user.

Put more simply:

Opportunistic meta-queries are opportunistic.

Encouraging or requiring hard-fail to DNSSEC validation of an
opportunistic meta-query just amounts to a reduction of service, and
provides no security or privacy improvements that i can see.

If the goal is to enforce corroborative authentication of the DNS
privacy server (e.g. via both DNSSEC and the X.509 cartel), i welcome a
writeup of a "Extra Strict" profile that adds a DNSSEC validation
requirement to the Strict profile.  But that's not this draft.

 --dkg


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

Re: [dns-privacy] dprive (bar) BoF?

[Daniel Kahn Gillmor]

On Mon 2017-10-23 06:14:36 +, Alexander Mayrhofer wrote:

> since we're not scheduled for a session in Singapore - would anybody
> be interested in meeting up for a bar BoF during the meeting? eg. a
> lunch break?

I'd be interested.

--dkg

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

Re: [dns-privacy] Demultiplexing HTTP and DNS on the same listener

[Daniel Kahn Gillmor]

Thanks to everyone for their useful feedback and commentary.  I've just
uploaded draft-dkg-dprive-demux-dns-http-03, which attempts to include
the insights that people have shared here.

Most significantly, it drastically tightens the scope of the draft by
focusing on HTTP/1.x only and explicitly excluding HTTP/2 and all future
versions of HTTP.

As such, it can be seen as a stopgap measure until one of the
DNS-over-HTTP/2 drafts reaches consensus (and running code).  I'm
interested in seeing that happen, and will work on it, but i've got to
come up to speed on h2 and its implementations myself.  And in the
meantime, i think can be useful to document what is working today.

I welcome further feedback on the draft!

  --dkg

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

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

[Daniel Kahn Gillmor]

On Thu 2017-05-04 11:11:59 +1000, Martin Thomson wrote:
> On 4 May 2017 at 10:43, Daniel Kahn Gillmor <d...@fifthhorseman.net> wrote:
>> I address this in the draft section "Why not ALPN?" -- if anyone thinks
>> the text there could be improved, i'd be happy to hear suggestions for
>> how to change it.
>
> Mike is suggesting that you define one that is "http + dns" or maybe
> "http or dns", which would mean that you could use either.  Then you
> convince existing HTTP clients to use that (a few browsers would do
> the job).  Even if they didn't actually DO DNS, you would still be
> able to hide in the mass/mess that they represent.

hm, it sounds like that won't work for h2, given Patrick's point that h2
isn't client-speaks-first.  Right?  If we tried to do something like
"h2|dns", it seems like it would introduce a potential latency hit for
any h2-specific client that proposed it, because the server couldn't
send its first frame unsolicited.  I know you can't speak for Mozilla,
but would you imagine firefox opting into this for normal http/2
connections?

> In TLS 1.3, the server choice is hidden, so even where the server
> doesn't pick this choice, it works.  In TLS 1.2, you probably want to
> convince a few servers to pick this new thing, but that obviously
> means more work for those servers.

For http/1.x, the draft is arguing that using an ALPN label is
unnecessary -- so if that's right, what would we gain from a new ALPN
label over using the existing HTTP/1.1 mechanism (i.e., either no ALPN
or the ALPN token "http/1.1")?

It looks to me like the new ALPN label introduces costs:

 * implementations on both server and client need to specify it
 
 * client implementations need to verify that it was chosen, and fail if
   not
   
 * network monitors can see that it was offered and discriminate against
   the offerer at least (TLS 1.3), and in some cases the established
   connections (TLS 1.2 and earlier).

What are the benefits of introducing a new ALPN label for demuxing
HTTP/1.1 from DNS?

Thanks for the discussion,

 --dkg


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

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

[Daniel Kahn Gillmor]

On Wed 2017-05-03 20:49:22 -0400, Patrick McManus wrote:
> the http/1 share of https:// traffic is dwindling fast. Its down to about
> 1/3 of https for me. So if you're looking to hide in a big pool, that's a
> shrinking segment.

1/3 of https traffic is still huge collateral damage to inflict, if a
network adversary were to try to block things to stamp out encrypted DNS
traffic.

> imo its a bigger problem because any rfc that required h1 would
> dis-incentivize h2 which is something the IETF should surely not want to do
> for many reasons.

I also wouldn't want to disincentivize h2.  But any server which still
offers h1, at any time in the future could implement this approach with
relatively little overhead (and no impact on h2 adoption) and it already
works today.

So an updated draft would be intended mainly as a stopgap measure while
we're getting DNS-over-h2 spec'ed and implemented, and as something a
server can offer to clients that don't yet speak h2.

--dkg


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

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

[Daniel Kahn Gillmor]

On Wed 2017-05-03 20:37:21 -0400, Patrick McManus wrote:
>> is the draft you and Paul are working on different than
>> ietf-dnsop-dns-wireformat-http ?  Can they be reconciled?
>
> its a superset of that -more aligned with HTTP than that draft, but it can
> also carry wireformat.
>
> your work doesn't break it anymore than it breaks h2 generally :)

Is your draft h2-specific, or is it valid for http/1.x as well?

>> response to Roy T. Fielding (upthread) for why the demux approach seems
>> cleaner and safer for clients as long as we're using stream-based
>> transport.
>
> I totally support the end goal here of dns looking like https.. but
> honestly I didn't hear anything about cleaner and safer. I heard that you
> wanted to use the https port, the https alpn token, and constrain the http
> protocol, but found the requirement to implement http burdening :)

:) I'm not actually interested in constraining the http protocol, i'm
just trying to make something that works with existing versions of the
http protocol.  I documented my expectations of future versions of HTTP
to make sure that they're understood, which got me to your helpful point
about h2 not being client-speaks-first.  I've documented that here now,
btw:

https://gitlab.com/dkg/hddemux/issues/5

I'd expect this draft to work with no ALPN token at all (which is the
traditional HTTP/1.1-over-TLS use case, and ALPN is still not mandatory
for TLS, right?

the "cleaner and safer" remark was from the DNS client point of view:
they already implement DNS-over-TLS, they just need to be pointed to the
right server and the right port -- that's literally no change to the
existing code, and as long as they don't indicate an alpn of "h2" they
should be safe, right?

> The most straightforward way seems to make dns look like https is to
> actually carry it in https.
>
> perhaps we could work together on making a dns client more capable in
> this regard?

I'd be happy to do that to make something like this work with HTTP/2.
I'll contact you off-list about what might be sensible next steps.

It occurs to me that an h2 CONNECT stream to localhost:53 ought to be
sufficient to do a stream-based wireformat transition (assuming that
there was a local DNS-over-TCP service active).  Does that seem right to
you?  If that's the case, then a DNS-only client would "only" need to
know enough HTTP/2 to establish the connection and to parse the incoming
frames.  Are there specific advantages of making the protocol
entanglement more complex?



Given that not everyone is adopting HTTP/2 right away, though, do you
think the proposed draft would be acceptable if it was limited in scope
to demuxing DNS with HTTP/1.x?

Regards,

--dkg

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

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

[Daniel Kahn Gillmor]

On Thu 2017-05-04 10:21:20 +1000, Martin Thomson wrote:
> On 4 May 2017 at 10:14, Mike Bishop  wrote:
>> It's ALPN.  At first blush, I would pick a different ALPN token for
>> h2+DNS and define it as a new, derivative protocol.
>
> For DKG to realize his goal, every client would have to offer that
> label.  That's not impossible, nor does it make it a bad choice, but
> you have to realize that this isn't as good an outcome.

if you're going to define an ALPN label, you might as well just pick
"dns" and then do straight DNS-over-TLS with it (no need for in-stream
demuxing).  The problem with this approach is that the network monitor
can observe which clients are picking "dns" and which ones are picking
"http/1.1", which puts you back in the position where the network
adversary can trivially hobble DNS-over-TLS requests while permitting
HTTPS.

I address this in the draft section "Why not ALPN?" -- if anyone thinks
the text there could be improved, i'd be happy to hear suggestions for
how to change it.

All the best,

--dkg


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

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

[Daniel Kahn Gillmor]

Hi Alex--

On Wed 2017-05-03 17:34:47 -0600, Alex Rousskov wrote:
> On 05/03/2017 05:17 PM, Daniel Kahn Gillmor wrote:
>> The idea of the demuxing stage is that a server that opts into this would
>> put the demuxing *before* the HTTP/1 server implementation gets access
>> to the data.
>
> Think of the HTTP proxies, not just origin servers. Using an HTTP proxy
> is often _required_ when sending traffic over an HTTP port. These HTTP
> proxies will break all the muxed DNS traffic they will get. Opting them
> "in" will be a lot more difficult than opting a specialized origin
> server that wants to participate...
>
> And yes, this deployment concern applies to port 443 traffic as well,
> unfortunately.

Thanks for this, but i'm not sure i understand the whole situation
you're describing.  Can you help me make more sense of it?  Here's a few
things i think you might be saying:

 0) A DNS client shouldn't expect this mechanism to work in the clear
over port 80, because existing transparent HTTP proxies that the
client doesn't know about will likely choke on it.  I've noted this
as https://gitlab.com/dkg/hddemux/issues/3

 1) A DNS client shouldn't expect to use this mechanism through an
explicit HTTP proxy either, as the explicit proxy will also choke on
it.  However, i'm not sure how this works for port 443.  I think
you're saying that the common network interference pattern is to
block outbound TCP port 443 explicitly, but to allow HTTP CONNECT
when established through the local required HTTP proxy.  Is that
right?  I've tried to capture this as
https://gitlab.com/dkg/hddemux/issues/4

I'm not sure what the right tradeoffs are here, or how widespread such
network interference is.  I am aware that the draft under discussion
can't solve all problems for all networks.  But i imagine that any
network that blocks TCP port 443 outbound and expects clients to route
through an HTTP CONNECT to an explicit proxy has already blocked TCP
port 853 outbound, so the DNS client that tries to use DNS-over-TLS is
no worse off for trying 443 instead of 853, at any rate.

Am i missing some other details of the circumstances you're describing?
Do you have suggestions of text for the draft that would address these
concerns?

Regards,

--dkg


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

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

[Daniel Kahn Gillmor]

On Wed 2017-05-03 15:13:43 -0400, Patrick McManus wrote:
> I forgot to mention another potential challenge with the demux approach -
> h2 is not client send first.. typically both sides send SETTINGS
> simultaneously.. and its important to the server not to hold those back
> .5RTT as it can contain a bunch of configuration information (buffer
> sizing, levels of parallelism, extension negotiation, etc..) that it wants
> the client to start honoring asap. (Whether this is actually simultaneous
> boils down to which flavor of tls handshake is done.)

Ah!  Thanks for this heads-up.  That's definitely an interesting
wrinkle.  How does this interact with HTTP/1 clients connecting to the
service?  or is it only possible to do this because of the negotiated
ALPN?

If so, perhaps the demuxing needs to be done only when not sending an
alpn of "h2", and the draft can drop the HTTP/2 section.  What do you
think?

 --dkg


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

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

[Daniel Kahn Gillmor]

On Wed 2017-05-03 12:35:52 -0700, Roy T. Fielding wrote:
> I see no reason to suggest that spraying DNS on an HTTP connection would
> be interoperable.  HTTP/1.x has a tradition (good or bad) of allowing
> robust parsing of bad messages, which means no analysis of DNS uniqueness
> can guard against the potential variance of a thousand or so independent
> implementations of servers and intermediaries (there are at least four
> figures of independent server development in the craft-your-own-microserver
> category).

Perhaps the draft needs to be clear that this draft provides guidance
for servers that *want* to be able to distinguish a DNS-over-TLS stream
from an HTTP-over-TLS stream.  According to the published specs, a
server is within its rights to not treat invalid HTTP requests as valid
HTTP requests, right?

> In contrast, it is trivial to transform a DNS query into a GET request
> which can be handled by any current or future version of HTTP.
> All you need is the absolute URI, which is already defined, and a
> media type for the response payload.  That would just be using HTTP,
> so no need to call that an update either.

Agreed on this one, quoting from the draft:

If being able to interleave DNS queries with HTTP requests on a
single stream is desired, a strategy like
{{I-D.ietf-dnsop-dns-wireformat-http}} is recommended instead.

The advantage of draft-dkg-dprive-demux-dns-http over this approach is
that existing DNS-over-TLS clients (of which there are several) don't
need to learn any HTTP framing or parsing, and can simply be repointed
to a server that already supports this demultiplexing on port 443.

For folks in the HTTP world that might sound like "just use HTTP", but
for an existing DNS client, it's an entirely different codebase to adopt
(or to build), with all the attendant bugs and maintenance risks.

Regards,

--dkg


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

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

[Daniel Kahn Gillmor]

Hi Patrick--

On Wed 2017-05-03 14:57:24 -0400, Patrick McManus wrote:

> My initial response is that legacy HTTP/1 implementations will sink you by
> scanning for stuff that looks like HTTP in your stream - even if the
> leading bytes don't match the production those RFCs required (and HTTP/1.0
> is only informational anyhow). You can look at the websockets masking
> madness to see the lengths the community went to to avoid that kind of
> detection in rfc 6455.

Are you talking about an existing HTTP/1 server implementation?  The
idea of the demuxing stage is that a server that opts into this would
put the demuxing *before* the HTTP/1 server implementation gets access
to the data.

> Coincidentally I have a draft with Paul Hoffman that we're close to
> publishing, that describes how to do DNS over https:// in a way that I
> think will play better with both the http and dns ecosystems than previous
> work in that area. It wouldn't be a http-wg item though, we don't normally
> take FOO-over-HTTP drafts here. That might be a better option - if you want
> to use the https port, and the https alpn token, perhaps the https protocol
> (without constraining its future) is the right choice :)

is the draft you and Paul are working on different than
ietf-dnsop-dns-wireformat-http ?  Can they be reconciled?  See my
response to Roy T. Fielding (upthread) for why the demux approach seems
cleaner and safer for clients as long as we're using stream-based
transport.

I certainly wouldn't want this work to get in the way of
ietf-dnsop-dns-wireformat-http (or any similar proposal), but i don't
think it does.  does it?

--dkg


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

[dns-privacy] Demultiplexing HTTP and DNS on the same listener [New Version Notification for draft-dkg-dprive-demux-dns-http-02]

[Daniel Kahn Gillmor]

Hi HTTP folks--

I've just pushed a revision to a recent individual submission about a
technique for hiding DNS traffic that makes use of HTTP:

  https://datatracker.ietf.org/doc/draft-dkg-dprive-demux-dns-http/

It describes how a TLS server can offer both HTTPS and DNS-over-TLS on
the same port, because valid initial messages from the client in each
protocol are always distinguishable by the server.

I brought this up first over on the DPRIVE mailing list (in CC), and
i've made some initial cleanup and improvements based on the suggestions
i got there.  But i also wanted to bring this to the HTTP working group
for feedback, since it's possible that i've mischaracterized the current
state of HTTP in my analysis.  Please review and let me know if i've
gotten anything wrong!

Also, if adopted widely, the draft has implications for the future
evolution of stream-based HTTP as well as stream-based DNS (see below).
And Joe Touch pointed out that the draft should explicitly update the
HTTP as well as DNS specifications, so i've marked the latest revision
of the draft that way.  If you think that's OK (or if you think it's
unnecessary), please let me know!

Assumptions about HTTP
--

The main constraints that the draft places on future stream-based
versions of HTTP (that is, HTTP-over-TCP or HTTP-over-TLS, but not
HTTP-over-QUIC any other fun non-stream transport) are:

 (a) it assumes that stream-based HTTP will remain a client-speaks-first
 protocol.

 (b) it assumes that the first flight of data sent by the client without
 expecting a response from the server will be at least 14 octets.

 (c) it requires that none of the first 14 octets of the stream sent by
 the client to the server be below 0x0A (LF) or above 0x7F.

AFAICT, These constraints are already met by HTTP/1.0 and HTTP/1.1 and
HTTP/2, as documented in the draft.  Please tell me if that's wrong!

Given HTTP/2's "connection preface", i've imagined thus far that future
stream-based versions of HTTP would be fine having their own "connection
preface" that meets constraints (b) and (c), and i don't see how a
future version that listens on the same port as existing versions of
HTTP could in any way violate constraint (a).  I hope the members of
this fine WG will tell me otherwise if that's not a good assumption.

Also, if you review the draft and you think it's placing some additional
constraint on future versions of stream-based HTTP that i haven't
mentioned, please call it out!

Implementation status
-

I have a functional implementation listening behind a TLS frontend on
TCP port 443 on dns.cmrg.net right now, if anyone wants to experiment
with it.  Consider all the possibilities of this terrible layering
violation!

Both of these commands work just fine:

wget -O- https://dns.cmrg.net/

kdig +tls @dns.cmrg.net:443 www.ietf.org

The implementation is in C, freely-licensed, and available at
https://gitlab.com/dkg/hddemux for anyone who wants to play with it.

It's also available in Debian's unstable distro:
https://packages.debian.org/unstable/hddemux

Followup


The IETF mailing lists aren't well-structured for conversations that
need to happen between WGs.

I'm subscribed to both ietf-http...@w3.org and dns-privacy@ietf.org, and
i welcome feedback from both working groups.  But maybe some folks who
want to follow up are not subscribed to both.  Unless either WG
complains, i encourage followup to be made to both mailing lists unless
it's clearly specific to one protocol only, and i humbly ask admins of
both lists to allow traffic from the other community through.

Minor editorial cleanup can be made as a merge request or issue at
https://gitlab.com/dkg/hddemux or by private e-mail.

Regards,

--dkg


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

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

[Daniel Kahn Gillmor]

Hi Joe--

Thanks for the feedback!

On Thu 2017-04-27 10:13:54 -0700, Joe Touch wrote:

> Speaking as an IANA ports team reviewer:
>
> IMO this document needs to UPDATE the HTTPS specification.

The draft isn't strictly about HTTPS, though that context is certainly a
prime motivating factor.

It's about demultiplexing cleartext, streamed DNS from cleartext,
streamed HTTP.  This just happens to mainly be useful in evading network
surveillance and censorship under cover of TLS :)

That said, i definitely agree that the draft needs more input from the
HTTP community.  In particular, if this approach gets deployed widely,
we'd want to ensure that future stream-based versions of HTTP are aware
of this demuxing algorithm and don't create a start-of-stream signature
that the algorithm might confuse with DNS.

But will there be future stream-based versions of HTTP?  afaict,
HTTP-over-QUIC is likely to be the future of HTTP, and that's a place
where this demuxing approach explicitly does not apply (since it's not
stream-based).  So maybe it'll turn out that the draft doesn't scare the
HTTP community much.  We should encourage their review!

I initially sent the doc for discussion here in DPRIVE because DPRIVE
offers one of the primary motivations for the work, and to make sure i
wasn't missing anything crucial from the DNS side. But i'm certainly
planning to bring the document to the attention of HTTP-specific groups.
Perhaps http...@ietf.org comes next?  I'm open to other suggestions.

> Keep in mind that any bit pattern that you *think* differentiates DNS
> from HTTPS is not yours to define - it is the purview of HTTPS to define
> or delegate in any way they see fit.

I hope it's clear from the draft that it's not defining any
differentiating bit pattern.  Rather, it's pointing out that the
existing specifications *already* define necessarily distinguishable bit
patterns.

> You can certainly ask IANA for a new port on which to run both HTTPS and
> DNS, but it is inappropriate to change port 443 without coordination.

This seems unlikely to achieve any useful goal -- existing HTTPS isn't
going to move to a new port, which means traffic on that port would be
suspect to a would-be censor or a pervasive monitor, right?

Joe, as a thought experiment, as an IANA ports reviewer, if both the
HTTP and DNS communities were to decide that some version of draft seems
OK to them, what would you want the IANA Considerations section to look
like?

--dkg


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

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

[Daniel Kahn Gillmor]

Hi Jan--

On Wed 2017-04-26 11:05:33 +0200, Jan Včelák wrote:
> thank you for writing this down. The draft is great. And it's awesome
> that it's accompanied with an actual running code.

thanks!  and thanks for the quick review :)

> A have just a few notes after reading the draft for the first time:
> - For the sake of simplicity, I would suggest dropping the part about
> HTTP/0.9. I don't think it's worth the effort keeping it supported.

That would definitely make the document much simpler :) I suppose i
should float this by the HTTP community, to see whether they agree that
it's ok to drop HTTP/0.9.

> - The Section 3 (Overview of initial octets) is a little bit chaotic
> and scattered. Maybe it would be more readable if you just provided
> pointers to specification of the protocols without providing much
> details, then shown the initial octets (or headers) side by side
> without analysing the content, and in the end walked by the bytes from
> the beginning while discussing the values.

I understand what you're saying, i'm not sure how to do this exactly.
With DNS, the fields are fixed size and have fixed meaning, but with
HTTP, there's an abstract grammar.  So they don't just "line up" side by
side, as it were.

I can certainly remove the copied text and just leave pointers to other
documents, but that seems like it effectively asks the reader to do a
bunch of pointer chasing when i've already done the pointer-chasing for
them.

Any concrete suggestions for how to improve it?  It's maintained in
markdown at https://gitlab.com/dkg/hddemux and i welcome merge requests
or patches!

> - I love how simple the algorithm is in the end. And the proof is
> great.

I'm glad you like it too -- i'm happy that it seems possible to be
strictly confident in the demuxing.

  --dkg


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

Re: [dns-privacy] DNS over DTLS

[Daniel Kahn Gillmor]

On Fri 2016-12-02 01:22:40 -0500, Tariq Saraj wrote:
> Thanks for your detailed reply, the point I am trying to highlight is the
> changes in TCP for DNS which is "TCP out of order packet delivery, i.e. the
> OOOP".

I think you're referring to "out of order processing" for DNS requests
by a recursive resolver.  While necessary for reasonable performance
over TCP, I don't think this approach remediates TCP
head-of-line-blocking.

imagine a client who makes two queries across a TCP connection in rapid
succession, the first for slow.example and the second for fast.example.

many traditional (old, unoptimized) DNS recursive resolvers will try to
find the answer for slow.example before they even start making the
queries needed for fast.example.  they might not even read the second
query from the TCP connection before responding to the first one.

OOOP says that a DNS recursive resolver should read queries as they come
in over TCP, even if it still has responses pending for other queries
from that connection.

IOW, the dns resolution *itself* should not block based on slow DNS
responses from the authoritative servers it queries.

but none of that resolves the problem of TCP head-of-line blocking.  if
one packet carrying a query on one TCP connection gets dropped, the
receiving server can't see any of the rest of the packets until the
earlier packet is re-sent.  (and vice versa for replies going from
recursor to stub)

does this make sense?

 --dkg

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

Re: [dns-privacy] Call for Adoption: draft-mayrhofer-dprive-padding-profile

[Daniel Kahn Gillmor]

On Fri 2016-11-18 13:42:08 +0900, Warren Kumari  wrote:
> This starts a Call for Adoption for draft-mayrhofer-dprive-padding-profile.
 [...]
> Please also indicate if you are willing to contribute text, review, etc.

As i said in the meeting Friday, I support WG adoption of this document.
Implementors need guidance, and implementations should avoid being
fingerprintable.

nitpick: i think it should be called "dprive-padding-policy" instead of
dprive-padding-profile" so that it's harder to confuse with the
authentication profiles document.

> In addition, to satisfy RFC 6702 ("Promoting Compliance with
> Intellectual Property Rights (IPR)"):
> If you are personally aware of any IPR that applies to
> draft-mayrhofer-dprive-padding-profile, has this IPR been disclosed in
> compliance with IETF IPR rules? (See RFCs 3979, 4879, 3669, and 5378
> for more details.)

I'm unaware of any IPR that applies to this work.

--dkg


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

Re: [dns-privacy] ENDS0 Padding Profile: Rough first draft

[Daniel Kahn Gillmor]

Thanks for
https://tools.ietf.org/html/draft-mayrhofer-dprive-padding-profile-00,
Alex!

On Tue 2016-11-01 07:09:28 -0400, Hugo Connery wrote:
> The list of strategies looks great.  Perhaps you could mention
> the "pad the message to the maximum possible message length"
> explicitly as a sub-case of "Block Length Padding".

The draft does mention "the maximum message length as dictated by
protocol negotiations" in the "General Guidance" section, but doesn't
make it an explicit padding option, or spell out what it is.  if you're
going to talk about "maximum possible message length" then it becomes
necessary to think about that here.

Note that the limits are different depending on whether you're using UDP
(DTLS) or TCP (TLS), and that the UDP limit depends on the underlying
MTU, which servers might not know.  the length limit over TCP (TLS)
connections is arguably bounded by either the size of the DNS query (16
bits?) or the TLS record boundary (2^14 + 1024, see
https://tools.ietf.org/html/rfc5246#page-21).

It might be worthwhile to have some discussion about choosing packet
size of the (D)TLS cleartext vs. packet size of the TLS ciphertext,
since those can be different values.

In implementations i've done, it's often much easier to pad the
cleartext to a fixed size, and to ensure that the security
considerations of https://tools.ietf.org/html/rfc7830#section-6 are
followed and that TLS compression is *off*.

Bob Harold wrote:

> Yes, I hope that the final document specifies all options, including
> the bad ones, and provides clear descriptions about the trade-offs
> involved.

I'm not convinced that documenting all possible patterns, including the
bad ones is a great strategy for a standards-track document.  I'd much
rather this document pick a single strategy, endorse it clearly, and
maybe at most include a mention of a few other strategies and why those
strategies are not recommended.

We want to make things *easier* for implementers, not harder.

fwiw, i'm puzzled by the claim that "Random Length Padding [...] is (at
first glance) the best strategy".  At first glance, i am not necessarily
convinced of this -- i found "block length padding" to be the easiest
and most understandable strategy when implementing.

(I'm also not convinced that a well-seeded, efficient CSPRNG would be
any sort of noticable hindrance to a server doing DNS-over-TLS at
wirespeed, but it's simply not necessary for block-length padding)

One missing proposal is "power of two padding" -- pad up to the nearest
power of two, with some minimum.  For example, pad up to 128 octets, and
then pad to 256 octets, 512 octets, 1024 octets, etc.

What would be really great (not as a standards draft, but as a regular
study) would be to frame the problem as an adversarial analysis "game",
taking samples of real-world DNS traffic, and see what can be inferred
From each of these strategies.  That might help to quantify the
differences between the schemes.

--dkg

PS you've got RFC 7803 where you mean RFC 7830


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

Re: [dns-privacy] DPRIVE client with captive portal

[Daniel Kahn Gillmor]

On Mon 2016-08-08 21:41:20 -0400, Dan Wing wrote:
> Thanks.  I searched that document, but my search terms were inadequate to 
> find the necessary text.

patches welcome are for changes to
draft-ietf-dprive-dtls-and-tls-profiles that would have matched your
search terms :)

   --dkg

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

Re: [dns-privacy] DNS + 0-RTT

[Daniel Kahn Gillmor]

On Wed 2016-04-06 11:08:55 -0300, Colm MacCárthaigh wrote:
>  On Wed, Apr 6, 2016 at 6:03 AM, Daniel Kahn Gillmor <d...@fifthhorseman.net> 
> wrote:
>
>  > forward secrecy
>  > ---
>  >
>  > IIUC for (b), the failing forward secrecy window is constrained by the
>  > duration of the PSK/session resumption ticket.  That's doesn't seem
>  > particularly worrisome to me for DNS.
>
>  I'd expect many operators to re-use ticket encryption keys for far too
>  long, as we see with HTTPS today, so the effect is that a dns server bug
>  may unlock years of 0RTT data. For DNS, the query is always likely to fit
>  in there.

This would be a good argument against doing any sort of session
resumption, i think, not just 0-RTT.

>  > replay protection
>  > -
>  >
>  > For DNS we don't particularly care about replay attacks initially, but
>  > replayable traffic might have some privacy implications.
>  >
>  > For example, if Mallory can monitor the traffic to and from the DNS
>  > resolver, and a TLS-wrapped DNS request is made that is answered from
>  > the cache, then the attacker has no additional information about what
>  > the answer is.
>  >
>  > But if the request is replayable, Mallory can capture it, and replay it
>  > at different intervals (when parts of the cache might be expired) to try
>  > to coax the recursor to call out to the authoritative resolvers, which
>  > might provide more information about the original query.
>
>  There's a simpler attack too; if the RRSet contains multiple RRs, it's
>  common for resolvers to rotate the order of the RRs in a fixed and
>  predictable order. So you can query a name you suspect was queried, then
>  replay the target query, then query the name again, and confirm your
>  suspicion.

Just to make sure i understand this attack: suppose the rotation of two
RRs returned for a given response goes:

  A,B
  B,A
  A,B
  ...

Then the attacker would query, note the order, replay, then query again.
if the order received each time was the same, it's strongly suggestive
that it was the correct guess.  Is that the proposed attack?

>  This requires only a copy of the target 0RTT section, and access
>  to query the resolver, so a typical wifi scenario would do. Multi-RR
>  responses are very common these days too.

It strikes me that we should discourage privacy-sensitive resolvers from
employing this pattern. though i'm not sure where that documentation
would go or how to write it.  Is there a term for this kind of stateful
response history leakage?

thanks for pointing it out.

 --dkg

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

Re: [dns-privacy] DNS + 0-RTT

[Daniel Kahn Gillmor]

On Tue 2016-04-05 14:07:27 -0300, Tim Wicinski  wrote:
> As many of you are aware, with the TLS1.3 spec, there is some security 
> concerns around DNS+TLS1.3 0-RTT.  dkg put together some threat models 
> and instead of forwarding some long thread, I figure I would put this 
> out there and let Mr. Gilmor lay out his theories.

Thanks for the nudge, Tim!

There are several different subtle security considerations with 0-RTT:

 a) no client authentication
 b) limited forward secrecy
 c) no replay protection
 d) client linkability

I assume we're not talking about DTLS here, so i'm going to omit any
concerns about:

 e) UDP-style spoofing/flooding/reflection attacks

Have i missed anything?

Also, i might be confused below about the state of 0-RTT and how it
relates to PSK and session-resumption, though i'm more confident in my
understanding based on the TLS WG discussion yesterday.  But please
correct me if i'm confused!

client auth
---

For standard DNS traffic, i think we don't care about property (a).
that's good!

forward secrecy
---

IIUC for (b), the failing forward secrecy window is constrained by the
duration of the PSK/session resumption ticket.  That's doesn't seem
particularly worrisome to me for DNS.

replay protection
-

For DNS we don't particularly care about replay attacks initially, but
replayable traffic might have some privacy implications.

For example, if Mallory can monitor the traffic to and from the DNS
resolver, and a TLS-wrapped DNS request is made that is answered from
the cache, then the attacker has no additional information about what
the answer is.

But if the request is replayable, Mallory can capture it, and replay it
at different intervals (when parts of the cache might be expired) to try
to coax the recursor to call out to the authoritative resolvers, which
might provide more information about the original query.

This is a minor leak, but probably not something to completely ignore.

client linkability
--

(this is in some sense the inverse of "no client authentication": we're
worried that the protocol might allow the server (or others) to identify
clients with greater precision than the client wants)

The TLS client doing 0-RTT can be linked by the server to their previous
session. If the client constrains itself to using each resumption ticket
exactly once, then it limits its linkability exposure to the DNS server.
If the client reuses the resumption ticket, then its sessions are
linkable by any network monitor.

Note that persistent TLS sessions that carry multiple DNS queries of
course have the same "linkability exposure" for queries within a single
TLS session, so it's not *just* a problem for 0-RTT.  and non-0-RTT
session resumption has exactly the same linkability exposure as 0-RTT,
aiui.  So this concern isn't specific to 0-RTT, but if a client wants to
limit its linkability exposure i think it will by definition limit its
use of 0-RTT.

What are the privacy risks of linkability?

 * The DNS server can establish a profile of a given user and their
   interests, even distinguishing between different users behind a LAN
   (or on a shared host with separate resolver sessions)

 * the DNS server (or network observer, in the case of reused session
   tickets) can track a given user as they move across the network,
   unless the client flushes its resumption cache upon network change.

Sadly, this linkability exposure risk is a net loss compared to
cleartext DNS, even compared with cleartext DNS with EDNS0 cookies :/

---

So, in conclusion, i think that DNS+TLS-1.3+0-RTT is not too scary.

That said, i'm not convinced that the savings of one round trip time is
particularly significant for the stub-to-resolver use case.  If the
connection is a long-standing connection that stays open (as we expect
for stub-to-resolver), the extra 1-RTT is amortized across lots of
queries; so it's not clear that connection setup speed is as important
in this case.

If we could have a story about how to mitigate the replay attack
concerns (which are already pretty minor), then the linkability concerns
are the only thing that remain, and those can be mitigated by
client-side policy about session ticket reuse (which would basically
extend to policy about when to use 0-RTT and when not to)

I'd be curious to think through how this all relates to TCP Fast Open if
anyone wants to brainstorm it with me.

   --dkg


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

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

[Daniel Kahn Gillmor]

On Mon 2016-01-25 12:26:59 -0500, Alex Mayrhofer 
 wrote:

> This version addresses comments received since the publication of the
> last draft version, including the WGLC comments.
>
> The only bigger change is that (in line with the comments received)
> I've generalized the text about Non-0x00 padding octects, based on
> text suggested by Andreas Gustaffson

Thanks for the update, Alex.  I think the new revision looks fine.

nit-pick: the Introduction now has the phrase "meta data of could
  still", which looks like an editing error.  i think you can
  just drop the word "of".

regards,

 --dkg

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

Re: [dns-privacy] 2nd WGLC for draft-ietf-dprive-dns-over-tls-02.

[Daniel Kahn Gillmor]

On Wed 2015-12-09 18:12:41 -0500, Christian Huitema  wrote:

> However, I am a bit skeptical of some of the requirement to provide
> "two or more pins" for each server. This assumes a specific model of
> out-of-band provisioning, and it also assumes that servers always have
> a second key to fallback to if the first one is compromised.

To clarify this: it requires server *operators* to prepare and have
available a second key for fallback.  It does not require the server
itself to have access to both keys concurrently.

> That may be true in many deployments, but that will not always be
> true. For example, just after a fallback, it will take some time for a
> second key to become available.

I think the implication here is that as soon as a compromise happens,
the servers may no longer use the original key.  This isn't how things
are likely to work in practice.  In practice, a key compromise and
rollover will have a timeline like this:

 Time   Action  Key used Keys Permitted
by serveron updated client
   
  0SetupAA,B
  
  1Compromise   AA,B
  
  2Compromise   AA,B
   Discovered 

  3Backup key   BA,B
   Deployed

  4New Pins BB,C
   Announced
   (OOB)


The time i think you're talking about is the time between 1 and 3,
right?  Key A, despite being known-compromised, does not become unusable
until step 4 has completed.  This is slower than we might like, but it
also allows for smooth service upgrades and no failures in service while
the operator waits for the action in step 4 to take effect across all
connected clients.

> Another model would be for clients to proactively refresh the pins
> that are nearing end-of-life, or maybe perform periodic updates. I
> would suggest replacing the text in section 4.2 between "MUST deploy"
> and "future key rollover" by something less imperative, like "SHOULD
> deploy a backup pin along with the primary pin, for the reasons
> explained in [RFC7479]."

If a server operator deploys this scheme with a pinset containing only
one pin, and they have more than one client, then they cannot change
their service key without either (a) coordinating a simultaneous
rollover between all clients, or (b) causing service interruption for
some clients.  This is effectively an unmaintainable system, and we
should not provide the wiggle-room to say that an unmaintainable service
is compliant with the specification.

> The mechanism is also somewhat under-specified, because RFC7469 pins
> can differ in many ways, besides pinning different keys. For example,
> they could be computed in the future using different hash algorithms,

HSTS has explicitly decided to not specify multiple algorithms now, and
will deal with subsequent algorithms with an update when SHA-256 is
nearing end-of-life.  I see no reason for this authentication mechanism
for dprive should be more specific.

> they may have different life times, they may include subdomains, or
> they may have different purposes such as "report-only."

None of these features are relevant to this dprive authentication
mechanism, which explicitly states that the pinsets are per-endpoint
(not associated with a name at all), are fail-closed, and must be
updated in some out-of-band process.  (yes, the "some out-of-band
process" is deliberately not specified -- that's the piece that an
implementer needs to handle on their own).

   --dkg

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

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

[Daniel Kahn Gillmor]

tl;dr: It's not this simple, and we should not try to use this draft to
specify padding policy.

below are some pointers about why it's not so simple.  If you want to
make a separate draft about padding policy, i'm happy to have that
discussion there, but please don't hold this mechanism draft up for the
sake of policy discussion.

On Tue 2015-11-24 18:15:44 -0500, Mark Andrews wrote:
> Padding is there to make responses indistigishable from each other.

Padding for the sake of defeating traffic analysis is also about making
queries indistinguishable from each other, and about making combinations
of queries and responses indistinguishable from each other.

> For UDP pad to the requested UDP message size. 

Traffic analysis countermeasures are only useful when the content is
encrypted.  so presumably when you say "For UDP pad..." you mean for
DNS-over-DTLS?  and "For TCP pad..." means for DNS-over-TLS?  TLS and
DTLS themselves have per-message overhead, which itself may vary
depending on the ciphersuites used.

> For TCP pad to the largest response size sent so far.

Is that the largest repsonse ever sent by the server so far?  or ever
sent by the server in the current TCP connection?  or ever sent to the
specific IP address?

> This gives you roughly less than or bigger than 512, 12xx, 14xx and
> 4096 depending upon whether the query is retried over TCP or not
> and the requested EDNS UDP size.

enumerating the bins and anonymity sets is useful, but this breakdown
seems like it's missing request/response pairings and other kinds of
info leakage.  I'd love to have a discussion about optimizing padding
policy for the sake of DNS privacy with this sort of explicit bin
enumeration and some attempts to categorize things with actual data from
actual DNS request patterns.

But discussion around this draft is not the place for it.

 --dkg

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

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

[Daniel Kahn Gillmor]

On Tue 2015-11-24 07:19:47 -0500, Alex Mayrhofer wrote:

> I've submitted a new version of the EDNS0 padding draft. The only major 
> change is that it does now allow for non-0x00 padding octets. I think 
> this was the (rough) consensus of the respective WG list discussion.

Thanks Alex!  a couple more comments...

---

   The PADDING octets SHOULD be set to 0x00.  Application developers who
   are concerned about misguided lower layer compression MAY instead
   fill the PADDING octets with the output of a cryptographic random
   number generator.  Responders MUST NOT reject messages containing
   non-0x00 PADDING octets.

I'm thinking we could add a sentence just before the last one here
"Applications MUST NOT send uninitialized memory in the padding octets."
to try to stave off another heartbleed opportunity.

(not that it will stop wilfully bad programmers, but at least we'll be
able to say "I told you so")

---

   Responders MUST pad DNS responses when the respective DNS query
   included the 'Padding' option, unless doing so would violate the
   maximum UDP payload size.

I'm not sure about this directive.  Without telling responders how much
to pad (e.g. by multiples of 512-octet blocks?  by powers of two?  by
some other statistical distribution?), this requirement doesn't provide
any additional metadata protection, and it's just an additional 4
octets on each packet.

I don't think this draft should try to tell implementers how much to pad
(i'd prefer to keep the draft simple and have it describe mechanism and
not policy), so i think this requirement is out of place.  I think it
could be dropped altogether.  But if it is not dropped, it should be
converted to a much weaker statement than this MUST.

Regards,

  --dkg

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

Re: [dns-privacy] Non-zero padding (was EDNS0 padding with non-0 MUST respond with FORMERR?)

[Daniel Kahn Gillmor]

On Wed 2015-11-18 15:45:51 -0500, Stephane Bortzmeyer wrote:
> On Wed, Nov 18, 2015 at 11:30:53AM +1300,
>  Alex Mayrhofer  wrote 
>  a message of 207 lines which said:
>
>> - I think we should stick with requiring 0x00 padding (I am avoiding
>> the term 'payload' here for a reason). This would prevent the abuse
>> as a covert channel,
>
> -1 for me. I agree with Mark Andrews that "preventing the use as a
> covert channel" is a non-goal (you cannot prevent two willing entities
> to set up anything as a covert channel).

I agree that we can't prevent them, and that it probably doesn't make
sense to allow recipients of non-zero padding to reject the packets.

Consider that a recipient that is not padding-aware will not reject the
packets; having a padding-aware recipient reject them seems like an
extra interop failure.  And as Alex said earlier:

>> If we find out this is really a problem, we can always define a
>> padding with more sophisticated contents which Updates or Obsoletes
>> this document. Requiring that a Responder ignores the contents would
>> create forward compatibility on the Responder end.

So i think that we should still say that a packet sender MUST pad with
all-zeros for this draft, even though a recipient MUST NOT reject a
query or response just because it a non-zero octet in its padding.

In addition to compatibility with future versions, we don't want to
encourage another heartbleed where uninitialized memory goes out on the
wire.  And we don't want to encourage people to leak big chunks of their
raw CSPRNG output to their correspondent.

   --dkg

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

Re: [dns-privacy] Non-zero padding (was EDNS0 padding with non-0 MUST respond with FORMERR?)

[Daniel Kahn Gillmor]

On Mon 2015-11-16 11:32:57 -0500, Shane Kerr wrote:
> Probably a paragraph saying "turn off TLS compression" is a better
> approach than trying to figure out how to defeat the compression?

yes, please.  The consensus of the TLS WG is that compression simply
does not belong at the TLS layer, that it was a mistake to put it there
in the first place, and that it will not be supported in the future.

Any attempt at compression needs to happen at the application layer
itself with full knowledge of the risks and tradeoffs. This implies that
if DNS cares about compression, it needs to write DNS-specific
compression rules, and those rules themselves need to clearly grapple
with what to do with packet padding when DNS-specific compression is
used.

I'm not proposaing that the DNS community do any sort of work on
compression right now.  We just need a simple statement that padding is
only expected to be useful against traffic analysis under encrypted
and non-compressed connections.

--dkg

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

Re: [dns-privacy] Non-zero padding (was EDNS0 padding with non-0 MUST respond with FORMERR?)

[Daniel Kahn Gillmor]

On Mon 2015-11-16 16:20:21 -0500, Stephen Farrell wrote:
> I agree that that is clearly the opinion in the TLS WG today. I'm
> less sure I agree that's correct - my fear is that it's being driven
> maybe too much by browsers and the web, where the conclusion is
> valid.

Well, certainly for a system-wide (or application-wide) arbitrary DNS
client it's the same risk.  We have no way of knowing how many avenues
there are for attackers to be able to make the user make certain DNS
requests to their preferred privacy-preserving resolver.

And since we expect (D)TLS channels to be kept open and reused, that
attacker-controlled data will be touching the same deflate dictionary
that the ostensibly private queries are using.  This is the same
scenario as CRIME and BREACH, no?

>> Any attempt at compression needs to happen at the application layer
>> itself with full knowledge of the risks and tradeoffs. 
>
> FWIW, I don't agree with the above, I think it's generalising too
> much from the browser use-case.

The point here is that if you don't know how the application layer mixes
attacker-controlled data with data that needs to be confidential, TLS
can't possibly do compression safely.

So while i agree with you that there could be (non-browser) applications
that clearly never mix any attacker-controlled data with
sensitive/private data on the same TLS channel, the only way to know
whether you're in such a state is by reasoning about it *at the
application layer*, which is why that's where the decisions about
compression need to be made.

anyway, i'm glad we agree on the outcome :)

 --dkg

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

Re: [dns-privacy] Call for Adoption: draft-mayrhofer-edns0-padding

[Daniel Kahn Gillmor]

On Tue 2015-11-03 21:54:27 +0900, Tim Wicinski wrote:
> During the meeting on Monday, it was obvious the Working Group wanted to 
> make this an official EDNS option.  We reached out to the author and 
> while he is traveling for an extended period of time, he is happy to 
> work on edits (with a small delay built in, but nothing this impatient 
> chair finds too onerous).
>
> This starts a Call for Adoption for draft-mayrhofer-edns0-padding
>
> The draft is available here:
> https://datatracker.ietf.org/doc/draft-mayrhofer-edns0-padding/
>
> 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.

I support adoption of this draft.  I have reviewed it and think it is
sensible.

I have also implemented it for queries in the getdns client library, and
it worked fine in communication with servers listening over TLS, making
otherwise-distinguishable queries indistinguishable to a network
observer:

   Table 0. Ethernet Frame sizes for packet containing DNS query

Transport|   query to   | query to
   used  |  example.com |  www.example.com
   --+--+---
   cleartext UDP |   82 octets  |   86 octets
   cleartext TCP |  108 octets  |  112 octets
TLS over TCP |  137 octets  |  141 octets
(padded to 512) TLS over TCP |  609 octets  |  609 octets


I used a value from the local/experimental range of DNS options (i chose
65461), but i'd like to move to using a standard EDNS(0) OPT code.  

The registry here:

  
https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-11

suggests that the registration procedure is "Expert Review", and points
to Olafur, who i'm Cc'ing here.

Can we ask for early codepoint assignment?  The registry has a lot of
space, and the draft is simple and easy to implement.

Regards,

--dkg

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

Re: [dns-privacy] Direction of draft-mayrhofer-edns0-padding

[Daniel Kahn Gillmor]

Hi folks--

On Wed 2015-07-29 09:41:10 -0400, Paul Hoffman wrote:
 On 29 Jul 2015, at 5:28, Alexander Mayrhofer wrote:
 I'm working through my notes from the DPRIVE session regarding the 
 EDNS0 Padding option. My takeaway was as follows:

 - Generally, this seems to be a reasonable idea

 That may be too strong of an assessment. There were questions about 
 whether the padding should be done in DNS or in TLS. My personal view is 
 that if the two types of padding give similar benefits, it absolutely 
 should be done in TLS for many reasons. I think we need to get more 
 input (possibly from CFRG) about the benefits of padding at each layer.

In the TLS WG, the broad consensus is that if padding is possible at the
application layer, that is the right place to pad.  The rationale
concerns countermeasures to traffic analysis -- in particular, the
application layer has much more knowledge than the TLS layer about what
its traffic generally looks like.  traffic analysis countermeasures are
subtle and closely tied to existing patterns of usage.  TLS is an
abstraction that is intentionally removed from what the application
layer does.

Also, there is no padding mechanism available in TLS at the moment :)
i'm trying to get one into TLS 1.3 for those application layers that
have nowhere to pad, and i could conceivably write up an extension to
TLS 1.2.  But even having that mechanism, you'd need to be able to set
policy about when to pad and by how much.

So from the thinking and work i've done on this, padding at the
application layer is preferable where possible.  Paul, you say you have
many reasons for wanting to do it in TLS -- can you explain some of
those a bit more?  I want to make sure i'm not missing anything vital.

 - Besides the use to evade size-based message correlation, this could 
 also be useful in other cases, eg. proof of work for clients when 
 requesting larger packets (Peter K.)

 This is possibly a bad idea. In the IPsecME WG, we have had an active 
 work item on proof-of-work for clients to prevent DDoS, with lots of 
 good discussion on how to do it, and we're probably going to only leave 
 it as an Experimental document. In summary, adding proof-of-work hurts 
 the group you care most about, namely clients on small machines.

I agree with Paul here that conflating padding with proof-of-work seems
like a bad idea.  For one, proof-of-work schemes tend to encourage one
partner to dictate the work to the other partner -- in such a scheme,
each peer wouldn't be able to pad according to its known traffic
patterns.  for another, if the proof-of-work scheme is intended to
require some kind of puzzle-solving, i wouldn't want someone who just
wants to pad to have to incur extra computational costs.

If someone wants a proof-of-work extension to DNS, i think that should
be specified independently so that it doesn't get tied into this
proposal.  It's not like the registry [0] is short of codepoints.

In practice, the EDNS0 spec appears to allow the use of unknown options
for padding already, since peers are expected to ignore options they
don't know.  Adopting this draft would provide a codepoint allocation
that explicitly acknowledges this as a practice and avoids codepoint
squatting or abuse of the Reserved for Local/Experimental Use section
for folks who try to make use of it.

   --dkg

[0] 
https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-11

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

Re: [dns-privacy] draft-mayrhofer-edns0-padding

[Daniel Kahn Gillmor]

On Thu 2015-07-23 18:50:14 +0200, Alexander Mayrhofer wrote:

 I had a discussion with Daniel Khan Gillmor today, and we talked about
 his proposal to specify a padding option in TLS so that message-size
 based correlation attacks on encrypted DNS packets could be
 prevented. We continued discussing other options (such as artificial
 RRs in the additional section), and I floated the idea that we could
 use EDNS0 to include padding in DNS packets.

 So, I've created a quick-and-dirty strawman proposal draft for this
 idea, and i'm happy to discuss this during tomorrow's DPRIVE session
 if we have time:

 https://www.ietf.org/id/draft-mayrhofer-edns0-padding-00.txt

wow, thanks for the incredibly quick writeup!

I think this draft could have an informative reference to Haya Shulman's
research on difficulties in DNS encryption, which won the recent ANRP:

  https://irtf.org/anrp
  https://www.ietf.org/mail-archive/web/dns-privacy/current/pdfWqAIUmEl47.pdf

Section 3.2.2 shows that her mechanism for inferring the contents of
queries becomes *even more effective* by including the size of the
packets in her analysis.  (Everyone working on dprive should read this
paper to get a sense of some of the massive difficulties we need to
consider because of the structure of DNS traffic analysis; just
encrypting the traffic is insufficient for several reasons)

I also note that draft-mayrhofer-edns0-padding curently suggests that
the minimum padding size is 1 octet.  Is there any reason to avoid a
padding size of 0? 

--dkg

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

Re: [dns-privacy] Call For Adoption: draft-wing-dprive-dnsodtls

[Daniel Kahn Gillmor]

On Wed 2015-05-20 10:03:27 -0400, Tim Wicinski wrote:
 During the previous Call for Adoption a number of participants expressed 
 interest in adopting this work.  WG members felt it needed some 
 improvements, but thought it had potential. The authors addressed the 
 issues and feel it meets what the working group was seeking, and have 
 requested that we initiate a call for adoption.

 If the working group adopts this document, it only means it wishes to 
 study this solution more carefully.  The working group may still 
 determine to not move forward with it.

 The draft is available here: 
 https://datatracker.ietf.org/doc/draft-wing-dprive-dnsodtls/

I support the WG adopting this document for consideration.

I'm willing to review.

Looking at -01 of the draft:

 Section 3.2:

   Verifying the server certificate based on fingerprint needs to be
   spelled out more clearly (what exactly is fingerprinted, how it is
   fingerprinted).  But i don't think we should be fingerprinting the
   certificate itself at all in this case.  I think we should be
   fingerprinting the subject's public key.  The folks working on HTTP
   Public Key Pinning (HPKP) already went through this discussion, and
   settled on pinning public keys instead of certificates for good
   reason: in the pinning case, we want to make sure that we're looking
   at the same public key, not about the identity material wrapped
   around it in the cert.  (this also allows them to work with
   oob-pubkeys, as you recommend in section 7)


 Section 3.3:

   This section seems to bundle assumptions about DHCP information and
   system configuration all together (an implementation will
   attempt). I think we should separate those considerations, and make
   it clearer that this section is not a normative set of guidelines,
   but rather a description of common behaviors and choices.

Section 7:

   amoritized should be amortized.  I'm not convinced by the NOT
   RECOMMENDED in this section. Especially as the root zone expands, it
   doesn't look all that much different than any other busy
   authoritative nameserver.  This sort of SHOULD NOT ought to be backed
   up by hard data, or some sort of operational characteristics (X
   number of clients, each querying Y times per day, or something), or
   else it looks like it would apply to all authoritative nameservers.
   I understand that we want dprive to focus first on the stub-resolver
   link, but i don't think we should shoot down using DNSSoD on
   resolver-authoritative links without more consideration.

Regards,

--dkg

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

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

[Daniel Kahn Gillmor]

On Tue 2015-05-12 14:40:12 -0400, Simon Josefsson wrote:
 What I'm basically wondering, and advocating, is if perhaps one method
 would be sufficient.  This would reduce complexity on the protocol and
 implementation level.

I agree that a single mechanism would be cleaner, but perhaps the two
mechanisms serve different purposes?

It seems to me that the STARTTLS variant is useful for opportunistic
dns-privacy, while the distinct-port-based TLS-wrapped variant is useful
for pre-configured non-opportunistic dns-privacy.

People might want to argue about whether opportunistic dns-privacy is
relevant or useful, but if we concede that it does defend against some
relevant attackers, then it might be useful?

I don't imagine a happy eyeballs approach happening -- if someone
isn't sure which will be available, they will just use the STARTTLS
approach.  If someone *is* sure, they will use DNS-over-TLS-over-TCP.

Perhaps this distinction could be handled differently, though (e.g. with
some external signalling, such as a DHCP option) so that everything
could be collapsed to the DNS-over-TLS-over-TCP case (since it appears
to be 1RTT faster).

 The preference in IETF has been for the inband STARTTLS approach

I think recent discussions have indicated that there isn't any consensus
for either approach these days.  see, for example, the 'is one or two
ports more secure' discussion in saag (hopefully i haven't greivously
misinterpreted it):

  http://thread.gmane.org/gmane.ietf.saag/4916


  --dkg

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

[dns-privacy] draft-ietf-dprive-start-tls-for-dns-00 comments

[Daniel Kahn Gillmor]

Hi all--

Thanks for the start-tls-for-dns draft!  i'm happy to see it.  I have a
few pieces of feedback below...

--

A structural nit: the draft has no Table of Contents -- can you update
whatever drafting toolchain you're using to include one?  they're
helpful for people trying to navigate the document.

--

The third bullet point in section 2.2 of
https://tools.ietf.org/html/draft-ietf-dprive-start-tls-for-dns-00 says:

   o  The DNS client sends a TO=1 query and receives a TO=1 response,
  but the middlebox does not understand the TLS negotiation and does
  not allow those packets to pass through.

those packets is confusing here -- my first reading of it took me a
couple tries to see that it wasn't talking about the query and response
in the first sentence.  It should probably say does not allow the TLS
handshake packets to pass.

--

section 3.1 says:

   Opportunistic privacy can be used by any current client, but it only
   provides privacy when there are no on-path attackers.

It should probably say no on-path active attackers, since it still
provides privacy against on-path passive eavesdroppers.

--


section 3.2 says:

   With pre-deployed privacy, a client retains a copy of the TLS
   certificate and IP address of each provider.  The client will only
   use one of those DNS providers.  Because it has a pre-deployed TLS
   certificate, it may detect person-in-the-middle and downgrade
   attacks.

I'm not sure that certificate is the relevant thing that a client
wants to cache here.  For example, a client could instead use one of the
following options:

 * a long-term public key (and the certificate itself could be
   re-issued as long as it retains the same key, or could be sent as a
   raw public key (RFC 7250), or a TLSA record, etc)

 * the equivalent of an HPKP pinset (a digest of two or more public
   keys that should be present somewhere in the certificate chain) plus
   a name of the peer

 * a PSK, for use with one of the TLS PSK modes

 * the name of the peer and a X.509 trust anchor list


Or maybe some combination of the above.  I'm not sure that this draft is
the place to specify all of these options, of course, but limiting it to
the TLS certificate of each provider seems unnecssesarily
constrained.  (This is partly addressed in item 4 of the security
considerations section, but seems to be in conflict)

--

DNSSEC-trigger is mentioned but has no reference.  perhaps a pointer to
https://www.nlnetlabs.nl/projects/dnssec-trigger/ or somewhere else
would be worth including?

--

The Security Considerations section does not mention traffic analysis at
all.  The sizes of DNS packets and their timing may turn out to be
significant, and this draft should at least mention these concerns.

--

There is no Privacy Considerations section, but there probably should
be.  RFC 6973 is a good resource here.

--

The draft mentions TCP Fast Open; it may also want to mention the
TLS False Start protocol optimization:

  https://tools.ietf.org/html/draft-ietf-tls-falsestart-00

--

hope these comments are helpful,

  --dkg


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

Re: [dns-privacy] Starting call for adoptions for the 3 documents

[Daniel Kahn Gillmor]

On Thu 2015-04-09 10:36:17 -0400, Phillip Hallam-Baker wrote:
 As I see it, there are two sub-problems:

 1) How does a client discover and establish a binding to a DPRIV service?
 2) What transport/sessions(s) are supported for queries?

 Before answering either, I think it is pretty clear that at some point
 in the future, SPUD will be the logical choice for transport/session.
 It is also clear that we should not build research on research.

 So the way forward as I see it should be that our answer to (1) should
 support some mechanism for advertising alternative transports so we
 can use TLS for now and make use of SPUD if  and when it matures.

I'm not convinced that SPUD is the long-term way forward, fwiw.  But
there was enough discord between the different proposals within DPRIVE
that use TLS for now seems like it would be a great consensus to come
to.  I hope we reach it.

I'd like to make sure we have a clear sense of how to do this securely
and efficiently independently of wrangling about this next part:

 The hard part of the problem is all in problem 1. I designed,
 implemented and wrote the draft for the transport/session part in a
 day. It isn't a difficult problem (if you are only solving DNS, SPUD
 is a lot harder). The hard question is how to discover and establish a
 binding to the DNS service before you have DNS.

I don't think this is quite as hard as you're making it out to be.
We're going from:

 * for each resolver, get:
- an IP address

to:

 * for each resolver, get:
- an IP address
- a privacy-preserving transport mechanism
- a trust anchor

Current discovery mechanisms are:

 * Manual configuration
 * DHCP

i think most people consider DHCP configuration to be at best minimally
useful for DPRIVE -- it leaves you vulnerable at network connection
time, but then protects you against subsequent attacks.  *shrug*

Perhaps DHCP could be seen as a mechanism to propose available choices
for manual configuration?

At any rate, i think we shouldn't block transport mechanism work on
discovery mechanism work.

  --dkg

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

Re: [dns-privacy] (re-)identifying from sets of queries (was Re: Start of WGLC for draft-ietf-dprive-problem-statement - please review.)

[Daniel Kahn Gillmor]

On Fri 2015-02-27 07:28:57 -0500, Stephane Bortzmeyer bortzme...@nic.fr wrote:
 On Fri, Feb 27, 2015 at 11:53:27AM +,
  Stephen Farrell stephen.farr...@cs.tcd.ie wrote 
  a message of 55 lines which said:

 How's about adding something like:
 
 2.6 Re-identification

 OK for me, thanks for the text. Any advice from the WG? (I don't want
 to make important changes in the middle of a WGLC if there is no
 consensus.)

This text looks OK to add to me.

 --dkg

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

Re: [dns-privacy] Moving things along...

[Daniel Kahn Gillmor]

On Thu 2015-02-26 08:57:19 -0500, Phillip Hallam-Baker wrote:
 On Thu, Feb 26, 2015 at 6:35 AM, Neil Cook neil.c...@noware.co.uk wrote:
 Whilst I don’t deny that ISPs are using middelboxes for things like
 advertising etc, it should also be pointed out that many ISPs are concerned
 about security, and may be using middleboxes to protect users from things
 like hijacking, detecting CC in the DNS stream, detecting lookups to known
 phishing/malware sites etc.

 Comodo provides that type of service.

Is this a reference to PrivDog?  With all respect to Phillip, i hope the
recent vulnerabilities announced in some versions of PrivDog will make
users think twice about subscribing to service:

https://blog.hboeck.de/archives/865-Software-Privdog-worse-than-Superfish.html

Adopting a security services provider like this invariably means
opening yourself to whatever vulnerabilities lurk in that provider's
technological (and organizational, and legal) stack.

There is room for such a service in the world, but we need to find ways
to hold services like that to a *much* higher standard if we hope to
rely on them safely.

A confidential resolving DNS cache sounds much easier and safer to use
by comparison, and DNSSEC could *still* be verified on the client side
(with some kind of extension to indicate that a domain is blacklisted)
to avoid exposure to the kind of untrustworthy behavior we saw in
PrivDog.

--dkg

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