Subject: Resolverless DNS Side Meeting in Montreal

From: Patrick McManus <[email-masked]>
Date: Mon, 9 Jul 2018 22:49:25 -0400

Hi All,

I am organizing an ad-hoc Side Meeting regarding 'Resolverless DNS' in
Montreal.

We have often talked about the benefits and concerns of DNS information
obtained from sources that are, shall we say, less globally trusted than a
recursive a resolver. The central use case is DoH when pushed from an
endpoint that isn't a recursive resolver but there have been other
proposals.

For example www.example.com pushes you a AAAA record for img1.example.com.
Should you use it? What if it is for img1.img-example.com ? Do the
relationship between these domains matter? What kind of relationship (i.e.
it could be a domain relationship, or in the context of a browser it might
be a first-party tab like relationship, etc..)? What are the implications
of poison? Trackers? Privacy of requests never made? Speed? Competitive
shenanigans or DoS attacks?

This was out of scope for DoH.

*We'll do the meeting over 1 hour in the Dorchester room from 16:30 to
17:30 on Monday July 16th.*

This is a meeting of interested folks looking to see if we can agree on
next steps - we're not going to work out the details (nor should a side
meeting try and do so). so we'll have a tight agenda that I suggest
organizaing as follows:

1] What forms of transport could be in scope? HTTP/2 push is one such
vector, but I've heard others. Spray paint for example.

2] What needs to be considered when using such data? (signatures? scope?
etc?)

3] Who are the stakeholders for 1 + 2?

4] Is there enough interest to explore further? Next steps as output

I hope you can come!

-Patrick

---

From: Patrick McManus <[email-masked]>
Date: Mon, 9 Jul 2018 23:06:26 -0400

this is essentially a bar bof - though lacking in a bar and I'm fond of
more professional terms so I call it a side meeting. It has no standing. If
you're interested then please come, if you're not or are conflicted then
you're missing anything process wise.

Someday it might graduate to becoming a bof - but I would never put a bof
forward that didn't have a proposal I was comfortable with. This is indeed
a side meeting for anyone interested to see if there is a shared vision for
what such a proposal might look like.

Its not in scope for any wg as there isn't a proposal. Its quite possible
that it might have multiple outcomes which are in scope for multiple
application groups; I've tried to cc the likely suspects here.  But that is
presupposing outcomes.

-P

On Mon, Jul 9, 2018 at 10:55 PM, Ted Lemon <[email-masked]> wrote:

> This sounds an awful lot like an unapproved bof. The reason we don’t do
> those is that they tend to make it hard for people to participate. Why
> isn’t this in scope for dnsop?
>
> On Mon, Jul 9, 2018 at 10:49 PM Patrick McManus <[email-masked]>
> wrote:
>
>> Hi All,
>>
>> _______________________________________________
>> DRIU mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/driu
>>
>

---

From: Patrick McManus <[email-masked]>
Date: Tue, 10 Jul 2018 09:28:43 -0400

> Assuming that in the context of DoH reply size is not an issue, is seems to
> me that this use case is already solved by DNSSEC. Just push all required
> signatures, key material and DS records that allow the receiving side to
> validate the additional information.
>
>
that validates its a valid dns record. And maybe that's the whole answer -
at which point we still need to write that down along with the scope of
where its valid.

otoh - maybe its not the same valid dns record another resolver might want
you to use. perhaps you have a stronger trust relationship with that other
resolver. hmm.

otoh - maybe an unsigned record is ok in an https context where DNS isn't
the https security model.

this is the kind of stuff that I expect is in scope for discussion.

> Are you trying to re-invent DNSSEC for people who don't want to deploy
> DNSSEC

no.

---

From: Patrick McManus <[email-masked]>
Date: Tue, 10 Jul 2018 09:46:56 -0400

probably not (whatever is available will be adhoc) - its a side meeting
(aka bar bof) meant to take advantage of whomever is there. It has no
process value.

I'll make an effort to take minutes and report out though.

On Tue, Jul 10, 2018 at 9:42 AM, manu tman <[email-masked]> wrote:

>
>
> On Mon, Jul 9, 2018 at 7:49 PM Patrick McManus <[email-masked]>
> wrote:
>
>>
> Will it be recorded and will there be everything set for remote
> participants?
>
> Manu
>

