Re: [DNSOP] Resolverless DNS Side Meeting in Montreal

[Paul Vixie]

Patrick McManus wrote:

...

For example www.example.com  pushes you a 
record for img1.example.com . Should you use
it?


no. sibling names might be delegation points. kashpureff taught us this 
in 1996 or so, and kaminsky reinforced that lesson in 2008.



What if it is for img1.img-example.com ?


certainly not.

--
P Vixie

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Resolverless DNS Side Meeting in Montreal

[Philip Homburg]

>For example www.example.com pushes you a  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.

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.

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


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Resolverless DNS Side Meeting in Montreal

[Patrick McManus]

> 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.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Doh] Resolverless DNS Side Meeting in Montreal

[manu tman]

On Mon, Jul 9, 2018 at 7:49 PM Patrick McManus  wrote:

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

Will it be recorded and will there be everything set for remote
participants?

Manu
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Doh] Resolverless DNS Side Meeting in Montreal

[Patrick McManus]

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  wrote:

>
>
> On Mon, Jul 9, 2018 at 7:49 PM Patrick McManus 
> wrote:
>
>>
>> *We'll do the meeting over 1 hour in the Dorchester room from 16:30 to
>> 17:30 on Monday July 16th.*
>>
>
> Will it be recorded and will there be everything set for remote
> participants?
>
> Manu
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Doh] Resolverless DNS Side Meeting in Montreal

[Tim Wicinski]

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


My magic 8-ball says "signs point to Yes"

On Tue, Jul 10, 2018 at 5:09 AM, Philip Homburg 
wrote:

> >For example www.example.com pushes you a  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.
>
> 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.
>
> Are you trying to re-invent DNSSEC for people who don't want to deploy
> DNSSEC?
>
>
> ___
> Doh mailing list
> d...@ietf.org
> https://www.ietf.org/mailman/listinfo/doh
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Working Group Last Call for: draft-ietf-dnsop-attrleaf

[Dave Crocker]

On 7/9/2018 2:35 PM, Dick Franks wrote:


On 9 July 2018 at 19:48, Dave Crocker > wrote:

 >8

Does this cause anyone intolerable heart-burn?  If it does, please
at least explain but preferably offer something better.


I do not suffer from intolerable heart-burn but happy to offer:

  If a public specification calls for the use of an 
underscore-prefixed domain name,

the underscored name closest to the root MUST be entered into this registry.



Thanks.  I've added some tweakage to your text:

 If a public specification calls for use of an _underscore-prefixed
   domain node name, the 'global' underscored name -- the name that is
   closest to the DNS root -- MUST be entered into this registry.
   Historically, this is the right-most name that is begins with an
   underscore.


> (Editorial:  The word underscore does not itself need to be
> underscore_prefixed)

  It's there as clarification/reminder, in case the reader isn't sure 
what character is meant.  But I'll re-calibrate its use and take out 
extra ones...


d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Resolverless DNS Side Meeting in Montreal

[Paul Wouters]

On Tue, 10 Jul 2018, Philip Homburg wrote:


For example www.example.com pushes you a  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.


I'm also confused about what the scope is. If you connect over TLS to a
site and it has links to other hostnames, I guess you trust it ? The
TLS/trust mechanism has really no other way of certifying the content
server over TLS, unless you want to object/webpage signing. Which is
impossible in today's dynamic web state.


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


It seems more like an extension of the Public Suffix. Which domains can
make claims about other domains.

I'm not sure I see the connection with private DNS queries.

Paul

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] DNSOP Agenda for IETF102

[Tim Wicinski]

All,

This is mostly the agenda.  The chairs reserve the right to shuffle the
order of the talks.
This also includes the second session on Thursday.

https://datatracker.ietf.org/meeting/102/materials/agenda-102-dnsop-01

Look forward to seeing everyone in Montreal.

for Benno and Suzanne,

Tim

---

# DNS Operations (DNSOP) Working Group
## IETF

* Date: Wednesday 18 July, 2018
* Time: 09:30-12:00 EDT (13:30-16:00 UTC)
* Room: Laurier

* Chairs: Tim Wicinski 
* Chairs: Suzanne Woolf 
* Benno Overeinder 

* Secretary: Paul Hoffman 

* IESG Overlord: Warren Kumari 

