Re: [DNSOP] Call for Adoption: draft-pwouters-powerbind

[Tim Wicinski]

All

The call for adoption period has ended and there has been enough consensus
to adopt this and work on this.

thank you

tim


On Fri, May 1, 2020 at 7:51 PM Wes Hardaker  wrote:

> Joe Abley  writes:
>
> > Anyway, I am fairly confident in saying that there are legitimate,
> > normal operational processes that can result in orphan glue, and that
> > it's not correct to infer that they all exist for reasons of poor
> > hygiene.
>
> For the record: I certainly (and I doubt Paul) envisioned that this
> draft would be useful and deployable to every possible
> TLD/registration-point.  It, hopefully, will be desired by some.
>
> Though ones that want to "convert" hanging glue in their zone to something
> that this
> draft could accommodate should be able to insert a new zone NS and
> delegate to their own servers with a new zone (and new dnskey).  The odd
> corner case someone mentioned is if the NS record was pointing to
> company.example, rather than ns1.company.example or something.  Then
> there is the interesting discussed question of whether company.example
> can delegate an NS to its own name [curious minds want to know].
>
> --
> Wes Hardaker
> USC/ISI
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Call for Adoption: draft-pwouters-powerbind

[Wes Hardaker]

Joe Abley  writes:

> Anyway, I am fairly confident in saying that there are legitimate,
> normal operational processes that can result in orphan glue, and that
> it's not correct to infer that they all exist for reasons of poor
> hygiene.

For the record: I certainly (and I doubt Paul) envisioned that this
draft would be useful and deployable to every possible
TLD/registration-point.  It, hopefully, will be desired by some.

Though ones that want to "convert" hanging glue in their zone to something that 
this
draft could accommodate should be able to insert a new zone NS and
delegate to their own servers with a new zone (and new dnskey).  The odd
corner case someone mentioned is if the NS record was pointing to
company.example, rather than ns1.company.example or something.  Then
there is the interesting discussed question of whether company.example
can delegate an NS to its own name [curious minds want to know].

-- 
Wes Hardaker
USC/ISI

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

Re: [DNSOP] Call for Adoption: draft-pwouters-powerbind

[John R Levine]

In a sense, a glue record with the same owner name as a zone cut could be 
equivalent to a glue record with an owner name that is subordinate to a zone 
cut. I don't have enough of the spec in my head to know why they would 
definitively be different from the protocol perspective. I realise it's not 
normal, but I don't know that it's prohibited.

I definitely don't know operationally how different DNS or registrar software 
implementations treat that case. I don't think the registry systems I'm 
familiar with allow host and domain objects with the same name to coexist, but 
I realise I could quite well be wrong.


I'm pretty sure I've never seen it in any TLD file.

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] Call for Adoption: draft-pwouters-powerbind

[Joe Abley]

Hi John,

On 1 May 2020, at 14:23, John R Levine  wrote:

>> On Thu, Apr 30, 2020 at 9:44 PM John Levine  wrote:
>>> I think it's benign to allow any sort of record as an immediate child
>>> of the domain, since you need to go two levels down for split zones.
>>> That handes the nominet and zz--zz cases.
> 
>> Is there any chance that a user trying to reach https://example.com could
>> get the orphan glue A record for example.com instead of the A record in the
>> real zone?
>> (Just trying to think of cases where orphan glue might make a difference.)
> 
> Only if the zone had NS and A at the same name, which would be pretty broken.

Oh, interesting.

In a sense, a glue record with the same owner name as a zone cut could be 
equivalent to a glue record with an owner name that is subordinate to a zone 
cut. I don't have enough of the spec in my head to know why they would 
definitively be different from the protocol perspective. I realise it's not 
normal, but I don't know that it's prohibited.

I definitely don't know operationally how different DNS or registrar software 
implementations treat that case. I don't think the registry systems I'm 
familiar with allow host and domain objects with the same name to coexist, but 
I realise I could quite well be wrong.

If I had any more energy to spend at the keyboard today I might be tempted to 
find out :-)


Joe


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

Re: [DNSOP] Call for Adoption: draft-pwouters-powerbind