---

From: Adam Roach <[email-masked]>
Date: Tue, 10 Jul 2018 10:09:41 -0500

[as an individual]

On 7/10/18 9:59 AM, Paul Wouters wrote:
> It seems more like an extension of the Public Suffix. Which domains can
> make claims about other domains. 

Based on the conversation that took place in DoH in Singapore, I think 
it's mostly *not* about this. The questions that have come up so far 
include: (a) If the record that is pushed to me is DNSSEC signed, is 
that sufficient to trust it? (b) If the record that is pushed to me is 
not DNS signed, but I'm using it in a context that requires TLS (e.g., 
HTTPS), and the thing that I connect to when I use the record can 
present a cert that proves its identity, is that okay?

There *might* be some useful discussion that includes applying the PSL 
to determine who can vouch for what, but I would expect this to be of 
significantly lower priority; and, given DBOUND's recent failure, I 
doubt there's useful IETF work to be done in that space, at least for 
the time being.

/a

---

From: Adam Roach <[email-masked]>
Date: Tue, 10 Jul 2018 11:22:55 -0500

On 7/10/18 10:30 AM, Joe Abley wrote:
> On Jul 10, 2018, at 16:09, Adam Roach <[email-masked]> wrote:
>
>> [as an individual]
>>
>> Based on the conversation that took place in DoH in Singapore, I think it's mostly *not* about this. The questions that have come up so far include: (a) If the record that is pushed to me is DNSSEC signed, is that sufficient to trust it? (b) If the record that is pushed to me is not DNS signed, but I'm using it in a context that requires TLS (e.g., HTTPS), and the thing that I connect to when I use the record can present a cert that proves its identity, is that okay?
> I think perhaps the people who have been having these conversations are not being ambitious enough.
>
> The pressures in the enterprise DNS market are overwhelmingly driven by the need to make web apps more reliable, load faster, and offer user-specific content. There are other reasons to want DNS tricks, but the customers that pay the big money are all concerned with HTTPS UX. Some of the decision points are in the DNS and some are in HTTP. The DNS is overwhelmingly involved at UX session initiation, but after that the HTTP layer has (can have) a far richer set of data about the user and is able to separate user-blocking decision-making from the flow of the UX which also affords extra time to make decisions without the user becoming frustrated.
>
> [To illustrate the architectural lunacy of the status quo, consider the data sets that are gathered through real-user-monitoring in browsers, served at the HTTP layer, that are subsequently used to steer DNS traffic used to retrieve resources back at the HTTP layer. There's a whole layer of derived datasets relating to the DNS there that are being generated by the web and used by the web, but with a tangy sandwich filler of DNS that is just overhead.]
>
> It seems like it would be nice then, after the UX-blocking elements are loaded and the user is already engaged, for subsequent lookups to be driven in HTTP and client-side scripting and to be presented to the stack as bare addresses rather than DNS names. That avoids the dependency on the DNS after initial page load altogether and leaves all the performance engineering decisions in the same place as the content decisions.

Basically, you're describing a solution space that could be realized as 
something like:

<img src="https://example.com/img/f.jpg" ip="192.0.2.1">

But this is really equivalent in just about every important way to 
sending the normal <img src="https://example.com/img/f.jpg"> along with 
a pushed DNS record that indicates that "example.com" resolves to 
"192.0.2.1" -- and this latter thing is (to my understanding, at least) 
in scope of the conversation that Patrick is proposing to have.

Note: I'm not saying anything about the trust issues that arise in 
either case, and I'm not trying to gloss over the need to perform a 
really careful analysis; I'm just saying that what you're suggesting is 
definitely equivalent to one of the implied eventual outcomes of what is 
being proposed.

/a

---

From: Adam Roach <[email-masked]>
Date: Tue, 10 Jul 2018 12:02:55 -0500

On 7/10/18 11:34 AM, Joe Abley wrote:
> On Jul 10, 2018, at 17:22, Adam Roach <[email-masked]> wrote:
>
>> Basically, you're describing a solution space that could be realized as something like:
>>
> Ok, interesting. I would suggest considering a richer scheme that
> accommodates address families and multiple addresses with priorities,
> but I see how that kind of thing would allow a client to do so
> certificate matching and resource retrieval without using the DNS.
>
>> But this is really equivalent in just about every important way to sending the normal <img src="https://example.com/img/f.jpg"> along with a pushed DNS record that indicates that "example.com" resolves to "192.0.2.1" -- and this latter thing is (to my understanding, at least) in scope of the conversation that Patrick is proposing to have.
> My question is why you would involve the DNS at all if all the
> performance-based resolution decisions can be made without it. You're
> just adding cost and complexity without benefit.

In large part because DNS provides "a richer scheme that accommodates 
address families and multiple addresses with priorities".

/a

---

From: Adam Roach <[email-masked]>
Date: Tue, 10 Jul 2018 12:05:45 -0500

On 7/10/18 11:41 AM, Ted Lemon wrote:
> On Tue, Jul 10, 2018 at 12:34 PM, Joe Abley <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     > But this is really equivalent in just about every important way to sending the normal <img
>     src="https://example.com/img/f.jpg
>     <https://example.com/img/f.jpg>"> along with a pushed DNS record
>     that indicates that "example.com <http://example.com>" resolves to
>     "192.0.2.1" -- and this latter thing is (to my understanding, at
>     least) in scope of the conversation that Patrick is proposing to have.
>
>     just adding cost and complexity without benefit
>
>
> The ip= modifier would be a great way to arrange for something to look 
> like it came from a different source than its actual source.   I'm 
> sure there's an attack surface in there somewhere.

Keeping in mind that the certificate provided by whatever machine you 
reached would necessarily have to match the URL's origin, this is very 
much one of the questions that is being asked: is there?

/a

---

From: Patrick McManus <[email-masked]>
Date: Tue, 10 Jul 2018 11:10:36 -0600

yes; and.. dns has always provided a point of indirection that is useful.
dynamically rewriting markup might be infeasible.. and many fetch() like
things are driven from script where the markup changes are not obvious or
perhaps ill fitting.. and of course there are questions of cached content
that might like to late bind. so lots to think about; but the markup
example is very illustrative of a very conservative way of scoping things.
perhaps too conservative. worth exploring.

On Tue, Jul 10, 2018 at 11:02 AM, Adam Roach <[email-masked]> wrote:

>>> "192.0.2.1" -- and this latter thing is (to my understanding, at least) in
>>> scope of the conversation that Patrick is proposing to have.
>>>

---

From: Adam Roach <[email-masked]>
Date: Tue, 10 Jul 2018 12:49:03 -0500

On 7/10/18 12:32 PM, Philip Homburg wrote:
> If we decide that TLS is strong enough to defend against these attacks,
> then there is no need to secure the DNS lookup, other than to reduce
> the risk of denial of service and for privacy reasons. Then such an ip=
> modifier would be fine, because the worst thing that can happen is denial
> of service.

To be crystal clear, my mentioning of that hypothetical parameter was 
part of a thought experiment, not a proposal.

/a

---

From: Ryan Sleevi <[email-masked]>
Date: Tue, 10 Jul 2018 13:51:54 -0400

On Tue, Jul 10, 2018 at 1:05 PM, Adam Roach <[email-masked]> wrote:

> On Tue, Jul 10, 2018 at 12:34 PM, Joe Abley <[email-masked]> wrote:
>
> like it came from a different source than its actual source.   I'm sure
> there's an attack surface in there somewhere.
>
>
> reached would necessarily have to match the URL's origin, this is very much
> one of the questions that is being asked: is there?
>
> /a
>
Yes. Consider Site A (foo.example) and Site B (bar.example). Both point
themselves to CDN 1, which then obtains a certificate for both their names
in subjectAltNames. Site B then decides that CDN 1 is an unreliable
partner, and goes CDN 2, updating DNS appropriately.

This is the same problem in considering the HTTP/2 coalescing without doing
DNS resolution (either because of poor security posture or by combining
ORIGIN + Secondary Certificates). RFC 8336 briefly touches on this (
https://tools.ietf.org/html/rfc8336#section-4 ) but doesn't really explore
the policy implications of the proposed or recommended mitigations.

If you start with no mitigations, the net effect of both an ip= or a
DNS-ignoring ORIGIN frame is to effectively treat the certificate as a
825-day DNS TTL. By framing the problem as "What's the worst that could
happen if DNS entries had their TTLs ignored and were cached for 825 days",
that might help explore things further. The suggestion of OCSP reduces that
TTL to 7 days (effectively; due to Microsoft's contractual requirements on
publicly trusted CAs), but that's still substantially longer.

That's why involving DNS is at least relevant to that discussion,
especially given that publicly trusted certificates are themselves
predicated on DNS. Further, considering that the CA only has to validate a
DNS once per 825-day period, and can issue unlimited 825-day certificates
during that period, then the effective extension of relying solely on
certificates 1650 days minus a second.

---

From: Adam Roach <[email-masked]>
Date: Tue, 10 Jul 2018 13:03:54 -0500

On 7/10/18 12:55 PM, Joe Abley wrote:
> On Jul 10, 2018, at 18:02, Adam Roach <[email-masked]> wrote:
>
>> In large part because DNS provides "a richer scheme that accommodates address families and multiple addresses with priorities".
> *cups hand to ear*
>
> Was that the sound of a distant desire to specify use of SRV for HTTP?
>

Speaking personally (that is: this position may be at odds with any 
number of organizations I'm affiliated with), I've been sad for a very 
long time that SRV didn't take off as the entry point for doing all 
name/service resolution. Maintaining a service-to-port map in 2018 seems 
as quaint as if we were still having to manually set and de-conflict IRQ 
values on PC peripherals. This is way off-topic, though -- if you want 
to continue, find another venue and let me know (or we can find a time 
to commiserate over beers in Montreal if you prefer).

/a

---

From: Mike Bishop <[email-masked]>
Date: Tue, 10 Jul 2018 18:09:34 +0000

Yes, the multi-CDN case is the scariest aspect of coalescing and the various DNS tricks we’ve been doing in recent years.  The server may not be malicious, may not even be misconfigured – site X uses DNS to dynamically share load between CDNs A and F.  If X decides to start moving more load to A, F could in all good faith continue to route clients to itself by providing cached, signed DNS records.

The industry norm is that changing the DNS record’s CNAME to a different CDN is the cut-over, regardless of whether the other CDN remains configured.  It’s effectively acting as a “hot standby.”  If it had to provided better proof of freshness, that might be sufficient, but how fresh is sufficiently fresh?  And does DNSSEC provide that freshness guarantee?

However, F could do this today with Alt-Svc and have the same impact.  Secondary Certificates provides another way this might happen.  So this ship might have already sailed.

From: Ryan Sleevi [mailto:[email-masked]]
Sent: Tuesday, July 10, 2018 10:52 AM
To: Adam Roach <[email-masked]>
Cc: Ted Lemon <[email-masked]>; Joe Abley <[email-masked]>; DoH WG <[email-masked]>; [email-masked]; dnsop WG <[email-masked]>; Paul Wouters <[email-masked]>; Patrick McManus <[email-masked]>; Philip Homburg <[email-masked]>; HTTP Working Group <[email-masked]>
Subject: Re: [Driu] [DNSOP] [Doh] Resolverless DNS Side Meeting in Montreal

On Tue, Jul 10, 2018 at 1:05 PM, Adam Roach <[email-masked]<mailto:[email-masked]>> wrote:
On 7/10/18 11:41 AM, Ted Lemon wrote:
On Tue, Jul 10, 2018 at 12:34 PM, Joe Abley <[email-masked]<mailto:[email-masked]>> wrote:
> But this is really equivalent in just about every important way to sending the normal <img src="https://example.com/img/f.jpg"> along with a pushed DNS record that indicates that "example.com<http://example.com>" resolves to "192.0.2.1" -- and this latter thing is (to my understanding, at least) in scope of the conversation that Patrick is proposing to have.

The ip= modifier would be a great way to arrange for something to look like it came from a different source than its actual source.   I'm sure there's an attack surface in there somewhere.

Keeping in mind that the certificate provided by whatever machine you reached would necessarily have to match the URL's origin, this is very much one of the questions that is being asked: is there?

/a
Yes. Consider Site A (foo.example) and Site B (bar.example). Both point themselves to CDN 1, which then obtains a certificate for both their names in subjectAltNames. Site B then decides that CDN 1 is an unreliable partner, and goes CDN 2, updating DNS appropriately.

This is the same problem in considering the HTTP/2 coalescing without doing DNS resolution (either because of poor security posture or by combining ORIGIN + Secondary Certificates). RFC 8336 briefly touches on this ( https://tools.ietf.org/html/rfc8336#section-4 ) but doesn't really explore the policy implications of the proposed or recommended mitigations.

If you start with no mitigations, the net effect of both an ip= or a DNS-ignoring ORIGIN frame is to effectively treat the certificate as a 825-day DNS TTL. By framing the problem as "What's the worst that could happen if DNS entries had their TTLs ignored and were cached for 825 days", that might help explore things further. The suggestion of OCSP reduces that TTL to 7 days (effectively; due to Microsoft's contractual requirements on publicly trusted CAs), but that's still substantially longer.

That's why involving DNS is at least relevant to that discussion, especially given that publicly trusted certificates are themselves predicated on DNS. Further, considering that the CA only has to validate a DNS once per 825-day period, and can issue unlimited 825-day certificates during that period, then the effective extension of relying solely on certificates 1650 days minus a second.

---

From: Ryan Sleevi <[email-masked]>
Date: Tue, 10 Jul 2018 14:57:24 -0400

On Tue, Jul 10, 2018 at 2:09 PM, Mike Bishop <[email-masked]> wrote:

> Yes, the multi-CDN case is the scariest aspect of coalescing and the
> various DNS tricks we’ve been doing in recent years.  The server may not be
> malicious, may not even be misconfigured – site X uses DNS to dynamically
> share load between CDNs A and F.  If X decides to start moving more load to
> A, F could in all good faith continue to route clients to itself by
> providing cached, signed DNS records.
>

Yup. And, at least for browsers that follow a Priority of Constituency
model, it seems more important to ensure that site operators wishes are
respected over that of the CDNs they've used, or for their being a more
explicit signal from the user that it truly intends to ignore the site
operator.

>
>
> The industry norm is that changing the DNS record’s CNAME to a different
> CDN is the cut-over, regardless of whether the other CDN remains
> configured.  It’s effectively acting as a “hot standby.”  If it had to
> provided better proof of freshness, that might be sufficient, but how fresh
> is sufficiently fresh?  And does DNSSEC provide that freshness guarantee?
>

Right, these are questions that need to be answered, and not just with
abstract theoretical mitigations that don't or can't be deployed.

> However, F could do this today with Alt-Svc and have the same impact.
> Secondary Certificates provides another way this might happen.  So this
> ship might have already sailed.
>

The ship has only sailed for those foolish enough to ship those features :)
That is, these are real security concerns, they have not been
satisfactorily addressed, and security conscious implementations have held
off implementing these features for precisely this reason. If there are
implementations that have shipped, without understanding or considering the
security harm they're doing, that doesn't seem like a good argument to keep
building more features on the buggy premise.

If they believe they have sufficiently mitigated those very real and
practical security concerns, they would hopefully be sharing those concrete
strategies and tradeoffs, rather than a Security Considerations that
acknowledges the dragons without adequately describing how to avoid them
(or how not to).

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 11 Jul 2018 11:22:55 +1000

> On 11 Jul 2018, at 3:55 am, Joe Abley <[email-masked]> wrote:
> 

I recently did some digging on this topic, and can try to characterise what the issues / objections are.

Would people be interested in a (hopefully brief) side meeting to discuss and maybe come to a shared understanding of the problem space?

Cheers,

--
Mark Nottingham   https://www.mnot.net/

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 11 Jul 2018 11:32:02 +1000

I didn't find those, but I found many others.

I'll start collecting. How about Tuesday, say 6:45-7:45pm?

> On 11 Jul 2018, at 11:30 am, Mark Andrews <[email-masked]> wrote:
> 
> 
> 
>> On 11 Jul 2018, at 11:22 am, Mark Nottingham <[email-masked]> wrote:
>> 
>> 
>> 
> I think there are three main objections.
> 
> 1) Wildcards don’t work with prefixes.
> 2) Additional data isn’t always returned it may require multiple round trips.
> 3) Additional data processing doesn’t support negative responses.
> 
> All of these issues are trivially easy to fix.  It just require willingness to implement.
> 
> 1) is addressed by defining a new type(s) rather than using prefixes.
> 2) is addressed by getting recursive servers to fill in missing additional data before returning.  Named has code in review for this for SRV as proof of concept.
> 3) is addressed by adding some signalling between the client and recursive server to indicate if the additional section is complete or not.
> 
> 
>> DNSOP mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/dnsop
> 
> -- 
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742              INTERNET: [email-masked]

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 11 Jul 2018 12:25:38 +1000

