Re: [DNSOP] Agenda for IETF100

[tjw ietf]

Great question Paul and thanks for getting that on record.

On Sat, Nov 11, 2017 at 2:59 AM, David Conrad  wrote:

> Can confirm, as can anyone willing to go to an Adobe Connect archive. For
> the curious:
>
> https://participate.icann.org/p6u03rimy92/?launcher=false;
> fcsContent=true=normal
>
> The discussion on Ethereum by Leonard Tan, an Ethereum developer, starts
> at 00:31:00. Paul’s question is at 00:42:16. From the transcript:
>
> >> PAUL:  PAUL, IETF.  LET'S SAY IETF GETS THE DOMAINS IETF IN THIS NAMING
> SYSTEM AND WE PAY OUR FEES FOR A COUPLE OF YEARS.  EVERYBODY USES THE
> SITE.  AND THEN AT SOME POINT WE FORGET TO PAY AND THE DOMAIN FALLS BACK
> INTO THE POOL AND SOMEBODY ELSE REGISTERS IT AND WE DON'T KNOW WHERE THEY
> ARE OR WHO THEY ARE.  NOW I GO TO A COURT SYSTEM.  I GET SOME LEGAL OPINION
> SAYING I OWN THIS TRADEMARK AND NOW I WANT TO GET THIS DOMAIN BACK.  IS
> THERE ANY WAY FOR ME TO GET THIS DOMAIN BACK?
> >>LEONARD TAN:  SO RIGHT NOW, THE ENS INDUSTRY, YOU CAN CHANGE IT BECAUSE
> IT REQUIRES FOUR OUT OF SEVEN PEOPLE.  MOST OF THEM ARE ETHEREUM
> DEVELOPERS.  AND IT IS A CONSENSUS OF THEM TO MAKE ANY CHANGES.  SO IT IS
> POSSIBLE, BUT IT IS GOING TO BE A VERY DIFFICULT THING TO DO.
>
> Regards,
> -drc
>
> On Nov 10, 2017, 10:47 PM +0800, Paul Wouters , wrote:
>
> The ENS developer said so in response to my question.
>
> Sent from my iPhone
>
> On Nov 10, 2017, at 19:55, Stephane Bortzmeyer  wrote:
>
> On Fri, Nov 10, 2017 at 05:58:13PM +0530,
> Paul Wouters  wrote
> a message of 29 lines which said:
>
> It takes 4 out of 7 geeks to bypass the blockchain in case of
> emergency, court orders or kneecaps.
>
> According to the presentation held at ICANN60
>
>
> Well, if someone at ICANN said so, someone is wrong (or, at the
> minimum, over-simplificator).
>
> ___
> 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
>
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Review of draft-dupont-dnsop-rfc2845bis-00.txt

[Francis Dupont]

 In your previous mail you wrote:

>  After a reading, I felt that this document needs the following:
>  
>  * Editing for clarity of sentences

=> I agree until the text comes from original RFCs (i.e. you are
17 year too late) or can only be clarified at the margin.

>  * Addressing insufficient protocol specification

=> these should be fixed if they have an impact on security
(a priori we already fixed them but perhaps we missed a few?)

>  Review follows that suggests changes. Some are nitpicking, but changes
>  are needed to be pedantically correct.
>  
>  >This protocol allows for transaction level authentication using
>  >shared secrets and one way hashing.  It can be used to authenticate
>  
>  I'd start as "This document describes a protocol for transaction level
>  authentication...".

=> 17y

>  >shared secrets and one way hashing.  It can be used to authenticate
>  >dynamic updates as coming from an approved client, or to authenticate
>  >responses as coming from an approved recursive name server.
>  
>  s/recursive name server/name server/

=> 17y but removing extra/superfluous word is good: adopted