[John R Levine]

On Thu, Apr 30, 2020 at 9:44 PM John Levine  wrote:

I think it's benign to allow any sort of record as an immediate child
of the domain, since you need to go two levels down for split zones.
That handes the nominet and zz--zz cases.



Is there any chance that a user trying to reach https://example.com could
get the orphan glue A record for example.com instead of the A record in the
real zone?
(Just trying to think of cases where orphan glue might make a difference.)


Only if the zone had NS and A at the same name, which would be pretty 
broken.


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] Call for Adoption: draft-pwouters-powerbind

[Joe Abley]

Hi Bob,

On 1 May 2020, at 14:02, Bob Harold  wrote:

> Is there any chance that a user trying to reach https://example.com could get 
> the orphan glue A record for example.com instead of the A record in the real 
> zone?

If the A record is orphan glue, there is no real zone (by being orphaned, it's 
no longer really glue).

So there's not just a chance that the A record from the parent zone would be 
returned, it's expected behaviour.


Joe



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

Re: [DNSOP] Call for Adoption: draft-pwouters-powerbind

[Bob Harold]

On Thu, Apr 30, 2020 at 9:44 PM John Levine  wrote:

> In article  you write:
> >Yep, I suspect some of the bigger TLDs probably couldn't opt in to this
> >draft simply because they're full of, um, "history".  Until that history
> >is cleaned, they probably couldn't deploy it.
>
> It's not just history.  All of the nominet TLDs and many Verisign TLDs
> have signed A records that are clearly deliberate.  There's also a fair
> number of TXT records named zz--zz. that have some sort of info
> about when the zone was updated.
>
> I think it's benign to allow any sort of record as an immediate child
> of the domain, since you need to go two levels down for split zones.
> That handes the nominet and zz--zz cases.
>
> R's,
> John
>
>
Is there any chance that a user trying to reach https://example.com could
get the orphan glue A record for example.com instead of the A record in the
real zone?
(Just trying to think of cases where orphan glue might make a difference.)

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

Re: [DNSOP] Call for Adoption: draft-pwouters-powerbind

[John Levine]

In article  you write:
>Yep, I suspect some of the bigger TLDs probably couldn't opt in to this
>draft simply because they're full of, um, "history".  Until that history
>is cleaned, they probably couldn't deploy it.

It's not just history.  All of the nominet TLDs and many Verisign TLDs
have signed A records that are clearly deliberate.  There's also a fair
number of TXT records named zz--zz. that have some sort of info
about when the zone was updated.

I think it's benign to allow any sort of record as an immediate child
of the domain, since you need to go two levels down for split zones.
That handes the nominet and zz--zz cases.

R's,
John


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

Re: [DNSOP] Call for Adoption: draft-pwouters-powerbind

[Joe Abley]

Hi Mark,

On 30 Apr 2020, at 19:52, Mark Andrews  wrote:

> On 1 May 2020, at 08:39, Wes Hardaker  wrote:

> 
>> Yep, I suspect some of the bigger TLDs probably couldn't opt in to this
>> draft simply because they're full of, um, "history".  Until that history
>> is cleaned, they probably couldn't deploy it.
> 
> I doubt there is any real history here other than “we didn’t properly clean
> up the records when the delegation was removed”.  If a DNS provider goes belly
> up then all the zones dependent on that provider should FAIL.  Its just poor
> zone hygiene that leaves orphaned glue in the ORG zone.

I don't want to speculate on the actual reasons that orphan glue exists in the 
ORG zone before actually taking the time to investigate, but I'll note that the 
EPP data model provides some constraints around host objects and domain objects 
(e.g. domain objects can't be deleted when there subordinate host objects that 
exist) and there are reasons for delegations to be removed from the TLD zone 
while the corresponding domain object in the registry still exists (e.g. as 
part of domains that are suspended through the normal processes by registrars 
when they are found to be abusive).

I also don't understand the theory that any of these glue records exist because 
a DNS provider ceases operations. DNS providers don't feature in the RRR model. 
A failure in a set of nameservers could cause delegations to become lame, but 
there is no process that I'm aware of where orphan glue is a direct or 
necessary consequence.