Sure, with the understanding that we'll probably start a few minutes after that, given the session end at 16:20 (I'm chairing then, it usually takes a little while to get out).

I've reserved Barre Oblique from 18:30 until 19:30 on Tuesday.

Cheers,

> On 11 Jul 2018, at 11:52 am, Dave Lawrence <[email-masked]> wrote:
> 
> Dave Lawrence writes:
>> Mark Nottingham writes:
>> Last session ends at 6:20 and social starts at 7, not sure how late
>> the last bus (if any?) will be leaving the hotel.
> 
> Nevermind, walking distance to social, under 1km.  Maybe still though
> shifting it a little earlier, like 18:30.
>

---

From: Leif Hedstrom <[email-masked]>
Date: Wed, 11 Jul 2018 10:24:43 -0600

> On Jul 10, 2018, at 7:22 PM, Mark Nottingham <[email-masked]> wrote:
> 
> 
> 

Definitely. We (Traffic Server) added some support for SRV a while back, but it’s mostly a hack.

Cheers,

— Leif

---

From: Mike Bishop <[email-masked]>
Date: Wed, 11 Jul 2018 20:42:34 +0000

But it's not necessarily the CDN that's generating the signed records in the general case.  You're wanting proof that the customer's domain is pointed to that CDN, so it's signed by whoever manages the DNS infrastructure instead.  That could be one of the CDNs, or the customer's operations team, or a third-party provider altogether.