>  >No provision has been made here for distributing the shared secrets:
>  >it is expected that a network administrator will statically configure
>  >name servers and clients using some out of band mechanism such as
>  >sneaker-net until a secure automated mechanism for key distribution
>  >is available.
>  
>  This paragraph may be misconstrued to imply that such an automated
>  mechanism is forthcoming. I'd leave it at just this:
>  
>  "This document does not describe how to distribute the shared secrets.
>  It is expected that a network administrator will statically configure
>  name servers and clients using some out of band mechanism."

=> adopted

>  >This document includes revised original TSIG specifications
>  >(RFC2845) and the extension for HMAC-SHA (RFC4635).
>  
>  s/and the extension/and its extension/

=> adopted

>  > 1.  Introduction
>  > 
>  >In 2017, security problems in two nameservers strictly following
>  >[RFC2845] and [RFC4635] (i.e., TSIG and HMAC-SHA extension)
>  
>  s/TSIG and HMAC-SHA extension/TSIG and its HMAC-SHA extension/

=> adopted

>  >This document specifies use of a message authentication code (MAC),
>  >either HMAC-MD5 or HMAC-SHA (keyed hash functions), to provide an
>  >efficient means of point-to-point authentication and integrity
>  >checking for transactions.
>  
>  I'd avoid listing the HMACs here and instead refer to the section below
>  that lists them.

=> I disagree: it is not a good idea to have forward references in
the introduction.

>  >The second area where the secret key based MACs specified in this
>  >document can be used is to authenticate DNS update requests as well
>  >as transaction responses, providing a lightweight alternative to the
>  >protocol described by [RFC3007].
>  
>  It isn't clear how this is different from "first area". DNS updates are
>  also transactions.

=> 17y

>  >A further use of this mechanism is to protect zone transfers.  In
>  >this case the data covered would be the whole zone transfer including
>  >any glue records sent.  The protocol described by DNSSEC does not
>  >protect glue records and unsigned records unless SIG(0) (transaction
>  >signature) is used.
>  
>  I'd avoid including this whole sentence about DNSSEC.

=> 17y

>  >The authentication mechanism proposed in this document uses shared
>  >secret keys to establish a trust relationship between two entities.
>  
>  I'd s/shared secret keys/pre-shared secret keys/

=> I don't think pre-shared is really clearer.

>  >Such keys must be protected in a fashion similar to private keys,
>  
>  s/fashion/manner/

=> 17y

>  >Note that use of TSIG presumes prior agreement between the resolver
>  >and server involved as to the algorithm and key to be used.
>  
>  Again this document seems to tie itself to the resolver case only.
>  
>  s/between the resolver and server/between the client and server/

=> I disagree and BTW 17y too.

>  >Since the publication of first version of this document ([RFC2845]) a
>  >mechanism based on asymmetric signatures using the SIG RR was
>  >specified (SIG(0) [RFC2931]) when this document uses symmetric
>  >authentication codes calculated by HMAC [RFC2104] using strong hash
>  >functions.
>  
>  s/when this document/whereas this document/

+> adopted (I assume your English is better than mine :-)

>  > 4.1.  TSIG RR Type
>  > 
>  >To provide secret key authentication, we use a new RR type whose
>  >mnemonic is TSIG and whose type code is 250.  TSIG is a meta-RR and
>  >MUST NOT be cached.  TSIG RRs are used for authentication between DNS
>  >entities that have established a shared secret key.  TSIG RRs are
>  >dynamically computed to cover a particular DNS 

Re: [DNSOP] Resolver behaviour with multiple trust anchors

[william manning]

in reverse order of trustworthiness:

the root
a third party - e.g. DLV
locally verified - e.g. my employer, ISP, someone I have a binding legal
relationship with

/Wm

On Thu, Nov 2, 2017 at 8:04 AM, Bob Harold  wrote:

>
> On Thu, Nov 2, 2017 at 10:41 AM, Matt Larson 
> wrote:
>
>> The root KSK rollover project has given me a real appreciation for the
>> brittleness of trust anchor configuration, even with RFC 5011. (Automated
>> update support should get better over time, especially after the first KSK
>> roll exposes problems, but right now it's pretty shaky, which is my
>> informed opinion based on observation from the operational trenches.) In
>> the real world, where trust anchors are going to go stale, an "Accept Any
>> Success" (in the language of Appendix C) trust anchor policy is the safest
>> operationally.
>>
>> I agree with Ed's observation that operators are, by and large, going to
>> use the defaults in whatever implementation they're running, so defaults
>> are important.
>>
>> Trust is always going to be a matter of local policy, so with DNSSEC
>> there's never going to be a consistent output given a consistent input. The
>> best we can do is give good guidance to implementors, ideally based on
>> operational experience, to inform their choices for the default settings
>> that operators will end up using.
>>
>> I think RFC 6840 gets it right: it acknowledges that trust anchor
>> preference is a matter of local policy, but recommends an operationally
>> safe default of "Accept Any Success".
>>
>> Why would one want a "Closest Encloser" trust anchor preference policy?
>> I've heard two reasons in this thread:
>>
>> 1. The untrusted parent scenario: I submit there's no practical
>> implication of distinguishing between the parent's control of the
>> delegation and its control of the DS: the child zone is completely at the
>> will of the parent zone, so if your parent has it in for you, you lose.
>> This scenario is not sufficient motivation, in my opinion, to suggest
>> "Closest Encloser" as a default policy.
>>
>> 2. In a split DNS context, reject answers that leak into the wrong view:
>> I think using DNSSEC as a backstop to enforce split DNS policy is a dubious
>> operational practice and likewise not sufficient motivation to suggest
>> "Closest Encloser" as a default policy.
>>
>> In my perfect world, implementations would offer a knob to set "Closest
>> Encloser" for consenting adults but default to "Accept Any Success".
>>
>> Matt
>>
>
> I generally agree with you, but wonder if there is a performance penalty
> to searching every possible path before failing.  Is that a reasonable
> concern?
>
> How many paths are there?  I can think of:
> 1. To the root
> 2. To a local trust anchor
> 3. To a DLV provider (gone as of Sept 30?)
>
> If local trust anchors are checked before the root, and they are under
> operator control, then maybe "Closest Encloser" is a reasonable default.  I
> don't know where to fit DLV into that plan.
>
> Also, if an operator does not configure DLV or local trust anchors, then
> is root the only path?  So "Closest Encloser" and "Accept Any Success" are
> the same?
> Or am I not understanding something (no experience with this yet)?
>
> --
> Bob Harold
>
>
> ___
> 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] Resolver behaviour with multiple trust anchors

[william manning]

in the last 20 years, there have been a few testbeds that have explored
this space.

irl.cs.ucla.edu/papers/imc71-osterweil.pdf
https://eprint.iacr.org/2013/254.pdf

that suggest Matt is spot on here.   accepting any success is likely to
present the fewest problems from a user perspective.

/Wm

On Thu, Nov 2, 2017 at 7:41 AM, Matt Larson  wrote:

> The root KSK rollover project has given me a real appreciation for the
> brittleness of trust anchor configuration, even with RFC 5011. (Automated
> update support should get better over time, especially after the first KSK
> roll exposes problems, but right now it's pretty shaky, which is my
> informed opinion based on observation from the operational trenches.) In
> the real world, where trust anchors are going to go stale, an "Accept Any
> Success" (in the language of Appendix C) trust anchor policy is the safest
> operationally.
>
> I agree with Ed's observation that operators are, by and large, going to
> use the defaults in whatever implementation they're running, so defaults
> are important.
>
> Trust is always going to be a matter of local policy, so with DNSSEC
> there's never going to be a consistent output given a consistent input. The
> best we can do is give good guidance to implementors, ideally based on
> operational experience, to inform their choices for the default settings
> that operators will end up using.
>
> I think RFC 6840 gets it right: it acknowledges that trust anchor
> preference is a matter of local policy, but recommends an operationally
> safe default of "Accept Any Success".
>
> Why would one want a "Closest Encloser" trust anchor preference policy?
> I've heard two reasons in this thread:
>
> 1. The untrusted parent scenario: I submit there's no practical
> implication of distinguishing between the parent's control of the
> delegation and its control of the DS: the child zone is completely at the
> will of the parent zone, so if your parent has it in for you, you lose.
> This scenario is not sufficient motivation, in my opinion, to suggest
> "Closest Encloser" as a default policy.
>
> 2. In a split DNS context, reject answers that leak into the wrong view: I
> think using DNSSEC as a backstop to enforce split DNS policy is a dubious
> operational practice and likewise not sufficient motivation to suggest
> "Closest Encloser" as a default policy.
>
> In my perfect world, implementations would offer a knob to set "Closest
> Encloser" for consenting adults but default to "Accept Any Success".
>
> Matt
>
> ___
> 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] Agenda for IETF100

