Re: [DNSOP] Warren did a bad (was Re: Datatracker State Update Notice: )

[Independent Submissions Editor (Eliot Lear)]

A quick status from the ISE:

draft-makarenko-gost2012-dnssec was formally submitted to me for 
consideration as an independent RFC in May of this year.  Before I make 
a publication decision, there are a number of issues that need to be 
addressed:


 * What to do about RFC 5933?  The original draft obsoleted that RFC,
   and independent submissions *can't* do that.
 * What to do about the very minor update that the original draft made
   to RFC 8624.  Again, independent submissions can't make changes to
   status of IETF works.
 * There are also some IANA issues that must be resolved.  A special
   thank you to Amanda for catching them.

As to the work's stream, the authors brought their document to the ISE 
and it is likely to meet the publication criteria, once the above issues 
are addressed.  If the IETF now decides to still move forward on 
draft-ietf-dnsop-rfc5933-bis, that's fine with me as well.  My one 
request, should this matter be reconsidered, is that the matter be 
discussed and decided in a timely fashion, in fairness to the authors.  
I'll be around in Prague, and I look forward to seeing many of you.


Eliot

On 21.10.2023 19:24, Warren Kumari wrote:

[ +DNSOP for real this time]
Dear DNSOP,

I accidentally did a bad.

Back in December 2022, when we were 
progressing draft-ietf-dnsop-rfc5933-bis, I sent this mail, but I 
missed the fact that DNSOP was not actually on the To: line, and so 
missed these discussions.


This email basically just agrees with Roman's suggested path forward 
in 
https://mailarchive.ietf.org/arch/msg/dnsop/XZoakWUDruPXylJ2wLIS4l4vevo/ , 
and asks if the ISE would take on the GOST stuff.


I also should have mentioned to the WG the ISE was 
progressing draft-makarenko-gost2012-dnssec-03 and asked y'all to 
review. Basically I was just received that it was finally moving 
along, and completely  spaced on the "Oh, yeah, I should make sure 
DNSOP has seen this" bit.


Apologies,
W

P.S: The discussions leading up to the ISE bit are all from 10-11 
months ago, so I've swapped out much of the state, and am still 
swapping it back in…






On Thu, Dec 01, 2022 at 10:00 PM, Warren Kumari  wrote:

Dear authors, and ISE (and Roman, PaulW, PaulH)

Thank you for updating the document to address Paul Wouter's
DISCUSS position (

https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc5933-bis/ballot/#draft-ietf-dnsop-rfc5933-bis_paul-wouters


 )