Anyway, I am fairly confident in saying that there are legitimate, normal 
operational processes that can result in orphan glue, and that it's not correct 
to infer that they all exist for reasons of poor hygiene.

This is a topic of interest in a number of places right now. It is definitely 
on the list of things to investigate.


Joe


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

Re: [DNSOP] Call for Adoption: draft-pwouters-powerbind

[Mark Andrews]

> On 1 May 2020, at 08:39, Wes Hardaker  wrote:
> 
> Joe Abley  writes:
> 
>> Well, for example there are some 28,000 examples of orphan glue in the
>> ORG zone.
> 
> Yep, I suspect some of the bigger TLDs probably couldn't opt in to this
> draft simply because they're full of, um, "history".  Until that history
> is cleaned, they probably couldn't deploy it.

I doubt there is any real history here other than “we didn’t properly clean
up the records when the delegation was removed”.  If a DNS provider goes belly
up then all the zones dependent on that provider should FAIL.  Its just poor
zone hygiene that leaves orphaned glue in the ORG zone.

>> Anyway, thanks for the edits; I will send comments back to the list
>> when I've had a chance to read them thoroughly.
> 
> Great!
> -- 
> Wes Hardaker
> USC/ISI
> 
> ___
> 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] Call for Adoption: draft-pwouters-powerbind

[Wes Hardaker]

Joe Abley  writes:

> Well, for example there are some 28,000 examples of orphan glue in the
> ORG zone.

Yep, I suspect some of the bigger TLDs probably couldn't opt in to this
draft simply because they're full of, um, "history".  Until that history
is cleaned, they probably couldn't deploy it.

> Anyway, thanks for the edits; I will send comments back to the list
> when I've had a chance to read them thoroughly.

Great!
-- 
Wes Hardaker
USC/ISI

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

Re: [DNSOP] Call for Adoption: draft-pwouters-powerbind

[Joe Abley]

Hi Wes.

On 30 Apr 2020, at 17:41, Wes Hardaker  wrote:

> I've just pushed the -04 version of the draft that has a fairly major
> overhaul of the problem statement.  I'd appreciate if it helps clarify
> the technical reasons why deployment of the bit would be beneficial in
> ways that are unrelated to contractual type controls.  I'll include the
> first three sections below, which are the parts that really changed.

Thanks! It's on the list :-)

>> Perhaps more substantially, but with more rapid oscillation of hands,
>> I am concerned that this draft, if adopted, will gain legitimacy in
>> policy circles where it might actually do damage.
> 
> I can't speculate whether zones would be under increased market pressure
> for a DNS feature you clearly indicate might be desired.  I find this
> statement that "this looks too helpful to some people; let's not do it"
> fascinating :-)

Well, no. I was really concerned that it would be of no help at all whilst 
simultaneously sounding tremendously necessary ("transparency!"), and that it 
might have collateral damage.

>> An example might be where there is contractual or market pressure to
>> require it for TLDs where its effect might be to cause suppressed
>> orphan glue to break otherwise functional delegations.
> 
> I'd love to see some registration point cases where this technique would
> cause harm.