But yes, clearly it's possible for at least some parties to do online signing in real-time.  That's at variance with the airgapped signature key design I've heard in other cases.

-----Original Message-----
From: Petr Špaček [mailto:[email-masked]] 
Sent: Wednesday, July 11, 2018 1:23 AM
To: Ryan Sleevi <[email-masked]>; Mike Bishop <[email-masked]>
Cc: DoH WG <[email-masked]>; Adam Roach <[email-masked]>; [email-masked]; Philip Homburg <[email-masked]>; dnsop WG <[email-masked]>; Ted Lemon <[email-masked]>; Patrick McManus <[email-masked]>; Paul Wouters <[email-masked]>; Joe Abley <[email-masked]>; HTTP Working Group <[email-masked]>
Subject: Re: [Doh] [Driu] [DNSOP] Resolverless DNS Side Meeting in Montreal

On 10.7.2018 20:57, Ryan Sleevi wrote:
> 
> 
> On Tue, Jul 10, 2018 at 2:09 PM, Mike Bishop <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>     various DNS tricks we’ve been doing in recent years.  The server may
>     not be malicious, may not even be misconfigured – site X uses DNS to
>     dynamically share load between CDNs A and F.  If X decides to start
>     moving more load to A, F could in all good faith continue to route
>     clients to itself by providing cached, signed DNS records.
> 
> 
> model, it seems more important to ensure that site operators wishes 
> are respected over that of the CDNs they've used, or for their being a 
> more explicit signal from the user that it truly intends to ignore the 
> site operator.
>  
> 
>     ____
> 
>     __ __
> 
>     The industry norm is that changing the DNS record’s CNAME to a
>     different CDN is the cut-over, regardless of whether the other CDN
>     remains configured.  It’s effectively acting as a “hot standby.”  If
>     it had to provided better proof of freshness, that might be
>     sufficient, but how fresh is sufficiently fresh?  And does DNSSEC
>     provide that freshness guarantee?
> 
> 