Unfortunately I was unsuccessful in arguing that this should
proceed in the IETF because:
1: the document only describes how to use GOST with DNSSEC (and
doesn't define GOST itself)
2: RFC5933 was an IETF document which this obsoletes
3: the WG had updated the registry policy to allow this to become
an Informational document and still progress in the WG.

The IESG pointed to significant precedent on these sorts of
documents going through the ISE, such as RFC 9189,
draft-smyshlyaev-tls13-gost-suites, and draft-smyslov-ike2-gost.

Roman has proposed a fairly simple, and, assuming that the ISE is
willing, fast and easy path forward:
https://mailarchive.ietf.org/arch/msg/dnsop/XZoakWUDruPXylJ2wLIS4l4vevo/
 .


So, while I'm sure that this is very frustrating to the authors,
I'm asking you to please split the document as described. Again, I
know that this is frustrating, and I'm willing to help with
editorial issues, and Roman has agreed to assist as well.

I'm also asking the ISE if they would be willing (please?) to take
on and publish the (split) document, and, because it has already
gone through the DNSOP WG, DNSOP WGLC, IETF LC, and IESG review,
if they would be willing to fast-track it.

Sorry for what I'm sure is discouraging news,
W



On Thu, Dec 01, 2022 at 11:06 AM, IETF Secretariat
mailto:ietf-secretariat-re...@ietf.org>> wrote:

IESG state changed:

New State: IESG Evaluation::AD Followup

(The previous state was IESG Evaluation)

Datatracker URL:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc5933-bis/

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

Re: [DNSOP] WGLC for draft-ietf-dnsop-alt-tld

[Eliot Lear]

Chairs,

Can we get some follow-up on this?

Thanks,

Eliot

On 13.01.23 16:56, Suzanne Woolf wrote:


Colleagues,

This WGLC is closed,  with many thanks to everyone who commented.

The chairs and editors are reviewing the comments and will summarize 
in the next few days.


Suzanne, for the chairs

*From: *Suzanne Woolf 
*Date: *Tuesday, December 13, 2022 at 3:26 PM
*To: *"dnsop@ietf.org" 
*Cc: *"dnsop-cha...@ietf.org" , "Rob Wilton 
(rwilton)" 

*Subject: *WGLC for draft-ietf-dnsop-alt-tld
*Resent-From: *
*Resent-To: *, , 
*Resent-Date: *Tuesday, December 13, 2022 at 3:26 PM

Dear colleagues,

This message will serve to start a Working Group Last Call on “The ALT 
Special Use Top Level Domain” 
(https://datatracker.ietf.org/doc/draft-ietf-dnsop-alt-tld/ 
). 
Due to the end-of-year holidays, we’re starting it now and will give 
it four weeks.


As you’ve seen from Paul Hoffman’s email, the authors have updated to 
version 19 based on the feedback they heard at IETF 115. Thanks Paul 
and Warren!


The WG is very familiar with this document by now, and the WGLC is to 
determine whether the document has rough consensus to progress. The 
chairs need to know whether you support it (which, for this purpose, 
includes “I can live with it”), or actively oppose publishing it.


Please also assume that any necessary liaison communications with 
ICANN will be undertaken if this document has WG consensus to move 
forward. Managing the potential for misunderstanding or differences of 
opinion among relevant organizations is the primary reason why the 
IETF has liaison relationships. The IETF liaison to the ICANN Board is 
Harald Alvestrand, who has been monitoring the conversations about 
alt-tld on the mailing list and has discussed the draft with the 
chairs and with Rob Wilton as the responsible AD.


Start date: 13 December 2022

End date:  10 January 2023

Many thanks,

Suzanne, Tim, and Benno


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

Re: [DNSOP] draft-ietf-dnsop-alt-tld-19

[Eliot Lear]

On 15.12.22 03:51, Paul Wouters wrote:

I don't interpret it as "the person responsible for fixing the
conflict". I think if one opts to use a name under .alt, one has to
engineer in how to deal with conflicts in that namespace. It is a
fundamental feature/bug of it. 


That is true with *any* namespace.  The reason we are here is that we 
are attempting to engineer how to deal with conflicts with the DNS name 
space.  Also,  some conflicts may be okay in .ALT, depending on how it 
is used (imagine locally scoped well known names, for instance).  We 
really can't say since we're not setting engineering goals or standards 
for its use. So let's be quiet on the matter, other than to say that how 
others use ALT is out of scope.


Eliot

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

Re: [DNSOP] draft-ietf-dnsop-alt-tld-19

[Eliot Lear]

We're off in the woods again.  Let's keep these two principles in mind:

 * The DNS resolution mechanisms are not expected to resolve, let alone
   secure names ending in .ALT.
 * How other resolution mechanisms secure names is their affair.

Therefore, any collisions that occur within .ALT are for alternate 
resolution mechanisms themselves to resolve (or not, as they see fit).  
Which brings me to this:


On 14.12.22 17:13, Paul Wouters wrote:

"bob.foo.alt" still squarely falls into "my" namespace
It is indeed not “yours”.


... from the perspective of DNS.  Whether it is "yours" or "mine" from 
the perspective of GNS is a matter for GNS to resolve (for example).


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

Re: [DNSOP] draft-ietf-dnsop-alt-tld-19

[Eliot Lear]

I think the point here is that collisions within the alt name space are 
beyond the scope of this document.  Perhaps that's what should be said.


Eliot

On 14.12.22 11:08, Martin Schanzenbach wrote:

Hi Paul,

the draft lgtm. But, the passage regarding collisions because of
the missing registry now contains a regression IMO:

"Developers are wholly responsible for dealing with any collisions"

I think this is an impossible task and as a developer that is addressed
here I have to say that we cannot do that unilaterally for our
implementation/design because collisions occur when _others_ do
something.
Maybe you are talking about "groups" (as used in this paragraph) or the
"alternative name system community" here, which would make more sense?
This paragraph also uses both "groups" and "developers", and the
difference (to me) is not clear.

Maybe simply strike this sentence again?
Instead or in addition maybe a full acknowledment of this issue in the
security considerations, along the lines of

"
This draft does not define a registry or governance model for the .alt
namespace and as such developers/groups as well as users and applications cannot
expect unambiguous mappings from names with a ".alt"-TLD to a specific
alternative name space / name resolution mechanism.
This issue can be mitigated, for example, through the creation and use of a
registry by the alternative name system developer community.
"

Best
Martin

On 13.12.22 20:20, Paul Hoffman wrote:

Greetings again. As you can see, Warren and I just updated the draft to reflect 
the WG discussion at IETF 115 and on the list after that. At IETF 115, the WG 
chairs said that they might move this to a second WG Last Call soon.

In the discussion, there was lots of active disagreement about reducing traffic 
to the root servers, particularly around what it would mean for recursive 
resolvers filtering for .alt. One such proposal that came up was scrapping this 
draft and moving to AS112, but there was little interest and some strong 
pushback.

Thus, we did not include any proposed way to do this in the new draft, although 
we did make a strong push towards methods resolvers could use that would reduce 
root queries for names ending not only in .alt, but all other non-existent TLDs.

--Paul Hoffman

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

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


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

[DNSOP] the requested change to the dns-alt draft

[Eliot Lear]

As mentioned in the dnsop meeting the proposed change would be to remove 
the following sentences in Section 2:


OLD:

   Alternative namespaces should differentiate themselves from other
   alternative namespaces by choosing a name and using it in the label
   position just before the .alt pseudo-TLD.  For example, a group
   wishing to create a namespace for Friends Of Olaf might choose the
   string "foo" and use any set of labels under foo.alt.

OLD:

 They should attempt to choose a label that they
   expect to be unique among similar groups and, ideally, descriptive.


This comes under the "do/do not" approach, and the WG has chosen to "do 
not" as far as a registry is concerned.


Regards,

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

Re: [DNSOP] [Ext] Possible alt-tld last call?

[Eliot Lear]

Hi Ben and Wes,

On 21.10.22 20:45, Ben Schwartz wrote:


Rather than placing "alt" in the TLD position, I think it might be 
better as a scheme modifier: https+alt://...  This is a common 
pattern  for modifications to URI schemes (c.f. git+ssh://), and 
informs the software that this URI is special without overloading the 
DNS namespace.


How would this work in practice?

 * Would this require a re-registering of each and every URI scheme
   with +alt, and monitoring the URI scheme registry for new ones? 
   (I'll note that git+ssh isn't registered.)
 * What is the value of +alt at this point?  Why not use +gns or +onion
   or +eliotsfavoritenamespace?
 * How might or should this be reflected in the browser bar?

That last question probably has no pat answer, which is okay so long as 
we are clear that it does not.


Eliot



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

Re: [DNSOP] [Ext] no regitry for you, Possible alt-tld last call?

[Eliot Lear]

On 23.10.22 05:40, John Levine wrote:

It appears that Eliot Lear   said:

As a matter of practicality, a registry surely will be form.  It is
simply a matter of whether the IANA will host it.  If the IANA does not
host it, then by shifting it elsewhere this group is actually weakening
the IANA function, and that would be sad.

But trying to turn IANA and .alt into a junior version of ICANN would
be much worse than sad.


Nobody is trying to do that.

Eliot


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

[DNSOP] a correction

[Eliot Lear]

Not to the content, but a note I sent earlier was sent from the wrong 
address (as ISE).  The content is below, and should have been sent from 
my personal address (this one).  My apologies for any confusion.


Eliot

I'm with Dave on this.  There is nothing wrong with telling endpoints, 
“Don't transmit queries for .ALT."  That is indeed the whole point.  
Paul, you're right: we can't stop applications from not doing this, 
but we can tell them what Good looks like.


Eliot

On 21.10.22 23:39, David Conrad wrote:
This is true for all IETF protocols/specifications.  Are you arguing 
RFC 2119 “MUST” is pointless?  As far as I understand, the point of 
2119 language is to be explicit in expected behaviors, not to imply 
that the Internet Police will hunt you down if you violate them.  If 
the intent here is that .alt names should never be looked up via the 
DNS, then MUST NOT is the expected behavior, no? 




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

Re: [DNSOP] [Ext] Possible alt-tld last call?

[Independent Submissions Editor (Eliot Lear)]

I'm with Dave on this.  There is nothing wrong with telling endpoints, 
“Don't transmit queries for .ALT."  That is indeed the whole point.  
Paul, you're right: we can't stop applications from not doing this, but 
we can tell them what Good looks like.


Eliot

On 21.10.22 23:39, David Conrad wrote:

This is true for all IETF protocols/specifications.  Are you arguing RFC 2119 
“MUST” is pointless?  As far as I understand, the point of 2119 language is to 
be explicit in expected behaviors, not to imply that the Internet Police will 
hunt you down if you violate them.  If the intent here is that .alt names 
should never be looked up via the DNS, then MUST NOT is the expected behavior, 
no?


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

Re: [DNSOP] [Ext] Possible alt-tld last call?

[Eliot Lear]

On 20.10.22 21:13, Andrew Sullivan wrote:

Hi Eliot,

Still employed and still not speaking for them, I have a question:

On Thu, Oct 20, 2022 at 10:15:22AM +0200, Eliot Lear wrote:


As a matter of practicality, a registry surely will be form.


What evidence do you have for this assertion? 


They're asking for the registry.  Do you think IANA hold some special 
value to them?  And it's a common coding pattern to provide a code 
switch.  You're asking the wrong question: why would they not?



As a practical matter, after all, if a registry function were wanted 
there _already is one_ in the form of any trivial name you can think 
of in the DNS (I think Joe Abley has made this point rather well on 
the list already).


We are rehashing, and that's a non-sequitor to the argument at hand, 
which is whether there should be a protocol switch inside .ALT.   But to 
answer your question anyway, as was answered previously, there's no 
reason for these people to continuously pay money to anyone for 
something that benefits others.


Eliot




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

Re: [DNSOP] [Ext] Possible alt-tld last call?

[Eliot Lear]

Joe,

On 20.10.22 14:44, Joe Abley wrote:


To be clear, Eliot, you're not suggesting that these topics shouldn't be 
discussed here, right?


It's a working group mailing list.  Of course things can be discussed 
here.  My issue is that we are suffering from that lack of high bandwidth.


Eliot



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

Re: [DNSOP] [Ext] Possible alt-tld last call?

[Eliot Lear]

Hi Jim,

On 20.10.22 14:14, Jim Reid wrote:

IMO, it doesn’t say that at all Eliot. A fairer PoV here would be when the IETF 
gets handed non-IETF problems, it keeps well away (perhaps after a discussion 
of the merits and/or scope of that problem).


As I wrote, we should discuss this in London, but I don't think that is 
a fairer point of view.  Such a registry would naturally attach to the 
ALT TLD.  Not doing this means half a job done, and nature abhors a vacuum.


Eliot

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

Re: [DNSOP] [Ext] Possible alt-tld last call?

[Eliot Lear]

Hi Vittorio

On 20.10.22 13:19, Vittorio Bertola wrote:

But IANA is not the registry for everything under the sun, it is the registry 
for things that fall under the purview of the IETF and are part of IETF 
standards. If we agree that names under .alt do not belong to and at the IETF, 
then it makes no sense for IANA to register them, nor this would be a wound to 
its role.


The flaw with that argument is that the registry would belong to no one 
else.  The best we have is us, and ducking that says that when the IETF 
faces tough problems, others *must *step in. And *that* weakens the IANA 
function.


Eliot



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

Re: [DNSOP] [Ext] Possible alt-tld last call?

[Eliot Lear]

Hi,

First, I would like us to continue to consult on the registry matter at 
least through the London IETF, and would ask the chairs for some time in 
London for this purpose.  I would also be available for side meetings 
with any interested party, before or during the IETF.  If people would 
like, we can grab a room for this purpose, if we can do so in the 
morning so that Martin can participate remotely (he is far to the east 
of London).


As a matter of practicality, a registry surely will be form.  It is 
simply a matter of whether the IANA will host it.  If the IANA does not 
host it, then by shifting it elsewhere this group is actually weakening 
the IANA function, and that would be sad.


Two more points below.

Paul wrote:



This proposes two significant changes to the draft: make the registry FCFS and 
make entrance to it be by RFC. Those are both pretty heavy-weight for things 
*that are not part of our naming system*.


Heavy for who?  Those wanting to create an entire naming systems for the 
Internet?  Look, from my perspective I am comfortable with ANY registry 
policy.  I've already provided a number of options to put the brakes on, 
if people are worried about a sudden rash of people building entire new 
name systems for the Internet.  So let's discuss.


Martin followed up to Paul:


  I strongly prefer "drop the registry" and let the non-DNS folks figure out 
how to deal with their own issues. After you see the next draft, if you think the 
registry with your two changes is needed, you can propose to add it back in.


The consequence of this (and I am looking at ISE here) will be that our
document will not be able to clearly define how to "use" alt as we are
not an authority on how to do things in the "non-DNS folks" community and
there is not way how to do that to date obviously.


There exist a number of possibilities to establish an external 
registry.  What is important is that one of them be mentioned in the ALT 
draft, so that others know where to look.  But let's get through London.


Eliot


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

Re: [DNSOP] Possible alt-tld last call?

[Eliot Lear]

On 17.10.22 17:16, Paul Wouters wrote:


But does the IETF, when running a FCFS registry, want to take the legal
liability of your adjudicating? 


Again, Paul, if you want to ask counsel for advice and have them provide 
it here, great.  Otherwise we end up Internet-lawyering, which is also 
when we end up making bad decisions.  Also, my preferred policy would be 
"RFC Required".


Eliot

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

Re: [DNSOP] Possible alt-tld last call?

[Independent Submissions Editor (Eliot Lear)]

Hi Vittorio,

On 17.10.22 12:37, Vittorio Bertola wrote:

Well, I'm just waiting for the request to register amazon.alt.

(or xxx.alt, or ru[ssia].alt, or .alt, which some people 
will do just for fun)

Unless, of course, you mean that the ISE will adjudicate trademarks, define which strings 
are offensive and determine whether an applicant has the right to use the name of a 
country or geographical entity, thus deciding whether a proposal is "trivial or 
bad" or not.


I don't want to adjudicate names, but I have no problem adjudicating 
naming systems, including transparent attempts to get vanity names.  
Since none of those are naming systems, they would all get the official 
"bubye".


Eliot

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

Re: [DNSOP] Possible alt-tld last call?

[Eliot Lear]

Hi Paul!

Good conversation!  I hope we can discuss some of this "in person" 
(whatever that means these days) at IETF 115.


On 17.10.22 04:20, Paul Wouters wrote:

On Sun, 16 Oct 2022, Suzanne Woolf wrote:

1. As far as I can tell, this draft does not comply with RFC 6761. 
This is a problem for two reasons.


One could advance the 6761bis proposal document first, which would
remove these non-compliance items as those would be no longer needed
(as the bis document proposal removes it as these were not consistently
required in the past). Alternatively, ignoring it wouldn't be the first
time these are ignored, so I guess there is a precedence of ignoring it.


If what you are saying is that we shouldn't get hung up on 6761, then I 
agree.  There are, I think, many ways to deal with the issue that 
Suzanne raised.  One possibility not mentioned was to simply slap an 
"Updates" header on this draft if we think it's necessary, but that 
wouldn't be my first choice.  The bigger issue is below.  IMHO if we can 
kink that out, we have ourselves a ballgame.



2. Having the IETF maintain a registry of pseudo-SLDs concerns me


Me too, I really do believe that the IETF should not do this. It is an
anchor for non-IETF hooks. There is no guarantee of uniqueness in names.
Some alternative sysytems might even use .alt without SLD.
[...]
But also, IETF maintaining a list might open it up for legal liabilities
with alternative naming systems.


Let's please leave Internet lawyering to lawyers.  If people want a 
legal opinion on this draft, the IETF does have resources for that.



So I disagree with Eliot who prefered some kind of FCFS registry that
requires RFCs to get an entry. We do not want alternative naming systems
to require (and burden) the IETF with RFCs.


I am struggling to parse that sentence, but taken together with this...

Basically, .alt is what IETF recommends you should not do, and we 
should not keep
a registry of entries within it. 


We cannot assume that DNS will forever be the only Good approach and 
that all others will forever be Bad. Given that, we as a community are 
obligated to search for better, and to try new things.  As I wrote 
earlier, I do not know that GNS will succeed. I do hope and expect that 
the community will learn something from some deployment experience of 
that protocol so that the next one can be better.


There exist many registries for things the IETF doesn't recommend.  One 
need look no further than TLS 1.3 crypto-suites as an example.


No matter what we say in the ALT draft, someone could burden the IETF 
with a new draft.  People do so every day.  If it gains sufficient 
support, it would have to be at least considered, no matter the topic.  
And again, I suspect most of these sorts of documents are more likely to 
flow to the ISE or perhaps a future IRTF RG.  As the current ISE, that 
is a burden I would gladly bear, because there is the opportunity to 
help the Internet community, including the IETF and ICANN.


I also have no problem rejecting trivial or bad proposals.

Eliot




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

Re: [DNSOP] Possible alt-tld last call?

[Eliot Lear]

Hiya!

Thanks to Suzanne and the chairs for moving things forward.  On this point:

On 16.10.22 17:22, Warren Kumari wrote:



2. Having the IETF maintain a registry of pseudo-SLDs concerns me
on the basis that having the IETF “recognize” (if only by
recording) such pseudo-delegations may serve to attract unwanted
attention to the IETF’s supposed recognition of alternate
(non-DNS) namespaces as reservations of the namespace from the
shared, common DNS root. We’re still being denounced in certain
corners for .onion. It might be good to have a paragraph calling
out specifically why .alt is not a delegation of a TLD from the
DNS root by the IETF, even though it looks like one. (We didn’t
invent this problem, because we didn’t make the decision that
top-level domain labels should be used by other protocols in a way
that led to confusion. But let’s not propagate it.)



Yup. This is (IMO) the area of the draft where the consensus was the 
least clear. I still think that it would be useful to have a *purely* 
informational list saying "Group A says it is using string B and their 
documentation is at https://foo.example.com"; and "Group X also says 
that it is using string B and their documentation is at 
https://bar.example. net". Enough people 
have pushed back on asking IANA to host this that I think that it 
should be removed (and I was the one most strongly arguing for it). 
Obviously it's the DNSOP WGs decision, but I won't argue for keeping 
it :-)



A few points:

First, absent at least an FCFS registry there will be no ability to 
programmatically switch against the label.  If multiple entries exist 
this is particularly painful.  If no registry exists, then perhaps 
multiple unofficial registries will pop up and we're in the same boat.  
Let's not have that.  That programmatic switch is important.  It allows 
multiple naming systems to co-exist all the way to the level of the 
application (e.g., end-to-end) without any ambiguity being introduced.


Second, people have been concerned about the possibility of vanity 
registries.  Requiring an RFC puts an end to that.  I don't think we 
want to *endorse* any particular approach, but IANA maintains many 
registries, and nobody has ever taken any of their entries as endorsements.


I suspect most of the burden here will fall on the Independent 
Submissions Editor (currently me) with maybe a little falling on the 
IRTF, because I doubt we will see a lot of consensus in the IETF for 
alternate naming systems.  I think some are worried that this will 
change the nature of the IETF, but to me this confuses names with naming 
systems.  Creating a naming system is no mean fete.


To address the possibility that we DO see a lot of requests, we can 
create different types of failsafe mechanisms.  They could be any or all 
of the following:


1. If more than one assignment occurs within a year, no assignments may
   occur in the following year.
2. After N assignments, the IAB MAY suspend this procedure if they see
   evidence of abuse, and refer the matter back to the IETF for further
   consideration.
3. This group can always amend the document based on whatever
   experiences we see.

I'm confident that there are other approaches as well.

Eliot


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

Re: [DNSOP] [Ext] draft-ietf-dnsop-alt-tld-17

[Eliot Lear]

On 24.08.22 16:13, Joe Abley wrote:

Hi Peter,


So the question is not whether to allow mixed capitalisation; the question is 
why we would intentionally change a fundamental expectation of domain names to 
accommodate names and resolution protocols that we largely don't have any 
requirements for because with one notable exception they don't exist?


This strikes me as a great way to think about it for all the reasons 
that Joe mentioned, but also because we are addressing various 
intermediary resolvers and name servers, and we are not looking to make 
their lives harder than they have to be.  I also don't think this is 
inconsistent with what John Levine suggested.


Eliot


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

Re: [DNSOP] Anything goes in ALT, was On ALT-TLD, GNS, and namespaces...

[Eliot Lear]

Hi George,

I could see the value in reserving dns.alt, and the potential mischief 
that could ensue by not doing so.


Eliot



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

Re: [DNSOP] Anything goes in ALT, was On ALT-TLD, GNS, and namespaces...

[Eliot Lear]

Hi Ben,

On 18.08.22 21:11, Ben Schwartz wrote:


What you are describing does not resemble draft-ietf-dnsop-alt-tld, 
which would define the "alt" SUDN.  That document says:


   There is no IANA
   registry for names under the ALT TLD - it is an unmanaged namespace,
   and developers are responsible for dealing with any collisions that
   may occur under .alt.

If you want a SUDN for technically meritorious non-DNS names, perhaps 
you should distinguish that proposal from .alt.


A few of us discussed this today.  Let's first remember that 
draft-ietf-dnsop-alt-tld is just that- a draft, and can be changed.  
With that in mind, you have to ask yourself: what happens when the next 
name system researcher comes a' callin. Having the 2nd level name serves 
two purposes:


1. Conflicts can be avoided between deployments of cooperating name
   systems; and
2. A protocol switch is created in that label (xyz.gns.alt->gns,
   xyz.eliot.alt->eliot name service)

I think there are some issues with doing all of this (like the IANA 
policy Stephen is asking about), but they may not be insurmountable.  
Anyway, seems like it's worth a healthy discussion.


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

Re: [DNSOP] [Ext] On ALT-TLD, GNS, and namespaces...

[Independent Submissions Editor (Eliot Lear)]

On 17.08.22 16:20, Paul Hoffman wrote:

The discussion with the Independent Submissions Editor appears to be about 
whether they are interested in using a TLD that would different TLD or 
pseudo-TLD in order to make their naming system more stable.


The authors of draft-schanzen-gns have shown some willingness in working 
with draft-ietf-dnsop-alt-tld for their "pet names" in order to address 
concerns around conflicts and ambiguities.


Eliot

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

Re: [DNSOP] On ALT-TLD, GNS, and namespaces...

[Independent Submissions Editor (Eliot Lear)]

On 15.08.22 22:22, Paul Wouters wrote:

Schanzenbach, Martin wrote on 2022-08-15 11:49:

 ...
 So, from my authors hat, I would appreciate FCFS; ideally also 
existing

 RFC/Other Specification + Implementation(s) for a registration in the
 registry.


"existing RFC" means all alternative name resolutions have to flow
through either the IETF or ISE. That is not something the IETF would
want to take on I think.


I truly don't think there are going to be a great many of these, but if 
they are reasonably well specified and don't pose major security 
concerns, they fit the bill for RFCs, either as independent or standard, 
depending on how the authors, the IETF, and the ISE feels in a 
particular situation.


Eliot




"Other specification" would likely lead to many copy & paste drafts
based on the first draft that is used to get an entry in .alt, with
only the name changed.

If an implementation is required, we will see many github forks with
just a name change.

Meanwhile, IANA will have to host 60M entries in the .alt registry.

I guess we could prevent draft--alt-name-cocacola if we consult the
Trademark Clearing House, but maybe this is a clear signal that we
are turning the IETF into ICANN and it is time to take a step^Wleap
back.

The IETF cannot bear the burden of managing or policing a non-IETF
namespace war, even handling a FCFS registry will take too many
resources.

Paul W

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



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

Re: [DNSOP] On ALT-TLD, GNS, and namespaces...

[Eliot Lear]

On 15.08.22 20:25, Ray Bellis wrote:


Someone also gets to solve the problem of how you get a CA/Browser Forum
Approved TLS cert for any system not accessible via "normal" DNS...


Yes, but not us.

Eliot

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

Re: [DNSOP] On ALT-TLD, GNS, and namespaces...

[Eliot Lear]

Hi,

On 15.08.22 16:11, David Conrad wrote:

My impression is that there'd be maybe an order of magnitude fewer clients.

This is irrelevant.

We have no idea whether GNS will take off in popularity or fade away into 
non-existence. Given the way "configuration is forever”, any partitioning of 
the namespace will be a feature for the foreseeable future.

I agree.  We shouldn't bet the Internet name space on something 
failing.  What I like about .alt (or whatever we end up calling it) is 
that it requires a single or small number of changes, not one change per 
name space.  That will help reduce leakage.


Eliot

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

Re: [DNSOP] On ALT-TLD, GNS, and namespaces...

[Eliot Lear]

Paul,

On 14.08.22 16:57, Paul Wouters wrote:

We can have all the clever mappings for DNS to support alternative backend 
systems, but in the end the real issue is that “issued names” in the DNS world 
won’t map to alternative owners. The only way to guarantee that is to carve out 
some strings. But it will be unpopular strings because the popular ones are 
taken or reserved.


If that's the distance that needs to be covered to close the gap here, 
then by all means "you" should work on that.*  But I suggest *not* being 
presumptuous, especially since one of the GNS people has already offered 
one possibility.


Eliot

* See my previous message about "you".
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [EXT] Re: draft-schanzen-gns and draft-ietf-dns-alt-tld

[Independent Submissions Editor (Eliot Lear)]

Hi Joe, Dave, Christian, John, George, and others,

Thank you for taking the volume down a notch.  It is much appreciated.

The ISE is looking for a way to have the work of the GNS published such 
that I am comfortable that if it achieves wild success (RFC 5218), its 
use is reasonably safe.  I use squishy words like “comfortable” and 
“reasonably safe”, because nobody here (especially me and including the 
researchers) has enough experience with the mechanisms involved to fully 
understand the security properties of this new namespace.


From a researcher perspective, they would surely want to see their work 
used, and that implies a few things in general:


1. Ease of implementation: ability to re-use code, including all of the
   parsers we have that handle DNS names, I18N, etc.
2. Ease of deployment: ability to use whatever application and OS
   interfaces such as nsswitch.conf, a plugin in a browser, etc.
3. A means to interface with the rest of the world, occasionally
   interacting with DNS.

Syntax changes, such as those John and others suggested (in fact I put 
this forward to the authors as an option), really don't advance the 
above goals.  But it is these very properties that gives rise to 
concerns around conflicts, leakage, and ambiguities, and all the 
assorted pain that RFC 8244 catalogs.


The community has more choices than Christian indicated.  One is that 
“You” carve out some space for namespaces like GNS, just as George 
suggested.  Warren's draft seems to comport itself to contours of that 
concept, which is why I came here. Also, the authors of 
draft-schanzen-gns seem to think that it is close to something they 
could use to be willing to engage here.  It also seems to me that such a 
draft is, roughly speaking, in line with the general principles of 
SSAC-113, as Andrew alluded, even if that document had the different 
goal of enabling privately or locally scoped namespaces.  Of course, 
there may be other approaches.


I caution against those approaches that would set such a high bar that 
they would require researchers to fork out hundreds of thousands of 
dollars on application fees alone plus who knows how much else for, as 
someone else wrote, an uncertain outcome.  They'll simply go elsewhere. 
That in itself would encourage squatting (or whatever you want to call 
it).  The benefits of avoiding squatting accrue not only to those 
researchers, but to those who use their technology, and others as well.


I put “You” in quotes above, because (a) it's not me who will decide 
these lofty issues, and I also don't get to decide who will.  The ISE 
only gets to decide about whether or not to publish the GNS draft as an 
RFC.  If the argument is truly over who “You” is rather than the 
solution, your friendly neighborhood ISE requests that You work that out 
in such a way that these researchers don't get caught in the switches.*  
If that requires one last invocation of 6761 or whatever else, then 
please consider it.  Let's call August “Be Kind to Namespace Researchers 
Month”!


Regards,

Eliot

* Ironically, when I typed "caught in the switches expression origin" 
into Google, one of the responses was a link to the Wikipedia entry for 
"Halt and Catch Fire".  Let's not let that happen here either ;-)
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [EXT] Re: draft-schanzen-gns and draft-ietf-dns-alt-tld

[Independent Submissions Editor (Eliot Lear)]

Dave,

To answer the question, “What is the ISE process?”:

On 04.08.22 21:28, David Conrad wrote:

Martin,
[...]



I see 4 options:

1) Wait for ICANN to fix their processes
2) Wait for the IETF to figure out whether/how to reopen the “Special Use 
Domains” registry
3) Try to bypass (1) and/or (2) by publishing through the ISE (I don’t know 
enough about the ISE process to guess whether this is appropriate or feasible)