Well, for example there are some 28,000 examples of orphan glue in the ORG 
zone. There are about 93,000 across all gTLDs. I haven't analysed these orphan 
glue records in any useful detail (that's on the list, too :-) but I'm wary of 
assuming that they could all be safely suppressed without harming any other 
delegation.

Anyway, thanks for the edits; I will send comments back to the list when I've 
had a chance to read them thoroughly.


Joe


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

Re: [DNSOP] Call for Adoption: draft-pwouters-powerbind

[Wes Hardaker]

Tim Wicinski  writes:

> Following up on Petr's suggestion that the "DNSEC Transparency" mechanism is 
> documented
> and somewhat tested. 

FYI, the new version (-04) that I just published hopefully clarifies
better why this draft is useful with or without DNSEC Transparency.
DNSSEC Transparency would certainly be helpful for auditing purposes.
But protection is provided to validating resolvers even without it.  And
yes, DNSSEC Transparency probably needs our draft in order to reach scalability.
-- 
Wes Hardaker
USC/ISI

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

Re: [DNSOP] Call for Adoption: draft-pwouters-powerbind

[Wes Hardaker]

Hi Joe,

Sorry for the delay (Paul and I did a bit of back and forth with text
changes that took a bit longer, but made it better!)

> This draft needs a more compelling problem statement, and a clear description 
> of why other controls
> (e.g. reputational, contractual) are insufficient. [It's also possible that 
> the draft just needs a
> clearer problem statement, rather than a more compelling one.]

I've just pushed the -04 version of the draft that has a fairly major
overhaul of the problem statement.  I'd appreciate if it helps clarify
the technical reasons why deployment of the bit would be beneficial in
ways that are unrelated to contractual type controls.  I'll include the
first three sections below, which are the parts that really changed.

> Perhaps more substantially, but with more rapid oscillation of hands,
> I am concerned that this draft, if adopted, will gain legitimacy in
> policy circles where it might actually do damage.

I can't speculate whether zones would be under increased market pressure
for a DNS feature you clearly indicate might be desired.  I find this
statement that "this looks too helpful to some people; let's not do it"
fascinating :-) More seriously, if a customer base wanted to ensure
their parent promised never to sign lower data with their key, there is
nothing stopping contractual wording around that from existing today.
This draft merely offers a technical solution to prevent parents from
*successfully* signing lower data and having it be accepted by
validating resolvers.

> An example might be where there is contractual or market pressure to
> require it for TLDs where its effect might be to cause suppressed
> orphan glue to break otherwise functional delegations.

I'd love to see some registration point cases where this technique would
cause harm.  It is an all or nothing solution, so if a zone had 1M
customers and 1 of them needed to be signed by the parental key, then
they couldn't set this flag.  That being said, if they're truly serving
client data, it would be strange that they couldn't just create a
new delegation to handle the issue.

Here's the next for the newly wording sections 1 and 3, that describe
the problem (2 was keywords):



1.  Introduction

   The DNS Security Extensions [DNSSEC] use public key cryptography to
   create an hierarchical trust base with the DNSSEC root public keys at
   the top, followed by Top Level domain (TLD) keys one level
   underneath.  While the root and most TLD zones are asumed to be
   exclusively delegation-only zones, there is currently no
   interoperable and automatable mechanism for auditing these zones to
   ensure they behave as a delegation-only zone.  This creates a target
   for malicious use of these zones - either by their owners or through
   coercion.

   This document defines a mechanism for delegation-only zone owners to
   create a DNSKEY that indicate they will only delegate the remainder
   of the DNS tree to lower-level zones.  This allows for easier
   delegation policy verification and logging and auditing of DNS
   responses served by their infrastructure.

   Specifically, this document introduces a new DNSKEY flag allowing
   zone owners to commit to only signing records relating to delegation.

   If a DNSSEC validator discovers any non-delegation zone data signed
   by a flagged key, this data can be interpreted as BOGUS.

3.  The Deep Signing problem

   The hierarchical model of DNS and DNSSEC ([RFC1034], [RFC1035],
   [RFC4033], [RFC4034] and [RFC4035]) comes with the property that a
   zone at one point in the hierarchy can define, and therefor override,
   everything below it in the DNS tree.  And this is possible to achieve
   on a per-client basis.

   For example, the owner of the DNSSEC root key could generate a
   specially crafted zone file that ignores the intended NS records for
   ".org" and "example.org".  It could place a  record for
   "www.example.org" directly into the specially crafted zone, with a
   corresponding RRSIG signed by the root DNSKEY itself.  Validating
   resolvers would find this record perfectly acceptable, as it was
   signed by a key within the proper chain of trust (in this case, a
   root DNSKEY).  This specially crafted zone could then even be served
   to specific clients in an effort to subvert a portion of the DNS
   ecosystem for a portion of the Internet.

   Similarly, the TLD "example" could circumvent company.example for
   certain clients.  It is important to note that this can be done
   without changing the upstream DS record or trust anchor -- the DNSKEY
   is (again) already in the trust path and is merely signing deeper DNS
   records than the zone owner's clients may have expected it to sign.

   It is important to note that this "feature" has always been present.
   Since the creation of the DNS, it has always been possible to serve
   "split zones".  Specifically, it is not a problem created by DNSSEC
   -- DNSSEC was not 