* [DocList](https://svn.tools.ietf.org/svn/wg/dnsop/doclist.html)
* [DataTracker](https://datatracker.ietf.org/wg/dnsop/documents/)

---
## Agenda

### Administrivia

* Agenda Bashing, Blue Sheets, etc,  10 min

* Updates of Old Work, Chairs, 10 min

---
### Current Working Group Business

* [draft-ietf-dnsop-terminology-bis](
https://datatracker.ietf.org/doc/draft-ietf-dnsop-terminology-bis/)
- Hoffman, 10min

* [draft-ietf-dnsop-algorithm-update](
https://datatracker.ietf.org/doc/draft-ietf-dnsop-algorithm-update/)
- Sury, 10min

* DNS Cookies and their Operational Impacts
- Sury, 15min

* Let's Talk CNAME @ APEX

---
## Previously Discussed Work

* [draft-huque-dnsop-multi-provider-dnssec](
https://datatracker.ietf.org/doc/draft-huque-dnsop-multi-provider-dnssec/)
- Huque, 10min

* [draft-woodworth-bulk-rr](
https://datatracker.ietf.org/doc/draft-woodworth-bulk-rr/)
- Woodworth, 10min

* [draft-pwouters-powerbind](
https://datatracker.ietf.org/doc/draft-pwouters-powerbind/)
- Wouters

## Session II

* [dns-ietf-dnsop-wireformat-http](
https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-wireformat-http/)
- Song, 10min

### New Working Group Business

### Time Permitting


* [draft-wessels-dns-zone-digest](
https://datatracker.ietf.org/doc/draft-wessels-dns-zone-digest/)
- Hardaker

* [draft-kh-dnsop-7706bis](
https://datatracker.ietf.org/doc/draft-kh-dnsop-7706bis/)
- Hoffman

* [draft-tariq-dnsop-iviptr](
https://tools.ietf.org/html/draft-tariq-dnsop-iviptr)
- Taqiq

* [draft-song-atr-large-resp](
https://datatracker.ietf.org/doc/draft-song-atr-large-resp/)
- Song


---
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Call for Adoption: draft-huque-dnsop-multi-provider-dnssec

[Paul Wouters]

On Fri, 6 Jul 2018, Tim Wicinski wrote:


This starts a Call for Adoption for: draft-huque-dnsop-multi-provider-dnssec

The draft is available here: 
https://datatracker.ietf.org/doc/draft-huque-dnsop-multi-provider-dnssec/


I've reviewed the draft. It seems to me this is mostly a description of
novel uses of IETF protocols and possible business models. I don't see
a strong case for publishing this as an RFC and have a preference for
DNSOP to focus their time on working on protocol/operations matters and
our communal backlog of that.

So I am not in favour of adoption, but I would not object to adoption
either if that's how others want to spend the DNSOP time.

Paul

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Doh] Resolverless DNS Side Meeting in Montreal

[Adam Roach]

[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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Doh] Resolverless DNS Side Meeting in Montreal

[Paul Wouters]

On Tue, 10 Jul 2018, Adam Roach wrote:


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?


I see. I guess I agree more now with the previous poster that this is
more like yet another kind of "transparancy" workaround for not wanting
to deploy dnssec :)

I understand that having a WebPKI and a DANE PKI leads to an unwanted
mixture of trust models. It might be useful to talk about that, especially
in light of tls-dnssec-chain where it seems that some proposals result
in a preventative block of a DANE PKI for no apparent other gain.

Paul

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Doh] Resolverless DNS Side Meeting in Montreal

[Joe Abley]

On Jul 10, 2018, at 16:09, Adam Roach  wrote:

> [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?

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.

There are problems with this approach today (certificate matching, for example) 
but I don't think the problems necessarily relate to the DNS. Perhaps they 
relate to a local-context naming system that doesn't exist outside a javascript 
sandbox. I see the attraction of shifting name resolution to DOH since it makes 
it look like everything is a web app, but collapsing the address selection back 
to the extent that you can avoid name resolution at all seems like a better end 
goal.

So rather than resolverless operation, think about resolutionless or nameless, 
eliminating the DNS as unnecessary overhead.

Perhaps I have misunderstood the whole problem space, of course :-)


Joe

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] Working Group Last Call for for draft-ietf-dnsop-rfc5011-security-considerations-12; was Publication has been requested for draft-ietf-dnsop-rfc5011-security-considerations-12

[Michael StJohns]

Thanks Tim -

Note the changed subject line.

And as you may have guessed I object to the publication of this document 
on the basis of quality for all the reasons previously stated.  This 
version of the document is actually in worse shape than the one that 
failed last call back in October.


I strongly object to the publication of this document as a Standards 
Track document. The appropriate status  - if published - is 
Informational with or without a BCP tag on it.  The document does not 
provide any implementable protocol, and by that I mean that the only 
protocol elements in this document must be executed by humans.  There is 
no on-the-wire elements, nor any process that can be implemented by a 
DNS resolver or server.  This is solely and only an operational 
practices document, and AFAICT, none of these have ever ended up as 
Standards Track.   Or to put it more bluntly - humans are not protocol 
elements that can be standardized.  Finally, this purports to update 
RFC7538 which is Informational.



Mike



On 7/10/2018 1:38 AM, Tim Wicinski wrote:

Michael

We talked it over and if there was a process fail, it's easier to fix 
now then later. I already reached out to the AD who is stepping in for 
Warren to hold off for now.


Let this be a Working Group Last Call on 
draft-ietf-dnsop-rfc5011-security-considerations.  This will go from 
now until the end of the IETF next Friday.


The Current Intended Status is: Standards Track

We will be take comments on the changes now, and as well as during the 
session on Wednesday.



Tim

On Mon, Jul 9, 2018 at 12:05 PM, Michael StJohns 
mailto:m...@nthpermutation.com>> wrote:


Tim/Suzanne -

Please cancel the request for publication until you complete the
WGLC for this document.

The last WGLC for the document was October of last year - it
failed on 28 October
https://www.ietf.org/mail-archive/web/dnsop/current/msg21225.html
.
No WGLC has been made since then.

The consensus referenced in the shepherd's report was meeting
consensus - not mailing list consensus AFAICT. Specifically, I'd
like to see if Ed's removed his objections.  I don't have a
problem with the WGLC being used to judge consensus - but that's
not what happened here.

Later, Mike



On 7/6/2018 9:08 PM, Michael StJohns wrote:

On 7/6/2018 8:13 PM, Tim Wicinski wrote:

Tim Wicinski has requested publication of
draft-ietf-dnsop-rfc5011-security-considerations-12 as
Proposed Standard on behalf of the DNSOP working group.

Please verify the document's state at

https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc5011-security-considerations/



___
DNSOP mailing list
DNSOP@ietf.org 
https://www.ietf.org/mailman/listinfo/dnsop



*sigh*

Point of order:  Did I miss the final WGLC on this after this
last version was published?  I can't actually find anything in
the DNSOP archives and I don't remember seeing the call.   So
I'm suggesting that we've missed a required stage.

With respect to the shepher's writeup:

1) The first reference in the shepherd's write-up  is wrong -
its pointing to a whole other set of discussions related to
Joe Abley's ideas.
2) The second reference isn't representative of the actual
discussion, but only shows the point at which I got worn down.
Please include a reference that actually shows the attempts to
try and resolve my issues.
3) This document should not be a Proposed Standard as it
documents nothing implementable (that is nothing implementable
in a computer), but is operational guidance for the
publication process.
4) Is it usual for the WG chair to write the shepherd's
report? Specifically, it seems a conflict of interest for
items (3) -(6).
5) The technical summary is misleading.  This is not an update
to 5011, but guidance to the zone publisher who may have not
understood the implications of operational choices (e.g.
steady state single trust anchor vs 5011s recommendation of
multiple trust anchors). E.g. "RFC5011 DNSSEC Key Rollover
Strategy" isn't a document referenced by this document, and
that would be the document that would be in need of an update.
6) Same comment - it's not an update to the 5011 timers, but
to the understanding of the publishers of such zones that use
5011.
7) Please include references of the emails of the "root server
community"