For information about independent submissions, please see 
https://rfc-editor.org/about/independent and RFC 4846 (among others).


Eliot (ISE)

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

Re: [DNSOP] draft-schanzen-gns and draft-ietf-dnsop-alt-tld

[Independent Submissions Editor (Eliot Lear)]

On 02.08.22 10:35, Joe Abley wrote:



Had I wanted to do so, I would not have approached dnsop in the first place.

Had you wanted to which? I'm confused.


I came to this group because of concerns that Warren raised, and because 
the draft sits before me.  I have reviewed what discussion I could find 
in the logs relating to Warren's draft, which amounts to either (a) this 
is ICANN's problem or (b) there is nobody willing to make use of the 
space.  Please feel free to inform me if I have missed something.


Regarding (a), that is not my interpretation of RFC 6761.  RFC 6761 
drops special use domains firmly in the lap of the IETF, which is 
presumably why Warren brought his draft here and why I came here and 
didn't go to ICANN.  Regarding (b), we have someone here willing to at 
least have the conversation.



By approaching dnsop in the first place with a box of freshly lit matches you 
seem precisely to be ignoring the prior discussion.


I didn't light the matches.  That, I'm afraid, is the nature of the 
publication request.  From an ISE perspective, my intent is to take 
quite seriously concerns that the IESG raises, with an eye toward safety 
in this case.