Re: [DNSOP] Call for Adoption: draft-pwouters-powerbind

[John Levine]

In article  
you write:
>
>My understanding of the draft is that it attempts to prevent a key to sign
>a RRset it is not necessarily authoritative for.

If that's what it means, that's what it should say.  As I read it, the flag it 
defines
says that the zone will only sign NS and DS and perhaps the occasional _flag.

The 95,000 signed A and  records I found in TLD files are all
authoritative, since there is no zone cut between them and the TLD.
But that's over 200 TLDs which this proposal would not apply to.

Perhaps we should ask some TLD operators if they'd be interested.


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

Re: [DNSOP] Call for Adoption: draft-pwouters-powerbind

[Linus Nordberg]

Tim Wicinski  wrote
Mon, 20 Apr 2020 14:03:03 -0400:

> This starts a Call for Adoption for draft-pwouters-powerbind

I am interested in the idea of a DNSSEC transparency system, i.e.
externally verifiable append-only logs of observed DNSSEC data, and do
support adoption of draft-pwouters-powerbind which I'm also willing to
review.

My experience with DNSSEC transparency is limited to an implementation
of such a log and the operation of a log instance. This experiment was
based on an implementation of [draft-zhang-trans-ct-dnssec] and was set
up at IETF96.

[draft-zhang-trans-ct-dnssec] 
https://tools.ietf.org/html/draft-zhang-trans-ct-dnssec-03

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

Re: [DNSOP] Call for Adoption: draft-pwouters-powerbind

[Tim Wicinski]

Following up on Petr's suggestion that the "DNSEC Transparency" mechanism
is documented
and somewhat tested.

I totally agree on this idea and can assure the WG that if this draft is
adopted, this will be one of the
conditions on progressing forward.

tim


On Thu, Apr 23, 2020 at 1:46 AM Petr Špaček  wrote:

> Hi dnsop,
>
> I support adoption under condition that the envisioned "DNSSEC
> Transparency" mechanism is documented and somewhat tested before
> "powerbind" draft progresses into form of RFC.
>
> At the moment there are insufficient details published for the dnsop WG to
> judge whether powerbind+transparency proposals together fulfill intended
> purpose.
>
> I would hate to see "powerbind" published for vendors to implement before
> (at least!) proof-of-concept implementations of powerbind _and_
> Transparency are done. That's the only way to make sure some little details
> are not preventing vendors from implementing practical proposals.
>
> RFCs 7901 (CHAIN extension) and 8094 (DTLS) should serve us as warnings.
>
> Petr Špaček  @  CZ.NIC
>
>
> On 20. 04. 20 20:03, Tim Wicinski wrote:
> >
> > All,
> >
> > As we stated in the meeting and in our chairs actions, we're going to run
> > regular call for adoptions over next few months.
> >
> > From the presentation during the last meeting, there was interest in
> > adtoping this document around the idea of DNSSEC transparency.  This
> > interest comes the privacy side of things, more than the DNS side.
> >
> > This starts a Call for Adoption for draft-pwouters-powerbind
> >
> > The draft is available here:
> https://datatracker.ietf.org/doc/draft-pwouters-powerbind/
> >
> > Please review this draft to see if you think it is suitable for adoption
> > by DNSOP, and comments to the list, clearly stating your view.
> >
> > We are looking for *explicit* support for adoption.
> >
> > Please also indicate if you are willing to contribute text, review, etc..
> >
> > This call for adoption ends: 4 May 2020
> >
> > Thanks,
> > tim wicinski
> > DNSOP co-chair
>
> ___
> 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] Call for Adoption: draft-pwouters-powerbind

[Daniel Migault]

My understanding of the draft is that it attempts to prevent a key to sign
a RRset it is not necessarily authoritative for. I think the WG should work
on this, and support adoption of the draft. I am happy to review further
version of the draft.
Yours,
Daniel

On Tue, Apr 28, 2020 at 4:27 PM Wes Hardaker  wrote:

> Joe Abley  writes:
>
> > On Apr 27, 2020, at 18:28, Wes Hardaker  wrote:
> >
> > > Thanks for the comments.  I'm working on a more clear rewrite of the
> > > introduction.  I'd love your feedback on it once I get it wrapped up.
> >
> > Yes, for sure! Happy to do that.
>
> Half done.  Either tonight or tomorrow.
> --
> Wes Hardaker
> USC/ISI
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>


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

Re: [DNSOP] Call for Adoption: draft-pwouters-powerbind

[Wes Hardaker]

Joe Abley  writes:

> On Apr 27, 2020, at 18:28, Wes Hardaker  wrote:
> 
> > Thanks for the comments.  I'm working on a more clear rewrite of the
> > introduction.  I'd love your feedback on it once I get it wrapped up.
> 
> Yes, for sure! Happy to do that.

Half done.  Either tonight or tomorrow.
-- 
Wes Hardaker
USC/ISI

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

Re: [DNSOP] Call for Adoption: draft-pwouters-powerbind

[John Levine]

In article ,
Brian Dickson   wrote:
>The two example zones I would reference would be ".uk", and ".jp", where
>there are SLDs immediately below the TLD, and additional SLD-like
>delegations or non-delegations further down in the zones.

I think you will find ENTs in more TLDs than not.  They certainly
exist in .US and .CA and lots of others like .AC .AD .AE .AERO .AF .AG
..AI .AL .AM .AO .AR .ARPA .AS .AT .AU .AW .AZ and those are just the
ones that start with A.

-- 
Regards,
John Levine, jo...@taugh.com, Primary Perpetrator of "The Internet for Dummies",
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] Call for Adoption: draft-pwouters-powerbind

[Paul Wouters]

On Mon, 27 Apr 2020, Brian Dickson wrote:


The other would be the kind that are multiple-depth delegation zones, where the 
Public Suffix List is already kind of necessary.

What I think is needed is a way to explicitly declare the places where the depth 
is > 1 (if a normal flat delegation-only zone has depth == 1).


We thought about using two bits instead of one, so we could specify a
variable depth (per zone, not per delegation) but it seemed to add a
lot of complexity. It is far easier for these TLDs to make their ENTs
a signed delegation.


And that would effectively just need a way of making permanent and well-known, 
the set of ENTs for the zone (empty non-terminals).

I think that list is likely to be short even for the most convoluted zones..


Doing things in more variable ways with lists of exceptions to a depth
== 1 seems very complicated and would add complexity for resolvers.


Without this, it would be theoretically possible for the TLD to add additional 
unsigned delegations to bypass a signed delegation.


I do not understand this? You mean leaving the ENT unsigned, and then
adding NS records to create a false shadow tree? At best that would
result in DS records for the real delegations to be ignored because
there is a validation error in the path. Or if the DS records would
still be served signed from the parent, then this hostile takeover
via unsigned records would not work because the shadow tree would not
have the DNSKEYs matching the signed DS record.


If two delegations were present, child.example.com and example.com, it would 
not be possible to disambiguate them without knowing more about the zone
structure and semantics.


This is an interesting case I had not considered. If a TLD hands out
domains in a mix of 1 level and 2 levels deep, what can be done
other than not using this draft? If the ENTs are limited, then
I'd still be tempted to say to turn those into real signed zones.
Any mechanism that would convey this list of ENT's would really
complicate things far more than just turning the ENTs into real
signed zones.

Paul

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

Re: [DNSOP] Call for Adoption: draft-pwouters-powerbind

[Brian Dickson]

On Mon, Apr 27, 2020 at 3:28 PM Wes Hardaker  wrote:

> Joe Abley  writes:
>
> > This draft needs a more compelling problem statement, and a clear
> > description of why other controls (e.g. reputational, contractual) are
> > insufficient. [It's also possible that the draft just needs a clearer
> > problem statement, rather than a more compelling one.]
>
> Hi Joe,
>
> Thanks for the comments.  I'm working on a more clear rewrite of the
> introduction.  I'd love your feedback on it once I get it wrapped up.  I
> think (hope) I can spell out the case for support more clearly.  I agree
> the subject is a bit hard to wiggle into your head (as are most
> somewhat-complex security cases)
>
>
Hi, Wes,