Re: [DNSOP] Working Group Last Call on draft-ietf-dnsop-terminology-bis

[fujiwara]

Thanks to Vladimír,

> From: Vladimír Čunát 
> "Bailiwick" definition: I have (also) seen use like "in-bailiwick
> records" in the sense being in a subdomain.  I can't really judge how
> common that usage is, but it has already been discussed wrt. this draft:
> https://mailarchive.ietf.org/arch/msg/dnsop/MyEdXXdUKKyTTfX3_4_7AnhE3Io 
> My understanding of that thread is that the meaning was planned to be extended
> in the draft, but the current text seems still restricted to name servers.

I missed updating the part. It's too late, but if possible, I would
like to update the part a follows.

---
"In-bailiwick" is an adjective indicating that a domain name is
a subdomain of or (rarely) the same as another domain name.
"Out-of-bailiwick" is the antonym of in-bailiwick.
(The term "bailiwick" means the district or territory where a bailiff or 
policeman has
jurisdiction.)

"In-bailiwick" and "out-of-bailiwick" are usually used for name servers' names.
"In-bailiwick" name server is a name server whose name
is either a subdomain of or (rarely) the same as the origin
of the zone that contains the delegation to the name server.
In-bailiwick name servers may have glue records in their parent
zone (using the first of the definitions of "glue records" in the definition 
above).

"In-bailiwick" names are divided into two type of name server names:
"in-domain" names and "sibling domain" names.

In-domain:
sibling domain:

examples
-

--
Kazunori Fujiwara, JPRS 

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Call for Adoption: draft-huque-dnsop-multi-provider-dnssec

[Joe Abley]

On Jul 10, 2018, at 16:09, Paul Wouters  wrote:

> On Fri, 6 Jul 2018, Tim Wicinski wrote:

> 
>> This starts a Call for Adoption for: draft-huque-dnsop-multi-provider-dnssec
>> The draft is available here: 
>> https://datatracker.ietf.org/doc/draft-huque-dnsop-multi-provider-dnssec/
> 
> I've reviewed the draft. It seems to me this is mostly a description of
> novel uses of IETF protocols and possible business models. I don't see
> a strong case for publishing this as an RFC and have a preference for
> DNSOP to focus their time on working on protocol/operations matters and
> our communal backlog of that.

I actually think the document is actually almost entirely operational; at 
least, it describes a set of operational and design considerations for 
deploying DNS services constrained by particular sets of requirements. I don't 
see it as describing business models, but rather how commonly-available 
commercial DNS services can be lego'd together. Having said that, see (further) 
below.

I don't particularly know who the audience for this document is, but I'm pretty 
sure it's not me. So I'm not the right person to judge whether it solves a real 
problem or is pitched at the right level. I haven't reviewed the document in 
detail; I've just skimmed through it. I'm pretty confident that the authors 
know what they are talking about :-)