If you don't intend to publish the drafts on your table then I don't understand 
what you're saying in the context of the hat you're wearing.


I have not made a publication decision.  That decision would be far 
EASIER to make if this group provided guidance, which is why I am here.  
Absent that guidance, I will... muddle along and make the best decision 
I can, again taking into account the IESG's forthcoming 5742 review.


I could have denied this publication request at its outset, but that 
would have sent a message to namespace researchers and developers that 
their work is not welcome, and that they should just ignore the IETF and 
the RFC series.  Is that what you would advocate?  Does that make the 
Internet safer?



Perhaps more fundamentally the idea of the ISE promoting work to be done in a 
working group apparently without the involvement of the chairs itself seems 
confusing. You know more about the job than I do, but in the past when I have 
published documents through the independent stream, the ISE's consultation was 
limited to an IESG conflict review.


The ISE may consult whoever is necessary to consult to achieve the best 
outcome.  Let's please not attempt to make this a process argument.


Eliot

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

Re: [DNSOP] draft-schanzen-gns and draft-ietf-dnsop-alt-tld

[Independent Submissions Editor (Eliot Lear)]

Aaaagain

On 02.08.22 09:56, Joe Abley wrote:


If the position of the ISE is to ignore the prior discussion and publish one 
set of opinions regardless then perhaps it would be more straightforward just 
to say so.