Signatures in DNSSEC (i.e. RRSIG records) have validity period with 1-second granularity so in theory it allows fine-tunning. Of course shorter validity means more cryptographic operations to update signatures etc.

Taking into account that Cloudflare signs all recorsd on the fly, it is clearly feasible for CDN to generate fresh signatures on every DNS request.

Petr Špaček  @  CZ.NIC

>     However, F could do this today with Alt-Svc and have the same
>     impact.  Secondary Certificates provides another way this might
>     happen.  So this ship might have already sailed.
> 
> 
> The ship has only sailed for those foolish enough to ship those 
> features
> :) That is, these are real security concerns, they have not been 
> satisfactorily addressed, and security conscious implementations have 
> held off implementing these features for precisely this reason. If 
> there are implementations that have shipped, without understanding or 
> considering the security harm they're doing, that doesn't seem like a 
> good argument to keep building more features on the buggy premise.
> 
> practical security concerns, they would hopefully be sharing those 
> concrete strategies and tradeoffs, rather than a Security 
> Considerations that acknowledges the dragons without adequately 
> describing how to avoid them (or how not to).

---

From: Nico Williams <[email-masked]>
Date: Wed, 11 Jul 2018 16:24:28 -0500

> > 1) is addressed by defining a new type(s) rather than using prefixes.