[David Conrad]

Can confirm, as can anyone willing to go to an Adobe Connect archive. For the 
curious:

https://participate.icann.org/p6u03rimy92/?launcher=false=true=normal

The discussion on Ethereum by Leonard Tan, an Ethereum developer, starts at 
00:31:00. Paul’s question is at 00:42:16. From the transcript:

>> PAUL:  PAUL, IETF.  LET'S SAY IETF GETS THE DOMAINS IETF IN THIS NAMING 
>> SYSTEM AND WE PAY OUR FEES FOR A COUPLE OF YEARS.  EVERYBODY USES THE SITE.  
>> AND THEN AT SOME POINT WE FORGET TO PAY AND THE DOMAIN FALLS BACK INTO THE 
>> POOL AND SOMEBODY ELSE REGISTERS IT AND WE DON'T KNOW WHERE THEY ARE OR WHO 
>> THEY ARE.  NOW I GO TO A COURT SYSTEM.  I GET SOME LEGAL OPINION SAYING I 
>> OWN THIS TRADEMARK AND NOW I WANT TO GET THIS DOMAIN BACK.  IS THERE ANY WAY 
>> FOR ME TO GET THIS DOMAIN BACK?
>>LEONARD TAN:  SO RIGHT NOW, THE ENS INDUSTRY, YOU CAN CHANGE IT BECAUSE IT 
>>REQUIRES FOUR OUT OF SEVEN PEOPLE.  MOST OF THEM ARE ETHEREUM DEVELOPERS.  
>>AND IT IS A CONSENSUS OF THEM TO MAKE ANY CHANGES.  SO IT IS POSSIBLE, BUT IT 
>>IS GOING TO BE A VERY DIFFICULT THING TO DO.

Regards,
-drc

On Nov 10, 2017, 10:47 PM +0800, Paul Wouters , wrote:
> The ENS developer said so in response to my question.
>
> Sent from my iPhone
>
> > On Nov 10, 2017, at 19:55, Stephane Bortzmeyer  wrote:
> >
> > On Fri, Nov 10, 2017 at 05:58:13PM +0530,
> > Paul Wouters  wrote
> > a message of 29 lines which said:
> >
> > > It takes 4 out of 7 geeks to bypass the blockchain in case of
> > > emergency, court orders or kneecaps.
> > >
> > > According to the presentation held at ICANN60
> >
> > Well, if someone at ICANN said so, someone is wrong (or, at the
> > minimum, over-simplificator).
> >
> > ___
> > 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
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Agenda for IETF100

[Paul Wouters]

The ENS developer said so in response to my question.

Sent from my iPhone

> On Nov 10, 2017, at 19:55, Stephane Bortzmeyer  wrote:
> 
> On Fri, Nov 10, 2017 at 05:58:13PM +0530,
> Paul Wouters  wrote 
> a message of 29 lines which said:
> 
>> It takes 4 out of 7 geeks to bypass the blockchain in case of
>> emergency, court orders or kneecaps.
>> 
>> According to the presentation held at ICANN60
> 
> Well, if someone at ICANN said so, someone is wrong (or, at the
> minimum, over-simplificator).
> 
> ___
> 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-wkumari-dnsop-internal and DNAME

[Stephane Bortzmeyer]