I was looking at the draft to see if I understood the intent correctly, and
I think there may be a small gap, if my understanding is correct.

So, I think there are two use cases that something doing this kind of thing
needs to handle.

One is the "flat delegation-only zone", like any of the big well-known ones
(com, net, org, info).

The other would be the kind that are multiple-depth delegation zones, where
the Public Suffix List is already kind of necessary.

What I think is needed is a way to explicitly declare the places where the
depth is > 1 (if a normal flat delegation-only zone has depth == 1).

And that would effectively just need a way of making permanent and
well-known, the set of ENTs for the zone (empty non-terminals).

I think that list is likely to be short even for the most convoluted zones.

Without this, it would be theoretically possible for the TLD to add
additional unsigned delegations to bypass a signed delegation.

With the addition of an explicit set of ENTs, there would be double-entry
accounting.
Entries in the zone with depth > 1 would require a chain of ENTs to the
zone apex.
Entries in the zone with depth == 1 would need to not also have
corresponding ENTs.

(My assumption is the ENT declarations would be separate from the intrinsic
ENTs from NSEC or the explicit ones from NSEC3, if I recall my NSEC vs
NSEC3 nuances, and probably in a sibling zone like _ent.TLD for example.)

If two delegations were present, child.example.com and example.com, it
would not be possible to disambiguate them without knowing more about the
zone structure and semantics.

The two example zones I would reference would be ".uk", and ".jp", where
there are SLDs immediately below the TLD, and additional SLD-like
delegations or non-delegations further down in the zones.

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

Re: [DNSOP] Call for Adoption: draft-pwouters-powerbind

[Joe Abley]

On Apr 27, 2020, at 18:28, Wes Hardaker  wrote:

> Thanks for the comments.  I'm working on a more clear rewrite of the
> introduction.  I'd love your feedback on it once I get it wrapped up.

Yes, for sure! Happy to do that.


Joe

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

Re: [DNSOP] Call for Adoption: draft-pwouters-powerbind

[Wes Hardaker]

Joe Abley  writes:

> This draft needs a more compelling problem statement, and a clear
> description of why other controls (e.g. reputational, contractual) are
> insufficient. [It's also possible that the draft just needs a clearer
> problem statement, rather than a more compelling one.]

Hi Joe,

Thanks for the comments.  I'm working on a more clear rewrite of the
introduction.  I'd love your feedback on it once I get it wrapped up.  I
think (hope) I can spell out the case for support more clearly.  I agree
the subject is a bit hard to wiggle into your head (as are most
somewhat-complex security cases)
-- 
Wes Hardaker
USC/ISI

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

Re: [DNSOP] Call for Adoption: draft-pwouters-powerbind

[Wes Hardaker]

Petr Špaček  writes:

> I support adoption under condition that the envisioned "DNSSEC
> Transparency" mechanism is documented and somewhat tested before
> "powerbind" draft progresses into form of RFC.

So that statement makes the point that there is no point in the document
except for DNSSEC Transparency.  I'm not sure that's true (and I'm going
to work on a better intro that hopefully may clarify things).

But implementation is pretty much a requirement in dnsop for anything
new; so implementation of the bit would certainly be needed (by both
client and sender).  But, IMHO, it shouldn't be tied to a larger topic's
(DNSSEC Transparency) implementation.
-- 
Wes Hardaker
USC/ISI

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

Re: [DNSOP] Call for Adoption: draft-pwouters-powerbind

[Joe Abley]

On 20 Apr 2020, at 14:03, Tim Wicinski  wrote:

> This starts a Call for Adoption for draft-pwouters-powerbind
> 
> The draft is available here: 
> https://datatracker.ietf.org/doc/draft-pwouters-powerbind/ 
> 
> 
> Please review this draft to see if you think it is suitable for adoption
> by DNSOP, and comments to the list, clearly stating your view.