> So I am not in favour of adoption, but I would not object to adoption
> either if that's how others want to spend the DNSOP time.

I don't know that the document would necessarily benefit from adoption by the 
working group. I also don't know that the working group ought to have the kind 
of concern about the topics that this document addresses that would cause it to 
seek editorial control. It seems entirely plausible that the document contains 
useful advice, however, and that the RFC series is a suitable place for its 
publication.

I think this document is an ideal candidate for the independent stream. I don't 
see an obvious reason why it belongs in dnsop.

Like Paul, my lack of enthusiasm for adoption shouldn't be interpreted as an 
objection.


Joe
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Doh] Resolverless DNS Side Meeting in Montreal

[Adam Roach]

On 7/10/18 10:30 AM, Joe Abley wrote:

On Jul 10, 2018, at 16:09, Adam Roach  wrote:


[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?

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:


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 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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Doh] Resolverless DNS Side Meeting in Montreal

[Joe Abley]

On Jul 10, 2018, at 17:22, Adam Roach  wrote:

> Basically, you're describing a solution space that could be realized as 
> something like:
>
> https://example.com/img/f.jpg"; ip="192.0.2.1">

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 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.

> 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;

Likewise. However, I think DNS protocol advice is probably more useful
as input to the analysis if it's clear that the DNS is necessarily
involved.


Joe

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Working Group Last Call for for draft-ietf-dnsop-rfc5011-security-considerations-12; was Publication has been requested for draft-ietf-dnsop-rfc5011-security-considerations-12

[Paul Hoffman]

On 10 Jul 2018, at 11:35, Michael StJohns wrote:

And as you may have guessed I object to the publication of this 
document on the basis of quality for all the reasons previously 
stated.  This version of the document is actually in worse shape than 
the one that failed last call back in October.


Documents go to WG Last Call to determine consensus and fix errors; this 
document appears to have done both, so there was no failure.


I strongly object to the publication of this document as a Standards 
Track document. The appropriate status  - if published - is 
Informational with or without a BCP tag on it. 


There is no such thing as a "BCP tag". An RFC that is a BCP is treated 
as a standard. See Section 5 of RFC 2026.


The document does not provide any implementable protocol, and by that 
I mean that the only protocol elements in this document must be 
executed by humans.  There is no on-the-wire elements, nor any 
process that can be implemented by a DNS resolver or server.  This is 
solely and only an operational practices document,


True.


and AFAICT, none of these have ever ended up as Standards Track.


Not true. Plenty of WGs, including this one, put operational documents 
on standards track.


   Or to put it more bluntly - humans are not protocol elements that 
can be standardized. 


True, but not relevant to the issue at hand.


Finally, this purports to update RFC7538 which is Informational.


That's a good point. The WG draft that led to RFC 7538 was marked as 
Informational for its entire lifetime, so the WG must have thought it 
was OK to treat key rollover timing considerations as Informational.


--Paul Hoffman

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Driu] [Doh] Resolverless DNS Side Meeting in Montreal

[Ted Lemon]

On Tue, Jul 10, 2018 at 12:34 PM, Joe Abley  wrote:

> > But this is really equivalent in just about every important way to
> sending the normal 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


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.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Driu] [Doh] Resolverless DNS Side Meeting in Montreal

[Joe Abley]

On Jul 10, 2018, at 17:41, Ted Lemon  wrote:

On Tue, Jul 10, 2018 at 12:34 PM, Joe Abley  wrote:

> > But this is really equivalent in just about every important way to
> sending the normal 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


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.


I'm haven't thought hard enough to say what vulnerability that would enable
that wasn't already there using unsigned zones (because enterprise DNS
tricks or some other reason) but you're probably right.


Joe
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Doh] Resolverless DNS Side Meeting in Montreal

[Adam Roach]

On 7/10/18 11:34 AM, Joe Abley wrote:

On Jul 10, 2018, at 17:22, Adam Roach  wrote:


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

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

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 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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Working Group Last Call for: draft-ietf-dnsop-attrleaf

[Dick Franks]

On 10 July 2018 at 15:32, Dave Crocker  wrote:

> On 7/9/2018 2:35 PM, Dick Franks wrote:

  >8
>
>>
>>   If a public specification calls for the use of an
>> underscore-prefixed domain name,
>> the underscored name closest to the root MUST be entered into this
>> registry.
>>
>>
> Thanks.  I've added some tweakage to your text:
>
>  If a public specification calls for use of an _underscore-prefixed
>domain node name, the 'global' underscored name -- the name that is
>closest to the DNS root -- MUST be entered into this registry.
>Historically, this is the right-most name that is begins with an
>underscore.
>

You just seem to have reintroduced yet more confusing and redundant
verbiage.

The whole point of my suggested text was to remove the extraneous
directional adjectives
like "right-most", "highest-level", "top-most", "global", etc., which we
have already established
are not as concise or unambiguous as we might have wished.

Also,  "domain name" is the recognised and recommended usage per RFC7719
and the latest
DNS Terminology draft.