Had I wanted to do so, I would not have approached dnsop in the first place.

Eliot


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

Re: [DNSOP] draft-schanzen-gns and draft-ietf-dnsop-alt-tld

[Independent Submissions Editor (Eliot Lear)]

Paul:

It is not the ISE that is ignoring RFC 6761, but this group. 6761 
envisioned this precise case.  For whatever reason, that document didn't 
take the next step and actually reserve a TLD. Sometimes it is 
reasonable to do things incrementally.  But what is not reasonable to 
expect researchers to attempt to enter the ICANN arena in order to 
facilitate a the safe use of a new naming system that doesn't require 
use of the DNS.



Alternate names spaces want a “real name”, so either their name or their 
mapping will  “squats” on the DNS namespace. They won’t use .alt or ._alt just 
like they aren’t using alt.onion or gns.onion.


If I thought there was no chance of these people using a suffix of some 
form, I wouldn't have come to DNSOP and I wouldn't have mentioned 
draft-ietf-dnsop-alt-tld.  You have a group of people who are here now, 
albeit grudgingly, to step through the process here with you, to address 
safety concerns.  Consider the alternative: they and others will do what 
they are going to do without whatever advice and safety the IETF could 
offer to the community.


My advice: take advantage of this opportunity.

Eliot

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

[DNSOP] draft-schanzen-gns and draft-ietf-dns-alt-tld

[Independent Submissions Editor (Eliot Lear)]

Hello from your friendly neighborhood independent submissions editor.

It is indeed the case that draft-schanzen-gns is in conflict review.  It 
is also the case that Warren and I have been discussing that review.  
Obviously there are some concerns.  On the one hand, we need to find a 
way for people to explore alternative namespaces that look a bit like 
domain names.  On the other hand, we don't want to create problems with 
user expectations.  draft-ietf-dns-alt-tld seems like a reasonable means 
to bridge these concerns.


The ISE is willing to wait a reasonable period of time for this work to 
conclude.   It seems that you are close to done.  I know that this draft 
doesn't solve *all* namespace research problems by any stretch, but it 
will make life easier for at least SOME researchers, not to mention me.


Whether that means using TLD labels that begin with _ or whether that 
means suffixing them with ".ALT", I leave to you experts to sort.  I do 
agree with Martin that it would be helpful to have some registration of 
names so that conflicts between name spaces can be avoided.  This would 
also encourage formal documentation of those projects.


Thanks!

Eliot (ISE)
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [arch-d] Call for Comment: (Nameservers for the Address and Routing Parameter Area ("arpa") Domain)

[Eliot Lear]

+1.  I think it looks good.

One very minor comment (more a question): if I read between the lines, it seems 
that some thought went into the use of the term “name space” in Section 3.1 
regarding there not being a zone cut for ns.arpa (not that it’s anyone’s 
business, I suppose).  Would it be reasonable to make more plain the logic for 
that decision?  I could envision at least two reasons, but my own logic could 
be faulty.

Eliot

> On 6 May 2021, at 20:52, Russ Housley  wrote:
> 
> I have read this document, and this seems like a fine way to separate the 
> .arpa servers from the root servers.
> 
> Russ
> 
> 
>> On May 6, 2021, at 2:48 PM, IAB Executive Administrative Manager 
>>  wrote:
>> 
>> This is an announcement of an IETF-wide Call for Comment on
>> draft-iab-arpa-authoritative-servers-00.
>> 
>> The document is being considered for publication as an Informational RFC
>> within the IAB stream, and is available for inspection at:
>> 
>> 
>> The Call for Comment will last until 2021-06-03. Please send comments to
>> architecture-disc...@ietf.org and i...@iab.org.
>> 
>> Abstract:
>> 
>>  This document describes revisions to operational practices to
>>  separate function of the "arpa" top-level domain in the DNS from its
>>  historical operation alongside the DNS root zone.
>> 
> 
> ___
> Architecture-discuss mailing list
> architecture-disc...@ietf.org
> https://www.ietf.org/mailman/listinfo/architecture-discuss



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

Re: [DNSOP] [Doh] [EXTERNAL] Re: New I-D: draft-reid-doh-operator

[Eliot Lear]

On 25 Mar 2019, at 10:25, Stephen Farrell  wrote:
> I see a problem with the above argument. DNS means nothing to
> most people, so I can't see how they can ever make the informed
> decision you mention.

I view that as a research question (I don’t accept your assertion, but neither 
can I disprove it).  That is- could a question be formed around local network 
trust that encompasses this component?  Possibly.

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

Re: [DNSOP] [Doh] [EXTERNAL] Re: New I-D: draft-reid-doh-operator

[Eliot Lear]

Hi,

> On 24 Mar 2019, at 23:25, Paul Wouters  wrote:
> 
>> The blocking of DoT to a given provider should be interpreted as an explicit 
>> policy. Users should be informed
>> that they may, and very likely will, be violating someone’s policy, if they 
>> choose to use DoH in that
>> circumstance, and that they may be violating laws by doing so, and should 
>> only do so if they are willing to
>> accept that risk.
> 
> Again, this is the network operator centric view. There are many hostile
> networks that would block DoT just so that they could monetize (legally
> or illegally!) from my harvested DNS data. I can assure you the warning
> you want to write to users would be very different from the warning I
> would want to give those users. Which is why the IETF doesn't do
> banners towards endusers.

Putting aside legal language, but Brian’s basic notion is that the user can 
make an informed decision and the network can express its policies, with which 
the user can agree or not agree (and go elsewhere).  Having the protocol 
elements to permit this sort of agreement is its own tussle.

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

Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator

[Eliot Lear]

Hi Wes,

On 22 Mar 2019, at 00:21, Wes Hardaker  wrote:
> 
> If DNS privacy is a goal, 


It is a goal. It is not the only goal.  There is a tussle here.  Let’s 
recognize that.

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

Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator

[Eliot Lear]

Hi Christian,

> On 19 Mar 2019, at 18:37, Christian Huitema  wrote:
> 
> 
> 
> On 3/19/2019 12:50 AM, Eliot Lear wrote:
>>> On 19 Mar 2019, at 01:50, Matthew Pounsett >> <mailto:m...@conundrum.com>> wrote:
>>> 
>>> Somewhere up-thread it was suggested that there are other reasonable steps 
>>> that a network/security operator can take to maintain the controls over 
>>> resolution that we have today, but so far I haven't seen them enumerated 
>>> anywhere.
>>> 
>> 
>> I had stated that one can use an MDM to manage the endpoint’s use of DoH.  
>> This doesn’t eliminate the possibility of malware, but does reduce 
>> misconfiguration in the enterprise, and provides for some protection against 
>> infection by blocking known bad names.
> Configuration works well for functions like "phishing protection": the device 
> users in most cases want some form of protection, and then it is a matter of 
> how this protection is configured. It does not work so well for functions 
> like intrusion detection, such as figuring out whether a device is trying to 
> contact a botnet C&C, because we cannot expect the infected device to be 
> amenable to configuration.
> 

Yes.


> Third party DNS/DoH providers could probably block resolution of phishing 
> names or  botnet C&C names using the same methods as enterprises do today, 
> but the enterprise network will not be informed that one of its devices just 
> tried to contact a botnet C&C. It would be very nice if the IETF standardized 
> a way to do that.
> 

I don’t see why they wouldn’t, and I could easily envision them being obliged 
to do so in the future.

>> 
>> In addition, there’s at least a heuristic for detection: compare data plane 
>> activity against ANSWERs.  If you’re seeing activity to addresses that don’t 
>> match (modulo some noise), you know an alternate resolver is active on that 
>> device.  And while it’s possible for malware to mimic queries to Do53 for 
>> Good sites versus what it really wants to access, you start tarnishing the 
>> rep of the IP address as and when you detect the problem through other means 
>> (AV s/w, honey pots, binary inspection, et al).  That leaves it with cloud 
>> providers to sort their wagons.
> Yes, one could imagine IP address or IP prefix reputation systems, similar to 
> the IP address block lists used to protect against spam. This would work, and 
> it would also provide intrusion detection signals when an infected device 
> starts contacting a botnet. The problem of course is the gray line between 
> "blocking phishing sites" and "blocking content that I disagree with". The 
> various attempts to block the whole of Wikipedia in order to block some 
> specific pages shows where this can lead.