While that is correct, and truly, it is trivial to implement, it is not
trivial to deploy: too many DNS hosting providers would have to update
UIs.

Let me add my voice in favor of new RR types by which to replace SRV
RRs.  URI is one of them, for the sorts of things we do in Kerberos for
KDC discovery, but no really appropriate for resolving HTTP authorities.

> > 2) is addressed by getting recursive servers to fill in missing additional data before returning.  Named has code in review for this for SRV as proof of concept.

That would be very nice indeed.  Unbound will need that too.

> > 3) is addressed by adding some signalling between the client and recursive server to indicate if the additional section is complete or not.

Well, OK, but as with (2) that requires recursive resolver critical
mass.  Not necessarily a big deal, though it will take enough time that
many apps will need to support falling back to doing multiple queries
one by one.

Nico
--

---

From: Joseph Lorenzo Hall <[email-masked]>
Date: Wed, 11 Jul 2018 18:25:38 -0400

I'm in, but will need to catch up on the convo... I'll do so.

BTW, don't look at the Yelp/Foursquare reviews for the social venue... yikes

On Tue, Jul 10, 2018 at 9:32 PM Mark Nottingham <[email-masked]> wrote:

> > 2) is addressed by getting recursive servers to fill in missing
> additional data before returning.  Named has code in review for this for
> SRV as proof of concept.
> > 3) is addressed by adding some signalling between the client and
> recursive server to indicate if the additional section is complete or not.
> >
> >
> >> Would people be interested in a (hopefully brief) side meeting to
> discuss and maybe come to a shared understanding of the problem space?
> >>
> >> Cheers,
> >>
> >> --
> Doh mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/doh
>