A reference to RFC7719 or its successor would be sufficient for readers
unfamiliar with DNS
terminology, if indeed there are any.

As for _underscore-prefixed,  there are enough examples in the document for
even the most
intellectually challenged reader to grasp what underscore-prefixed domain
names look like.
Idiosyncratic usage reflects badly on the document production standards of
the organisation.



> > (Editorial:  The word underscore does not itself need to be
> > underscore-prefixed)
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Driu] [Doh] Resolverless DNS Side Meeting in Montreal

[Adam Roach]

On 7/10/18 11:41 AM, Ted Lemon wrote:
On Tue, Jul 10, 2018 at 12:34 PM, Joe Abley > wrote:


> But this is really equivalent in just about every important way to sending 
the normal 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


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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Driu] [Doh] Resolverless DNS Side Meeting in Montreal

[Ted Lemon]

I'm not suggesting that the attack surfaces couldn't be closed, and that
does seem like it would be sufficient to close them.   However, we've been
burned by implementations not getting details like this right in the past,
so that's why I brought it up.

On Tue, Jul 10, 2018 at 1:05 PM, Adam Roach  wrote:

> On 7/10/18 11:41 AM, Ted Lemon wrote:
>
> On Tue, Jul 10, 2018 at 12:34 PM, Joe Abley  wrote:
>
>> > But this is really equivalent in just about every important way to
>> sending the normal 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
>
>
> 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
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Doh] Resolverless DNS Side Meeting in Montreal

[Patrick McManus]

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  wrote:

> On 7/10/18 11:34 AM, Joe Abley wrote:
>
>> On Jul 10, 2018, at 17:22, Adam Roach  wrote:
>>
>> Basically, you're describing a solution space that could be realized as
>>> something like:
>>>
>>> https://example.com/img/f.jpg"; ip="192.0.2.1">
>>>
>> 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 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
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Working Group Last Call for for draft-ietf-dnsop-rfc5011-security-considerations-12; was Publication has been requested for draft-ietf-dnsop-rfc5011-security-considerations-12

[Michael StJohns]

On 7/10/2018 12:34 PM, Paul Hoffman wrote:

On 10 Jul 2018, at 11:35, Michael StJohns wrote:

And as you may have guessed I object to the publication of this 
document on the basis of quality for all the reasons previously 
stated.  This version of the document is actually in worse shape than 
the one that failed last call back in October.


Documents go to WG Last Call to determine consensus and fix errors; 
this document appears to have done both, so there was no failure.


I'm not sure if you're word parsing or what here, but the result of the 
WGLC was that the document still needed work and that there was no 
consensus.  Generally referred to as "failing to pass the WGLC".   
Generally, passing means nits to be fixed, with a general consensus to 
publish.  That didn't happen - the "pass", so the opposite of "pass" is 
"fail".


If you're saying that the document has both fixed the issues and gained 
consensus - well, that's what this call is for.  My opinion is that the 
document still needs work, others may not agree.  As for consensus, 
AFAICT, there has been no on-the-list call from consensus since the 
previous WG meeting that noted meeting consensus - and as we all know - 
meeting consensus isn't sufficient to determine consensus.




I strongly object to the publication of this document as a Standards 
Track document. The appropriate status  - if published - is 
Informational with or without a BCP tag on it.


There is no such thing as a "BCP tag". An RFC that is a BCP is treated 
as a standard. See Section 5 of RFC 2026.


Mostly fair point - but while treated as a standard, a BCP is not a 
standard in the meaning of Standards Track.   So Informational or BCP, 
not Proposed Standard.  And given 7893, I'd say Informational.





The document does not provide any implementable protocol, and by that 
I mean that the only protocol elements in this document must be 
executed by humans. There is no on-the-wire elements, nor any process 
that can be implemented by a DNS resolver or server.  This is solely 
and only an operational practices document,


True.


and AFAICT, none of these have ever ended up as Standards Track.


Not true. Plenty of WGs, including this one, put operational documents 
on standards track.


Here are the RFCs that come up with "Standard Track" and "dnsop" as the 
search terms.   Which one is an "operational document"?    I didn't have 
time to search through the other pile of 8K plus RFCs, but did check 
dnsext and found a dearth of operational documents as standards there.  
AFAICT, all of these propose modifications to resolver or server behavior.





Number 
 



	Files 	Title 	Authors 	Date 
 
	More Info 	Status
RFC 7344  	ASCII 
, PDF 
 	Automating DNSSEC 
Delegation Trust Maintenance 	W. Kumari, O. Gudmundsson, G. Barwood 
September 2014 	Updated by RFC 8078 
 	Proposed Standard (changed 
from Informational March 2017 )
RFC 7477  	ASCII 
, PDF 
 	Child-to-Parent 
Synchronization in DNS 	W. Hardaker 	March 2015 	Errata 
 	Proposed Standard
RFC 7686  	ASCII 
, PDF 
 	The ".onion" 
Special-Use Domain Name 	J. Appelbaum, A. Muffett 	October 2015 	 
Proposed Standard
RFC 7766  	ASCII 
, PDF 
 	DNS Transport over 