In the enterprise this is not a problem.  In the consumer space, it is a big 
problem.  This goes back to the fundamental issue of whether or not the user 
has given meaningful consent and what happens when they do not.  We should be 
at least mindful of the game of Chicken being played here with governments.  
Lessig’s Law is bounded by the fact that governments have a lot more guns than 
most of us do (with some notable and amusing exceptions).  The point of my 
message was not to go into this discussion, however, but to talk about what is 
possible, rather than what is necessarily desirable.

The sharing of threat intel is something that could be reasonably governed by 
contract in this scenario.  Think about that a bit.

Eliot



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

Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator

[Eliot Lear]

> On 19 Mar 2019, at 14:10, Ted Lemon  wrote:
> 
> On Mar 19, 2019, at 3:50 AM, Eliot Lear  <mailto:l...@cisco.com>> wrote:
>> It might also be possible to whitelist ANSWERs into iptables. I wrote the 
>> code for that for a dnscap plugin some years ago, and you could even play 
>> with it if you want (it’s on GitHub), but I’m not suggesting it’s a good 
>> general answer (it was intended for a very specific use case involving 
>> relatively few domains for (hopefully cooperating) IoT devices).  As you 
>> point out, it won’t tackle shared IP addresses, and quite frankly, little 
>> CPE gear won’t scale with a gazillion iptables entries (I’m not sure big 
>> gear would either).
> 
> Link?
> 


Sure.  It’s my branch off of dnscap.  https://github.com/elear/dnscap 
<https://github.com/elear/dnscap>.  See plugins/aclm.  Limited doc is 
available, but anyone who wants to play just let me know.

Eliot



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

Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator

[Eliot Lear]

Matthew

> On 19 Mar 2019, at 01:50, Matthew Pounsett  wrote:
> 
> Somewhere up-thread it was suggested that there are other reasonable steps 
> that a network/security operator can take to maintain the controls over 
> resolution that we have today, but so far I haven't seen them enumerated 
> anywhere.
> 

I had stated that one can use an MDM to manage the endpoint’s use of DoH.  This 
doesn’t eliminate the possibility of malware, but does reduce misconfiguration 
in the enterprise, and provides for some protection against infection by 
blocking known bad names.

In addition, there’s at least a heuristic for detection: compare data plane 
activity against ANSWERs.  If you’re seeing activity to addresses that don’t 
match (modulo some noise), you know an alternate resolver is active on that 
device.  And while it’s possible for malware to mimic queries to Do53 for Good 
sites versus what it really wants to access, you start tarnishing the rep of 
the IP address as and when you detect the problem through other means (AV s/w, 
honey pots, binary inspection, et al).  That leaves it with cloud providers to 
sort their wagons.

It might also be possible to whitelist ANSWERs into iptables. I wrote the code 
for that for a dnscap plugin some years ago, and you could even play with it if 
you want (it’s on GitHub), but I’m not suggesting it’s a good general answer 
(it was intended for a very specific use case involving relatively few domains 
for (hopefully cooperating) IoT devices).  As you point out, it won’t tackle 
shared IP addresses, and quite frankly, little CPE gear won’t scale with a 
gazillion iptables entries (I’m not sure big gear would either).

Eliot


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

Re: [DNSOP] [Doh] [dns-privacy] New: draft-bertola-bcp-doh-clients

[Eliot Lear]

Gentlemen,

This conversation has gone to the zoo.  What is or is not political doesn’t 
matter at this stage in the game, and neither is arguing over rights over bits. 
 If people want to do that I suggest doing so in the HRPC WG and with a draft 
in hand.  Flaming back and forth without an objective of actually modifying 
text or developing a work proposal is quite pointless.

What is important is to document the technical ramifications of the changes 
brought about by DoH.  To move things forward, can we simply go through the 
drafts in the side meeting, and indicate what administrators might do about any 
perceived negative effects?  Whether those effects seem negative to you only 
matters if there is a proposal for the IETF to take on new work to “correct” 
them.

Eliot

> On 13 Mar 2019, at 03:59, Christian Huitema  wrote:
> 
> 
> 
> On 3/12/2019 2:11 PM, Paul Vixie wrote:
>>> I don't see why, based on your argument, your concerns
>>> trump his.
>>> 
>>> Can you explain?
>> he's trying to achieve a political aim using technology. that is not the
>> purpose for which the internet engineering task force, or the internet 
>> itself,
>> was convened. it is not why our employers pay our travel costs. and it is not
>> why the rest of the world trusts our outputs.
> 
> Sorry, but no. I am vying for network transparency, and I believe that if 
> filtering is to be enforced, it should be controlled by the user. You are 
> claiming that safety mandates giving the network operator full control over 
> name resolution. Both of these positions come from specific visions about how 
> the network should work. Neither is more a political goal than the other.
> 
> -- Christian Huitema
> 
> ___
> Doh mailing list
> d...@ietf.org
> https://www.ietf.org/mailman/listinfo/doh



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

Re: [DNSOP] [dns-privacy] [EXTERNAL] [Doh] New: draft-bertola-bcp-doh-clients

[Eliot Lear]

Hi Tiru,

> On 12 Mar 2019, at 16:31, Konda, Tirumaleswar Reddy 
>  wrote:
> 
> MDM may or may not be acceptable even in Enterprise networks. For instance, 
> today network security services are using ML techniques to identify malware 
> flows without acting as a TLS proxy. MDM is also not an option to secure 
> devices in the home networks, especially consumer IoT devices.
> 


I agree that MDMs should not be viewed as a panacea.  Just a tool in the box.  
But this is why I wrote that text the way I did: there may be other ways to 
express in some secure way evidence of the owner’s intent.

Eliot



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

Re: [DNSOP] [EXTERNAL] [dns-privacy] [Doh] New: draft-bertola-bcp-doh-clients

[Eliot Lear]

Hi,

> On 12 Mar 2019, at 14:11, Winfield, Alister  wrote:
> 
> MDM is also a red-herring given >90% of devices world-wide aren't managed so 
> anyone talking of MDM riding to the rescue of DoH client configuration is 
> walking around with blinkers on.

Firefox has published a specific policy interface just for this purpose.  I 
think the point, and perhaps others could correct me, is that the MDM serves as 
evidence that the owner of the device is authorizing a configuration change.  
And the use case I am discussing is the enterprise use case.  Your #s do not 
take that into account.

> Even inside company networks there are servers not under MDM;

Servers seem an unlikely use of DoH from an application in particular.

> locally developed applications that might in future pull in a DoH resolver;

In that case, the enterprise administrator is aiming the shotgun at his or her 
own foot.  I propose not to solve that problem, but rather to help them with 
tools to do the right thing.

> BYOD; visitors; malware and so on.

It is certainly not best practice for visitors to be granted access to internal 
access; instead they typically are given guest access.

BYOD is a different story.  Here DoH may add pressure on those bringing their 
own devices to have to place them under MDM control.  That pressure already 
exists, by the way.  DoH just adds to it.


> So whatever you think a reasonable solution for client configuration has to 
> start with unmanaged clients. That last one malware is why the corporate 
> response may well be 'MITM' the traffic so we can protect the data, people 
> and systems using our network.
> 
> What DoH discovery and presentation looks like is complex issue that will 
> take some discussion. Just one small example, I might want to use the local 
> networks DNS if and only if it provides anti-malware protection and has a 
> reasonable privacy policy but use a static one if not. Or perhaps on a 
> child's device it's okay if there is filtering in place suitable for children.

I have previously written here that meaningful consent (a’la Sasse, Acquisti, 
et al) is a key issue.  With your example, Alister, you are essentially asking 
about number of attributes from the DNS server; some of which would have to be 
ascribed by others rather than simply self-asserted.  And then you have to make 
all of that information consumable and actionable by a normal person.  Good 
luck.

Just establishing an operational model in which split DNS is handled correctly 
will be enough of a challenge, but is worth exploring.

And that is why much of this smells like research to me.  If there are willing 
partners, I think that would be a great avenue to tread down.

Eliot