-- 
Joseph Lorenzo Hall
Chief Technologist, Center for Democracy & Technology [https://www.cdt.org]
1401 K ST NW STE 200, Washington DC 20005-3497
e: [email-masked], p: 202.407.8825, pgp: https://josephhall.org/gpg-key
Fingerprint: 3CA2 8D7B 9F6D DBD3 4B10  1607 5F86 6987 40A9 A871

---

From: Nico Williams <[email-masked]>
Date: Wed, 11 Jul 2018 19:48:36 -0500

On Thu, Jul 12, 2018 at 08:51:43AM +1000, Mark Andrews wrote:
> Garbage.  There really isn’t.  People keep saying something can’t be done
> because there are too many X.  X get replaced.  X get updated.  As for DNS
> hosting providers that support a given type, we create a site and report
> what software by version and date and what DNS hosting providers support
> the type native or unknown formats.

I didn't mean to say not to go this way.  On the contrary, we should.
Just that this is an issue.

> We also don’t have to achieve 100%.  People can move to DNS hosters that
> do support the type or host their own DNS.  Every DNS hoster that provides
> slave/secondary services already supports they type as UNKNOWN has been out
> there so long.

Ah yeah, that's true -- not a great UI, but it works.

> They can do the queries in parallel, that 2 RTTs.

Yes, that's a big deal.

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 16 Jul 2018 10:29:38 -0400

Room change - we're now in Square Dorchester (the bigger room).

Cheers,

> On 10 Jul 2018, at 10:25 pm, Mark Nottingham <[email-masked]> wrote:
>

---

From: "Patrik Fältström" <[email-masked]>
Date: Wed, 11 Jul 2018 19:21:01 +0000

On 11 Jul 2018, at 8:21, Mark Andrews wrote:

> As for lib curl, there is not a RFC that says to lookup SRV records for HTTP or HTTPS.

Agree, and I have wanted it to be part of HTTP/2, or at least resolve this mess, but it did not happen.

This is my recurring discussion with Daniel when we have beer :-D

  paf

---

From: Shane Kerr <[email-masked]>
Date: Tue, 17 Jul 2018 23:43:42 +0000

All,

I took some random notes at the meeting. Apologies for any errors or misstatements.

Cheers,

--
Shane

---

From: Mark Andrews <[email-masked]>
Date: Thu, 12 Jul 2018 01:30:54 +0000

> On 12 Jul 2018, at 10:48 am, Nico Williams <[email-masked]> wrote:
> 

It’s a self correcting problem though.  Recursive nameservers do get upgraded.

If we could have got people on board back when I first submitted
https://datatracker.ietf.org/doc/draft-andrews-http-srv/ everyone would be using
it and I suspect recursive servers would have been optimised to fetch the additional
data before returning.  There is nothing in the RFC’s that says you can’t stall the
response to fetch additional data.  This isn’t hard.  It just requires people to
stop arguing and “Just Do It”.

Also writing documentation that says “if the query has these properties, fetch missing
additional data” will help.

We could have done 5 or 6 transitions since 2000 on both the DNS and HTTP sides.
While there are long tails most of the world upgrades within 3 years.

---

From: Mark Andrews <[email-masked]>
Date: Wed, 11 Jul 2018 06:22:09 +0000

> On 11 Jul 2018, at 3:53 pm, Patrik Fältström <[email-masked] <mailto:[email-masked]>> wrote:
> 
> On 11 Jul 2018, at 3:30, Mark Andrews wrote:
> 
> 4) Various libraries in PHP and ultimately lib curl do not include SRV in the resolution