On Fri, Nov 10, 2017 at 08:53:06AM -0500,
 Matt Larson  wrote 
 a message of 32 lines which said:

> I'll note that from a technical/mechanical perspective, ICANN's and
> Verisign's root zone management systems already know how to deal
> with delegations. A DNAME in the root would require an unknown level
> of development by both parties.

I've never read the source code of the root zone management system,
but it seems surprising that it could be a non-trivial level of
development. I assume this system is complicated because it is highly
sensitive, and because it needs to incorporate a lot of defenses
against both mistakes and attacks, but they should be more or less the
same for DNAME and NS/A/, no?

> Adding new types of information to the root is certainly possible:
> I'm not trying to discourage that. But for planning and
> expectation-setting purposes, the community needs to take into
> account the long lead time that will be required for anything that
> requires technical modifications to the root zone management system.

Wild guess (and I pay beers if I'm wrong): the technical work will
take much less time than the process one.

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

Re: [DNSOP] Agenda for IETF100

[Stephane Bortzmeyer]

On Fri, Nov 10, 2017 at 05:58:13PM +0530,
 Paul Wouters  wrote 
 a message of 29 lines which said:

> It takes 4 out of 7 geeks to bypass the blockchain in case of
> emergency, court orders or kneecaps.
> 
> According to the presentation held at ICANN60

Well, if someone at ICANN said so, someone is wrong (or, at the
minimum, over-simplificator).

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

Re: [DNSOP] draft-wkumari-dnsop-internal and DNAME

[Matt Larson]

> On Nov 10, 2017, at 7:12 AM, Stephane Bortzmeyer  wrote:
> 
> draft-wkumari-dnsop-internal-00 says "This document requests that the
> .internal TLD be assigned to the IANA (similar to the way that
> .example is) and a DNSSEC insecure delegation (that is, a delegation
> with no DS records) be inserted into the root-zone, delegated to
> blackhole-[12].iana.org."
> 
> This implies NS records in the root. Why not using the DNAMEs of RFC
> 7535 instead? I understand there is currently no ICANN process to add
> DNAME in the root zone but there is no process to add .internal
> either.

Without commenting on the contents of that particular draft, I'll note that 
from a technical/mechanical perspective, ICANN's and Verisign's root zone 
management systems already know how to deal with delegations. A DNAME in the 
root would require an unknown level of development by both parties.

While you're correct about no existing process (that I'm aware of) to add 
either .internal or a DNAME to the root, at least with a delegation there is 
only process work, not technical work, as well.

Adding new types of information to the root is certainly possible: I'm not 
trying to discourage that. But for planning and expectation-setting purposes, 
the community needs to take into account the long lead time that will be 
required for anything that requires technical modifications to the root zone 
management system.

Matt

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

Re: [DNSOP] Agenda for IETF100

[Stephane Bortzmeyer]

On Fri, Nov 03, 2017 at 11:07:54PM -0400,
 tjw ietf  wrote 
 a message of 202 lines which said:

> As you can see, we have time for our Monday Morning slot of 2.5 hours.
> Because of this, we're currently planning on giving back the Thursday
> meeting slot.

Any news on that? The monday session collides with DIN which is really
unfortunate for me because they talk a lot about name resolution
(Namecoin, Ethereum Name Service). I may face a hard choice.

(And thursday collides with CBOR, which is a smaller problem for me.)

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

[DNSOP] draft-wkumari-dnsop-internal and DNAME

[Stephane Bortzmeyer]

draft-wkumari-dnsop-internal-00 says "This document requests that the
.internal TLD be assigned to the IANA (similar to the way that
.example is) and a DNSSEC insecure delegation (that is, a delegation
with no DS records) be inserted into the root-zone, delegated to
blackhole-[12].iana.org."

This implies NS records in the root. Why not using the DNAMEs of RFC
7535 instead? I understand there is currently no ICANN process to add
DNAME in the root zone but there is no process to add .internal
either.

(draft-bortzmeyer-dname-root may be relevant here.)

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