This draft needs a more compelling problem statement, and a clear description 
of why other controls (e.g. reputational, contractual) are insufficient. [It's 
also possible that the draft just needs a clearer problem statement, rather 
than a more compelling one.]

I identify with Warren's furrowed brow as he asked how this draft would protect 
against a rogue registrar or registry publishing a zone with a 
covertly-modified delegation, since such rogue behaviour would not be 
identified or suppressed by the mechanism proposed in this draft. This seems 
fundamental to the concept of "delegation-only" which is the central and sole 
consideration of this proposal.

Perhaps more substantially, but with more rapid oscillation of hands, I am 
concerned that this draft, if adopted, will gain legitimacy in policy circles 
where it might actually do damage. An example might be where there is 
contractual or market pressure to require it for TLDs where its effect might be 
to cause suppressed orphan glue to break otherwise functional delegations. It 
seems better to me to understand the implications of the mechanism up front 
before it gets close to an RFC number, because those RFC numbers can smell 
deceptively potent.

I would prefer this idea to be better fleshed out in these areas before the 
draft sees adoption, and hence I do not support adoption at this time. I 
understand the sentiment expressed by some others with the opinion that the 
proposal in any case does no harm since it's optional, but I find myself less 
optimistic about the future than they are.

My day job is at a company responsible for a significant and venerable 
top-level domain. Lest anybody infer otherwise, let me confirm that we are very 
much in favour of measures that allow compliance to be ensured through 
automated and mechanical means and, correspondingly, for trust in our 
stewardship to be as close as possible to absolute. I am, in general, very open 
to ideas that would promote those things. However, I am not convinced that this 
proposal will get us there and I am concerned that the legitimacy that is 
associated with the work on this group might ultimately result in collateral 
damage.


Joe


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

Re: [DNSOP] Call for Adoption: draft-pwouters-powerbind

[Petr Špaček]

Hi dnsop,

I support adoption under condition that the envisioned "DNSSEC Transparency" 
mechanism is documented and somewhat tested before "powerbind" draft progresses 
into form of RFC.

At the moment there are insufficient details published for the dnsop WG to 
judge whether powerbind+transparency proposals together fulfill intended 
purpose.

I would hate to see "powerbind" published for vendors to implement before (at 
least!) proof-of-concept implementations of powerbind _and_ Transparency are 
done. That's the only way to make sure some little details are not preventing 
vendors from implementing practical proposals.

RFCs 7901 (CHAIN extension) and 8094 (DTLS) should serve us as warnings.

Petr Špaček  @  CZ.NIC


On 20. 04. 20 20:03, Tim Wicinski wrote:
> 
> All,
> 
> As we stated in the meeting and in our chairs actions, we're going to run
> regular call for adoptions over next few months.  
> 
> From the presentation during the last meeting, there was interest in
> adtoping this document around the idea of DNSSEC transparency.  This
> interest comes the privacy side of things, more than the DNS side.  
> 
> This starts a Call for Adoption for draft-pwouters-powerbind
> 
> The draft is available here: 
> https://datatracker.ietf.org/doc/draft-pwouters-powerbind/
> 
> Please review this draft to see if you think it is suitable for adoption
> by DNSOP, and comments to the list, clearly stating your view.
> 
> We are looking for *explicit* support for adoption.
> 
> Please also indicate if you are willing to contribute text, review, etc.
> 
> This call for adoption ends: 4 May 2020
> 
> Thanks,
> tim wicinski
> DNSOP co-chair

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

Re: [DNSOP] Call for Adoption: draft-pwouters-powerbind

[Paul Wouters]

On Apr 20, 2020, at 14:35, Dave Lawrence  wrote:
> 
> I support adoption, with the caveat that either the draft name should
> be updated with something like s/powerbind/delegation-only-dnssec/, or
> the draft should describe why it is being called "powerbind".

The name was a joke. It is not used anyway in the document text on purpose and 
will not appear in the name when adopted.

Paul



> 
> ___
> 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] Call for Adoption: draft-pwouters-powerbind

[Dave Lawrence]

I support adoption, with the caveat that either the draft name should
be updated with something like s/powerbind/delegation-only-dnssec/, or
the draft should describe why it is being called "powerbind".

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