> 
> Alister
> 
> On 12/03/2019, 05:43, "dns-privacy on behalf of Konda, Tirumaleswar Reddy" 
>  tirumaleswarreddy_ko...@mcafee.com> wrote:
> 
>> -Original Message-
>> From: Eliot Lear 
>> Sent: Monday, March 11, 2019 11:49 PM
>> To: Paul Vixie 
>> Cc: nalini elkins ; Konda, Tirumaleswar Reddy
>> ; d...@ietf.org; dnsop@ietf.org;
>> Ackermann, Michael ; Christian Huitema
>> ; dns-priv...@ietf.org; Vittorio Bertola
>> ; Stephen Farrell
>> 
>> Subject: Re: [Doh] [dns-privacy] [DNSOP] New: draft-bertola-bcp-doh-clients
>> 
>> Hi Paul,
>> 
>>> On 11 Mar 2019, at 19:12, Paul Vixie  wrote:
>>> 
>>> 
>>> 
>>> nalini elkins wrote on 2019-03-11 10:26:
>>>> Tiru,
>>>> Thanks for your comments.
>>>>> Enterprise networks are already able to block DoH services,
>>> i wonder if everyone here knows that TLS 1.3 and encrypted headers is
>> going to push a SOCKS agenda onto enterprises that had not previously
>> needed one, and that simply blocking every external endpoint known or
>> tested to support DoH will be the cheaper alternative, even if that makes
>> millions of other endpoints at google, cloudflare, cisco, and ibm unreachable
>> as a side effect?
>> 
>> That or it will require a bit more management at the MDM level.  I’m hoping
>> the latter.  And I hope that one output of all of these documents will be a
>> recommendation regarding MDM interfaces.
> 
>I don't think MDM is required to use the DoT/DoH servers provided by the 
> local network.
> 
>-Tiru
> 
>> 
>> Eliot
>___
>dns-privacy mailing list
>dns-priv...@ietf.org
>
> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fdns-privacy&data=02%7C01%7Calister.winfield%40sky.uk%7Cab5faa933f374ae7b72c08d6a6ada348%7C68b865d5cf184b2b82a4a4eddb9c52

Re: [DNSOP] [hrpc] [Doh] Proposal for a side-meeting on services centralization at IETF 104 Prague

[Eliot Lear]

Warren,

I would suggest that you wait on creating a new list.

I think Stephane was proposing an *in person* meeting, using the 
104sidemeetings Wiki, and I’d like to see that happen first.  That also gives 
time for the dust from the release of these new drafts to settle a bit, so that 
the contours of what can be reasonably accomplished becomes more clear.

Eliot


> On 12 Mar 2019, at 07:45, Warren Kumari  wrote:
> 
> 
> On Tue, Mar 12, 2019 at 1:58 AM Stephane Bortzmeyer  > wrote:
> [Sorry for the long list of working groups but the discussion already
> started in different places.]
> 
> There are been some discussion about DoH (DNS-over-HTTPS, RFC 8484)
> deployment and the risk of centralization of Internet services.
> (See
> for instance drafts [this is not an endorsement]
> draft-bertola-bcp-doh-clients, draft-reid-doh-operator and
> draft-livingood-doh-implementation-risks-issues.)
> 
> It was suggested Reference necessary to have a
> side meeting in Prague at IETF 104. I propose monday, 1400-1600 in
> Tyrolka. The proposal is at
>  >. You
> are welcome to agree/disagree/meet in a bar instead.
> 
> [ Replying here instead of bottom of thread ]
> 
> Thank you for proposing / organizing this - there has been a lot of 
> discussions, but (as demonstrated by the list of WGs in the To: line) it is 
> somewhat unclear where the discussions should happen -- I'm planning on 
> asking the secretariat to please make us a mailing list to better focus the 
> discussions -- does anyone have a strong objection to this?
> 
> (also, a good suggestion for a name would be helpful :-))
> 
> W
> 
> 
> 
> ___
> Doh mailing list
> d...@ietf.org 
> https://www.ietf.org/mailman/listinfo/doh 
> 
> 
> 
> --
> I don't think the execution is relevant when it was obviously a bad idea in 
> the first place.
> This is like putting rabid weasels in your pants, and later expressing regret 
> at having chosen those particular rabid weasels and that pair of pants.
>---maf
> ___
> hrpc mailing list
> h...@irtf.org
> https://www.irtf.org/mailman/listinfo/hrpc



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

Re: [DNSOP] [Doh] [dns-privacy] New: draft-bertola-bcp-doh-clients

[Eliot Lear]

Hi Paul,

> On 11 Mar 2019, at 19:12, Paul Vixie  wrote:
> 
> 
> 
> nalini elkins wrote on 2019-03-11 10:26:
>> Tiru,
>> Thanks for your comments.
>> > Enterprise networks are already able to block DoH services,
> i wonder if everyone here knows that TLS 1.3 and encrypted headers is going 
> to push a SOCKS agenda onto enterprises that had not previously needed one, 
> and that simply blocking every external endpoint known or tested to support 
> DoH will be the cheaper alternative, even if that makes millions of other 
> endpoints at google, cloudflare, cisco, and ibm unreachable as a side effect?

That or it will require a bit more management at the MDM level.  I’m hoping the 
latter.  And I hope that one output of all of these documents will be a 
recommendation regarding MDM interfaces.

Eliot


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

Re: [DNSOP] Last Call: (The .onion Special-Use Domain Name) to Proposed Standard

[Eliot Lear]

So... Alec and I did a bit of wordsmithing and what I propose is a
slight clarification on the existing text, based on this exchange, and
here it is:


   Like Top-Level Domain Names, .onion addresses can have an arbitrary
   number of subdomain components.  Only the first first label to the
   left of ".onion" is significant to the layer 3 Tor protocol, while
   application layers above have access to the full name.  For example...


And then an HTTP example would be inserted (or otherwise "For
example..." taken out).

Eliot


On 7/20/15 12:58 PM, Alec Muffett wrote:
>>
>> Yes, there is an HTTP Host header.  Yes, responses vary by the
>> *value* but not by the *structure*.  As far as Apache is concerned,
>> for instance, I would imagine it's doing a string compare without
>> counting or considering dots.  By discussing an arbitrary number of
>> components, that paragraph implies that HTTP cares about the
>> *structure* of the name, when it does not (although some
>> implementations might kludge this with www.domain = domain). 
>>
>> And I'll just hasten to add that now between you and Richard there
>> are two interpretations of what the text in the document means.  All
>> I am suggesting is a bit of clarity, please.
>
> Hi Eliot,
>
> I am one of the authors of this draft, and I would like to spell out
> the concern which was raised to us, and which we sought, with this
> paragraph to try and address.
>
> Onion addresses are much closed to (say) dotted quads (or other
> layer-3 addresses) than to domain names, albeit that to denote them
> there is the label ".onion" affixed in the place where one would
> expect to find a TLD.
>
> Where the analogy between onion addresses and IP addresses breaks down
> is that the following is illegal (or, at least, has never been
> functionally viable):
>
> http://www.192.168.0.1/  (versus http://eliot.blogs.192.168.0.1/)
>
> ...whereas the following *is* viable:
>
> https://www.facebookcorewwwi.onion/
>
> In some hypothetical alternate universe where we were all using IP
> addresses rather than DNS to connect to endpoints, it might be cute to
> support . and let the "Host" header (and/or the
> HTTPS SNI) disambiguate the intent, though doubtless this would also
> lead to some kind of disaster.
>
> In the Onion world, the canonical representation of an onion address is:
>
> sixteencharlabel.onion (compare representations: 192.168.1.1, [::1], etc)
>
> ...and in the outline we sketched of how Onions work, we sought to
> describe them properly in their role as layer-3 analogues,
> mechanically generated hashes of a randomly generated certificate,
> beyond human choice except for brute-force mining.
>
> However, the Tor software has a party trick, that (as Richard has
> explained) given an "onion" label for surety, it's happy to parse-out
> the "sixteencharlabel" label and use that for connection
> establishment, ignoring any other labels leftwards of that, if any.
>
> Of course using (say) "ssh" to connect to www.sixteencharlabel.onion
>  will not be beneficial, because
> SSH supports neither "Host" header nor SNI; but a web browser using
> HTTP/S will pass a Host header, and thus we may effect virtual hosting
> over a single ".onion" address.
>
> In pursuit of "clarity", having had this explained, I would welcome a
> better and more succinct phrasing, if you can offer one and yet not
> bury the reader in unnecessary detail, or in technical detail which
> might become inaccurate as implementations improve whilst the outline
> remains largely unchanged.
>
>
> -a
>
> --
> Alec Muffett
> Security Infrastructure
> Facebook Engineering
> London
>



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

Re: [DNSOP] Last Call: (The .onion Special-Use Domain Name) to Proposed Standard

[Eliot Lear]

Hi David,

On 7/20/15 6:06 AM, David Cake wrote:
> As someone with moderate experience in both DNS and web server
> configuration, FWIW I found the meaning relatively obvious. The notion
> that HTTP Host headers might be used to change web server response
> independent of name resolution (e.g. that two names that return
> identical responses to every possible DNS query, but produce different
> web server responses) has been fairly intrinsic to how web servers
> operate for a couple of decades now, and this seems a simple but
> useful clarification regarding how this operates for .onion names to me.

Yes, there is an HTTP Host header.  Yes, responses vary by the *value*
but not by the *structure*.  As far as Apache is concerned, for
instance, I would imagine it's doing a string compare without counting
or considering dots.  By discussing an arbitrary number of components,
that paragraph implies that HTTP cares about the *structure* of the
name, when it does not (although some implementations might kludge this
with www.domain = domain). 

And I'll just hasten to add that now between you and Richard there are
two interpretations of what the text in the document means.  All I am
suggesting is a bit of clarity, please.

Eliot



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

Re: [DNSOP] Last Call: (The .onion Special-Use Domain Name) to Proposed Standard

[Eliot Lear]

Hi Richard,

Thanks for the explanation.  Please see below.

On 7/17/15 4:38 PM, Richard Barnes wrote:
> On Fri, Jul 17, 2015 at 4:20 PM, Eliot Lear  wrote:
>> I have no particular objection to the concept here, but I do have a
>> question about one sentence in the draft.  Section 1 states:
>>>Like Top-Level Domain Names, .onion addresses can have an arbitrary
>>>number of subdomain components.  This information is not meaningful
>>>to the Tor protocol, but can be used in application protocols like
>>>HTTP [RFC7230].
>>>
>> I honestly don't understand what is being stated here, or why a claim is
>> made about HTTP at all in this document.  Are we talking about the
>> common practice of www.example.com == example.com?  And what
>> significance does that last phrase have to the document?
> I made a comment on this to the authors earlier, and they decided to
> leave it as-is :)
>
> The idea is that TOR routing will only use the first label after
> .onion, but if you're using the .onion name in an application, that
> application might use the whole name.  For example, if you put
> "http://mail.example.onion/";, TOR will route on "example.onion", but
> the HTTP Host header might be "mail.example.onion".
>
> -