TCP - Implementation Requirements 	J. Dickinson, S. Dickinson, R. 
Bellis, A. Mankin, D. Wessels 	March 2016 	Obsoletes RFC 5966 
, Updates RFC 1035 
, RFC 1123 
 	Proposed Standard
RFC 7828  	ASCII 
, PDF 
 	The 
edns-tcp-keepalive EDNS0 Option 	P. Wouters, J. Abley, S. Dickinson, 
R. Bellis 	April 2016 		Proposed Standard
RFC 7873  	ASCII 
, PDF 
 	Domain Name System 
(DNS) Cook

Re: [DNSOP] [Driu] [Doh] Resolverless DNS Side Meeting in Montreal

[Philip Homburg]

>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.

That's a rather fundamental issue.

In the context of TLS, and a DNSSEC insecure zone, there are two realistic
attack scenarios:
- an attack on DNS that returns different addresses for a DNS lookup
- a routing attack, that reroutes traffic.

Both types of attacks are realistic and happen quite frequently.

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.

On the other hand, if we don't trust TLS, then we have a bit of a problem.
Too many people using public resolvers. Route hijacks are quite easy, etc.


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Doh] Resolverless DNS Side Meeting in Montreal

[Dave Lawrence]

Paul Vixie writes:
> > For example www.example.com  pushes you a 
> > record for img1.example.com . Should you use
> > it?
> 
> no. sibling names might be delegation points. kashpureff taught us this 
> in 1996 or so, and kaminsky reinforced that lesson in 2008.
> 
> > What if it is for img1.img-example.com ?
> 
> certainly not.

In the large I agree with you, but I think there's more to it than
that.  If it pushed me DNSSEC records that I could verify myself from
my own configured trust anchor, why can't I trust them then?


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Doh] [Driu] Resolverless DNS Side Meeting in Montreal

[Adam Roach]

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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Driu] [Doh] Resolverless DNS Side Meeting in Montreal

[Ryan Sleevi]

On Tue, Jul 10, 2018 at 1:05 PM, Adam Roach  wrote:

> On 7/10/18 11:41 AM, Ted Lemon wrote:
>
> On Tue, Jul 10, 2018 at 12:34 PM, Joe Abley  wrote:
>
>> > But this is really equivalent in just about every important way to
>> sending the normal 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
>
>
> 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.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Doh] Resolverless DNS Side Meeting in Montreal

[Dave Lawrence]

Tim Wicinski writes:
> "Are you trying to re-invent DNSSEC for people who don't want to deploy
> DNSSEC?"
> 
> My magic 8-ball says "signs point to Yes"

I don't grok how y'all got "trying to re-invent DNSSEC" out of this,
so this is sure to be an entertaining discussion.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Doh] Resolverless DNS Side Meeting in Montreal

[Joe Abley]

On Jul 10, 2018, at 18:02, Adam Roach  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?


Joe

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Doh] Resolverless DNS Side Meeting in Montreal

[Adam Roach]

On 7/10/18 12:55 PM, Joe Abley wrote:

On Jul 10, 2018, at 18:02, Adam Roach  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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Driu] [Doh] Resolverless DNS Side Meeting in Montreal

[Paul Wouters]

On Tue, 10 Jul 2018, Ryan Sleevi wrote:


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. 


This of course, is only an argument in favour of DANE depricating WebPKI,
especially in light of the EV failures reducing webpki to only DNS already :)

Paul





___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Doh] Resolverless DNS Side Meeting in Montreal

[Dave Lawrence]

Joe Abley writes:
>but collapsing the address selection back to the extent that you can
> avoid name resolution at all seems like a better end goal. 
> 
> So rather than resolverless operation, think about resolutionless or
> nameless, eliminating the DNS as unnecessary overhead. 
> 
> Perhaps I have misunderstood the whole problem space, of course :-)

I believe you are spot-on.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Driu] [Doh] Resolverless DNS Side Meeting in Montreal

[Mike Bishop]

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:ryan-i...@sleevi.com]
Sent: Tuesday, July 10, 2018 10:52 AM
To: Adam Roach 
Cc: Ted Lemon ; Joe Abley ; DoH WG 
; d...@ietf.org; dnsop WG ; Paul Wouters 
; Patrick McManus ; Philip Homburg 
; HTTP Working Group 
Subject: Re: [Driu] [DNSOP] [Doh] Resolverless DNS Side Meeting in Montreal



On Tue, Jul 10, 2018 at 1:05 PM, Adam Roach 
mailto:a...@nostrum.com>> wrote:
On 7/10/18 11:41 AM, Ted Lemon wrote:
On Tue, Jul 10, 2018 at 12:34 PM, Joe Abley 
mailto:jab...@hopcount.ca>> wrote:
> But this is really equivalent in just about every important way to sending 
> the normal 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

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.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Doh] Resolverless DNS Side Meeting in Montreal

[Daniel Kahn Gillmor]

On 07/10/2018 01:43 PM, Dave Lawrence wrote:

> In the large I agree with you, but I think there's more to it than
> that.  If it pushed me DNSSEC records that I could verify myself from
> my own configured trust anchor, why can't I trust them then?

alternately, if i know that i'm going to verify the data in them some
other way (e.g. via X.509 certificate verification in a TLS connection),
is it even "trust" to say that you might be willing to try using the
data in those records to see whether you can create an authenticated
connection?

I'm not saying it's a slam dunk: there are privacy concerns in both
directions. but i think the situation is very context-specific.  certain
clients have specific needs for these records to validate in some
particular ways, but other clients have different needs.  I hope the
discussion will be very specific about which clients we're talking about
-- not just which specific transport the DNS records arrive over.

--dkg


-- 
Daniel Kahn Gillmor
Senior Staff Technologist
Speech, Privacy, and Technology Project
American Civil Liberties Union
+1.212.284.7336
OpenPGP fingerprint: 0EE5BE979282D80B9F7540F1CCD2ED94D21739E9
Pronouns: he/him/his
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Doh] Resolverless DNS Side Meeting in Montreal

[Tony Finch]

Dave Lawrence  wrote:
>
> In the large I agree with you, but I think there's more to it than
> that.  If it pushed me DNSSEC records that I could verify myself from
> my own configured trust anchor, why can't I trust them then?

I've been idly wondering about this from the point of view of RFC 2181
trust ranking: to what extent does it make sense to promote the rank of
data (e.g. additional records) that has been validated?

The risk, I think, is replaying stale data - there shouldn't be any worse
consequences. So it should amount to a DoS attack (and there are easier
ways to achieve one of those).

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
Shannon: Northerly 3 or 4, occasionally 5 in east. Moderate. Mainly fair.
Good.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Working Group Last Call for for draft-ietf-dnsop-rfc5011-security-considerations-12; was Publication has been requested for draft-ietf-dnsop-rfc5011-security-considerations-12

[Wes Hardaker]

Michael StJohns  writes:

> I strongly object to the publication of this document as a Standards Track
> document.

I'll catch up on the rest of the thread later tonight (I've been gone),
but I agree with MSJ here: it should be informational; it's not a
protocol.
-- 
Wes Hardaker
USC/ISI

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Driu] [Doh] Resolverless DNS Side Meeting in Montreal

[Ryan Sleevi]

On Tue, Jul 10, 2018 at 2:09 PM, Mike Bishop  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).
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Working Group Last Call for for draft-ietf-dnsop-rfc5011-security-considerations-12; was Publication has been requested for draft-ietf-dnsop-rfc5011-security-considerations-12

[Paul Hoffman]

On 10 Jul 2018, at 13:25, Michael StJohns wrote:


Finally, this purports to update RFC7538 which is Informational.


That's a good point. The WG draft that led to RFC 7538 was marked as 
Informational for its entire lifetime, so the WG must have thought it 
was OK to treat key rollover timing considerations as Informational.


*sigh*  Sorry - RFC7583 - not 7538.


We both gave the wrong number, but what you say and what I say still 
stands: this WG earlier decided that an earlier document on key rollover 
timing considerations was Informational.


--Paul Hoffman

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] SRV and HTTP

[Mark Nottingham]

> On 11 Jul 2018, at 3:55 am, Joe Abley  wrote:
> 
> On Jul 10, 2018, at 18:02, Adam Roach  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?
> 

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/

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] SRV and HTTP

[Ólafur Guðmundsson]

Yes


On Tue, Jul 10, 2018 at 9:22 PM, Mark Nottingham  wrote:

>
>
> > On 11 Jul 2018, at 3:55 am, Joe Abley  wrote:
> >
> > On Jul 10, 2018, at 18:02, Adam Roach  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?
> >
>
> 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/
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>



-- 
Ólafur Gudmundsson | Engineering Director
www.cloudflare.com blog.cloudflare.com
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] SRV and HTTP

[Mark Andrews]

> On 11 Jul 2018, at 11:22 am, Mark Nottingham  wrote:
> 
> 
> 
>> On 11 Jul 2018, at 3:55 am, Joe Abley  wrote:
>> 
>> On Jul 10, 2018, at 18:02, Adam Roach  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?
>> 
> 
> I recently did some digging on this topic, and can try to characterise what 
> the issues / objections are.

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.


> 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/
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] SRV and HTTP

[Mark Nottingham]

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  wrote:
> 
> 
> 
>> On 11 Jul 2018, at 11:22 am, Mark Nottingham  wrote:
>> 
>> 
>> 
>>> On 11 Jul 2018, at 3:55 am, Joe Abley  wrote:
>>> 
>>> On Jul 10, 2018, at 18:02, Adam Roach  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?
>>> 
>> 
>> I recently did some digging on this topic, and can try to characterise what 
>> the issues / objections are.
> 
> 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.
> 
> 
>> 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/
>> 
>> ___
>> DNSOP mailing list
>> DNSOP@ietf.org
>> https://www.ietf.org/mailman/listinfo/dnsop
> 
> -- 
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org

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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] SRV and HTTP

[Mark Andrews]

Fine by me.