Then PHP is not STD 13 compliant.  Resolver libraries are supposed to be able resolve UNKNOWN records per STD 13 and that includes SRV.
As for lib curl, there is not a RFC that says to lookup SRV records for HTTP or HTTPS.

> 5) New resource record types are very hard to implement (same argument as why we use TXT for SPF and not SPF for example)

SPF was just plain unwillingness to complete the transition.  The code was out there.  It was being deployed.  TXT to SPF transition was never part of the experiment, it was in addition to the experiment.

No resources record is hard to implement.  What hard is getting someone to commit 30 minutes to 1 hour of time to do something at all.  That is what it takes most pieces of software to add a new record type.  Thats been true since I started in the DNS back in the early 90’s.

> 6) You "only" change hostname with SRV and not a "complete change of the URL

> 4) Is of course "just code" in lib curl and what not
> 
> 5) Is like (4) but possibly harder if you want it implemented in PHP, javascript etc and not in the underlying libraries
> 
> 6) This is why I came up with URI which is supposed to be a competitor to "well known URI"
> 
>  paf

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

---

From: Patrick McManus <[email-masked]>
Date: Sat, 28 Jul 2018 12:32:02 -0400

Hi All -

This is a wrap-up email for the Resolverless DNS meeting held on July 16 in
Montreal. We had, by my rough count, about 50 people and two sets of
minutes are attached. If you attended, contributed, or took minutes (Thanks
Shane and Ben!) thank you - it was, imo, a productive, professional, and
even pretty focused discussion.

We identified a next step: using an AD sponsored list (See Below!),
identify one minimal context or use case that provides value for using DNS
information without direct recursive resolver contact, and enumerate the
concerns and potential mitigations for those concerns. If we can focus on
that and make some progress then we might have a proposal for a future BoF
- if we cannot make progress then that is also telling.

Adam and Warren have setup a list for us to use. I apologize to the various
working group's cc'd on this so far (and thank them for their indulgence) -
future communications should move to the new list.

New List Info
-------------------
https://www.ietf.org/mailman/listinfo/resolverless-dns

-Patrick