I just leave the IESG and WG with the comment that two of us "old
timers" are trying to divine the meaning of those two sentences, and
that can't be good for others with (even) less clue.  Personally I think
the easiest approach is to remove those two sentences, but if others
really disagree, then a bit more clarity seems in order.

Eliot




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

Re: [DNSOP] Last Call: (The .onion Special-Use Domain Name) to Proposed Standard

[Eliot Lear]

I have no particular objection to the concept here, but I do have a
question about one sentence in the draft.  Section 1 states:
>Like Top-Level Domain Names, .onion addresses can have an arbitrary
>number of subdomain components.  This information is not meaningful
>to the Tor protocol, but can be used in application protocols like
>HTTP [RFC7230].
>
I honestly don't understand what is being stated here, or why a claim is
made about HTTP at all in this document.  Are we talking about the
common practice of www.example.com == example.com?  And what
significance does that last phrase have to the document?

Eliot




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

Re: [DNSOP] [Int-area] various approaches to dns channel secrecy

[Eliot Lear]

On 7/7/14, 1:14 PM, Hannes Tschofenig wrote:
>
> I also struggle to see the significant improvement for the cases that
> had been discussed on the list. I would say that they go close to zero
> when one uses DNS servers provided by the local network operator.
>

That's a matter of service selection and orthogonal to Paul's proposal.

Eliot

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

Re: [DNSOP] [Int-area] various approaches to dns channel secrecy

[Eliot Lear]

Hi Hannes,


On 7/7/14, 8:23 AM, Hannes Tschofenig wrote:
> Just a minor note on this paragraph:
>
> On 07/07/2014 06:48 AM, Eliot Lear wrote:
>> because HTTPS currently depends on X.509 keys, other

I didn't write the above, Paul did.  But to your point below...
>>> groups in the IETF world are already working to make HTTPS proof against
>>> on-path surveillance. (google for "perfect forward secrecy" to learn
>>> more), and others are working to defend the internet user population
>>> against wildcard or targeted SSL certificates issued by governments and
>>> other anti-secrecy agents with on-path capabilities.
> TLS has this ciphersuite concept and allows you to more than just X.509
> certificates. As such, you have more freedom than you think (if you know
> what you want).

Yes.  This is something you might know something about ;-)
>
> It would be funny if the precondition using using DANE would be to
> require a PKI as currently used on the Web...
>

Unless what you're using ISN'T a PKI.  Any DNS mechanism must be free
and clear of dependency loops.  While that may be theoretically possible
with a PKI, I'd hazard a guess (perhaps worth a drink at a bar) that the
number of dependencies explodes, making such a loop more likely in an
operational environment.

Eliot

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

Re: [DNSOP] [Int-area] various approaches to dns channel secrecy

[Eliot Lear]

Paul,

This seems like a fine and modular approach that doesn't boil the ocean.

Eliot

On 7/5/14, 5:04 AM, Paul Vixie wrote:
> i've now seen a number of proposals reaction to "the snowden
> disclosures", seeking channel encryption for dns transactions. i have
> some thoughts on the matter which are not in response to any specific
> proposal, but rather, to the problem statement and the context of any
> solution.
>
> first, dns data itself is public -- the data is there for anybody to
> query for it, if you know what to query for. only the question,
> questioner, and time can be kept secret. answers are only worth keeping
> secret because they identify the question, questioner, and time.
>
> second, dns transactions are not secret to protocol agents. whether stub
> resolver, full resolver, forwarder, proxy, or authority server -- the
> full identity of the question must be knowable to the agent in order to
> properly process that question. if the agent does logging, then the
> question, questioner, and time will be stored and potentially shared or
> analyzed.
>
> by implication, then, the remainder of possible problem statement
> material is "hide question from on-wire surveillance", there being no
> way to hide the questioner or the time. to further narrow this, the
> prospective on-wire surveillance has to be from third parties who are
> not also operators of on-path dns protocol agents, because any second
> party could be using on-wire surveillance as part of their logging
> solution, and by (2) above there is no way to hide from them. so we're
> left with "hide question from on-wire surveillance by third parties."
>
> this is extremely narrow but i can envision activists and dissidents who
> rightly fear for their safety based on this narrowly defined threat, so
> i'm ready to agree that there should be some method in DNS of providing
> this secrecy. and as we know from the history of secrecy, if you only
> encrypt the things you care about, then they stand out. therefore,
> secrecy of this kind must become ubiquitous.
>
> datagram level channel secrecy (for example, DTLS or IPSEC) offers a
> solution which matches the existing datagram level UDP transport used
> primarily by DNS. however, the all-pervasive middleboxes (small plastic
> CPE devices installed by the hundreds of millions by DSL and Cable and
> other providers) have been shown to be more powerful than IPv6, DNSSEC,
> and EDNS -- we could expect them to prevent any new datagram level
> channel secrecy protocol we might otherwise wish to employ.
>
> TCP/53 is less prone to middlebox data inspection, and may seem to be an
> attractive solution here. i think "not" for two reasons. first, TCP/53
> is often blocked outright, and second, because TCP/53 as defined in RFC
> 1035 has a connection management scheme that prohibits persistent TCP/53
> connections at Internet scale, and we cannot afford the setup/teardown
> costs of a non-persistent TCP-based channel secrecy protocol for DNS. to
> those who suggest redefining TCP/53 and upgrading the entire physical
> plant and all software and operating systems, i challenge you to first
> show how this is less global effort than other proposals now on the
> table, and then show how you would handle the long-tail problem, since
> many agents will never be upgraded, or will only be upgraded on a scale
> of half-decades. DNS works today because TCP/53 is a fallback for
> UDP/53. its definition and deployment makes it unsuitable either
> currently or as-would-be upgraded to become the primary transport.
>
> i suggest that any channel secrecy protocol we wish to add to the DNS
> system must be suitable as the primary transport, to which the existing
> UDP/53 and TCP/53 protocols are fallbacks. i further suggest that any
> new transport be operable at internet scale, which demands connection
> persistence. finally i suggest that this be done using a protocol that
> the internet's "middle boxes" (cheap CPE devices who think they know
> what all valid traffic must look like) will allow to pass without comment.
>
> one candidate for this would be RESTful JSON carried over HTTPS. because
> of its extensive use in e-commerce and "web API" applications, HTTPS
> works everywhere. because HTTPS currently depends on X.509 keys, other
> groups in the IETF world are already working to make HTTPS proof against
> on-path surveillance. (google for "perfect forward secrecy" to learn
> more), and others are working to defend the internet user population
> against wildcard or targeted SSL certificates issued by governments and
> other anti-secrecy agents with on-path capabilities.
>
> stephane bortzmeyer has already shown us that JSON representation of DNS
> transactions is possible. i have heard from another protocol engineer
> who is also working in this area (and who credits bortzmeyer for
> informing his work).
>
> the special advantage of TCP/443 as a primary transport for persistent
> DNS with channel secrecy is that H

Re: [DNSOP] Practical issues deploying DNSSEC into the home.

[Eliot Lear]

Ted,

What I like about this message is that you have demonstrated the
*potential* severability of these issues.  Things are set up as they are
for a matter of scaling.  Clearly it ain't perfect, and as one of my
mentors would say, that represents an opportunity.  It's also pretty
clear that we should be reviewing this stuff in consultation with
ICANN's SSAC committee.

Eliot

On 9/12/13 7:21 PM, Theodore Ts'o wrote:
> Fair enough, but if the goal is to prevent pervasive surveillance,
> simply using a key exchange which provides perfect forward secrecy
> will do that, even given the pathetic state of https security given
> the realities of the web and the CA's out there.
>
> Still, I agree with the general precept that perfect should not enemy
> of the better, and DNSSEC certainly adds value.  I just get worried
> about people who seem to think that DNSSEC is a panacea.
>
>  - Ted
>
>

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