> On 11 Jul 2018, at 11:32 am, Mark Nottingham  wrote:
> 
> 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  wrote:
>> 
>> 
>> 
>>> On 11 Jul 2018, at 11:22 am, Mark Nottingham  wrote:
>>> 
>>> 
>>> 
 On 11 Jul 2018, at 3:55 am, Joe Abley  wrote:
 
 On Jul 10, 2018, at 18:02, Adam Roach  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?
 
>>> 
>>> I recently did some digging on this topic, and can try to characterise what 
>>> the issues / objections are.
>> 
>> 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.
>> 
>> 
>>> 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/
>>> 
>>> ___
>>> DNSOP mailing list
>>> DNSOP@ietf.org
>>> https://www.ietf.org/mailman/listinfo/dnsop
>> 
>> -- 
>> Mark Andrews, ISC
>> 1 Seymour St., Dundas Valley, NSW 2117, Australia
>> PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org
> 
> --
> Mark Nottingham   https://www.mnot.net/
> 

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] SRV and HTTP

[Dave Lawrence]

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

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.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] SRV and HTTP

[Dave Lawrence]

Dave Lawrence writes:
> Mark Nottingham writes:
> > I'll start collecting. How about Tuesday, say 6:45-7:45pm?
> 
> 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.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] SRV and HTTP

[Mark Andrews]

> On 11 Jul 2018, at 11:51 am, Dave Lawrence  wrote:
> 
> Mark Nottingham writes:
>> I'll start collecting. How about Tuesday, say 6:45-7:45pm?
> 
> 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.

It’s a 9 minute walk (4 blocks).

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] SRV and HTTP - 18:30 Tuesday

[Mark Nottingham]

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  wrote:
> 
> Dave Lawrence writes:
>> Mark Nottingham writes:
>>> I'll start collecting. How about Tuesday, say 6:45-7:45pm?
>> 
>> 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.
> 
> ___
> DRIU mailing list
> d...@ietf.org
> https://www.ietf.org/mailman/listinfo/driu

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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] SRV and HTTP

[John Levine]

In article <82099ded-ccb6-4cdc-bfe6-97b1ab3eb...@isc.org> you write:
>1) Wildcards don’t work with prefixes.

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

There's over 6000 service names defined for SRV.  That's a lot of rrtypes.

R's,
John

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] SRV and HTTP

[Evan Hunt]

On Tue, Jul 10, 2018 at 11:08:37PM -0400, John Levine wrote:
> There's over 6000 service names defined for SRV.  That's a lot of rrtypes.

But HTTP/HTTPS is the one we have by far the most problems with.

-- 
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] SRV and HTTP

[John R Levine]

On Tue, Jul 10, 2018 at 11:08:37PM -0400, John Levine wrote:

There's over 6000 service names defined for SRV.  That's a lot of rrtypes.


But HTTP/HTTPS is the one we have by far the most problems with.


True, and there have been some proposals for DNS records to return http 
parameters.


It's always been my impression that the http crowd believe that the
overhead of a two DNS lookups is too slow, for some meaning of too slow.

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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] SRV and HTTP

[Mark Andrews]

> On 11 Jul 2018, at 1:16 pm, John R Levine  wrote:
> 
>> On Tue, Jul 10, 2018 at 11:08:37PM -0400, John Levine wrote:
>>> There's over 6000 service names defined for SRV.  That's a lot of rrtypes.
>> 
>> But HTTP/HTTPS is the one we have by far the most problems with.
> 
> True, and there have been some proposals for DNS records to return http 
> parameters.
> 
> It's always been my impression that the http crowd believe that the
> overhead of a two DNS lookups is too slow, for some meaning of too slow.

Which is predicated on the recursive server not filling in the additional 
section.
Recursive servers can and do fill the additional section with SRV (starting 
with NAPTR
records) then add A,  and TLSA records.  They can lookup missing record 
before
returning the SRV or NAPTR records (there is code to do that for SRV).  Its 
easy to
do the same thing for other record types.  

> Regards,
> John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
> Please consider the environment before reading this e-mail. https://jl.ly
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] SRV and HTTP

[Patrik Fältström]

On 11 Jul 2018, at 3:30, Mark Andrews 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.

4) Various libraries in PHP and ultimately lib curl do not include SRV in the 
resolution

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

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

> 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.

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


signature.asc
Description: OpenPGP digital signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] SRV and HTTP

[Patrik Fältström]

On 11 Jul 2018, at 5:16, John R Levine wrote:

> It's always been my impression that the http crowd believe that the
> overhead of a two DNS lookups is too slow, for some meaning of too slow.

They rather stay in the space they know, HTTP resolution, and do multiple HTTP 
requests instead of multiple DNS requests.

Just like we DNS people rather do more in DNS.

   paf


signature.asc
Description: OpenPGP digital signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] SRV and HTTP

[Mark Andrews]

> On 11 Jul 2018, at 3:53 pm, Patrik Fältström  wrote:
> 
> On 11 Jul 2018, at 3:30, Mark Andrews 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.
> 
> 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

>> 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.
> 
> 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: ma...@isc.org

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop