[DNSOP] Re: Possible breaking inconsistencies in draft-ietf-dnsop-rfc8624-bis-01

[Steve Crocker]

Paul,

You wrote, "You cannot use two algorithms to sign or delegate at the same
time."  If there are two or more independent signers for a zone -- see RFC
8901 -- then multiple algorithms might be in use at the same time.

I think there is some wording that says the algorithms must be the same, I
believe there is an effort to remove that restriction.  If there are
multiple signers, each of them will likely change the algorithm it uses, so
it's necessary to permit the concurrent use of distinct algorithms.

With respect to MUST, etc., I'm not a big fan of these designations in this
context, but the terms are deeply embedded in the RFC culture and
impossible to avoid.  That said, both 8624-bis and our lifecycle document
anticipate there may be multiple acceptable algorithms to use at any one
time.  Indeed, in order to support transitions from one algorithm to
another, use of multiple algorithms concurrently is necessary.

I'll leave it to Wes or Warren, the co-authors of RFC 8624-bis, to respond
more fully.

Thanks,

Steve




On Sat, Oct 12, 2024 at 11:27 AM Paul Hoffman 
wrote:

> Earlier, Wes said "I believe the 8624bis document is functionally "done"
> and should be published." However, there has been too little discussion on
> what the new columns actually mean, and someone reading the new IANA
> registries would not know what to do.
>
> In specific, "Use for DNSSSEC Signing" and "Use for DNSSSEC Delegation" do
> not make sense if there is more than one "MUST" in that column. You cannot
> use two algorithms to sign or delegate at the same time.
>
> Table 2 is for "Domain Name System Security (DNSSEC) Algorithm Numbers".
> It reads in part:
>
> +==+===+===+===+===+===+
> |N |Mnemonics  |Use for|Use for|Implement  |Implement  |
> |  |   |DNSSEC |DNSSEC |for DNSSEC |for DNSSEC |
> |  |   |Signing|Validation |Signing|Validation |
> +==+===+===+===+===+===+
> +--+---+---+---+---+---+
> |8 |RSASHA256  |MUST   |MUST   |MUST   |MUST   |
> +--+---+---+---+---+---+
> |10|RSASHA512  |NOT|MUST   |NOT|MUST   |
> |  |   |RECOMMENDED|   |RECOMMENDED|   |
> +--+---+---+---+---+---+
> |13|ECDSAP256SHA256|MUST   |MUST   |MUST   |MUST   |
> +--+---+---+---+---+---+
> |14|ECDSAP384SHA384|MAY|RECOMMENDED|MAY|RECOMMENDED|
> +--+---+---+---+---+---+
> |15|ED25519|RECOMMENDED|RECOMMENDED|RECOMMENDED|RECOMMENDED|
> +--+---+---+---+---+---+
> |16|ED448  |MAY|RECOMMENDED|MAY|RECOMMENDED|
> +--+---+---+---+---+---+
>
> How can both 8 and 13 be "MUST use for signing" at the same time?
>
> How can 14 and 16 be "MAY use for signing" if there are other values that
> MUST be used instead?
>
> Is 15 more recommended than 14 and 16 even though 14 and 16 are currently
> obviously stronger?
>
> Without more description of what the new columns mean, a reader of the
> IANA registry will have no idea what to use when choosing a signing
> algorithm. The same is true for the new column in the DS table. Either
> there has to be definitions of the terms above the new tables at IANA, or a
> pointer to a concise description of the terms in an RFC, such as in a short
> appendix in this draft. However, I still don't see how defining these terms
> using the normal use of MUST in the IETF would make sense for this new
> column.
>
> --Paul Hoffman
>
> ___
> DNSOP mailing list -- dnsop@ietf.org
> To unsubscribe send an email to dnsop-le...@ietf.org
>


-- 
Sent by a Verified
[image: Sent by a Verified sender]

sender
___
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org

[DNSOP] Re: draft-crocker-dnsop-dnssec-algorithm-lifecycle-01

[Steve Crocker]

Thanks for your comments.  Regarding the lack of mention of the Red Hat
incident, it seemed to me that an RFC proposing an organized way to manage
the lifecycle of algorithms should not include mention of a particular
incident.  If someone feels it's necessary to document the triggering
event, perhaps there's another way to do so.

Regarding national algorithms, I don't see any restriction.  They can be
given IANA identifiers, and they can move through the lifecycle phases.
The life cycle model does NOT require selecting which algorithms are
advanced through the cycle.

Steve

On Sun, Oct 6, 2024 at 12:24 PM S Moonesamy  wrote:

> Hi Steve,
> At 11:31 AM 05-10-2024, Steve Crocker wrote:
> >Thanks for your comments.  This submission was triggered by the Red
> >Hat snafu.  Red Hat removed an algorithm from the library when they
> >determined it should not be used.  However, as their users
> >discovered quickly, messages signed with that algorithm continued to
> >arrive, with consequent disruption of their operation.
> >
> >It seemed obvious to me that removal of an algorithm from services
> >should be done carefully.  Validation should continue to be
> >available long after the new signing is quenched.
> >
> >I assumed there would be fairly explicit advice along this line
> >somewhere in the RFCs.  RFC 8624 gave the status of various
> >algorithms, but it did advise how to introduce and how to remove an
> >algorithm in coordination with other algorithms.
>
> One of the good things that came out of the IAB was BCP 201 (authored
> by one of the co-authors of
> draft-crocker-dnsop-dnssec-algorithm-lifecycle-01).  There is a part
> in it which I am not that enthusiastic about.
>
> I did not understand the rationale for
> draft-crocker-dnsop-dnssec-algorithm-lifecycle-01 as that document is
> silent about the RedHat confusion (re. Section 1).  There is a
> message at
>
> https://mailarchive.ietf.org/arch/msg/tools-discuss/kvqXZ8-NXTuwPTzIVtL4rjxNoL8/
> which, in my opinion, explains the ietf.org angle.
>
> One of the potential issues would be national algorithms.  It might
> be somewhat awkward to not approve a request for inclusion in the
> "protocol parameters" registry.  It might also be somewhat awkward to
> push for a phased approach (please see Section 3.1 of RFC 8624).
>
> Regards,
> S. Moonesamy
>
>

-- 
Sent by a Verified
[image: Sent by a Verified sender]
<https://wallet.unumid.co/authenticate?referralCode=tcp16fM4W47y>
sender
___
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org

[DNSOP] Re: DNSOPDNSOPdraft-crocker-dnsop-dnssec-algorithm-lifecycle-01

[Steve Crocker]

As I said in my immediately previous email, thanks for the support and I'm
in complete agreement.

Steve


On Fri, Oct 11, 2024 at 6:22 PM Wes Hardaker  wrote:

> Wes Hardaker  writes:
>
> > I believe we must allow for this possibility in the 4 columns even
> > when we may wish it won't be used.
>
> Following myself, because I forgot my ending opinion:
>
> 1. I think that the current 8624bis document should not be combined with
> the phasing document, for the reasons I laid out.  I believe the 8624bis
> document is functionally "done" and should be published.
>
> 2. I think the WG should consider adopting the phasing document, and
> that document should make use of the columns from 8624bis (it already
> does this).  Thus, 8624bis is a base for the phasing document.
>
> --
> Wes Hardaker
> USC/ISI
>
> ___
> DNSOP mailing list -- dnsop@ietf.org
> To unsubscribe send an email to dnsop-le...@ietf.org
>


-- 
Sent by a Verified
[image: Sent by a Verified sender]

sender
___
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org

[DNSOP] Re: DNSOPdraft-crocker-dnsop-dnssec-algorithm-lifecycle-01

[Steve Crocker]

Wes,

Thanks for your comments and support.  I'm in complete agreement.  See
inline for an additional comment.

Steve


On Fri, Oct 11, 2024 at 6:16 PM Wes Hardaker  wrote:

> Tim Wicinski  writes:
>
> > I do believe the 8624bis authors and the WG are open to updating
> the values for the table
> >
> https://www.iana.org/assignments/dns-sec-alg-numbers/dns-sec-alg-numbers.xhtml
>
> So, yes and no.
>
> Steve, Russ, Warren and I had a long conversation about this (actually
> multiple: at least one in a verbal discussion and a bunch more over
> email).
>
> My stance is that we are solving two different problems with the two
> documents, and that they should not be combined.
>
> 1. Problem one: moving the existing registry components into the IANA
> table, and this allows for the encoding of any set of values for
> recommendations.  This includes the possibility of encoding values sets
> that are entirely different than what the phasing document prescribes.
> In other words, I do not think that the phases MUST be the only way to
> encode recommendations and that the 4 new recommendation columns in
> RFC8624bis should be a super-set of the (currently) perceived best path
> through a deployment life cycle.  Furthermore, I think the IANA table
> should be capable of storing multiple phasing life-cycles if someone
> else comes up with an alternative set of values to stick into the
> 8624bis defined columns.
>
> 2. draft-crocker-dnsop-dnssec-algorithm-lifecycle is proposing a
> solution to a different, but related, problem: as an algorithm
> progresses through a life-cycle what should the ideal values be for each
> of the 4 columns in 8624bis for a given point in time?  This seems
> highly useful if we can come to agreement on that progression.
>
> I do think that weird corner cases may even suddenly require different
> states to exist besides the ideal phasing considered in the
> algorithm-lifecycle document.  Consider the case when an algorithm is
> fully deployed and actively in use for "phase 4" (MUST MUST MUST
> RECOMMEND).  What if that algorithm is (very) suddenly very
> cryptographically weakened?  I'd argue that jumping straight to phase 7
> would be problematic.  Certainly the "Use" columns should immediately go
> to MUST NOT, but I'm not so sure about the Implementation columns -- I
> think there is a transition period where that algorithm must be still be
> implemented because the world can't transition over night.
>

It will be interesting to see how many times, if ever, sudden transitions
are required.  I think a jump from 4-Mainstream to 6-Deprecated would
probably be the right step.  Moving immediately to 7-Obsolete causes the
problem that triggered the creation of this lifecycle documentation.

In prior discussions and presentations, I also suggested an algorithm might
move from 3-Available to either 5-Phaseout or 6-Deprecated if it is
determined that the algorithm is weaker or less suitable than had been
expected.

>
> I also think that the 8624bis table should support cases where the
> community has some other random exception for the current state of
> affairs of something.  Hopefully this is rare, or even "almost never".
> But I note that we're already in that state: the values that are in
> 8624bis are functionally taken from the past without modification (at
> least until the gost/sha1 documents are also published to change the
> values).  Thus, the current RSASHA512 values that we have defined today
> (NOT RECOMMENCED/MUST/NOT RECOMMENDED/MUST) do not even map to a phasing
> value set in the algorithm-lifecycle document.  I believe we must
> allow for this possibility in the 4 columns even when we may wish it
> won't be used.
>
> The downside of my thinking?  You can absolutely come up with completely
> useless combination sets (MUST NOT implement, and MUST use).  But by
> requiring a standards action to change the values, it's up to the IETF
> consensus process to ensure we don't make such crazy decisions like that.
>

It will take several years -- or decades -- before there is enough
experience to see whether there are useful combinations that are not
consistent with the lifecycle model.  Perhaps this will be both fun and
useful for someone's master's thesis in 15 to 20 years.

Steve

sender
___
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org

[DNSOP] Re: draft-crocker-dnsop-dnssec-algorithm-lifecycle-01

[Steve Crocker]

but it did NOT advise how to introduce and how to remove an algorithm in
coordination with other algorithms.

On Sat, Oct 5, 2024 at 2:31 PM Steve Crocker  wrote:

> Paul and Tim,
>
> Thanks for your comments.  This submission was triggered by the Red Hat
> snafu.  Red Hat removed an algorithm from the library when they
> determined it should not be used.  However, as their users discovered
> quickly, messages signed with that algorithm continued to arrive, with
> consequent disruption of their operation.
>
> It seemed obvious to me that removal of an algorithm from services should
> be done carefully.  Validation should continue to be available long after
> the new signing is quenched.
>
> I assumed there would be fairly explicit advice along this line somewhere
> in the RFCs.  RFC 8624 gave the status of various algorithms, but it did
> advise how to introduce and how to remove an algorithm in coordination with
> other algorithms.
>
> I thought about it afresh and described the seven phases.  I then sought
> help/comment/etc from Russ Housley.  Meanwhile, Wes Hardaker and Warren
> Kumari were working on RFC 8624-bis.  We had some substantive and civilized
> exchange.  At the risk of speaking for them, I understand they want to have
> a way to record the current status of an algorithm, and they wanted to
> distinguish implementation vs use for both signing and validation.  In our
> judgment, this is fine but doesn't tell those operators looking for
> operational advice re the steps are in a lifecycle.  In the Red Hat
> situation, they skipped from phase 5 to phase 7 without spending time in
> phase 6.
>
> Regarding the number of RFCs needed to step each algorithm through its
> phases, this feels to me the wrong issue to focus on.  The criteria and
> decision process to move from one phase to the next are substantive.  I'm
> agnostic regarding whether each phase change requires a fresh RFC or some
> other process involving expert advice that updates the tables.  In any
> case, we're talking about six transitions over the life of the algorithm.
> Algorithm lifetimes are on the order of twenty years, and we're likely only
> dealing with a half dozen algorithms or so.
>
> Returning to the main point, it seems to me there should be crisp,
> credible advice to operators altering them that multiple steps are required
> to properly phase in and phase out an algorithm.
>
> Thanks,
>
> Steve
>
>
> On Sat, Oct 5, 2024 at 2:07 PM Tim Wicinski  wrote:
>
>>
>> As an operator, I feel the implementers should have a strong say in
>> this.  They have business decisions based on what customers wish to have
>> supported, and while they can guide customers, they need to think of the
>> long tail.
>> (I worked for a software company that supported Internet Explorer 6 into
>> the 2010s, because of large contracts).
>>
>>
>> As a chair, the current draft appears to require seven RFCs for the
>> lifecycle of an algorithm.
>> I agree with Paul W that the WG should spend their time on other
>> documents, but am happy to be proven wrong.
>>
>> I do believe the 8624bis authors and the WG are open to updating
>> the values for the table
>>
>> https://www.iana.org/assignments/dns-sec-alg-numbers/dns-sec-alg-numbers.xhtml
>>
>> that seems like a starting point
>>
>> tim
>>
>>
>> On Fri, Oct 4, 2024 at 10:40 PM Paul Wouters  wrote:
>>
>>>
>>> >
>>> > On Oct 4, 2024, at 15:28, Russ Housley  wrote:
>>> >
>>> > This document is related to draft-ietf-dnsop-rfc8624-bis.  We ask the
>>> DSNOP WG to adopt it.
>>>
>>> The document seems like a theoretical ideal of an algorithm life cycle.
>>> There have been many kind of considerations in play that have determined
>>> the algorithm and key sizes of algorithms. There have been good strong
>>> discussions in many venues inside and outside IETF. I don’t think this
>>> document would add any value to those discussions, such as those happening
>>> recently on RFC8624bis or the sha1 deprecation documents.
>>>
>>> I would rather see the WG spend their time on other documents.
>>>
>>> Paul
>>> ___
>>> DNSOP mailing list -- dnsop@ietf.org
>>> To unsubscribe send an email to dnsop-le...@ietf.org
>>>
>> ___
>> DNSOP mailing list -- dnsop@ietf.org
>> To unsubscribe send an email to dnsop-le...@ietf.org
>>
>
>
> --
> Sent by a Verified
> [image: Sent by a Verified sender]
> <https://wallet.unumid.co/authenticate?referralCode=tcp16fM4W47y>
> sender
>


-- 
Sent by a Verified
[image: Sent by a Verified sender]
<https://wallet.unumid.co/authenticate?referralCode=tcp16fM4W47y>
sender
___
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org

[DNSOP] Re: draft-crocker-dnsop-dnssec-algorithm-lifecycle-01

[Steve Crocker]

Paul and Tim,

Thanks for your comments.  This submission was triggered by the Red Hat
snafu.  Red Hat removed an algorithm from the library when they
determined it should not be used.  However, as their users discovered
quickly, messages signed with that algorithm continued to arrive, with
consequent disruption of their operation.

It seemed obvious to me that removal of an algorithm from services should
be done carefully.  Validation should continue to be available long after
the new signing is quenched.

I assumed there would be fairly explicit advice along this line somewhere
in the RFCs.  RFC 8624 gave the status of various algorithms, but it did
advise how to introduce and how to remove an algorithm in coordination with
other algorithms.

I thought about it afresh and described the seven phases.  I then sought
help/comment/etc from Russ Housley.  Meanwhile, Wes Hardaker and Warren
Kumari were working on RFC 8624-bis.  We had some substantive and civilized
exchange.  At the risk of speaking for them, I understand they want to have
a way to record the current status of an algorithm, and they wanted to
distinguish implementation vs use for both signing and validation.  In our
judgment, this is fine but doesn't tell those operators looking for
operational advice re the steps are in a lifecycle.  In the Red Hat
situation, they skipped from phase 5 to phase 7 without spending time in
phase 6.

Regarding the number of RFCs needed to step each algorithm through its
phases, this feels to me the wrong issue to focus on.  The criteria and
decision process to move from one phase to the next are substantive.  I'm
agnostic regarding whether each phase change requires a fresh RFC or some
other process involving expert advice that updates the tables.  In any
case, we're talking about six transitions over the life of the algorithm.
Algorithm lifetimes are on the order of twenty years, and we're likely only
dealing with a half dozen algorithms or so.

Returning to the main point, it seems to me there should be crisp, credible
advice to operators altering them that multiple steps are required to
properly phase in and phase out an algorithm.

Thanks,

Steve


On Sat, Oct 5, 2024 at 2:07 PM Tim Wicinski  wrote:

>
> As an operator, I feel the implementers should have a strong say in this.
> They have business decisions based on what customers wish to have
> supported, and while they can guide customers, they need to think of the
> long tail.
> (I worked for a software company that supported Internet Explorer 6 into
> the 2010s, because of large contracts).
>
>
> As a chair, the current draft appears to require seven RFCs for the
> lifecycle of an algorithm.
> I agree with Paul W that the WG should spend their time on other
> documents, but am happy to be proven wrong.
>
> I do believe the 8624bis authors and the WG are open to updating
> the values for the table
>
> https://www.iana.org/assignments/dns-sec-alg-numbers/dns-sec-alg-numbers.xhtml
>
> that seems like a starting point
>
> tim
>
>
> On Fri, Oct 4, 2024 at 10:40 PM Paul Wouters  wrote:
>
>>
>> >
>> > On Oct 4, 2024, at 15:28, Russ Housley  wrote:
>> >
>> > This document is related to draft-ietf-dnsop-rfc8624-bis.  We ask the
>> DSNOP WG to adopt it.
>>
>> The document seems like a theoretical ideal of an algorithm life cycle.
>> There have been many kind of considerations in play that have determined
>> the algorithm and key sizes of algorithms. There have been good strong
>> discussions in many venues inside and outside IETF. I don’t think this
>> document would add any value to those discussions, such as those happening
>> recently on RFC8624bis or the sha1 deprecation documents.
>>
>> I would rather see the WG spend their time on other documents.
>>
>> Paul
>> ___
>> DNSOP mailing list -- dnsop@ietf.org
>> To unsubscribe send an email to dnsop-le...@ietf.org
>>
> ___
> DNSOP mailing list -- dnsop@ietf.org
> To unsubscribe send an email to dnsop-le...@ietf.org
>


-- 
Sent by a Verified
[image: Sent by a Verified sender]

sender
___
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org

[DNSOP]Further comment re algorithm life cycles

[Steve Crocker]

Under the heading of saying what might be obvious but needs to said anyway,
there should always be at least one mainstream (phase 4) algorithm in use.
When an algorithm is moved to phaseout (phase 5), there should already be
one or more other mainstream algorithms in use.

On Sun, May 19, 2024 at 1:11 PM Steve Crocker  wrote:

> Warren, Wes, et al,
>
> TL;DR: Yes and No.
>
> Yes: Thanks for the initiative to move this into an IANA Registry.  This
> is the right idea, and what I've been advocating for the past many months.
>
> No: I don't think the scheme is quite right.
>
> In my view, an algorithm moves through seven phases during its lifecycle.
>
> 1. Experimental – defined and included in the IANA registry
> 2. Adopted – begin inclusion in validation suite
> 3. Available – ok to use for signing
> 4. Mainstream – recommended for signing
> 5. Phaseout  – transition to newer signing algorithm
> 6. Deprecated  – signing should have stopped
> 7. Obsolete  – ok to remove from validation suite
>
> Each transition from one phase to another should be controlled by an
> expert group that advises IANA.  (In some cases, an algorithm might be
> deprecated before reaching the "Mainstream" stage.)
>
> When I try to reconcile the above with 8624 bis-03, there are some rough
> edges.  The table below represents my view of the preferred words to use in
> Table 2 in 8624 bis-03
>
> PhaseSigning   ValidationAlgorithms
>   1  Must Not  May
>   2  Must Not  Must
>   3  May   Must  (8) RSASHA256, (13)
> ECDSAP256SHA256
>   4  Recommended   Must  (15) ED25519
>   5  Not Recommended   Must  (5) RSASHA1, (7)
> RSASHA1-NSEC3-SHA1, (10) RSASHA512
>   6  Must Not  Must  (12) ECC-GOST
>   7  Must Not  Must Not  (1) RSAMD5, (3) DSA, (6)
> DSA-NSEC3-SHA1
>
> I'm not sure where to place algorithms (14) ECDSAP384SHA384 and (16) ED448.
> They're marked as MAY/RECOMMENDED in 8624 bis-03, and I assume they're in
> the early part of their life cycles, so I'm inclined to put them in phase
> 3, but I don't see how to distinguish their status from (8) RSASHA256,
> (13) ECDSAP256SHA256.  Or perhaps these are in phase 5, which leads to the
> question of how to distinguish them from the ones listed in phase 5.
>
> Implementers and purveyors of crypto suites should treat May, Recommended
> and Not Recommended as equivalent to Must.  The distinctions among these
> terms are intended for usage of these algorithms, not the implementation of
> the crypto suite.
>
> Comment: In the recent Red Hat snafu, I heard a comment that it was not
> possible to disable use of an algorithm for signing without also disabling
> the algorithm for validation.  Hence, when Red Hat wanted to shut off use
> of an algorithm for signing, it removed it from the crypto suite and thus
> disabled validation.  While it's understable that a straightforward
> implementation of a crypto suite might provide the same path to an
> algorithm irrespective of whether it will be used for signing or
> validation, it is possible provide distinct paths for these two uses and
> thereby permit validation but not signing during phases 2 and 6 at the
> beginning and end of the algorithm's life cycle.
>
> Thanks,
>
> Steve
>
>
>
>
>
>
>
> On Tue, May 14, 2024 at 4:58 PM Warren Kumari  wrote:
>
>> 
>> Hello everybody,
>>
>> Firstly thank you for all of the discussion on these documents - we
>> really appreciate the review and feedback.
>>
>> We’ve read all of the discussion(s) and will be updating the documents to
>> address your comments, based on our understanding of the group’s consensus
>> so far. While reviewing the discussion, we came to the realization that
>> there are two potential paths forward for draft-hardaker-dnsop-rfc8624-bis,
>> and we would like your opinion on which choice everyone feels is best.
>>
>> As evidenced by the discussions, implementations can’t realistically
>> remove the Foo algorithm if many of their customers are still using it. So:
>>
>> Option 1: Pivot this document from providing implementers with guidance
>> (“Implementers MUST NOT use Foo for signing”) to providing guidance to
>> operators instead (“Operators MUST NOT use Foo for signing”).
>>
>> Or
>>
>> Option 2: Focus on removing algorithm usage first, by informing operators
>> to stop using an algorithm to be deprecated, and then, later, specify that
>> implementers may/should/must stop supporting the algorithm.
>>
>> We 

[DNSOP]Re: Our reading of consensus on draft-hardaker-dnsop-rfc8624-bis, and the "must-not-algorithm" docs.

[Steve Crocker]

Warren, Wes, et al,

TL;DR: Yes and No.

Yes: Thanks for the initiative to move this into an IANA Registry.  This is
the right idea, and what I've been advocating for the past many months.

No: I don't think the scheme is quite right.

In my view, an algorithm moves through seven phases during its lifecycle.

1. Experimental – defined and included in the IANA registry
2. Adopted – begin inclusion in validation suite
3. Available – ok to use for signing
4. Mainstream – recommended for signing
5. Phaseout  – transition to newer signing algorithm
6. Deprecated  – signing should have stopped
7. Obsolete  – ok to remove from validation suite

Each transition from one phase to another should be controlled by an expert
group that advises IANA.  (In some cases, an algorithm might be
deprecated before reaching the "Mainstream" stage.)

When I try to reconcile the above with 8624 bis-03, there are some rough
edges.  The table below represents my view of the preferred words to use in
Table 2 in 8624 bis-03

PhaseSigning   ValidationAlgorithms
  1  Must Not  May
  2  Must Not  Must
  3  May   Must  (8) RSASHA256, (13)
ECDSAP256SHA256
  4  Recommended   Must  (15) ED25519
  5  Not Recommended   Must  (5) RSASHA1, (7)
RSASHA1-NSEC3-SHA1, (10) RSASHA512
  6  Must Not  Must  (12) ECC-GOST
  7  Must Not  Must Not  (1) RSAMD5, (3) DSA, (6)
DSA-NSEC3-SHA1

I'm not sure where to place algorithms (14) ECDSAP384SHA384 and (16) ED448.
They're marked as MAY/RECOMMENDED in 8624 bis-03, and I assume they're in
the early part of their life cycles, so I'm inclined to put them in phase
3, but I don't see how to distinguish their status from (8) RSASHA256, (13)
ECDSAP256SHA256.  Or perhaps these are in phase 5, which leads to the
question of how to distinguish them from the ones listed in phase 5.

Implementers and purveyors of crypto suites should treat May, Recommended
and Not Recommended as equivalent to Must.  The distinctions among these
terms are intended for usage of these algorithms, not the implementation of
the crypto suite.

Comment: In the recent Red Hat snafu, I heard a comment that it was not
possible to disable use of an algorithm for signing without also disabling
the algorithm for validation.  Hence, when Red Hat wanted to shut off use
of an algorithm for signing, it removed it from the crypto suite and thus
disabled validation.  While it's understable that a straightforward
implementation of a crypto suite might provide the same path to an
algorithm irrespective of whether it will be used for signing or
validation, it is possible provide distinct paths for these two uses and
thereby permit validation but not signing during phases 2 and 6 at the
beginning and end of the algorithm's life cycle.

Thanks,

Steve







On Tue, May 14, 2024 at 4:58 PM Warren Kumari  wrote:

> 
> Hello everybody,
>
> Firstly thank you for all of the discussion on these documents - we really
> appreciate the review and feedback.
>
> We’ve read all of the discussion(s) and will be updating the documents to
> address your comments, based on our understanding of the group’s consensus
> so far. While reviewing the discussion, we came to the realization that
> there are two potential paths forward for draft-hardaker-dnsop-rfc8624-bis,
> and we would like your opinion on which choice everyone feels is best.
>
> As evidenced by the discussions, implementations can’t realistically
> remove the Foo algorithm if many of their customers are still using it. So:
>
> Option 1: Pivot this document from providing implementers with guidance
> (“Implementers MUST NOT use Foo for signing”) to providing guidance to
> operators instead (“Operators MUST NOT use Foo for signing”).
>
> Or
>
> Option 2: Focus on removing algorithm usage first, by informing operators
> to stop using an algorithm to be deprecated, and then, later, specify that
> implementers may/should/must stop supporting the algorithm.
>
> We think Option 2 makes much more sense, as this provides both
> “operational guidance” and “implementation guidance.”  With such, we can
> leave implementations interoperable while slowly decreasing algorithm
> deployment until it is safe to actually remove implementation support once
> perceived usage has decreased. If we were to provide guidance to either
> implementers or operators -- but not both --  then we leave one side
> questioning their purpose in life.
>
> This means that we should actually have a column per type (i.e “Operators”
> and “Implementers”) crossed with a column per DNSSEC usage type (“Signing”
> and “Validation”), such that for the “Domain Name System Security (DNSSEC)
> Algorithm Numbers” table we would be adding FOUR columns:
>
>-
>
>“Use for DNSSEC Signing”
>-
>
>“Use for DNSSEC Validation”
>-
>
>“Implement for DNSSEC Signing”
>-
>
>“Implement for DNSSEC Va

[DNSOP] Looking for panelists for DNSSEC provisioning session at Cancún ICANN meeting in March

[Steve Crocker]

Folks,


I am organizing a panel session within the DNSSEC Workshop during
the upcoming ICANN meeting in Cancún in March on the subject of DNSSEC
provisioning.  There are two related but somewhat distinct topics.  One is
the update of the DS record when the DNS provider rolls the key.  The other
is how multiple DNS providers coordinate when each is signing the zone.
Various proposals exist to solve each of these problems, but none has been
fully accepted, and each suffers from a gap in the provisioning process.


Depending on who is on the panel and we can cover either both topics or
just the first topic.  I also intend to organize a session on these topics
in Paris in May at the ICANN Global Domains Division Summitt and/or the DNS
Symposium.  Also, the dnssec-provision...@shinkuro.com mailing list is
specific devoted to these two topics.


Please let me know if you're interested in participating and if you have a
position on how to address these problems.


*Details*


What is the path forward for automating solutions to these two provisioning
problems?  Are new protocols needed?  What changes are required of
registrars, DNS providers and/or registries?



With respect to updating DS records, the solution space is basically a two
by two matrix, with a subordinate third dimension:

   - Are new DS records pushed upward, i.e. is the transmission initiated
   by the DNS provider, or are new DS records pulled upward by the registry or
   registrar?

   - Is the registry or the registrar involved on the upper end of the
   transmission?


The subordinate third dimension is whether the KSK, DS or both are
communicated.


The solution in RFC 8078 is the pull/registry solution with support for
both KSK and DS.  It was developed by a couple of DNS providers and is on
the IETF standards track, but, so far as I can tell, is being adopted by a
relatively few ccTLDs and is not gaining any traction within the gTLD
community.  In contrast, GoDaddy has suggested its Domain Connect software
could be extended to allow a push/registrar solution for DS updates.



With respect to coordination among multiple DNS providers, Shumon Huque, et
al's Internet-Draft
https://tools.ietf.org/html/draft-ietf-dnsop-multi-provider-dnssec-01
[tools.ietf.org]
<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Ddnsop-2Dmulti-2Dprovider-2Ddnssec-2D01&d=DwMFaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=_qSa12UaM5Nl6sbpmBZnYyeUu-qJt2ubgQJechcqldM&m=zQDYr_jJSOyuDOEF5tU7f-JhexPBRkY5Clkb6Rn9m3s&s=eH4Q6Yxg9dNg2IRqEmEWewca-7dYhKmHKbAZyCP7yHg&e=>
sets
for a scheme for multiple DNS providers to coordinate cross-signing of the
same zone when it's served from multiple providers.



I have both a general and a specific interest in this.  The general
interest is in seeing some sort of solution be adopted in order to
facilitate smoother operation and greater adoption of DNSSEC.  My specific
interest is a guess that if the registrant could add the names of his DNS
providers into the registration details, it would make both of these
coordination processes much easier.


Thanks,


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

Re: [DNSOP] AD review of draft-ietf-dnsop-multi-provider-dnssec

[Steve Crocker]

Shumon,

You're asking the right questions:

This also begs the question: should we (in another document) update RFC
4035, Section 2 (last paragraph) to relax or eliminate the rule, if in fact
it is being ignored?

Frankly, I've always been a bit perplexed by this text, since it has no
accompanying rationale. The only compelling rationale I see is downgrade
protection - to detect that someone hasn't stripped away the signatures of
a stronger algorithm and forced a validator to authenticate only the weaker
signatures. But that implies that validators have a documented procedure to
rank algorithms, which I haven't yet seen. Is a 3072-bit RSASHA256 key
stronger or weaker than an ECDSAP256SHA256 key for example, or Ed25519 vs
ECDSAP256SHA256?

On the face of it, absent a good counter argument, this does indeed seem
like an appropriate time to revise RFC 4035 as you suggest.  Strict
adherence to the rule would require a somewhat awkward multi-step process
for switching from a provider who only supports algorithm x to a provider
that supports -- or at least prefers -- algorithm y.  The transition would
first have to be to a provider that supports both x and y but is willing to
use just x.  After the transition, the new provider would then introduce
algorithm y, and then would eliminate algorithm x.  This seems like an
unnecessary and lengthy sequence.

Thanks,

Steve


On Tue, Jan 21, 2020 at 10:06 AM Shumon Huque  wrote:

> Hi Matthijs,
>
> Sorry, I did miss your original note on this point. Now that I've seen it,
> I'm copying back dnsop@ietf.org to see if there are other comments on
> your proposal.
>
> When the Algorithm Considerations section was originally written, I
> intentionally did not prohibit the use of multiple algorithms across
> providers (even though we recommended against it) for a very
> pragmatic reason: I was actually working with 2 DNS providers that
> supported disjoint algorithms (one RSASHA256 and the other ECDSAP256), and
> was seriously contemplating deploying such a multi-signer configuration in
> production. It would be a bit strange to deploy a configuration on the one
> hand, and at the same time write a document that explicitly forbid that
> configuration.
>
> You mention that authoritative servers cannot simply ignore the rule that
> they must sign all RRsets in the zone with every algorithm in the DNSKEY
> RRset. However, in practice it is clearly being ignored. Neither .SE or .BR
> double signed their zone data during their algorithm rollovers and there
> are other cases.
>
> As it turns out, the provider that only supported RSASHA256 exited the
> managed DNS provider business, and the only vendors we are working with
> currently all support our preferred algorithm (ECDSAP256) in common. Hence,
> I am now open to updating the document to prohibit it. But will such text
> cause aggravation for other potential deployers that may run into a similar
> situation with other providers, and do we care?
>
> This also begs the question: should we (in another document) update RFC
> 4035, Section 2 (last paragraph) to relax or eliminate the rule, if in fact
> it is being ignored?
>
> Frankly, I've always been a bit perplexed by this text, since it has no
> accompanying rationale. The only compelling rationale I see is downgrade
> protection - to detect that someone hasn't stripped away the signatures of
> a stronger algorithm and forced a validator to authenticate only the weaker
> signatures. But that implies that validators have a documented procedure to
> rank algorithms, which I haven't yet seen. Is a 3072-bit RSASHA256 key
> stronger or weaker than an ECDSAP256SHA256 key for example, or Ed25519 vs
> ECDSAP256SHA256?
>
> Shumon.
>
> On Tue, Jan 21, 2020 at 3:59 AM Matthijs Mekking 
> wrote:
>
>> Hi Shumon,
>>
>> On 1/20/20 9:21 PM, Shumon Huque wrote:
>> > 4: The document uses one inceanse of RFC2119 language (RECOMMENDED)
>> -
>> > please either drop this, or add the 2119 / 8174 boilerplate.
>> >
>> >
>> > Ok, I'm inclined to lowercase it, since we don't use 2119/8174 keywords
>> > anywhere else in this document.
>>
>> Did you see my mail related to this? If you are going with the lowercase
>> approach, please use the word "must" instead of "should".
>>
>> Best regards,
>>
>> Matthijs
>>
>>
>>  Forwarded Message 
>> Subject: Re: [DNSOP] Working Group Last Call for
>> draft-ietf-dnsop-multi-provider-dnssec
>> Date: Mon, 13 Jan 2020 09:57:50 +0100
>> From: Matthijs Mekking 
>> To: dnsop@ietf.org
>>
>> Late to the party, I am sorry.
>>
>> I am positive about this document, and support publication. I do have
>> one comment on the document, requesting an update.
>>
>> In section 4 it is said it is RECOMMENDED that providers use a common
>> signing algorithm.  I think this is too weak and it must be a MUST.
>>
>> The reason given for RECOMMENDED is that the "liberal approach" works.
>> The liberal approach says that authoritative zones MUST sign RRsets with
>> every 

[DNSOP] Fwd: Adding DNS providers to the registration

[Steve Crocker]

Folks,

I've started a new mailing list for discussion of how to facilitate both DS
updates and cross-signing of zones when there are multiple DNS providers.
My tastes run toward "push/registrar" solutions for DS updates, but it's
certainly possible to use pull instead of push and registry instead of
registrar.  RFC 8078 is a pull/registry solution.  I believe some ccTLDs
are using it, but I have not seen any traction within the gTLD community.

I'm hoping one or more concrete proposals emerge from the interactions on
this list.  If they do, they will be submitted through the usual channels
for adoption.  (Some aspects will likely be appropriate for the IETF;
others for ICANN or other bodies.)  This activity is therefore a design
team.

The new mailing list is dnssec-provision...@shinkuro.com  Comments are
welcome, as is membership on the list.

Thanks,

Steve


-- Forwarded message -
From: Steve Crocker 
Date: Sun, Jan 19, 2020 at 12:16 PM
Subject: Adding DNS providers to the registration
To: DNSSEC Provisioning 


I hereby propose that RDDS be extended to include the DNS provider(s).  I
believe that making DNS providers visible in the registration will make it
easier to automate both the upward movement of DS records to the registry
and coordination of cross-signing when there are multiple DNS providers.

DNS service is generally provided in one of three ways:

   - By the registrar.  This is probably the most common in terms of number
   of registrations, but not as common for larger registrants.
   - By the registrant as part of its internal operation.
   - By 3rd party DNS providers, e.g. Cloudflare, Dyn, et al.

Some registrants, particularly large registrants, will use multiple DNS
providers, so my proposal permits naming more than one DNS provider.

The intended functionality is for DNS providers to be able to push new DS
records upward whenever they roll the keys.  Accordingly, I'm expecting
that in addition to simply adding the name of the DNS provider to the
registration, the registrar will also have an access path for the DNS
provider to send it new DS records.  This leads to some design questions:

   1. How should DNS providers be designated?  The designation should be
   easy for the registrant to specify and not easily confused.

   2. The designation should serve as authorization for the DNS provider(s)
   to act on behalf of the registrant.

   3. In addition to updating the DS records, it  seems sensible to have
   the DNS provider specify the NS records as well.  What about glue records?

   4. Would DNS providers need to be qualified before being allowed to be
   included in the registration?  My quick thought is no because there are no
   barriers today in setting the NS records.

   5. Do we need a common naming scheme for DNS providers.  Perhaps
   something like _dns-provider. would do the job.

It also seems to me that whenever a DNS provider is added to or removed
from a registration, both it and any other DNS providers receive
notification.  This should trigger the appropriate coordination.  To take
the easiest case, here's a sequence for the registration with a single 3rd
party DNS provider.

   1. Registrant registers the domain name with the registrar.
   2. Registrant contracts with the DNS provider for DNS service and
   populates the child zone.
   3. Registrant tells adds the name of the DNS provider to the
   registration.
   4. Registrar's process sends a notice to the DNS provider that it has
   been named as a DNS provider for the registrant's domain.
   5. DNS provider tells the registrar the list of nameservers, the DS
   record and any other details that may be needed.

Comments?  Suggestions?  Problems?

Thanks,

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

Re: [DNSOP] On .ZZ

[Steve Crocker]

I too find myself puzzled about trying to assign ZZ for this role.  I
strongly prefer we stay far away from using two letter codes for anything
other than ISO 3166 assignment of country codes for ccTLDs.  (I even think
we made a mistake in allowing two letter codes in Cyrillic and
Greek.)  Postel's dictum of being conservative comes in here.  Even if
using ZZ is *supposed* to work according to the rules, it seems unnecessary
and a bit risky.

What's the attraction of using a two letter code instead of something
longer?  And speaking of longer, I think it ought to be four characters or
more to aid in stamping out the whatever remaining code still thinks top
level domains are only two or three characters.

Steve



On Fri, Nov 22, 2019 at 10:15 AM Bill Woodcock  wrote:

> Eberhard:
>
> The principle I’m trying to articulate is that our relationship to ISO
> 3166 is that of a standards body which has delegated to it.
>
> ISO 3166, in turn, specifies that this code is (for now, and at their
> authority) to be used by USERS for their purposes.
>
> It’s my assertion that it’s bad form for us, having placed ourselves in
> the standards body role on one side of ISO, to now also claim that we, the
> same people, are also  “users”  Standing on the other side of ISO.
>
> That seems to me to not be in the spirit of a good-faith delegation.
>
> If we want to start individually specifying the meaning or use of
> two-letter TLDs, it’s my assertion that We should first un-delegate that
> role from ISO, and take direct control of the task, not attempt to stand on
> both sides of them. And I think the harm of doing so would vastly outweigh
> any benefit. Therefore I think this shouldn’t be done. Either we delegate
> authority to them, or we don’t. No splitting the baby.
>
> -Bill
>
>
> > On Nov 22, 2019, at 02:17, Dr Eberhard W Lisse  wrote:
> >
> > Bill,
> >
> > ISO has new draft out as part of their regular maintenance cycle which
> > states
> >
> >[...]  In addition exactly 42 alpha-2 code elements are not used in
> >the ISO 3166, AA, QM to QZ, XA to XZ, ZZ. This rule may change in
> >the future.  [...]
> >
> > and then references this
> >
> >If users need code elements to represent country names not included
> >in this part of ISO 3166, the series of letters AA, QM to QZ, XA to
> >XZ, and ZZ [...] are available.
> >
> > I read that to mean that a .ZZ (or rather any of the 42 possibles) would
> > be safe to use in our context.
> >
> > If the rule were to change I would however speculate that the wishes of
> > the government concerned might prevail over the wishes of ICANN.
> >
> > Whether this all is safe enough to write a standard, I don't know.
> >
> >
> > el
> >
> >
> >> On 22/11/2019 10:26, Bill Woodcock wrote:
> >>> On Nov 22, 2019, at 12:20 AM, Shane Kerr 
> >>> wrote:
> >>>
> >>> "User-assigned codes - If users need code elements to represent
> >>> country names not included in ISO 3166-1, the series of letters AA,
> >>> QM to QZ, XA to XZ, and ZZ, and the series AAA to AAZ, QMA to QZZ,
> >>> XAA to XZZ, and ZZA to ZZZ respectively, and the series of numbers
> >>> 900 to 999 are available.  NOTE: Please be advised that the above
> >>> series of codes are not universal, those code elements are not
> >>> compatible between different entities."
> >>>
> >>> So the intention of the ISO at least is that these codes are used by
> >>> users.  (I'm not sure what the scary warning means.)  Certainly I
> >>> have made heavy use of .Q* and .X* in my own testing, with the
> >>> assumption that these would never be assigned (and yes, there is
> >>> .TEST but sometimes you need more than one one TLD).
> >>
> >> Right.  And in fact, “unassigned” ISO codes _do_ get used, for places
> >> like Kosovo, that are in a state of disputed or partially-recognized
> >> countryhood, and ranges that are reserved for user use really should
> >> be left for that use, because they do in fact get used by users, so
> >> any centrally-coordinated use will run afoul of that.
> >>
> >> Again, this is an argument from principle rather than an argument
> >> based on the specific case at hand.  I just think that we have a
> >> well-established precedent that all two-letter TLDs are derived from
> >> ISO 3166 Alpha-2, and it’s bad form to cross back over and start
> >> poaching in their territory.
> >>
> >>-Bill
> >
> > --
> > Dr. Eberhard W. Lisse   \ /  Obstetrician & Gynaecologist
> > e...@lisse.na / *  | Telephone: +264 81 124 6733 (cell)
> > PO Box 8421  \  /
> > Bachbrecht 10007, Namibia ;/
> >
> >
> > ___
> > 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 m

Re: [DNSOP] Special-use TLDs in resolvers

[Steve Crocker]

Ack.  Tnx.

On Fri, Aug 16, 2019 at 11:56 AM Joe Abley  wrote:

> On 16 Aug 2019, at 10:59, Steve Crocker  wrote:
>
> > At the risk of revealing that I haven't been following this thread
> carefully, I don't understand how a resolver is supposed to know all of the
> special names.  Resolvers that are configured to know that invalid, local,
> onion, and test are special will not know about the next name that's put on
> the special list.
>
> The pragmatic answer right now is that vendors and package maintainers do
> a good job with their default configurations. DNS software tends to get
> upgraded frequently enough in applications with significant user bases that
> this goes some of the distance.
>
> I can see your point though that there might be some merit in having a way
> to retrieve a current list, or at least telling whether the list you have
> is up-to-date. I don't know that I think it's a particularly pressing
> problem though (I think DNSSEC trust anchor distribution for the root zone
> is higher up the priority list, for example).
>
>
> Joe
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Special-use TLDs in resolvers

[Steve Crocker]

At the risk of revealing that I haven't been following this thread
carefully, I don't understand how a resolver is supposed to know all of the
special names.  Resolvers that are configured to know that invalid,
local, onion,
and test are special will not know about the next name that's put on the
special list.

I guess the larger picture is that onion is a protocol switch, so it's not
sufficient for a resolver to know that it shouldn't look up strings ending
in onion in the global DNS; it must also know what it should do.

Steve


On Fri, Aug 16, 2019 at 10:47 AM Andrew Sullivan 
wrote:

> As I often note, I work for ISOC but I'm not speaking for it.
>
> On Fri, Aug 16, 2019 at 11:30:06AM +0200, Vladimír Čunát wrote:
>
> > I've been wondering what's best to do around these TLDs: invalid, local,
> > onion, test.  The RFCs say that resolvers SHOULD recognize them as
> > special and answer NXDOMAIN without any interaction with nameservers (by
> > default).  What do you think about NOT following this "advice", subject
> > to some conditions that I explain below?
>
> I think it's less than ideal, because the point of resolvers immediately
> answering NXDOMAIN is that these are not and never will be names in
> the global DNS.  That is, they really are special-use, and part of
> that specialness is that they're part of the domain name space but not
> part of the global DNS name space.
>
> This is particularly true of onion, which is a protocol switch.  It's
> intended to signal that you should _never_ look up that name in the
> DNS.  That's its whole function.
>
> Best regards,
>
> A
>
> --
> Andrew Sullivan
> a...@anvilwalrusden.com
>
> ___
> 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] Proposal: Whois over DNS

[Steve Crocker]

Folks,

Let me share a somewhat broader perspective.  I was chair of the ICANN
board for several years.  During that period, I attempted, without success,
to reset the dialog related to whois.  After I stepped off the board in
late 2017, I decided to take another run at the problem.  I've been working
quietly with a small, excellent group to see if we can provide some useful
tools for assisting the community in thinking about the policy issues.  Our
first goal is to provide a policy framework for expressing the wide variety
of policies in this area, both existing and proposed.  We're not quite
ready to release this framework, but it's coming along and I hope to be
able to publish it shortly.  That said, I can share a few points.

   1.  "Whois" is a somewhat ill-fitting handle.  The policy problems
   extend beyond contact data to include quite few other types of data, some
   of which are inherently public such as the DNS records, some of which are
   inherently extremely sensitive such credit card numbers, and others which
   fall somewhere in between such as dates of registration and expiration.

   I'll also note that WHOIS arose in the days of the Arpanet, prior to the
   existence of the domain name system and prior to the Internet.  The admin
   and tech contacts referred to the people running the time-shared systems
   that were hosts on the Arpanet, and these contacts were published so they
   could reach each other.  Almost fifty years later and a millionfold
   expansion, it's not a surprise the original concepts are not a perfect fit.

   2. Of the various contacts that are usually published, only the
   registrant contact has any real meaning.  For most registrations, the admin
   and tech contacts have no agreed upon meaning.  By "an agreed upon meaning"
   I mean an explicit statement of the authority (what the contact may do) and
   responsibility (what the contact is supposed to do) so that both the
   contact and everyone who accesses the contact data would share the same
   understanding.

   One of the most important roles in the entire structure is the person
   who has the account with the registrar and therefore has direct, electronic
   control of all the data.  We use the term "account holder" for this role.
   It may or may not be the same as the registrant.

   Other contact data is occasionally published, e.g. billing contact,
   legal contact, etc.  While the meaning of these roles is alluded to in the
   name, there is usually nothing explicit about authority and responsibility.

   3. The policy issues related to all of this are quite tangled.  The
   registrar and the registrar are the primary parties involved.  The
   blazingly simple and obvious fact is that neither of these parties have any
   trouble with the accuracy or meaning of the data they share with
each other *that
   are related to the actual process of registration*.  The registrar is
   primarily concerned with getting paid and the registrant is primarily
   concerned with having his registration active.  The trouble comes from the
   many third parties who have developed practices and policies related to the
   registration data.  A full discussion of these multiple parties, their
   motivations and needs, and the wide variety of policy issues requires much
   more space and attention than is appropriate for this note and this thread,
   but a couple of specific points are relevant and worth emphasizing.

   4. It's important to separate (a) the definition of the data elements,
   (b) the policies governing who should have access to which data elements,
   and (c) the access mechanisms.  As I said in an earlier note, the proposal
   being discussed in this thread, viz to use DNS to publish contact data,
   speaks to only a small portion of the overall problem.  Because the
   proposed mechanism is DNS, the data will presumably be public and provided
   at the discretion of the registrant.   This is useful for some purposes,
   but it clearly does not address the larger policies issues of allowing
   different groups to have differing levels of access to various types of
   data.

   5. With respect to the role of the IETF, I agree the policy issues
   belong elsewhere.  That said, there is, I believe, a natural role for the
   IETF that matches one part of the current proposal.  All parties will
   benefit if there is a dictionary of the possible registration data
   elements.  As I suggested in point 1 above, the relevant data elements
   include more than just contact data.  And even with respect to contact
   data, a more precise definition of the various roles would be quite helpful.

   The distinction implied here is the separation of the definition of the
   data elements from the publication mechanism.

I would strongly support an effort within the IETF to create and maintain a
dictionary of registration data elements.  This would probably be in the
form of an IANA-maintained registry, with oversight 

Re: [DNSOP] Proposal: Whois over DNS

[Steve Crocker]

>
> Folks,

Let me share a somewhat broader perspective.  I was chair of the ICANN
board for several years.  During that period, I attempted, without success,
to reset the dialog related to whois.  After I stepped off the board in
late 2017, I decided to take another run at the problem.  I've been working
q
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Proposal: Whois over DNS

[Steve Crocker]

John and Bill,

Let me offer a slightly different perspective.  The proposal would provide
a way for domain name owners to publish information that they want
published, and it would, of course, be publicly available.

The pre-GDPR whois system collected contact information from registrants
irrespective of whether the registrant would have chosen to provide it.
That's a fundamentally flawed structure, i.e. the incentives are misaligned..

I'm not immediately persuaded the proposed solution, i.e. allowing
registrants to publish what they want via DNS records, will result in a
large amount of incorrect data.  What's the motivation to publish wrong
information as opposed to simply not publishing anything?  On the other
hand, it doesn't address the main issue under consideration these days, a
differentiated access system.  Thus, in my view, the proposal would provide
a solution to the easiest portion of the problem space and would not
address any of the deeper issues.

Steve


On Mon, Jul 8, 2019 at 5:45 PM Bill Woodcock  wrote:

>
>
> > On Jul 8, 2019, at 2:38 PM, John Bambenek  40bambenekconsulting@dmarc.ietf.org> wrote:
> >
> > All-
> >
> > In response to ICANN essentially removing most of the fields in WHOIS
> for domain records, Richard Porter and myself created a draft of an
> implementation putting these records into DNS TXT records. It would require
> self-disclosure which mitigates the sticky issues of GDPR et al. Would love
> to get feedback.
>
> Good in principle, but the information in whois has always been, at least
> nominally, third-party vetted.  This would not be.  So my worry is that
> either it would get no uptake, or it would get filled with bogus
> information.  It’s a little hard for me to imagine it being widely used for
> valid information, though that would of course be the ideal outcome.
>
> So, no problem with this in principle, but I’d like to see some degree of
> consensus that user-asserted content is sufficient for people’s needs.
>
> -Bill
>
> ___
> 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] [Ext] "The Forgotten Object Lesson Of The Dyn DDoS Attack"

[Steve Crocker]

Weighing in on this, I think this is an important piece of work.  I’m 
particularly interested in what else is necessary to introduce the multiple dns 
operators to each, to authorize their cooperation, and facilitate cross signing 
of keys whenever a new operator is introduced and whenever one or more of the 
operators rolls its/their key(s).

This draft is framed in terms of having multiple dns operators serve the same 
zone on a continuing basis.  An important corner case is the transfer of a 
signed zone from one operator to another without loss of resolution and without 
loss of validity.

If I can be helpful moving this forward, I’ll be glad to help.

Steve Crocker

Sent from my iPhone

> On Jan 3, 2019, at 9:33 PM, Tim Wicinski  wrote:
> 
> Actually  draft-huque-dnsop-multi-provider-dnssec was adopted, but the author 
> (whom I work with and has heard from 
> me about this regularly) has failed to push up an updated version.   I'm 
> going to force him to turn the authorship
> over to one of the other authors who is more responsive to the needs of the 
> chairs.
> 
> Tim
> 
> 
>> On Thu, Jan 3, 2019 at 11:26 AM Paul Hoffman  wrote:
>> On Jan 3, 2019, at 5:02 AM, Töma Gavrichenkov  wrote:
>> > If I were to trace that through the recent DNSOP activity, I could
>> > bring up my own draft (draft-gavrichenkov-dnsop-dnssapi), also not
>> > adopted and now expired.  Maybe there were discussions of the same
>> > sort before me that I'm not aware of.
>> 
>> Or he was possibly talking about draft-huque-dnsop-multi-provider-dnssec, 
>> which expired yesterday, and also has not been adopted.
>> 
>> --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
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Informal meeting about root KSK futures at IETF 103

[Steve Crocker]

I had advocated early and frequent rollovers for precisely the reason: keep
doing it until it’s easy, so we’re in strong agreement.

Yes, this one actually went smoothly but there was some tension.  Aside
from any specific improvement, reducing the tension and sense of drama is
mainly what I had in mind.

Thanks,

Steve

On Mon, Oct 29, 2018 at 8:23 PM Joe Abley  wrote:

> Hi Steve,
>
> There will always be the potential for tension between the desire to
> perform measurement and the need for privacy. In this case it seems to me
> that a well-intentioned and competent authority, supported by a
> well-intentioned and occasionally-coherent community has a plausible and
> sensible desire to understand the configuration of resolvers. I imagine
> others might see things differently, however. I suspect that having a clean
> signal that can be relied upon is going to at least change the extent to
> which client infrastructure is private.
>
> Your last paragraph caught my eye, though. It could be argued that the
> rollover that just completed was straightforward, at least from a technical
> perspective. The delays, uncertainty, concern and unfulfilled doomsaying
> were the things that made it difficult. (It's easy to load that last
> sentence so that the concern looks ridiculous given the outcome; I am fully
> aware that the hyperbole would be the thing that looked ridiculous if
> things had turned out differently.)
>
> To what extent does a regular and frequent cadence of key rollovers
> obviate the need for concern? It seems to me that at some point down the
> road if a key roll breaks someone's network, it's going to be much easier
> to point the finger at the network operator than at whomever is responsible
> for rolling the key. Perhaps the way to eliminate the things that made the
> first rollover hard is just to keep doing it until it's officially easy.
>
>
> Joe
>
> On 29 Oct 2018, at 18:46, Steve Crocker  wrote:
>
> I won't be in Bangkok, so I won't be able to participate.  In my view,
> there were two specific problems that dominated the rollover problem.  The
> first was the inability to determine the configuration of querying
> resolver.  The second was the in ability to notify resolver operators if it
> was evident their software was misconfigured.
>
> Although these two problems became evident and important during the
> rollover, they also apply more generally, so if the IETF is going to work
> on improvements, it would be helpful if the improvements would be useful in
> the event of other configuration or operational issues.  Ideally, every
> resolver that issues a query would provide configuration information,
> perhaps in a controlled fashion, and there should also be a way to notify
> the resolver operator of operational problems.
>
> We will need to do more rollovers in the future, driven at least in part
> by the need to change algorithms.  I would hope we can work toward making
> these relatively straightforward.
>
> Thanks,
>
> Steve
>
>
> On Mon, Oct 29, 2018 at 12:36 PM Dave Lawrence  wrote:
>
>> Dave Lawrence writes:
>> > Count me as another, for that very reason.  When I first saw Paul's
>> > message I thought, "oh that's a shame" but figured it to be fairly
>> > set.  If there's flexibility for making the meeting happen earlier in
>> > the week, I'd be interested.
>>
>> Following up to my own message, since this was further down in my box
>> on another list...
>>
>> --- start of forwarded message (RFC 934 encapsulation) ---
>> From: Paul Hoffman 
>> Subject: Re: [ksk-rollover] Informal meeting at IETF 103
>> To: "ksk-rollo...@icann.org" 
>>
>> Based on some requests from folks who are leaving the IETF meeting
>> early, I have also reserved a meeting room for 1600-1700 Wednesday
>> afternoon (local time), Pagoda Room on the 4th floor.
>>
>> And just to emphasize: the purpose of this week's informal gatherings is
>> to let folks in the IETF community chat about their ideas in front of
>> other IETFers. This is similar to the KSK-related mic lines at the
>> DNS-OARC and RIPE meetings a few weeks ago. These IETF side-meetings
>> really are just slightly-better-organized hallway discussions. Given the
>> wide range of proposals we have already heard, it is good to get a bit
>> of face-to-face sharing going early.
>>
>> We won't start formal planning about the KSK futures until after the
>> rollover process is complete*. When we do, we'll do it in discussion
>> environments that are much more inclusive than these informal IETF
>> side-meetings o

Re: [DNSOP] Informal meeting about root KSK futures at IETF 103

[Steve Crocker]

I won't be in Bangkok, so I won't be able to participate.  In my view,
there were two specific problems that dominated the rollover problem.  The
first was the inability to determine the configuration of querying
resolver.  The second was the in ability to notify resolver operators if it
was evident their software was misconfigured.

Although these two problems became evident and important during the
rollover, they also apply more generally, so if the IETF is going to work
on improvements, it would be helpful if the improvements would be useful in
the event of other configuration or operational issues.  Ideally, every
resolver that issues a query would provide configuration information,
perhaps in a controlled fashion, and there should also be a way to notify
the resolver operator of operational problems.

We will need to do more rollovers in the future, driven at least in part by
the need to change algorithms.  I would hope we can work toward making
these relatively straightforward.

Thanks,

Steve


On Mon, Oct 29, 2018 at 12:36 PM Dave Lawrence  wrote:

> Dave Lawrence writes:
> > Count me as another, for that very reason.  When I first saw Paul's
> > message I thought, "oh that's a shame" but figured it to be fairly
> > set.  If there's flexibility for making the meeting happen earlier in
> > the week, I'd be interested.
>
> Following up to my own message, since this was further down in my box
> on another list...
>
> --- start of forwarded message (RFC 934 encapsulation) ---
> From: Paul Hoffman 
> Subject: Re: [ksk-rollover] Informal meeting at IETF 103
> To: "ksk-rollo...@icann.org" 
>
> Based on some requests from folks who are leaving the IETF meeting
> early, I have also reserved a meeting room for 1600-1700 Wednesday
> afternoon (local time), Pagoda Room on the 4th floor.
>
> And just to emphasize: the purpose of this week's informal gatherings is
> to let folks in the IETF community chat about their ideas in front of
> other IETFers. This is similar to the KSK-related mic lines at the
> DNS-OARC and RIPE meetings a few weeks ago. These IETF side-meetings
> really are just slightly-better-organized hallway discussions. Given the
> wide range of proposals we have already heard, it is good to get a bit
> of face-to-face sharing going early.
>
> We won't start formal planning about the KSK futures until after the
> rollover process is complete*. When we do, we'll do it in discussion
> environments that are much more inclusive than these informal IETF
> side-meetings or the mic lines at other technical meetings.
>
> [...]
> --- end ---
>
> ___
> 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] DNSSEC threshold signatures idea

[Steve Crocker]

My focus is on preventing the orchestrator from faking the signatures.

Steve

Sent from my iPhone

> On Sep 6, 2018, at 3:52 PM, Hugo Salgado-Hernández  wrote:
> 
>> On 15:25 06/09, Steve Crocker wrote:
>> Let me flag a key point.  You said this scheme will *detect* faked
>> signatures.  If you want to *prevent* faked signatures, you need additional
>> structure.
> 
> The orchestrator can detect faked signature pieces when is
> merging them, before going live. So for this definition of
> "prevent" should be sufficient. If you're referring to
> prevent the orchestrator with faking the resulting signature,
> I think we're gonna fail preventing but only reacting after
> detecting it alive.
> 
> Hugo
> 
>> 
>> Steve
>> 
>> 
>> On Thu, Sep 6, 2018 at 3:22 PM, Hugo Salgado-Hernández 
>> wrote:
>> 
>>>> On 15:08 06/09, Steve Crocker wrote:
>>>> How do you prevent compromise of the central service?
>>>> 
>>> 
>>> For the initial setup a physical ceremony is necessary,
>>> to check there's no extra subkeys and for secure transmision
>>> of them. But afterwards there's no need. Each node can check
>>> the final signature validates with the public key (just like
>>> a normal signature), and the plain data should be public
>>> (DNSKEY rrset).
>>> 
>>> In this same first ceremony you can also share simmetric
>>> keys for the secure transmission of data and signature
>>> pieces.
>>> 
>>> The system is fault-tolerant as a subset of nodes can fail
>>> and the signing process can be completed, and you can
>>> detect faked sub-signatures.
>>> 
>>> Hugo
>>> 
>>>> Steve
>>>> 
>>>> 
>>>> On Thu, Sep 6, 2018 at 3:02 PM, Hugo Salgado-Hernández 
>>>> wrote:
>>>> 
>>>>>> On 23:19 06/09, Mukund Sivaraman wrote:
>>>>>> On Thu, Sep 06, 2018 at 02:34:12PM -0300, Hugo Salgado-Hernández
>>> wrote:
>>>>>>> Hi Mukund.
>>>>>>> I talked about this to Davey in Montreal. There's an implementation
>>>>>>> in github[1] and presentations in OARC[2] and ICANN[3].
>>>>>> 
>>>>>> Aha so you're the original source :)
>>>>>> 
>>>>>>> I'm not sure if its being used right now in a live zone, but
>>> certainly
>>>>>>> in labs and testing. There's been some interests with academic
>>>>>>> institutions, but don't think they're ready yet.
>>>>>>> 
>>>>>>> We've been trying to focus this technology as a "poor-man" HSM, as
>>>>>>> having similar security features without buying an expensive HW.
>>>>>>> But I think the root and similar high-value zones will benefit for
>>>>>>> having an split of the private key AND the fact of not needing a
>>>>>>> "root key ceremony" to sign, because you can sign remotely with
>>>>>>> each piece of the private key, and transmit the "signature pieces"
>>>>>>> to a central place.
>>>>>>> 
>>>>>>> Hugo
>>>>>>> 
>>>>>>> [1] https://github.com/niclabs/docker/tree/master/tchsm
>>>>>>> [2] <https://indico.dns-oarc.net/getFile.py/access?contribId=
>>>>> 22&sessionId=3&resId=1&materialId=slides&confId=20>
>>>>>>> [3] <http://buenosaires48.icann.org/en/schedule/wed-dnssec/
>>>>> presentation-dnssec-cryptographic-20nov13-en>
>>>>>> 
>>>>>> So this's implemented as a PKCS 11 provider.. interesting. In my
>>> mind I
>>>>>> was thinking along the lines of updates to dnssec-keygen +
>>>>>> dnssec-signzone + intermediate RRSIG representation using new RR
>>> type +
>>>>>> zone transfers to share intermediate effects.
>>>>> 
>>>>> In our implementation you'll need a central "orchestrator" who
>>>>> creates the first key and split the private pieces to each
>>>>> signing node. This same orchestrator later send signature
>>>>> requests to each node, collect the signature pieces and
>>>>> defines the "consensus" of M/N. Finally, there's an PKCS11
>>>>> interface between this orchestrator and the zone signing
>>>>> policy machinery (OpenDNSSEC in our setup).
>>>>> 
>>>>> Hugo
>>>>> 
>>>>> 
>>>>> ___
>>>>> 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
> 

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

Re: [DNSOP] DNSSEC threshold signatures idea

[Steve Crocker]

Let me flag a key point.  You said this scheme will *detect* faked
signatures.  If you want to *prevent* faked signatures, you need additional
structure.

Steve


On Thu, Sep 6, 2018 at 3:22 PM, Hugo Salgado-Hernández 
wrote:

> On 15:08 06/09, Steve Crocker wrote:
> > How do you prevent compromise of the central service?
> >
>
> For the initial setup a physical ceremony is necessary,
> to check there's no extra subkeys and for secure transmision
> of them. But afterwards there's no need. Each node can check
> the final signature validates with the public key (just like
> a normal signature), and the plain data should be public
> (DNSKEY rrset).
>
> In this same first ceremony you can also share simmetric
> keys for the secure transmission of data and signature
> pieces.
>
> The system is fault-tolerant as a subset of nodes can fail
> and the signing process can be completed, and you can
> detect faked sub-signatures.
>
> Hugo
>
> > Steve
> >
> >
> > On Thu, Sep 6, 2018 at 3:02 PM, Hugo Salgado-Hernández 
> > wrote:
> >
> > > On 23:19 06/09, Mukund Sivaraman wrote:
> > > > On Thu, Sep 06, 2018 at 02:34:12PM -0300, Hugo Salgado-Hernández
> wrote:
> > > > > Hi Mukund.
> > > > > I talked about this to Davey in Montreal. There's an implementation
> > > > > in github[1] and presentations in OARC[2] and ICANN[3].
> > > >
> > > > Aha so you're the original source :)
> > > >
> > > > > I'm not sure if its being used right now in a live zone, but
> certainly
> > > > > in labs and testing. There's been some interests with academic
> > > > > institutions, but don't think they're ready yet.
> > > > >
> > > > > We've been trying to focus this technology as a "poor-man" HSM, as
> > > > > having similar security features without buying an expensive HW.
> > > > > But I think the root and similar high-value zones will benefit for
> > > > > having an split of the private key AND the fact of not needing a
> > > > > "root key ceremony" to sign, because you can sign remotely with
> > > > > each piece of the private key, and transmit the "signature pieces"
> > > > > to a central place.
> > > > >
> > > > > Hugo
> > > > >
> > > > > [1] https://github.com/niclabs/docker/tree/master/tchsm
> > > > > [2] <https://indico.dns-oarc.net/getFile.py/access?contribId=
> > > 22&sessionId=3&resId=1&materialId=slides&confId=20>
> > > > > [3] <http://buenosaires48.icann.org/en/schedule/wed-dnssec/
> > > presentation-dnssec-cryptographic-20nov13-en>
> > > >
> > > > So this's implemented as a PKCS 11 provider.. interesting. In my
> mind I
> > > > was thinking along the lines of updates to dnssec-keygen +
> > > > dnssec-signzone + intermediate RRSIG representation using new RR
> type +
> > > > zone transfers to share intermediate effects.
> > >
> > > In our implementation you'll need a central "orchestrator" who
> > > creates the first key and split the private pieces to each
> > > signing node. This same orchestrator later send signature
> > > requests to each node, collect the signature pieces and
> > > defines the "consensus" of M/N. Finally, there's an PKCS11
> > > interface between this orchestrator and the zone signing
> > > policy machinery (OpenDNSSEC in our setup).
> > >
> > > Hugo
> > >
> > >
> > > ___
> > > 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] DNSSEC threshold signatures idea

[Steve Crocker]

How do you prevent compromise of the central service?

Steve


On Thu, Sep 6, 2018 at 3:02 PM, Hugo Salgado-Hernández 
wrote:

> On 23:19 06/09, Mukund Sivaraman wrote:
> > On Thu, Sep 06, 2018 at 02:34:12PM -0300, Hugo Salgado-Hernández wrote:
> > > Hi Mukund.
> > > I talked about this to Davey in Montreal. There's an implementation
> > > in github[1] and presentations in OARC[2] and ICANN[3].
> >
> > Aha so you're the original source :)
> >
> > > I'm not sure if its being used right now in a live zone, but certainly
> > > in labs and testing. There's been some interests with academic
> > > institutions, but don't think they're ready yet.
> > >
> > > We've been trying to focus this technology as a "poor-man" HSM, as
> > > having similar security features without buying an expensive HW.
> > > But I think the root and similar high-value zones will benefit for
> > > having an split of the private key AND the fact of not needing a
> > > "root key ceremony" to sign, because you can sign remotely with
> > > each piece of the private key, and transmit the "signature pieces"
> > > to a central place.
> > >
> > > Hugo
> > >
> > > [1] https://github.com/niclabs/docker/tree/master/tchsm
> > > [2]  22&sessionId=3&resId=1&materialId=slides&confId=20>
> > > [3]  presentation-dnssec-cryptographic-20nov13-en>
> >
> > So this's implemented as a PKCS 11 provider.. interesting. In my mind I
> > was thinking along the lines of updates to dnssec-keygen +
> > dnssec-signzone + intermediate RRSIG representation using new RR type +
> > zone transfers to share intermediate effects.
>
> In our implementation you'll need a central "orchestrator" who
> creates the first key and split the private pieces to each
> signing node. This same orchestrator later send signature
> requests to each node, collect the signature pieces and
> defines the "consensus" of M/N. Finally, there's an PKCS11
> interface between this orchestrator and the zone signing
> policy machinery (OpenDNSSEC in our setup).
>
> Hugo
>
>
> ___
> 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] New Version Notification for draft-wessels-dns-zone-digest-01.txt

[Steve Crocker]

Joe,

Thanks.  You've mentioned several things tagged with "it would be nice to
have."  Each of these has both (a) one or more assumptions about a problem
that seeking to be addressed and (b) the implication of a fairly massive
architectural change.  These need a deeper and better organized discussion
than can be done on this list.  This is really IAB territory or something
similar, in my opinion, and the starting point is a careful delineation of
the problems before we engage in specific solutions.  Your experience,
perceptions and judgments are top notch, but it will take time and work to
get everyone else on the same page.  (Or not.)

Meanwhile, there is already an evolution toward local service of the root
zone.  It seems to be there are two relevant threads to pursue.  One is how
best to support it, and the other, picking up on your point, is to
understand what problems, defects, etc. there might be as more and more
recursive resolvers start to serve the root zone.

Speaking for myself, I'm not opposed, in principle, to thinking about fresh
designs and radical changes where it's appropriate.  For example, I have
made comments in the past and will be making more comments in the future
about the whois system.  But with respect to the evolution of the root
service, I'm not in agreement that we should be entangling it with the much
larger architectural issues you're raising.

Steve


On Sun, Jul 29, 2018 at 12:44 PM, Joe Abley  wrote:

> Hi Steve,
>
> On Jul 29, 2018, at 15:09, Steve Crocker  wrote:
>
> > As an individuals, you, I, or anyone else, can do whatever we like, of
> course.  On the other hand, as system designers we presumably look at the
> overall system and try to put in place an operational structure that
> anticipates and meets the likely needs of the users.
>
> Agreed!
>
> > The present and long-standing system provides the recursive resolvers
> with well-oiled and highly effective solutions to (a) finding the root
> servers and (b) getting highly reliable and highly responsive answers from
> them.
>
> This is true. However, there are some disadvantages of the current system
> that are worth thinking about when we consider alternatives, such as the
> privacy implications of having all resolvers call home to a set of
> well-known servers and the aggregate cost of engineering and operations
> that has gone into making the root system as resilient as it is.
>
> I have spoken in the past in opposition to the idea that slaving the root
> zone on resolvers was a desirable end-state; I think it leaves operational
> gaps that we should want to fill. Being able to validate the contents of
> the zone and have software react appropriately (without human operator
> intervention) when zone data is found to be stale or inaccurate obviates
> many of my concerns.
>
> Perhaps there is a future where the root server system was preserved only
> to serve legacy clients, whilst more modern software had a diversity of
> options in addition to that fall-back.
>
> I think the root zone is a convenient starting point for these kinds of
> discussions, but I think the scope could be wider. Maybe one day the DNS
> protocol (for all zones, not just the root zone) is only comonly used for
> communications between stub and resolver, where we have the deployed base
> with the longest tail, and where capacity planning and attack resistance is
> a different kind of problem because all your traffic generators are on-net.
> Perhaps the database problem of replicating authoritative data into
> resolver caches is solved in different ways.
>
> It would be nice if end-users didn't have to rely upon authoritative
> servers being up in order to resolve names; it would be nice if there
> wasn't a small set of targets against which the next memcached-scale attack
> could be used to take us back to 21 October 2016; it would be nice if the
> integrity of the naming scheme didn't ultimately rely upon the deployment
> of BCP38.
>
> If such a mechanism relied upon DNSSEC to ensure integrity of data in the
> absence of plausible channel authentication, availability of zones might be
> aligned with DNSSEC deployment, which would give the Alexa 500 a(nother)
> reason to sign their zones.
>
> There are lots of things to think about here. I don't think clinging to
> the status quo in terms of infrastructure or institutions is necessarily a
> good idea, although I do agree with the idea of preserving legacy
> compatability and incremental change.
>
>
> Joe
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] New Version Notification for draft-wessels-dns-zone-digest-01.txt

[Steve Crocker]

Joe,

As an individuals, you, I, or anyone else, can do whatever we like, of
course.  On the other hand, as system designers we presumably look at the
overall system and try to put in place an operational structure that
anticipates and meets the likely needs of the users.

The present and long-standing system provides the recursive resolvers with
well-oiled and highly effective solutions to (a) finding the root servers
and (b) getting highly reliable and highly responsive answers from them.
It seems to me reasonable and reasonably easy to sustain these attributes
as we evolve toward downloading the entire root zone instead of individual
pieces of it.  And by "evolution" we're necessarily talking about a lengthy
period of hybrid operation.  There will likely be a growing set of
recursive resolvers downloading the full root zone and but there will
certainly be a very large set of recursive resolvers that continue to
operate in the current model.  Even if there were to be an aggressive push
toward hyper local root service, the existing service would have to remain
as is for a long time.  And by "a long time" I'm guessing ten years is not
enough, so I suspect it will be twenty years before one can imagine the
current root service reaching twilight.

The heated concern of several years ago about the potential size of the
root zone is behind us, I hope.  The root zone is not going to grow
exponentially.  The whole zone will be in the single megabyte range, I
think.  (Caution: I haven't looked at the actual size.  Apologies if I am
off a bit.  But the overall point is still right.  Another round or so of
gTLDs might double or even triple the current size of the root zone, but it
will not grow by even one order of magnitude and certainly not by multiple
orders of magnitude.)

Distribution of a megabyte or even a few megabytes to, say, a million
recursive resolvers twice a day is a relatively modest endeavor on today's
Internet.  If there are going to be problems, I suspect they won't be
related to ad hoc fetching of the root zone from random untrusted sources.

Steve


On Sun, Jul 29, 2018 at 11:50 AM, Joe Abley  wrote:

> On Jul 29, 2018, at 12:19, Steve Crocker  wrote:
>
> > It feels like this discussion is based on some peculiar and likely
> incorrect assumptions about the evolution of root service.  Progression
> toward hyper local distribution of the root zone seems like a useful and
> natural sequence.  However, the source of the copies of the root zone will
> almost certainly remain robust and trusted.
>
> I think you need to be more clear what you mean by "source".
>
> If you mean the original entity that constructs and first makes
> available the root zone (e.g. the root zone maintainer in the current
> system) then what you say seems uncontentious.
>
> If what you mean is "the place that any particular consumer if the
> root zone might have found it" then I think you need to show your
> working.
>
> Resolvers currently prime from a set of trusted servers (albeit over
> an insecure transport without authentication, so we could quibble
> about what "trusted" means even there) but it's not obvious to me that
> this is a necessary prerequisite for new approaches.
>
> If I have a server sitting next to me that has a current and accurate
> copy of the root zone and I am able to get it from there and assess
> the accuracy of what I receive autonomously, why wouldn't I?
>
>
> Joe
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] New Version Notification for draft-wessels-dns-zone-digest-01.txt

[Steve Crocker]

It feels like this discussion is based on some peculiar and likely incorrect 
assumptions about the evolution of root service.  Progression toward hyper 
local distribution of the root zone seems like a useful and natural sequence.  
However, the source of the copies of the root zone will almost certainly remain 
robust and trusted.  The current system has evolved carefully over a very long 
period of time.  Recursive resolvers are configured with a hints file and start 
up fetching the current set of root servers.  (This is the priming process.).  
The evolution that’s needed as more and more recursive resolvers fetch complete 
copies of the root zone is simply the strengthening of the distribution process.

The root server operators have been spending quite a bit of time thinking about 
the future.  One important result is the recent RSSAC report, RSSAC 037, 
https://www.icann.org/en/system/files/files/rssac-037-15jun18-en.pdf .  This 
focuses on possible changes in their governance and doesn’t speak directly to 
the issues here, but it’s part of a larger process of looking at the future.

It seems to me very reasonable for this group  to say what you would like in 
the way of an evolving root service and distribution system.

Steve

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

Re: [DNSOP] New Version Notification for draft-wessels-dns-zone-digest-01.txt

[Steve Crocker]

Let me play Candide and stumble into this naively.  If we’re imagining very
wide spread distribution of the root zone, say 100,000 or 1,000,000 local
copies distributed twice a day, I would expect the evolution of a set of
trusted sources and the use of some existing secure transport protocol to
protect the transmission.  No new protocol or data types, just a way of
finding the address of one more trusted sources.  And the existing set of
root servers seems like a perfectly good set of trusted sources.

Steve

On Thu, Jul 26, 2018 at 7:45 PM Shumon Huque  wrote:

> On Thu, Jul 26, 2018 at 10:16 PM Davey Song  wrote:
>
>>
>> - It was not really clear exactly what kind of problem this digest
>>>tries to solve, especially given that the primarily intended usage
>>>is for the root zone, which is DNSSEC-signed with NSEC.
>>>
>>
>> It puzzled me as well.
>>
>> It is said in the document that diffferent from DNSSEC (and NSEC), the
>> zone digest is for the intergirty of unsigned NS and Glue of the zone. As I
>> asked in IETF102: why unsigned NS and glue is worth of protecting by
>> introducing a new RRtype, addtional complexity of degesting and validation.
>> Is it really necessary for local resolver(or local-root) aware the integity
>> of NS and glue?  any technical problems if the NS RR and glue are
>> modified locally?
>>
>
> The ZONEMD digest is over the entire zone, not just the delegation NS and
> glue records.
>
> Normally, in order to ensure that secondary servers accurately got a copy
> of a zone from the master server, we would use a channel protection
> mechanism like TSIG. This is typically needed even if they were no unsigned
> data in the zone because authoritative servers do not typically validate
> signatures of the data in zones they themselves serve - in theory they
> could, but in fact I don't know any implementations that validate RRSIGs
> received over zone transfers - they just trust the source and serve the
> data. Resolvers validate signatures. Authoritative servers that serve
> signed zones trust that they have already have an authentic copy of the
> zone.
>
> The problem for wide scale distribution of the root zone, is that
> traditional TSIG (without adding a complex key management infrastructure)
> doesn't scale. Earlier in this thread, I had proposed that SIG(0) could be
> a scalable solution to this problem, but it has some limitations, and Duane
> has argued that the full zone signature is a better solution. I'm not
> opposed to this, but I think Mark Andrew's XHASH proposal is worth thinking
> through also.
>
> Even if the local-root-zone resolvers were modified to validate signatures
> of signed RRsets in the zone, if a MITM attacker fed them bogus glue, to
> recover from this, they would need operator intervention to manually
> retransfer the zone. This doesn't strike me as a robust operational
> configuration.
>
> --Shumon.
>
> ___
> 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] New Version Notification for draft-wessels-dns-zone-digest-01.txt

[Steve Crocker]

The passage below puzzles me.  Why do you want servers to get the root zone 
from less trusted sources?  And why does the source matter if the zone entries 
are DNSSEC-signed?

Thanks,

Steve

Sent from my iPhone

> On Jul 26, 2018, at 7:33 PM, Mark Andrews  wrote:
> 
> Additionally most nameservers treat zone data as fully trusted.  This is 
> reasonable when you are getting data from a “trusted" source.  For the root 
> zone we want servers to be able to get a copy of the zone from a untrusted / 
> less trusted source.

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

Re: [DNSOP] IETF102 Actions and Updates

[Steve Crocker]

I've been watching actively but quietly.  Stellar work!  Congratulations!

Steve Crocker

On Fri, Jul 20, 2018 at 2:40 PM, Tim Wicinski  wrote:

>
> All
>
> Thanks for a pretty productive week and thanks for
> breaking in our new chair slowly.
>
> Rough Minutes have been uploaded:
>
> https://datatracker.ietf.org/doc/minutes-102-dnsop/
>
> And I apologize - I took notes of the last topic on Thursday but have
> somehow lost them. I will listen to the audio and update those comments
> early next week.
>
> If you have issues with the minutes drop the chairs a note, *or*
> send us a pull request:
>
> https://github.com/DNSOP/wg-materials/blob/master/dnsop-
> ietf102/dnsop-ietf102-minutes-1.txt
>
> IETF103:  I am thinking we will focus on one meeting next time,
> though who knows, we may get 100 new documents next month.
>
> Also, we will send some documents through for adoption in August, but
> the chairs feel that Europe is much more civilized in how they take
> the month as a holiday, and will probably slow down more than normal.
>
> -
> Actions:
>
> Here is what we have in terms of actions from this week.
> If we missed something, it's my fault.
>
> * draft-ietf-dnsop-kskroll-sentinel - Submitted to IESG
>
> * draft-ietf-dnsop-isp-ip6rdns - Submitted to IESG
>
> * draft-ietf-dnsop-attrleaf
> * draft-ietf-dnsop-attrleaf-fix
> - WGLC has ended, Shepherd write up is underway (with thanks
> to Mr. Crocker!), and working with Benno on this.  He's
> double checking everything to make sure pushing the button
> won't end the world.
>
> - The chairs feel these documents need to move thru the process
> promptly so other working groups can seek their guidance.
>
> * draft-ietf-dnsop-rfc5011-security-considerations
> - We are holding this for now, and the chairs feel that
> there is an issue with consensus and content that will
> most likely kill this moving forward.
>
> * draft-ietf-dnsop-terminology-bis
> - Write-up is wrapping up and *will be submitted* by Monday at
> the latest.
>
> * draft-ietf-dnsop-dns-capture-format
> - WGLC last call ended with two issues to be addressed.
> These will be resolved in Early August after Holiday.
>
> * draft-huque-dnsop-multi-provider-dnssec:  Adopted !
>
> * draft-ietf-dnsop-algorithm-update - is almost ready for WGLC
>
> * draft-dupont-dnsop-rfc2845bis - is almost ready for WGLC
>
> * draft-wessels-dns-zone-digest - Candidate for adoption
>
> * draft-kh-dnsop-7706bis - Candidate for adoption.
>
> * draft-bortzmeyer-rfc7816bis - Candidate for adoption
>
> * draft-song-atr-large-resp - Candidate for adoption, though more
> contentious.
>
> * DNS Cookies and their Operational Impacts
> - We expect to see drafts addressing these issues, as well as
> drafts urging to move cookies to Historic to appear..
>
> * Addressing the Zone Apex Synthetic Records (CNAME/ALIAS/ANAME/ZNAME)
> - We will continue to work to address this gap between the user
> community
> and the protocol folks.
>
>
> ___
> 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] Terminology question: split DNS

[Steve Crocker]

I haven't been following the current thread but I have encountered this
topic before and I have thought about the implications for DNSSEC.

The terminology of "split DNS" -- and equivalently "split horizon DNS" --
is, in my opinion, a bit limited.  It's not too hard to imagine further
carve outs.  For me, the general case is at every point in the network,
there is an external world and an internal world.  Let's say I am in charge
of the systems that support a department within a division of a very large
company.  I could imagine a department DNS that resolves names within the
department but forwards other queries to the division DNS resolvers.  They
resolve names within the division and forward other queries to the
company's resolvers.  The company's resolvers handle queries for names
defined by the company and forward other queries to the outside.

If we're going to tackle this problem, let's do it cleanly and completely.

Steve


On Mon, Mar 19, 2018 at 5:14 PM, Paul Wouters  wrote:

> On Mon, 19 Mar 2018, John Heidemann wrote:
>
> +1 on "split-horizon dns" as the term, over "split dns" and some other
>> neologism, on the basis of running code and existing documentation and
>> existing wide use.
>>
>
> I and google disagree:
>
> "split dns":  72900 hits
> "split horizon dns": 5640 hits
>
>
> If the document is about explaining terminology, it must explain "split
> dns" and can say another term for it is "split horizon dns", but not the
> other way around.
>
> I personally don't hear (or use) "split horizon dns"
>
> 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] Measuring DNS TTL clamping in the wild

[Steve Crocker]

I would be very interested in a bit more precision here.  Is there a way to say 
what is permissible vs impermissible re TTLs, and is there a way to say what is 
desirable vs undesirable re TTLs?  We all understand that longer TTLs reduce 
the frequency of refresh at the expense of slower response whenever the 
authoritative information changes.  However, some fraction of the recursive 
resolvers impose minimum and/or maximum limits on the TTLs they receive from 
the authoritative servers.

Shortening TTLs increases the amount of traffic between the recursive resolvers 
and authoritative resolvers and lengthens the response time for some queries.  
However, I don’t think there is any service guarantee with respect to an 
individual query that is violated by shortening the TTL.

Lengthening a TTL, on the other hand, does change one of the service 
guarantees.  When there is a change in the entry in the authoritative server, 
what is the maximum time until that change is guaranteed to be propagated 
throughout the net?  This depends primarily on the TTL.  However, when the TTL 
is lengthened by the recursive resolvers, the upper bound for propagation of a 
change is similarly increased.

Is there any common understanding of how much lengthening is permitted?  Is 
commonplace?

Let me make a guess that the only lengthening that takes place in practice is a 
floor of ten seconds.

Comments?

Thanks,

Steve




> On Dec 1, 2017, at 12:52 PM, Jared Mauch  wrote:
> 
> 
> 
>> On Dec 1, 2017, at 12:23 PM, Paul Hoffman  wrote:
>> 
>> On 1 Dec 2017, at 9:16, Ólafur Guðmundsson wrote:
>> 
>>> We are getting into religion here, the original poster called people that
>>> cap TTL's Heretics,
>> 
>> Looking through the mail archives, no one other than you is using that term.
> 
> I think this is subject to interpretation, some people view the done 
> differently.
> The subject line felt hostile.. 2nd attempt to adjust subject-line to make it 
> less hostile.
> 
> - jared
> 
> ___
> 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] [homenet] My assessment of .homenet as described during the WG session yesterday.

[Steve Crocker]

On the other hand, might there be value in seeing how much errant traffic goes 
to the root so it can be reported and used to inform vendors, network 
architects, network administrators, et al?

Given the amount of bogus traffic already goes to the root, I’m not immediately 
worried this will increase the traffic level to a point of concern.

And I remain puzzled as to why a simple NXDOMAIN response from the root isn’t 
exactly the right thing and why it matters whether it’s signed or not.

Steve

> On Mar 30, 2017, at 2:05 PM, Paul Vixie  wrote:
> 
> On Thursday, March 30, 2017 5:54:50 PM GMT Brian Dickson wrote:
>> Mark,
>> 
>> When I say, "never reaches the roots", this is what I mean:
>> Resolution of "example." is, by design, intercepted by
>> homenet resolvers, and never reaches the outside world.
>> Do you concur with this statement?
>> 
>> ...
> 
> i'm not mark, but i'd like to speak on a related topic.
> 
> by design, queries that result in RFC 1918 addresses, and queries for RFC 
> 1918 
> PTR names, were to be intercepted by local resolvers.
> 
> let me know if you can't access DNS-OARC's DITL archives, which will show you 
> how prominent both kinds those queries loom in actual root name service load.
> 
> i predict that foo.bar. will do likewise, whatever its design. 
> this is the one saving grace in asking for a real root zone delegation: we 
> can 
> add an NS pointing to localhost, and try to get subsequent queries to go to 
> heck rather than to the root servers.
> 
> vixie
> 
> ___
> 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] WG review of draft-ietf-homenet-dot-03

[Steve Crocker]

Before addressing the questions you've asked, let me about the rest of the 
picture.  How do names get assigned within the local homenet domain?

Steve

Sent from my iPhone

> On Mar 20, 2017, at 9:25 PM, Ted Lemon  wrote:
> 
> I'm curious what Russ and Steve think about this as an alternative.   It 
> seems a bit byzantine to me, but I can't say that I object to it on 
> principal.   It does create a lot of extra work for ICANN, though, and it 
> would be a bit more brittle than just doing an unsigned delegation: we now 
> have to have some way to get current versions of these signatures into the 
> homenet resolver.
> 
> Further comments inline.
> 
>> On Mar 20, 2017, at 6:08 PM, Brian Dickson  
>> wrote:
>> What is required for the above, is generation of DNSSEC records including 
>> RRSIG(NS), NSEC, and RRSIG(NSEC), for "homenet" TLD.
> 
> Yes.
> 
>> Since the queries are never meant to reach the root servers, the presence or 
>> absence of "homenet" in the root is mostly moot.
> 
> Sure.
> 
>> The only technical requirement is that suitable DNSSEC records be generated, 
>> and that the special-purpose homenet DNS resolvers are able to have 
>> up-to-date copies of these DNSSEC records.
> 
> Sure.
> 
>> As a technical matter, this does not require publishing these records in the 
>> root zone, although that would be one way of achieving the necessary 
>> requirement.
> 
> True.
> 
>> Perhaps the homenet WG folks could talk to the ICANN folks about ways of 
>> accomplishing the above, without the need for publishing the unsigned 
>> delegation in the root zone?
> 
> Strictly speaking I think this is something the IESG would have to do.  I 
> don't object to this as a solution, but operationally I think it's a lot more 
> work.   It may be that it's worth doing it, since it might be applicable to 
> other special-use name allocations.
> 
>> The benefit of not publishing, is that any queries that do hit the root 
>> servers, would get a signed NXDOMAIN, which IMHO is a more correct response.
> 
> Yes.   I'm not sure that's enough to justify the extra work.
> 
> ___
> 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] WG review of draft-ietf-homenet-dot-03

[Steve Crocker]

Thanks for the quick response.

> On Mar 20, 2017, at 5:14 PM, Ted Lemon  wrote:
> 
> On Mar 20, 2017, at 4:57 PM, Steve Crocker  wrote:
>> First, neither my opinion as an individual nor my opinion as an official of 
>> ICANN should be considered definitive, normative or otherwise compelling 
>> except and unless the substance of what I say makes sense
> 
> I was being facetious, in case it wasn’t obvious. :)

Heh.  I guess it wasn’t as obvious to me as it should have been.

> 
>> Second, speaking as an observer and with some familiarity with DNS, DNSSEC 
>> and with the process related to entering strings into the root zone, the 
>> homenet sequence seems backwards to me.  I would have expected the 
>> coordination to happen before or during the working group.  If the homenet 
>> spec is approved as a proposed standard but there’s no agreement to put 
>> .homenet into the root or there is a glitch somewhere else in the 
>> coordination, the IETF will be in the position of having published an 
>> unimplementable standard.  Running code is the hallmark of the IETF and a 
>> primary distinguishing characteristic, so I’m surprised and puzzled if this 
>> is the path the IETF is taking.
> 
> It is a bit backwards.   The name '.home' got allocated in the HNCP RFC 
> without due process, so we wound up suddenly needing to fix that.
> 
>> Third, having now read the homenet spec, I see what the point is, but I can 
>> also see a bunch of questions.  It looks like the idea is to establish a 
>> local DNS tree that is good only within a home or similar contained 
>> environment.  This is analogous to a 192.168.x.x environment.  To make this 
>> work, ignoring DNSSEC for a minute, it seems to me the DNS queries have to 
>> go to a DNS resolver that is acting as a local authoritative server for 
>> .homenet.  This is problematic because there are often multiple DNS stub 
>> resolvers operating within a single machine, and there’s no guarantee they 
>> will send their queries to a particular local DNS server.  The only way I 
>> see to force the issue is to intercept all queries headed for port 53 
>> outside the local environment and examine them for .homenet.
> 
> You should bear in mind that homenet is assuming the Internet of maybe five 
> years from now, more so than the Internet of now, although obviously we'd 
> like to get done sooner than that.   So you should assume that stub resolvers 
> never, ever do anything so foolish as to trust a recursive resolver to 
> validate for them.  And, indeed, as you say, any resolver that doesn’t use 
> the host's resolver configuration to figure out which resolver to talk to 
> isn't going to be able to resolve queries in the .homenet domain.

It is hard to predict how things are going to evolve.  The idea that all stub 
resolvers will be validating everything they get is a nice goal, and I 
certainly wouldn’t want to choose a path that precludes that, but I think it’s 
prudent to also design for the present.  Assume we’ll be somewhere along the 
path between here and there.

If you assume the local environment is going to get complicated and that 
signing of the local domain will become important in order to guard against 
hijacking by errant devices inside the perimeter, it looks to me there will 
have to be a local trust anchor. For devices brought into the environment, DHCP 
already assigns the IP address and the DNS servers.  It can “easily” be 
augmented to hand out the public key of the local hierarchy.  Or, I suppose, 
since I’ve just posited that the DHCP server will tell the new device which DNS 
server to use, the device could then query the DNS server to find out if it has 
a signed .homenet domain and what its public key is.

I’m typing as I’m thinking, and I may have overlooked something quite basic and 
embarrassing.  I’ll stop typing now ;)

> 
> We don't consider this to be a serious problem.   Are you aware of some 
> reason to think it is?
> 
>> Fourth, I’m not sure I understand what the issue is with DNSSEC.  If the 
>> queries are intercepted locally and if you trust the internal environment — 
>> an assumption you might want to ponder carefully as internal environments 
>> become ever more complicated and populated by devices and software from 
>> many, many sources — DNSSEC doesn’t come into play.  If the queries are not 
>> intercepted locally, you’ll get the official answer, viz NXDOMAIN.  I gather 
>> you want something else, and perhaps I didn’t read carefully enough to 
>> understand what that something else is and why it would be helpful.
> 
> The queries are being resolved by a local resolver.  But they are being 
> validated by the stub.   So if the

Re: [DNSOP] WG review of draft-ietf-homenet-dot-03

[Steve Crocker]

Ted, et al,

I’ve been watching this dialog and staying silent, but since I’m referenced and 
quoted directly, let me offer some points.

First, neither my opinion as an individual nor my opinion as an official of 
ICANN should be considered definitive, normative or otherwise compelling except 
and unless the substance of what I say makes sense.  (Well, I guess when I 
speak officially as chair of ICANN’s board, it’s been coordinated and approved 
in advance and carries the weight of the organization, but I haven’t spoken in 
that capacity on this subject and I expect that if and when ICANN does speak 
officially on this subject, it’s likely to come from others.)

Second, speaking as an observer and with some familiarity with DNS, DNSSEC and 
with the process related to entering strings into the root zone, the homenet 
sequence seems backwards to me.  I would have expected the coordination to 
happen before or during the working group.  If the homenet spec is approved as 
a proposed standard but there’s no agreement to put .homenet into the root or 
there is a glitch somewhere else in the coordination, the IETF will be in the 
position of having published an unimplementable standard.  Running code is the 
hallmark of the IETF and a primary distinguishing characteristic, so I’m 
surprised and puzzled if this is the path the IETF is taking.

Third, having now read the homenet spec, I see what the point is, but I can 
also see a bunch of questions.  It looks like the idea is to establish a local 
DNS tree that is good only within a home or similar contained environment.  
This is analogous to a 192.168.x.x environment.  To make this work, ignoring 
DNSSEC for a minute, it seems to me the DNS queries have to go to a DNS 
resolver that is acting as a local authoritative server for .homenet.  This is 
problematic because there are often multiple DNS stub resolvers operating 
within a single machine, and there’s no guarantee they will send their queries 
to a particular local DNS server.  The only way I see to force the issue is to 
intercept all queries headed for port 53 outside the local environment and 
examine them for .homenet.

Fourth, I’m not sure I understand what the issue is with DNSSEC.  If the 
queries are intercepted locally and if you trust the internal environment — an 
assumption you might want to ponder carefully as internal environments become 
ever more complicated and populated by devices and software from many, many 
sources — DNSSEC doesn’t come into play.  If the queries are not intercepted 
locally, you’ll get the official answer, viz NXDOMAIN.  I gather you want 
something else, and perhaps I didn’t read carefully enough to understand what 
that something else is and why it would be helpful.

What emerged most clearly for me in reading the homenet spec is the apparent 
desire to have a locally served domain, which seems similar in some respects to 
a classic split domain, and the real challenge, as best I can see, is 
characterizing the perimeter and internal topology.

And returning to the first point, let’s do indeed get people together to 
understand how the parts are supposed to fit together.  Over at ICANN we try 
very hard to be of service and we also take the security and stability of the 
DNS, and particularly the root, very seriously.  A non-standard request is 
almost going to be the beginning of lengthy discussion.  Our mind set will be 
aimed at getting it right, not arguing about who’s in charge.

Steve



> On Mar 20, 2017, at 4:15 PM, Ted Lemon  wrote:
> 
> On Mar 20, 2017, at 3:44 PM, Russ Housley  <mailto:hous...@vigilsec.com>> wrote:
>> This document does not describe a collaborative approach.
> 
> The document specifies what the working group needs to have happen in order 
> for the specification to work.   How the collaboration happens is out of 
> scope for the homenet working group.   The working group understands that a 
> process needs to be invented, and I believe that the document says so.
> 
>> Steve Crocker has already stated that he does not believe that entries that 
>> cannot be DNSSEC signed belong in the DNS root zone.  I know that others 
>> share this view.  For this reason, I do not think that the IETF should 
>> approve a document that specifies this processing until the root zone 
>> publication process is successful.
> 
> 
> Yes, I understand that Steve Crocker has said this.   And perhaps Steve 
> Crocker's opinion should be considered normative.   However, like you, Steve 
> didn't give a technical reason why this policy must be applied universally, 
> even in the case of technical uses.
> 
> We have a legitimate question to answer here.   It seems reasonable to say 
> that under the MoU, the IETF can designate a name for the use that homenet is 
> trying to designate.   Maybe the IETF consensus will be that the IETF should 
> not de

Re: [DNSOP] ALT-TLD and (insecure) delgations.

[Steve Crocker]

We (ICANN) have no mechanism or process for inserting a DNAME record into the 
root.  We do have a process for considering the general issue, but, so far as I 
know, no one has yet brought that idea into the ICANN/PTI arena.

Steve Crocker
[I am having trouble sending from st...@shinkuro.com, but I am receiving mail 
without trouble.  Please continue to send mail to me at st...@shinkuro.com]

> On Feb 3, 2017, at 12:28 PM, Brian Dickson  
> wrote:
> 
> 
> 
> On Fri, Feb 3, 2017 at 12:21 PM, Steve Crocker  <mailto:steve.croc...@gmail.com>> wrote:
> And just to stir the pot a bit, what would you have ICANN do if someone 
> applies for .alt as a top level domain?  Is it ok if we say yes and delegate 
> the name?  If not, what is the basis for us to say no?
> 
> The insertion of the DNAME record in the root, instantiates the ALT domain. 
> It says the ALT domain exists.
> 
> However, the DNAME target of an empty zone, assures (with DNSSEC signatures) 
> that no names below ALT exist.
> 
> So, a query to a root server for "alt." would get the DNAME (if the query was 
> for type DNAME or type ANY), or would get "NODATA" for any other RRTYPE.
> 
> And a query to a root server for "anything.alt" would get the DNAME to 
> AS112.ARPA, and the subsequent query (rewritten as anything.as112.arpa) would 
> get NXD.
> 
> As to the question about applying for "alt": it means no one can apply for 
> .alt as a TLD, because it is taken. That is the basis for saying "no".
> 
> Brian
>  
> 
> 
> Steve Crocker
> [I am having trouble sending from st...@shinkuro.com 
> <mailto:st...@shinkuro.com>, but I am receiving mail without trouble.  Please 
> continue to send mail to me at st...@shinkuro.com <mailto:st...@shinkuro.com>]
> 
>> On Feb 3, 2017, at 12:18 PM, Brian Dickson > <mailto:brian.peter.dick...@gmail.com>> wrote:
>> 
>> The DNAME has an effect similar to delegation, except that in the case of 
>> the AS112++ RFC ( https://tools.ietf.org/html/rfc7535 
>> <https://tools.ietf.org/html/rfc7535> ) , the target is a well-known & 
>> published empty zone (as112.arpa.)
>> 
>> (Delegation and DNAME cannot coexist for the same owner name - that is one 
>> of the edicts for DNAME, similar to CNAME.)
>> 
>> Any local configuration of something.alt (as an authoritatively served zone) 
>> would be matched before checking the cache or attempting recursive 
>> resolution, per 103[345].
>> 
>> I don't have any desire or intention of local something.alt, I'm just 
>> pointing out that the existence of a signed NXD result (via DNAME to an 
>> empty zone) doesn't break such a set-up.
>> 
>> 
>> 
>> The reason for DNAME instead of delegation, is that it avoids the operators 
>> of AS112 instances from having to configure the new zone(s) whenever a new 
>> "delegation" occurs.
>> 
>> If, instead, a delegation were done, the specific zone (.alt) would need to 
>> be configured and served somewhere.
>> 
>> RFC7535 is designed to avoid the need for coordination in configuring such 
>> zones.
>> 
>> (RFC7535 also allows authorities for other places in the DNS tree to make 
>> use of AS112, but that is a non-sequitur.)
>> 
>> Brian
>> 
>> On Fri, Feb 3, 2017 at 12:06 PM, Steve Crocker > <mailto:steve.croc...@gmail.com>> wrote:
>> Are you also expecting ALT will never be delegated in the root?  If it were 
>> to be delegated in the root, what impact would that have on the uses you 
>> have in mind?
>> 
>> Steve Crocker
>> [I am having trouble sending from st...@shinkuro.com 
>> <mailto:st...@shinkuro.com>, but I am receiving mail without trouble.  
>> Please continue to send mail to me at st...@shinkuro.com 
>> <mailto:st...@shinkuro.com>]
>> 
>> 
>>> On Feb 3, 2017, at 12:02 PM, Brian Dickson >> <mailto:brian.peter.dick...@gmail.com>> wrote:
>>> 
>>> Stephane wrote: 
>>> On Wed, Feb 01, 2017 at 03:28:29PM -0500,
>>>  Warren Kumari http://kumari.net/>> wrote 
>>>  a message of 103 lines which said:
>>> 
>>> > or 2: request that the IANA insert an insecure delegation in the
>>> > root, pointing to a: AS112 or b: an empty zone on the root or c"
>>> > something similar.
>>> 
>>> Here, people may be interested by draft-bortzmeyer-dname-root (expired
>>> but could be revived). The main objection was the privacy issue
>>> (sending user queries to the "random" operat

Re: [DNSOP] ALT-TLD and (insecure) delgations.

[Steve Crocker]

And just to stir the pot a bit, what would you have ICANN do if someone applies 
for .alt as a top level domain?  Is it ok if we say yes and delegate the name?  
If not, what is the basis for us to say no?


Steve Crocker
[I am having trouble sending from st...@shinkuro.com, but I am receiving mail 
without trouble.  Please continue to send mail to me at st...@shinkuro.com]

> On Feb 3, 2017, at 12:18 PM, Brian Dickson  
> wrote:
> 
> The DNAME has an effect similar to delegation, except that in the case of the 
> AS112++ RFC ( https://tools.ietf.org/html/rfc7535 
> <https://tools.ietf.org/html/rfc7535> ) , the target is a well-known & 
> published empty zone (as112.arpa.)
> 
> (Delegation and DNAME cannot coexist for the same owner name - that is one of 
> the edicts for DNAME, similar to CNAME.)
> 
> Any local configuration of something.alt (as an authoritatively served zone) 
> would be matched before checking the cache or attempting recursive 
> resolution, per 103[345].
> 
> I don't have any desire or intention of local something.alt, I'm just 
> pointing out that the existence of a signed NXD result (via DNAME to an empty 
> zone) doesn't break such a set-up.
> 
> 
> 
> The reason for DNAME instead of delegation, is that it avoids the operators 
> of AS112 instances from having to configure the new zone(s) whenever a new 
> "delegation" occurs.
> 
> If, instead, a delegation were done, the specific zone (.alt) would need to 
> be configured and served somewhere.
> 
> RFC7535 is designed to avoid the need for coordination in configuring such 
> zones.
> 
> (RFC7535 also allows authorities for other places in the DNS tree to make use 
> of AS112, but that is a non-sequitur.)
> 
> Brian
> 
> On Fri, Feb 3, 2017 at 12:06 PM, Steve Crocker  <mailto:steve.croc...@gmail.com>> wrote:
> Are you also expecting ALT will never be delegated in the root?  If it were 
> to be delegated in the root, what impact would that have on the uses you have 
> in mind?
> 
> Steve Crocker
> [I am having trouble sending from st...@shinkuro.com 
> <mailto:st...@shinkuro.com>, but I am receiving mail without trouble.  Please 
> continue to send mail to me at st...@shinkuro.com <mailto:st...@shinkuro.com>]
> 
> 
>> On Feb 3, 2017, at 12:02 PM, Brian Dickson > <mailto:brian.peter.dick...@gmail.com>> wrote:
>> 
>> Stephane wrote: 
>> On Wed, Feb 01, 2017 at 03:28:29PM -0500,
>>  Warren Kumari http://kumari.net/>> wrote 
>>  a message of 103 lines which said:
>> 
>> > or 2: request that the IANA insert an insecure delegation in the
>> > root, pointing to a: AS112 or b: an empty zone on the root or c"
>> > something similar.
>> 
>> Here, people may be interested by draft-bortzmeyer-dname-root (expired
>> but could be revived). The main objection was the privacy issue
>> (sending user queries to the "random" operators of AS112.)
>> 
>> My opinion on these issues are as follows, roughly:
>> I am in favor of AS112 for ALT
>> For AS112, I prefer the AS112++ method (DNAME)
>> I do not see why the DNAME would/should not be DNSSEC signed
>> Any local use of ALT can be served locally and signed using an alternative 
>> trust anchor
>> I don't think there is any issue with having both the NXD from the root, and 
>> the local assertion of existence, both present (in cache and in 
>> authoritative data respectively)
>> Maybe there are issues with specific implementations? 
>> If anyone knows of such problems, it would be helpful to identify them along 
>> with the implementation and version
>> For AS112 privacy, perhaps someone should write up a recommendation to set 
>> up local AS112 instances, to provide privacy, as an informational RFC?
>> Even simply through resolver configurations, without a full AS112 "announce 
>> routes"?
>> Do any resolver packages offer such a simple AS112 set-up?
>> Maybe the efforts for privacy should start there (implement first, then 
>> document)?
>> Do any stub resolver packages include host-local AS112 
>> features/configurations?
>> Overall, I'm obviously in favor of use of ALT, and for signing whatever is 
>> done for ALT, and for use of DNAME for ALT.
>> 
>> Brian "DNAME" Dickson
>> ___
>> DNSOP mailing list
>> DNSOP@ietf.org <mailto:DNSOP@ietf.org>
>> https://www.ietf.org/mailman/listinfo/dnsop 
>> <https://www.ietf.org/mailman/listinfo/dnsop>
> 
> 
> 
> 
> 

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

Re: [DNSOP] ALT-TLD and (insecure) delgations.

[Steve Crocker]

Are you also expecting ALT will never be delegated in the root?  If it were to 
be delegated in the root, what impact would that have on the uses you have in 
mind?

Steve Crocker
[I am having trouble sending from st...@shinkuro.com, but I am receiving mail 
without trouble.  Please continue to send mail to me at st...@shinkuro.com]


> On Feb 3, 2017, at 12:02 PM, Brian Dickson  <mailto:brian.peter.dick...@gmail.com>> wrote:
> 
> Stephane wrote: 
> On Wed, Feb 01, 2017 at 03:28:29PM -0500,
>  Warren Kumari http://kumari.net/>> wrote 
>  a message of 103 lines which said:
> 
> > or 2: request that the IANA insert an insecure delegation in the
> > root, pointing to a: AS112 or b: an empty zone on the root or c"
> > something similar.
> 
> Here, people may be interested by draft-bortzmeyer-dname-root (expired
> but could be revived). The main objection was the privacy issue
> (sending user queries to the "random" operators of AS112.)
> 
> My opinion on these issues are as follows, roughly:
> I am in favor of AS112 for ALT
> For AS112, I prefer the AS112++ method (DNAME)
> I do not see why the DNAME would/should not be DNSSEC signed
> Any local use of ALT can be served locally and signed using an alternative 
> trust anchor
> I don't think there is any issue with having both the NXD from the root, and 
> the local assertion of existence, both present (in cache and in authoritative 
> data respectively)
> Maybe there are issues with specific implementations? 
> If anyone knows of such problems, it would be helpful to identify them along 
> with the implementation and version
> For AS112 privacy, perhaps someone should write up a recommendation to set up 
> local AS112 instances, to provide privacy, as an informational RFC?
> Even simply through resolver configurations, without a full AS112 "announce 
> routes"?
> Do any resolver packages offer such a simple AS112 set-up?
> Maybe the efforts for privacy should start there (implement first, then 
> document)?
> Do any stub resolver packages include host-local AS112 
> features/configurations?
> Overall, I'm obviously in favor of use of ALT, and for signing whatever is 
> done for ALT, and for use of DNAME for ALT.
> 
> Brian "DNAME" Dickson
> ___
> DNSOP mailing list
> DNSOP@ietf.org <mailto: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] [homenet] WGLC on "redact" and "homenet-dot"

[Steve Crocker]

Ted,

I am truly confused by your note.  I sense I am missing something fundamental.

See specific questions below.

Thanks,

Steve

> On Dec 15, 2016, at 12:20 PM, Ted Lemon  wrote:
> 
> On Dec 15, 2016, at 11:05 AM, Jacques Latour  > wrote:
>> Where do you delegate homenet to? Advanced DNSSEC validation may check for 
>> proper delegation?  
> 
> I think we should ask ICANN to set up an unsecured delegation of .homenet to 
> the AS112 servers.

I don’t understand what is meant by an “unsecured delegation.”  I also don’t 
understand what sort of delegation you want, irrespective of whether DNSSEC is 
involved.

I think there are two very big hurdles implicit in “I think we should ask ICANN 
to set up …”  One is the technical hurdle of whether this is a sensible thing 
technically with respect to the security and stability of the Internet.  It 
will take a fairly long time and a lot of analysis for ICANN to get comfortable 
with such a result, and I would not count on a positive outcome.

That’s the first hurdle.  The second hurtle may be even harder.  The only 
existing procedures for adding new delegations to the root are for:

o New ccTLDs, i.e. when new countries are created and get two letter codes from 
the ISO 3166 Maintenance Agency;

o New IDN ccTLDs via the Fast Track; and

o New gTLDs through the gTLD process.

The first two would not apply.  The window for the third was closed a while ago 
and we are studying when and how to reopen the window.  The process is geared 
toward prospective operators of registries.  A substantial fee is required, and 
an even more substantial investment in registry operation is required.

I suspect what’s intended here is something qualitatively different, e.g. some 
sort of entry in the root that returns a fixed result, not a pointer to name 
servers.  Aside from the technical questions I mentioned above, we would also 
have to sort out the policy questions, e.g. what are the rules for accepting 
such requests, what happens if there are competing requests, and perhaps others 
that aren’t occurring to me as I write this.

>   In order for names under .homenet to be validated by DNSSEC, it would be 
> necessary for the validating resolver to have a trust anchor for any homenet 
> on which it wants to do validation, and a means of differentiating between 
> home nets so that it doesn’t use the wrong key to validate.

Yes, but the way the sentence is written suggests this would difficult or odd.  
In a homenet environment, if you have a local name server responding to 
requests as an authority, it can sign those requests as the authority.  The 
requesting resolver will have to have the public key associated with the 
authority.  This is a configuration matter.  When the requesting resolver is 
told which resolver on the edge of the homenet is authoritative for the homenet 
environment, it should also learn that resolver’s public key.  This seems like 
a DHCP issue.

>   But that’s out of scope for this discussion: the point of this discussion 
> is simply to figure out whether we want to do the hard thing or the easy 
> thing: .homenet or home.arpa.

I don’t see a difference between .homenet or home.arpa in this regard.


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

Re: [DNSOP] [homenet] WGLC on "redact" and "homenet-dot"

[Steve Crocker]

Mike,

A query to the root for .homenet results in a *signed* answer that .homenet 
does not exist.  This should suffice for the purpose you have in mind.

Ralph,

Re moving to the homenet list, I will try to send the same info there once I 
have time to sign up for that list.

Steve

> On Dec 14, 2016, at 12:23 PM, Michael StJohns  wrote:
> 
> On 12/14/2016 12:07 PM, Ted Lemon wrote:
>> I hope it was obvious that I was pretty confident that you actually had a 
>> reason.   :)
>> 
>> The issue what what you are saying is that sometimes it is technically 
>> correct for a name to not be validatable.   The reason we want an unsecured 
>> delegation for .homenet is that .homenet can't be validated using the root 
>> trust anchor, because the name is has no globally unique meaning.   So the 
>> reason that you've given doesn't apply to this case, although I completely 
>> agree with your reason as it applies to the case of names that are globally 
>> unique.
> 
> I went back and forth on this three times in 3 minutes "Steve's right, no 
> Ted's right, no, Steve's right" before settling on "I think Steve is mostly 
> right, but there may be an alternative third approach".
> 
> Here's the reasoning:   Either your home router understands .homenet or it 
> doesn't.  If it doesn't, then your homenet shouldn't be using .homenet and 
> any .homenet lookups to the real world should fail.  If it does, then it 
> should trap .homenet queries and do with it what it will.
> 
> Doing it Steve's way removes one attack surface for non-compliant routers on 
> home networks and for all the rest of the networks (e.g. feeding a user a URL 
> with a .homenet name on a fake webpage).
> 
> However, I think doing it Steve's way requires a *real* TLD zone for 
> .homenet, if for no other reason than to include NSEC and NSEC3 records 
> indicating an empty domain.
> 
> The third way is to do no delegation from the root for .homenet and just 
> ensure that that name never gets registered and published.
> 
> "If it's stupid and it works, it's not stupid".
> 
> Mike
> 
>> 
>> On Wed, Dec 14, 2016 at 11:59 AM, Steve Crocker > <mailto:st...@shinkuro.com>> wrote:
>> The latter.  All DNS answers at all levels should be signed to assure the 
>> querier of the integrity of the answer.  This has been the goal and best 
>> practice for a very long time.  For example, it was the explicit objective 
>> of the quote substantial DNSSEC effort funded by the US Dept of Homeland 
>> Security starting in 2004.
>> 
>> Within ICANN, in 2009 we made it a formal requirement of all new gTLDs must 
>> be signed.  The ccTLDs are not subject to ICANN rules but they have been 
>> gradually moving toward signed status.  Most of the major ccTLDs are signed 
>> and many of the others are too.  Detailed maps are created every week by 
>> ISOC.
>> 
>> I will also try to contribute to the homenet mailing list.
>> 
>> Steve
>> 
>> Sent from my iPhone
>> 
>> On Dec 14, 2016, at 11:36 AM, Ted Lemon > <mailto:mel...@fugue.com>> wrote:
>> 
>>> Is this a matter of religious conviction, or is there some issue with 
>>> unsecured delegations in the root that you are assuming is so obvious that 
>>> you don't need to tell us about it?   :)
>>> 
>>> On Wed, Dec 14, 2016 at 11:18 AM, Steve Crocker >> <mailto:st...@shinkuro.com>> wrote:
>>> I am strongly opposed to unsecured delegations in the root zone.  No matter 
>>> what the problem is, an unsecured delegation is not the answer.
>>> 
>>> Steve
>>> 
>>>> On Dec 14, 2016, at 11:11 AM, Suzanne Woolf >>> <mailto:suzworldw...@gmail.com>> wrote:
>>>> 
>>>> Hi all,
>>>> 
>>>> DNSOP participants who are interested in the special use names problem 
>>>> might want to review draft-ietf-homenet-redact 
>>>> (https://datatracker.ietf.org/doc/draft-ietf-homenet-redact/ 
>>>> <https://datatracker.ietf.org/doc/draft-ietf-homenet-redact/>) and 
>>>> draft-ietf-homenet-dot 
>>>> (https://datatracker.ietf.org/doc/draft-ietf-homenet-dot/ 
>>>> <https://datatracker.ietf.org/doc/draft-ietf-homenet-dot/>) for the WGLC 
>>>> on them in the HOMENET wg.
>>>> 
>>>> WGLC comments should go to the WG list, home...@ietf.org 
>>>> <mailto:home...@ietf.org>.
>>>> 
>>>> If you do, it will also be helpful to look at RFC 

Re: [DNSOP] [homenet] WGLC on "redact" and "homenet-dot"

[Steve Crocker]

If it doesn’t have a globally unique meaning, it doesn’t make sense to query 
the root for an answer.

What problem is trying to be solved?  I suspect whatever the problem actually 
is, the answer will be something other than adding an unsecured delegation to 
the root zone.

Steve




> On Dec 14, 2016, at 12:07 PM, Ted Lemon  wrote:
> 
> I hope it was obvious that I was pretty confident that you actually had a 
> reason.   :)
> 
> The issue what what you are saying is that sometimes it is technically 
> correct for a name to not be validatable.   The reason we want an unsecured 
> delegation for .homenet is that .homenet can't be validated using the root 
> trust anchor, because the name is has no globally unique meaning.   So the 
> reason that you've given doesn't apply to this case, although I completely 
> agree with your reason as it applies to the case of names that are globally 
> unique.
> 
> On Wed, Dec 14, 2016 at 11:59 AM, Steve Crocker  <mailto:st...@shinkuro.com>> wrote:
> The latter.  All DNS answers at all levels should be signed to assure the 
> querier of the integrity of the answer.  This has been the goal and best 
> practice for a very long time.  For example, it was the explicit objective of 
> the quote substantial DNSSEC effort funded by the US Dept of Homeland 
> Security starting in 2004.
> 
> Within ICANN, in 2009 we made it a formal requirement of all new gTLDs must 
> be signed.  The ccTLDs are not subject to ICANN rules but they have been 
> gradually moving toward signed status.  Most of the major ccTLDs are signed 
> and many of the others are too.  Detailed maps are created every week by ISOC.
> 
> I will also try to contribute to the homenet mailing list.
> 
> Steve
> 
> Sent from my iPhone
> 
> On Dec 14, 2016, at 11:36 AM, Ted Lemon  <mailto:mel...@fugue.com>> wrote:
> 
>> Is this a matter of religious conviction, or is there some issue with 
>> unsecured delegations in the root that you are assuming is so obvious that 
>> you don't need to tell us about it?   :)
>> 
>> On Wed, Dec 14, 2016 at 11:18 AM, Steve Crocker > <mailto:st...@shinkuro.com>> wrote:
>> I am strongly opposed to unsecured delegations in the root zone.  No matter 
>> what the problem is, an unsecured delegation is not the answer.
>> 
>> Steve
>> 
>>> On Dec 14, 2016, at 11:11 AM, Suzanne Woolf >> <mailto:suzworldw...@gmail.com>> wrote:
>>> 
>>> Hi all,
>>> 
>>> DNSOP participants who are interested in the special use names problem 
>>> might want to review draft-ietf-homenet-redact 
>>> (https://datatracker.ietf.org/doc/draft-ietf-homenet-redact/ 
>>> <https://datatracker.ietf.org/doc/draft-ietf-homenet-redact/>) and 
>>> draft-ietf-homenet-dot 
>>> (https://datatracker.ietf.org/doc/draft-ietf-homenet-dot/ 
>>> <https://datatracker.ietf.org/doc/draft-ietf-homenet-dot/>) for the WGLC on 
>>> them in the HOMENET wg.
>>> 
>>> WGLC comments should go to the WG list, home...@ietf.org 
>>> <mailto:home...@ietf.org>.
>>> 
>>> If you do, it will also be helpful to look at RFC 7788, which specifies the 
>>> Home Networking Control Protocol for homenets. 
>>> 
>>> The redact draft is intended to remove the inadvertent reservation of 
>>> “.home” as the default namespace for homenets in RFC 7788. 
>>> 
>>> The homenet-dot draft is intended to provide a request under RFC 6761 for 
>>> “.homenet” as a special use name to serve as a default namespace for 
>>> homenets. It also asks IANA for an unsecured delegation in the root zone to 
>>> avoid DNSSEC validation failures for local names under “.homenet”. The root 
>>> zone request to IANA has caused some discussion within the WG, as there’s 
>>> no precedent for such a request.
>>> 
>>> Terry Manderson mentioned the homenet-dot draft briefly at the mic in 
>>> Seoul. 
>>> 
>>> The WGLC ends this week.
>>> 
>>> 
>>> Suzanne
>>> 
>>>> Begin forwarded message:
>>>> 
>>>> From: Ray Bellis mailto:r...@bellis.me.uk>>
>>>> Subject: [homenet] WGLC on "redact" and "homenet-dot"
>>>> Date: November 17, 2016 at 11:27:08 PM EST
>>>> To: HOMENET mailto:home...@ietf.org>>
>>>> 
>>>> This email commences a four week WGLC comment period on
>>>> draft-ietf-homenet-redact and draft-ietf-homenet-dot
>>>> 
>>>> Please send any comments to the WG list

Re: [DNSOP] Fwd: [homenet] WGLC on "redact" and "homenet-dot"

[Steve Crocker]

The latter.  All DNS answers at all levels should be signed to assure the 
querier of the integrity of the answer.  This has been the goal and best 
practice for a very long time.  For example, it was the explicit objective of 
the quote substantial DNSSEC effort funded by the US Dept of Homeland Security 
starting in 2004.

Within ICANN, in 2009 we made it a formal requirement of all new gTLDs must be 
signed.  The ccTLDs are not subject to ICANN rules but they have been gradually 
moving toward signed status.  Most of the major ccTLDs are signed and many of 
the others are too.  Detailed maps are created every week by ISOC.

I will also try to contribute to the homenet mailing list.

Steve

Sent from my iPhone

> On Dec 14, 2016, at 11:36 AM, Ted Lemon  wrote:
> 
> Is this a matter of religious conviction, or is there some issue with 
> unsecured delegations in the root that you are assuming is so obvious that 
> you don't need to tell us about it?   :)
> 
>> On Wed, Dec 14, 2016 at 11:18 AM, Steve Crocker  wrote:
>> I am strongly opposed to unsecured delegations in the root zone.  No matter 
>> what the problem is, an unsecured delegation is not the answer.
>> 
>> Steve
>> 
>>> On Dec 14, 2016, at 11:11 AM, Suzanne Woolf  wrote:
>>> 
>>> Hi all,
>>> 
>>> DNSOP participants who are interested in the special use names problem 
>>> might want to review draft-ietf-homenet-redact 
>>> (https://datatracker.ietf.org/doc/draft-ietf-homenet-redact/) and 
>>> draft-ietf-homenet-dot 
>>> (https://datatracker.ietf.org/doc/draft-ietf-homenet-dot/) for the WGLC on 
>>> them in the HOMENET wg.
>>> 
>>> WGLC comments should go to the WG list, home...@ietf.org.
>>> 
>>> If you do, it will also be helpful to look at RFC 7788, which specifies the 
>>> Home Networking Control Protocol for homenets. 
>>> 
>>> The redact draft is intended to remove the inadvertent reservation of 
>>> “.home” as the default namespace for homenets in RFC 7788. 
>>> 
>>> The homenet-dot draft is intended to provide a request under RFC 6761 for 
>>> “.homenet” as a special use name to serve as a default namespace for 
>>> homenets. It also asks IANA for an unsecured delegation in the root zone to 
>>> avoid DNSSEC validation failures for local names under “.homenet”. The root 
>>> zone request to IANA has caused some discussion within the WG, as there’s 
>>> no precedent for such a request.
>>> 
>>> Terry Manderson mentioned the homenet-dot draft briefly at the mic in 
>>> Seoul. 
>>> 
>>> The WGLC ends this week.
>>> 
>>> 
>>> Suzanne
>>> 
>>>> Begin forwarded message:
>>>> 
>>>> From: Ray Bellis 
>>>> Subject: [homenet] WGLC on "redact" and "homenet-dot"
>>>> Date: November 17, 2016 at 11:27:08 PM EST
>>>> To: HOMENET 
>>>> 
>>>> This email commences a four week WGLC comment period on
>>>> draft-ietf-homenet-redact and draft-ietf-homenet-dot
>>>> 
>>>> Please send any comments to the WG list as soon as possible.
>>>> 
>>>> Whilst there was a very strong hum in favour of ".homenet" vs anything
>>>> else during the meeting, and there's some discussion of that ongoing
>>>> here on the list - I'd like us to please keep the discussion of the
>>>> choice of domain separate from other substantive comment about the
>>>> drafts' contents.
>>>> 
>>>> thanks,
>>>> 
>>>> Ray
>>>> 
>>>> ___
>>>> homenet mailing list
>>>> home...@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/homenet
>>> 
>>> ___
>>> 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] Fwd: [homenet] WGLC on "redact" and "homenet-dot"

[Steve Crocker]

I am strongly opposed to unsecured delegations in the root zone.  No matter 
what the problem is, an unsecured delegation is not the answer.

Steve

> On Dec 14, 2016, at 11:11 AM, Suzanne Woolf  wrote:
> 
> Hi all,
> 
> DNSOP participants who are interested in the special use names problem might 
> want to review draft-ietf-homenet-redact 
> (https://datatracker.ietf.org/doc/draft-ietf-homenet-redact/ 
> ) and 
> draft-ietf-homenet-dot 
> (https://datatracker.ietf.org/doc/draft-ietf-homenet-dot/ 
> ) for the WGLC on 
> them in the HOMENET wg.
> 
> WGLC comments should go to the WG list, home...@ietf.org 
> .
> 
> If you do, it will also be helpful to look at RFC 7788, which specifies the 
> Home Networking Control Protocol for homenets. 
> 
> The redact draft is intended to remove the inadvertent reservation of “.home” 
> as the default namespace for homenets in RFC 7788. 
> 
> The homenet-dot draft is intended to provide a request under RFC 6761 for 
> “.homenet” as a special use name to serve as a default namespace for 
> homenets. It also asks IANA for an unsecured delegation in the root zone to 
> avoid DNSSEC validation failures for local names under “.homenet”. The root 
> zone request to IANA has caused some discussion within the WG, as there’s no 
> precedent for such a request.
> 
> Terry Manderson mentioned the homenet-dot draft briefly at the mic in Seoul. 
> 
> The WGLC ends this week.
> 
> 
> Suzanne
> 
>> Begin forwarded message:
>> 
>> From: Ray Bellis mailto:r...@bellis.me.uk>>
>> Subject: [homenet] WGLC on "redact" and "homenet-dot"
>> Date: November 17, 2016 at 11:27:08 PM EST
>> To: HOMENET mailto:home...@ietf.org>>
>> 
>> This email commences a four week WGLC comment period on
>> draft-ietf-homenet-redact and draft-ietf-homenet-dot
>> 
>> Please send any comments to the WG list as soon as possible.
>> 
>> Whilst there was a very strong hum in favour of ".homenet" vs anything
>> else during the meeting, and there's some discussion of that ongoing
>> here on the list - I'd like us to please keep the discussion of the
>> choice of domain separate from other substantive comment about the
>> drafts' contents.
>> 
>> thanks,
>> 
>> Ray
>> 
>> ___
>> homenet mailing list
>> home...@ietf.org 
>> https://www.ietf.org/mailman/listinfo/homenet
> 
> ___
> 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] DNSSEC operational issues long term

[Steve Crocker]

I recall a discussion several years about having a site that would have all of 
the keys accumulated over time.  A query to it would return the current key.  
It's roughly analogous to using a root hints file to find a current root server 
and from that the full set of current servers.

This wouldn't be hard to do, but it also wasn't considered terribly urgent.

Steve 

Sent from my iPhone

> On Nov 16, 2016, at 11:26 AM, william manning  
> wrote:
> 
> Johan Ihren and I and Olaf had a competing ID that delt with shelf life and 
> embedded devices w/o an easy way to update key info.  RFC 5011 won out since 
> shelf life and embedded devices were considered edge cases.
> 
> /Wm 
> 
>> On Wednesday, 16 November 2016, Tony Finch  wrote:
>> Wessels, Duane  wrote:
>> >
>> > I don't think its possible to have a solution that works for devices on
>> > the shelf for an arbitrarily long time.  You posed the problem as 10
>> > years, which I think is an unrealistically long time.
>> >
>> > You could probably have a useful discussion about what is an appropriate
>> > amount of time for something to be on the shelf and still expect it to
>> > work.  If there is some consensus on that then the operators of the key
>> > material can design around it.
>> 
>> Good points.
>> 
>> I think 10 years is definitely ambitious, but we do have multiple existing
>> points of comparison:
>> 
>> (1) Lifetime of X.509 trust anchors
>> 
>> e.g. www.iana.org (where the DNSSEC root trust anchor is distributed)
>> has a cert that chains up to the DigiCert High Assurance EV Root CA which
>> is 10 years old and expires 15 years in the future.
>> 
>> (2) Root DNS server IP addresses
>> 
>> 8 of the 13 servers have the same IPv4 address as they had in 1999, which
>> is plenty for establishing a quorum of witnesses.
>> 
>> Tony.
>> --
>> f.anthony.n.finchhttp://dotat.at/  -  I xn--zr8h punycode
>> Shannon: West 6 to gale 8, perhaps severe gale 9 later. Rough or very rough,
>> becoming mainly high. Thundery showers. Good, occasionally poor.
>> 
>> ___
>> 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] I-D Action: draft-ietf-dnsop-nxdomain-cut-02.txt

[Steve Crocker]

Ok, thanks.

Steve

On May 10, 2016, at 11:54 AM, 神明達哉  wrote:

> At Tue, 10 May 2016 15:04:56 +0200,
> Stephane Bortzmeyer  wrote:
> 
>>>  This is true, but I suspect it would be pretty easy for this type
>>>  of attacker to circumvent the effect if and when the nxdomain-cut
>>>  behavior is more widely deployed.  An attacker for the '.wf' zone
>>>  would simply send random junk query .wf instead of
>>>  .dafa888.wf.  So I think the mitigation effect in this
>>>  sense is quite limited.
>> 
>> Speaking of that, I have a philosophical question. Attackers in the
>> real world (not in labs or in security conferences, where researchers
>> try to impress their peers with clever hacks) are often
>> unsophisticated. [...] Why do they
>> continue to do so?
> 
> I don't know:-)  In any case, my comment on this was not to request a
> particular change to the draft.  But I believe one with a decent
> knowledge on DNS won't have to be particularly "clever" to have the
> same question, you might want to add more discussion to answer (or at
> least respond to) that question if we keep this topic in the draft.
> It's up to you.
> 
> --
> jinmei
> 
> ___
> 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] Last Call: (The .onion Special-Use Domain Name) to Proposed Standard

[Steve Crocker]

Five years is not enough.  Think in terms of 20 to 50 years.

On Aug 10, 2015, at 3:10 PM, John Levine  wrote:

>>> I believe that the registry we have currently defined doesn't do a great 
>>> job of capturing the actual needs here. 
> 
> Agreed.  It seems to me that there are two somewhat separate things going on 
> here.
> 
> One is the .ONION issue.  It's a domain name string that has a
> coordinated use that is implemented outside the RFC 1034/1035 DNS.
> 
> The other is the .BELKIN and .CORP issue.  They're domain name strings
> that have no coordinated use, but there's enough uncoordinated use
> that there'd be a stability risk if a live TLD started answering
> queries.
> 
> In both cases, one question is when we reserve the name, and the other equally
> important question is when we un-reserve the name.
> 
> For all three, I think there's adequate evidence to reserve them now.
> The un-reserve criteria is different, and I expect would be different
> for any other name we reserved.  For .onion, it's not out of the
> question that five or ten years from now we check in with the ToR
> project and they say oh, the whole reserved name thing was such a hassle
> that we switched to onion:// names and we don't use domain names at all.
> 
> For .BELKIN, the problem was a lot of home routers shipped a decade
> ago.  Eventually most of them will die and the problem will go away.
> Or if the Belkin company wanted a vanity domain, they presumably know
> what the routers did and could come up with a TLD that avoided sending
> unfortunate responses to the old queries.
> 
> For .CORP, I gather the main usage was for intranet TLS certificates,
> but the public CAs have stopped signing them so they will probably
> mostly go away, too.
> 
> The point of these examples is not that we need to solve any of those
> issues now, but that a useful reserved name registry needs to deal with
> the reality that most reservations need not be forever.
> 
> R's,
> John
> 
> ___
> 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] what's in .alt, was Last Call: (The .onion Special-Use Domain Name) to Proposed Standard

[Steve Crocker]

Hugo, et al,

I think the experience is exactly the opposite, i.e. these names will *always* 
show up in the DNS.  As a consequence, I would argue that names being used for 
any of these purposes should not be delegated into the DNS root unless it’s for 
the same purpose.  Thus, if the village of Elba in the state of New York, USA, 
which calls itself the Onion Capital of the World applied to ICANN for .onion 
in some future round of gTLD applications, I would hope ICANN would turn down 
the application on the basis that the name is already in use.  I should note 
that not all of my colleagues agree with me.  When I was chair of ICANN’s 
Security and Stability Advisory Committee (SSAC) we noted that .belkin was one 
of the undelegated names that shows up quite frequently at the root.  If 
.belkin were delegated in the root, it would instantly change the responses 
those queries are currently receiving, thus raising some questions about 
security and/or stability for those end systems that have been generating bogus 
.belkin queries to root for many years.

I haven’t looked to see how often .onion and .alt show up at the root.  Others 
on this list can or already have done so.

Steve Crocker

(Founding chair of ICANN’s SSAC; currently chair of the ICANN board, speaking 
as an individual not officially on behalf of the ICANN board)





On Jul 19, 2015, at 3:26 AM, Hugo Maxwell Connery  wrote:

> Hi,
> 
> My reflections on this interesting discussion:
> 
> Software using names under *.alt (or whatever it will be) do not use DNS, by 
> definition.
> 
> Thus, there can never be a DNS name collision.  It will be up to the 
> alternate name
> resolution software, and its users, to deal with the name collision problem, 
> until IETF
> decides to take on name management for this/these non-DNS name resolution 
> systems.
> 
> So, we dont have to solve this problem.  I dont believe that a registry is 
> required at all.
> 
> If we do offer one, that registry should be for dual entries (name, name 
> resolution mechanism)
> as (sex.alt, tor hidden service) and (sex.alt, GNUnet) are different things 
> using different
> mechanisms, but the same label.
> 
> Regards,  Hugo
> ___
> 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] what's in .alt, was Last Call: (The .onion Special-Use Domain Name) to Proposed Standard

[Steve Crocker]

Hugo, et al,

I think the experience is exactly the opposite, i.e. these names will *always* 
show up in the DNS.  As a consequence, I would argue that names being used for 
any of these purposes should not be delegated into the DNS root unless it’s for 
the same purpose.  Thus, if the village of Elba in the state of New York, USA, 
which calls itself the Onion Capital of the World applied to ICANN for .onion 
in some future round of gTLD applications, I would hope ICANN would turn down 
the application on the basis that the name is already in use.  I should note 
that not all of my colleagues agree with me.  When I was chair of ICANN’s 
Security and Stability Advisory Committee (SSAC) we noted that .belkin was one 
of the undelegated names that shows up quite frequently at the root.  If 
.belkin were delegated in the root, it would instantly change the responses 
those queries are currently receiving, thus raising some questions about 
security and/or stability for those end systems that have been generating bogus 
.belkin queries to root for many years.

I haven’t looked to see how often .onion and .alt show up at the root.  Others 
on this list can or already have done so.

Steve






On Jul 19, 2015, at 3:26 AM, Hugo Maxwell Connery  wrote:

> Hi,
> 
> My reflections on this interesting discussion:
> 
> Software using names under *.alt (or whatever it will be) do not use DNS, by 
> definition.
> 
> Thus, there can never be a DNS name collision.  It will be up to the 
> alternate name
> resolution software, and its users, to deal with the name collision problem, 
> until IETF
> decides to take on name management for this/these non-DNS name resolution 
> systems.
> 
> So, we dont have to solve this problem.  I dont believe that a registry is 
> required at all.
> 
> If we do offer one, that registry should be for dual entries (name, name 
> resolution mechanism)
> as (sex.alt, tor hidden service) and (sex.alt, GNUnet) are different things 
> using different
> mechanisms, but the same label.
> 
> Regards,  Hugo
> ___
> 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] Thoughts on the top level name space

[Steve Crocker]

Thanks.  Minor comments in line below.

Steve

On Jul 7, 2015, at 5:42 AM, Jaap Akkerhuis  wrote:

> Not taking a stand on this, but some more remarks on these thoughts.
> 
> Edward Lewis writes:
> 
>> 
>> On 7/5/15, 7:26, "DNSOP on behalf of Steve Crocker"
>>  wrote:
>> 
>>> 3. (ICANN) Two letter Latin characters that have not yet been assigned by
>>> the ISO 3166 maintenance agency but might be in the future.  Names in
>>> this subset may move to subset 7 to become active ccTLDs.  Examples:
>>> 
>>> xq
>> 
>> 'pq' is a better example.  'xq' is classified as User Assigned, which
>> means it has been assigned for use by anyone for their own purposes.  'pq'
>> is (using Wikipedia's term) unassigned.
> 
> Indeed. The complete user assigned set is:
> 
>   AA, QM-QZ, XA-XZ and ZZ
> 
> For the alpha 3-code the complete user assigned set is:
> 
>   AAA-AAZ, QMA-QZZ, XAA-XZZZ and ZZA to ZZZ
> 
> so one could argue that the delegations for TLD xyz (and maybe xxx) is
> a actually against the rules in ICANN’s Application Guide Book.

It’s my understanding that only the two character codes are included in the 
relationship between DNS top level names and ISO 3166-1.  Three letter codes 
aren’t included, so there’s no conflict.

>> In recognition of this, though, I'd lump all of the alpha-2 codes
>> ([A-Z][A-Z]) into category 3, and call it informally "being at the mercy
>> of the ISO 3166-1 Maintenance Agency."
> 
> But given that they can be freely used, one could consider them as
> candidates for non-TLD use in the name space.

Hmm… Maybe.  Seems like a bad idea, though.

>>> 4. (IETF) Names the IETF has formally recognized as reserved for
>>> particular non-DNS uses.  Names in this subset are effectively permanent.
>>> (=E2=80=9CEffectively permanent=E2=80=9D means they are expected to remain 
>>> in this
>>> subset forever and there is no defined process for changing the status of
>>> names in this subset.)  Examples:
>>> 
>>> example, local
>> 
>> (Left in for the discussion later in this message.)
>> 
>>> 7. (ICANN) ccTLDs, both Latin and IDN.  Names in this subset are expected
>>> to last indefinitely.  If they are taken out of service they move to
>>> subset 8.  Examples:
>>> 
>>> jp, uk, na, xn--fzc2c9e2c
>> 
> 
> I would recommend to not use UK as an example in this discussion. If I
> remember correctly, the use as a TLD stems from the time before the
> iso alpha-2 codes got adopted as TLDs.

Well, I know there is controversy over some of the two letter codes, 
particularly UK, SU and EU, but it seems to me they are in full use and treated 
as ccTLDs.

> 
>> The quirk I have here is the IDN Fast Track
>> [https://www.icann.org/resources/pages/fast-track-2012-02-25-en] and
>> trying to anticipate what names will be in that.   The Latin ccTLD codes I
>> can anticipate from category 3 above.  But the IDN ccTLD names aren't
>> distinguishable from other IDN names without consulting the Fast Track and
>> even so, well I'll put this under - I don't understand if a name coming
>> through the Fast Track might also be on a generic TLD track.
> 
> As far as I know, the Fast-Track IDN process uses the ISO standard to
> see whether the requested name can be applied as ccTLD. so something like
> Scandinavia will drop because because there is no ISO code for the 
> corresponding country or (administrative) territory.

This comment applies to whether a particular name is permitted to move from one 
subset to another.  I don’t think it’s necessary to include the rules for 
moving, just what subsets names can be in.
> 
>> 
>> As far as I know, if the Fask Track the only source of IDN ccTLD names?
>> 
>>> 8. (ICANN) Previously used TLDs that have been taken out of service.
>>> Names in this subset must remain out of service for a very long time,
>>> currently estimated at 50 years, to avoid unintended consequences.
>>> Examples:
>>> 
>>> cs
> 
> CS has been used twice by ISO 3166. It is now in the 50 year cool-off period.
> 
>> 
>> Perhaps there's an 8-1/2: I've been told that the 11 IDN test TLDs which
>> have been rescinded (NS records removed) are eligible to be reinstated if
>> needed for further testing.  "I've been told" means that I have never seen
>> this in print and thus have no citation to give.

See my reply to Ed Lewis re a possible additional subset for names that have 
appeared at the root with some frequency but might subside

> And there are other cases; Official assigned by ISO but not used as
> TLD (um comes  to mind).

It seems to me that UM did appear in the root and then was taken out of 
service.  I doubt we’d want to see it assigned to another country or territory 
in the near future.  I’d put it in subset 8 unless it were brought back to life 
in the service of the same territory it had been used for before.

Steve

> 
> 
>   jaap

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

Re: [DNSOP] Thoughts on the top level name space

[Steve Crocker]

On Jul 6, 2015, at 5:08 PM, Edward Lewis  wrote:

> On 7/5/15, 7:26, "DNSOP on behalf of Steve Crocker"
>  wrote:
> 
>> 3. (ICANN) Two letter Latin characters that have not yet been assigned by
>> the ISO 3166 maintenance agency but might be in the future.  Names in
>> this subset may move to subset 7 to become active ccTLDs.  Examples:
>> 
>>  xq
> 
> 'pq' is a better example.  'xq' is classified as User Assigned, which
> means it has been assigned for use by anyone for their own purposes.  'pq'
> is (using Wikipedia’s term) unassigned.

Thanks.  I didn’t check the tables before writing.  I was pretty sure xq wasn’t 
already assigned to a specific country or territory, but I didn’t think about a 
“1918” style designation of two letter codes.  Perhaps we need another subset 
to put these into.  It would be a “final” state in the sense that once a two 
letter code is put into that state, it can’t move to another state.  And the 
purview would be the ISO 3166-1 Maintenance Agency.

> In recognition of this, though, I'd lump all of the alpha-2 codes
> ([A-Z][A-Z]) into category 3, and call it informally "being at the mercy
> of the ISO 3166-1 Maintenance Agency.”

Hmm… I understand your point, but I think it would feel odd to our audiences.  
If the ISO 3166-1 Maintenance Agency were to tinker with established codes, 
e.g. DE, JP, CN, etc., all hell would break loose.

>> 4. (IETF) Names the IETF has formally recognized as reserved for
>> particular non-DNS uses.  Names in this subset are effectively permanent.
>> (“Effectively permanent” means they are expected to remain in this
>> subset forever and there is no defined process for changing the status of
>> names in this subset.)  Examples:
>> 
>>  example, local
> 
> (Left in for the discussion later in this message.)
> 
>> 7. (ICANN) ccTLDs, both Latin and IDN.  Names in this subset are expected
>> to last indefinitely.  If they are taken out of service they move to
>> subset 8.  Examples:
>> 
>>  jp, uk, na, xn--fzc2c9e2c
> 
> The quirk I have here is the IDN Fast Track
> [https://www.icann.org/resources/pages/fast-track-2012-02-25-en] and
> trying to anticipate what names will be in that.   The Latin ccTLD codes I
> can anticipate from category 3 above.  But the IDN ccTLD names aren't
> distinguishable from other IDN names without consulting the Fast Track and
> even so, well I'll put this under - I don't understand if a name coming
> through the Fast Track might also be on a generic TLD track.

I think this is a non-problem.  Strings beginning with “x n - -“ are in subset 
1 until they are moved into either subset 7 (Active ccTLD) or subset 6 (Active 
gTLD).  It doesn’t matter whether they moved into the Active ccTLD subset 
because of the current FastTrack or some future process.

> 
> As far as I know, if the Fask Track the only source of IDN ccTLD names?

I believe this is true at present.  There may be other processes in the future.
> 
>> 8. (ICANN) Previously used TLDs that have been taken out of service.
>> Names in this subset must remain out of service for a very long time,
>> currently estimated at 50 years, to avoid unintended consequences.
>> Examples:
>> 
>>  cs
> 
> Perhaps there's an 8-1/2: I've been told that the 11 IDN test TLDs which
> have been rescinded (NS records removed) are eligible to be reinstated if
> needed for further testing.  "I've been told" means that I have never seen
> this in print and thus have no citation to give.

Heh.  Good point.  Well, for other reasons I’ve been thinking we may need three 
additional subsets, and perhaps the experimental IDN TLDs would fit into one of 
these.  The three are:

o The two letter codes reserved by the ISO 3166-1 Maintenance Agency that will 
never be assigned to countries or territories, i.e. what you said above.  This 
subset would be carved out of subset 3 and be a final state.

o Names that have shown up in queries with some frequency but may subside in 
the future and hence may be available for assignment in the future.  They would 
arrive into this subset from subset 1 (or possibly subset 3), and either return 
to the subset they came from or progress to subset 5.  I would put the test 
IDNs into this subset.

o Names that have been permanently excluded from use by both the IETF and ICANN 
and hence fall into both subsets 4 and 5.  I think there’s value in keeping all 
of these subsets distinct from each other, it’s necessary to create a new 
subset for names that both groups have excluded.  This would be a final state, 
arrived at either from subset 4 or subset 5.



> 
>> ISSUES
>> 
>> o Should there be some sort of operat

Re: [DNSOP] Top level names -- precision re categories and where are are the uncertainties?

[Steve Crocker]

Jaap,

This was a mistake on my part.  I was working at my laptop and didn’t have 
space to see everything at once.

As a separate matter I didn’t see a copy of my submission, and I incorrectly 
assumed it hadn’t gotten through, perhaps because attachments weren’t allowed.  
I was wrong, but it caused me to resubmit a text-only version.  The error, 
along with another error, were corrected, and I updated the text slightly.  I 
have also updated my slide deck in case I need to use it another time ;)

With respect to terminology, I am now using “name” to mean a top level string.  
Some names are top-level domain names, i.e. TLDs, and some are not.  I am using 
“subset” instead of state to designate the status of a name.  I have in mind 
that at any given time, each name is in exactly one of these subsets.  If we 
need to create more subsets, that’s fine with me.  This is a draft that is 
intended to stimulate a discussion.

Thanks,

Steve

On Jul 7, 2015, at 4:50 AM, Jaap Akkerhuis  wrote:

> Steve Crocker writes:
> 
>> Folks,
>> 
>> I`ve been watching the dialog on this list regarding to level names.
>> Attached is my attempt to clarify the state of affairs and identify the
>> loose ends.  Both PDF and pptx versions attached, the latter in case
>> someone is moved to edit the slides directly.
> 
> 
> Either I don't understand the slides or they seem to be inconsistent.
> As an example, you defines 8 "states" [1] and 8 definitions (later
> called "Categories: when you give exanples. However the examples
> doesn't match the definitions:
> 
>   Definition 2: Names that have not been formally recognized but
>   are being used privately or for applications that have
>   not yet become standard
> 
>   Definition 3: Two letter Latin characters that have not yet
>   been assigned by the ISO 3166 maintenance agency but
>   might be in the future.
> 
>   Category 2: xq
> 
>   Category 3: onion
> 
> Are these mistakes or purposely. (There seem to be more of these cases
> on the slides).
> 
>   jaap
> 
> 
> 
> [1] I'm not sure whether this is a proper term. Can one state move to another?
> 
> ___
> 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] Some distinctions and a request - Have some class?

[Steve Crocker]

Stephane and Paul,

I’m ok with anything that provides effective negative feedback.  Dropping 
queries or redirecting them is ok with me.

Thanks,

Steve

On Jul 5, 2015, at 5:11 AM, P Vixie  wrote:

> Delay is expensive for responders since it requires state. Steve's goal of 
> making some tld strings flaky so as to encourage developers to avoid DNS for 
> those names could be met statelessly. For example delegate them to localhost.
> 
> On July 5, 2015 12:51:08 PM GMT+01:00, Stephane Bortzmeyer 
>  wrote:
> On Sat, Jul 04, 2015 at 09:16:17AM -0700,
>  Steve Crocker  wrote 
>  a message of 21 lines which said:
> 
>  except for the additional load it places on the root servers,
> 
> RFC 7535 could be a solution.
> 
>  I propose augmenting the DNS to include entries in the root that
>  serve the purpose of giving slow NXDOMAIN responses instead of quick
>  responses for those strings that the IETF has identified as not
>  TLDs.
> 
> If it is a serious proposal, I object. Delaying answers require
> keeping state in the authoritative name server and opens a nice DoS
> boulevard.
> 
> 
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
> 
> -- 
> Sent from my Android device with K-9 Mail. Please excuse my brevity.
> ___
> 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] Some distinctions and a request - Have some class?

[Steve Crocker]

On Jul 5, 2015, at 4:51 AM, Stephane Bortzmeyer  wrote:

> On Sat, Jul 04, 2015 at 09:16:17AM -0700,
> Steve Crocker  wrote 
> a message of 21 lines which said:
> 
>> except for the additional load it places on the root servers,
> 
> RFC 7535 could be a solution.
> 
>> I propose augmenting the DNS to include entries in the root that
>> serve the purpose of giving slow NXDOMAIN responses instead of quick
>> responses for those strings that the IETF has identified as not
>> TLDs.
> 
> If it is a serious proposal, I object. Delaying answers require
> keeping state in the authoritative name server and opens a nice DoS
> boulevard.

Hmm… It would be acceptable to simply dump requests for those names if the load 
is too high.

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

[DNSOP] Thoughts on the top level name space

[Steve Crocker]

This note is an attempt to describe how things work today and to bring some 
precision to the current discussion.  Except very mildly under the ISSUES 
section at the end, this note does not propose anything new.

This is quick draft.  There might be errors, missing pieces, assumptions, etc.  
Please comment or fix.

ONE NAME SPACE

There’s really just one top level name space.  The top level of the domain name 
system (DNS) is *part* of this name space.  Names for other uses are also part 
of this space.  Names not intended to be used as top-level *domain* names 
(TLDs) leak into the public DNS, so it’s not really possible to keep these 
apart.

Informal vs Formal Allocation

ICANN allocates top level names via its formal processes.  IETF tends to 
recognize names that have developed use informally, although sometimes IETF 
will formally allocate a name prior to seeing the name in use.  These processes 
do not usually clash but have the potential for doing so.

EIGHT SUBSETS?

Here is an attempt to subdivide the entire name space into non-overlapping 
subsets and to show the pathways for a name to move from one subset to another. 
 The subsets are annotated with whether the subset falls into the IETF’s, 
ICANN’s or neither’s purview.

1. (Neither) Names that have not yet been used for anything.  This is an 
initial state for all names except two letter Latin letters.  Names in this 
subset may move to subsets 2, 4, 5, 6 or 7.  Examples:

unusedname96456

2. (IETF) Names that have not been formally recognized but are being used 
privately or for applications that have not yet become standard.  Names in this 
subset may move to subset 4.  Examples:

onion

3. (ICANN) Two letter Latin characters that have not yet been assigned by the 
ISO 3166 maintenance agency but might be in the future.  Names in this subset 
may move to subset 7 to become active ccTLDs.  Examples:

xq

4. (IETF) Names the IETF has formally recognized as reserved for particular 
non-DNS uses.  Names in this subset are effectively permanent.  (“Effectively 
permanent” means they are expected to remain in this subset forever and there 
is no defined process for changing the status of names in this subset.)  
Examples:

example, local

5. (ICANN) Names ICANN has determined to be inappropriate to delegate.  Names 
in this subset are effectively permanent.  Examples:

corp, home, mail

6. (ICANN) gTLDs, both Latin and IDN.  Names in this subset are expected to 
last indefinitely.  If they are taken out of service they move to subset 8.  
Examples:

net, info, xxx, xn--cg4bki

7. (ICANN) ccTLDs, both Latin and IDN.  Names in this subset are expected to 
last indefinitely.  If they are taken out of service they move to subset 8.  
Examples:

jp, uk, na, xn--fzc2c9e2c

8. (ICANN) Previously used TLDs that have been taken out of service.  Names in 
this subset must remain out of service for a very long time, currently 
estimated at 50 years, to avoid unintended consequences.  Examples:

cs

ISSUES

o ICANN speaks indistinctly about subset 5.

o Does the IETF have a process for moving a name from subset 2 to subset 4?

o A process for coordination between the IETF and ICANN regarding subsets 2, 4 
and 5 would be helpful.

o Should there be some sort of operational penalty for leakage of names in 
subsets 2, 4, 5 and 8 into the public DNS, e.g. a slow response from DNS 
servers?

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

Re: [DNSOP] Some distinctions and a request - Have some class?

[Steve Crocker]

See the end for something provocative.

> ICANN do say what strings in the name space should be TLDs.
> 
> IETF do say what strings in the name space should NOT be TLDs.
> 
> The rest are just strings waiting to end up in one of the two groups.
> 
>   Patrik

Perfectly stated.  There is really just one name space.  Once a string is 
designated by the IETF for some purpose other than allocation as a top level 
domain, it is, IMO, permanently barred from being allocated as a TLD.

As a practical matter, non-TLD strings regularly leak into the public domain 
name system and wind up at the root.  In principle, this should not be a 
problem except for the additional load it places on the root servers, EXCEPT we 
have also seen end systems depend on the NXDOMAIN response from the root 
servers as part of their processing.  This creates a nasty security hole.

I propose augmenting the DNS to include entries in the root that serve the 
purpose of giving slow NXDOMAIN responses instead of quick responses for those 
strings that the IETF has identified as not TLDs.  local, corp, home, mail, and 
others are what I have in mind.  This is intended to incentivize developers not 
to release code that improperly depends on the NXDOMAIN response in their 
search path.

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

Re: [DNSOP] Interim DNSOP WG meeting on Special Use Names: some reading material

[Steve Crocker]

These comments might be more usefully said in the relevant ICANN forums.

Steve

On May 17, 2015, at 7:07 PM, Paul Vixie  wrote:

> 
> 
> John Levine wrote:
>>> ...
>> 
>> I would be much happier with a statement that said "the names are
>> blocked indefinitely, and here's the plan for the $4 million in
>> application fees we accepted for those names."
> 
> +1.
> 
> -- 
> Paul Vixie
> 
> ___
> 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] terminology: glue

[Steve Crocker]

Paul,

Thanks.  I agree it’s good to explain this.  I’d rather it were explained in a 
document that purported to explain how things work instead of slipping it into 
a terminology document, but getting it written down somewhere is better than 
nowhere.

Steve

On May 4, 2015, at 3:01 PM, Paul Vixie  wrote:

> 
> 
> Steve Crocker wrote:
>> Glue records are necessary to prevent circular references, i.e. to cut the 
>> loop.  ...
> 
> after kashpureff, circular references are no longer allowed. XYZ.NET
> cannot have only nameservers named within within XYZ.ORG, if XYZ.ORG has
> only name servers named within XYZ.NET. that's because, due to cache
> poisoning risks, out-of-zone glue must be in-bailiwick for the delegator.
> 
> i see no reason not to explain it this way in the terminology document,
> even though this was an undocumented protocol change. (one of hundreds
> of little things that you "just have to know", and this terminology
> document would be a fine place to list some of those.)
> 
> -- 
> Paul Vixie
> 
> ___
> 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] terminology: glue

[Steve Crocker]

Glue records are necessary to prevent circular references, i.e. to cut the 
loop.  The most obvious and common situation is where the name server is below 
the cut.  If the address of the name server were not included, the querying 
system would keep being referred to the parent, i.e. stuck in a loop of length 
1.  It is also possible to have loops of length 2 or more, though these will be 
quite rare.  If the name servers for A are below B, and the name servers for B 
are below A, if glue records are not included for either, the querier will 
bounce back and forth between A and B without ever succeeding.

It would be nice if the definition of glue records included the complete 
picture, though that might make it harder for people to understand the basic 
case.  So, a brief bit of explanatory and example text in addition to the 
formal definition would also be advisable.

Steve

On May 4, 2015, at 10:32 AM, Casey Deccio  wrote:

> I am still a bit uncomfortable with the -01 definition of glue, specifically 
> the reference to RFC 2181.  I think the reference to RFC 2181 is useful and 
> necessary, but I hesitate to think that RFC 2181's use of glue is a 
> redefinition that is intended to apply outside of the RFC itself.  That is, I 
> believe the term was overloaded (similar to the apparent overloading of 
> "label" discussed in another recent dnsop thread).
> 
> Here is some proposed re-wording (modified from a previous proposal), which 
> both adds more context (quoted from earlier RFC 1034 text) for the use of 
> glue to the first paragraph and gives less weight to the RFC 2181 reference 
> in the second.
> 
> Glue records -- "[Records] which are not part of the
>authoritative data [for a zone], and are address resource records for
>the servers [in a subzone].  These RRs are only necessary if the name
>server's name is 'below' the cut, and are only used as part of a
>referral response."  Without glue "we could be faced with the situation
>where the NS RRs tell us that in order to learn a name server's
>address, we should contact the server using the address we wish to
>learn." (Definition from RFC 1034, section 4.2.1)
> 
>A later definition is that glue "includes any record in a zone file
>that is not properly part of that zone, including nameserver records
>of delegated sub-zones (NS records), address records that accompany
>those NS records (A, , etc), and any other stray data that might
>appear" ([RFC2181], section 5.4.1).  Although glue is sometimes used
>today with this wider definition in mind, the context surrounding the
>RFC 2181 definition suggests it is intended to apply to the use of glue
>within document itself and not necessarily beyond.
> ___
> 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] DNS terminology (Was: draft-bortzmeyer-dnsop-dns-privacy (was: DNS privacy : now at least two drafts)

[Steve Crocker]

Sent from my iPhone

> On Jul 16, 2014, at 10:02 PM, "Guangqing Deng"  wrote:
> 
> This sounds very needful and useful especially for new comers. And I once had 
> been puzzled by "DNS recursive server" and "DNS caching server" for a 
> relatively long time.

I still am :)

Steve
>  
> Guangqing Deng
> CNNIC 
>  
> From: Andrew Sullivan
> Date: 2014-07-17 00:07
> To: dnsop
> Subject: Re: [DNSOP] DNS terminology (Was: draft-bortzmeyer-dnsop-dns-privacy 
> (was: DNS privacy : now at least two drafts)
> On Wed, Jul 16, 2014 at 11:45:16AM -0400, Olafur Gudmundsson wrote:
> > I think you are right we NEED a single document/source that expresses a 
> > preferred vocabulary
> > and translations from common RFC’s to the preferred modern vocabulary.
>  
> I will note that the last time DNSEXT came back from the dead, it was
> supposed to issue a whole bunch of such clarifications, but little
> actual work got done.  Perhaps a document just on terminology would be
> a good start, because a little less ambitious.
>  
> A
>  
> --
> Andrew Sullivan
> a...@anvilwalrusden.com
>  
> ___
> 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

[DNSOP] Signaling Cryptographic Algorithm Understanding (Was: key lengths for DNSSEC)

[Steve Crocker]

Perhaps this a good time for me to plug adoption of Signaling Cryptographic 
Algorithm Understanding, per RFC 6975.  The sooner this gets included in the 
implementation on the query side, the sooner we will have solid information on 
when it will be ok to phase out an obsolete algorithm.

This is not directly related to changes in key lengths, but it is relevant for 
the shifts from one algorithm to another, including changes in hash algorithms.

Steve



On Apr 4, 2014, at 12:28 PM, Tony Finch  wrote:

> Frederico A C Neves  wrote:
>> On Wed, Apr 02, 2014 at 04:25:10PM -0400, Nicholas Weaver wrote:
>>> 
>>> IMO they do until validators record and use a 'root key ratchet':
>>> never accept a key who's expiration is older than the inception date
>>> of the RRSIG on the youngest root ZSK seen, or have some other defense
>>> to roll-back-the-clock attacks.
>> 
>> What do you mean by "..key who's expiration is.."? A new propertie
>> recorded at this "ratchet", btw what is this?
> 
> I assume he means that the ratchet would observe when a key is no longer
> published in the DNSKEY RRset and treat it as implicitly revoked.
> 
> Tony.
> -- 
> f.anthony.n.finchhttp://dotat.at/
> Portland, Plymouth: South 4 or 5, occasionally 6 in Plymouth. Slight or
> moderate. Rain, fog patches later. Moderate or poor, occasionally very poor.
> 
> ___
> 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] RISKS and mitigations for draft-jabley-dnssec-trust-anchor

[Steve Crocker]

Tony,

Nice post.  This reminds me of some thinking along these lines I did several 
years ago, which was based on the analogy of how stock market prices are 
published.  (Things have shifted quite a bit with the availability of real-time 
feeds on the Internet, so give me some latitude here.)

In the "old days" most people would get closing stock market prices from their 
newspaper.  Newspapers were not primary authorities, of course, but they were 
trusted publishers.  Each person could choose which paper to read, and if a 
particular paper were to screw up the publication of the stock market page, 
readers would have quickly switched to another publisher.

The application of that scheme to the present issue is to allow multiple 
"publishers" sign and promulgate the root key.  For automated operation it's 
best if they all use the same publication format.  Each user could then choose 
any of the available publishers.  If a publisher were to publish the wrong 
information, it be evident very quickly and the consequences would be 
relatively painful.

If someone is paranoid about the possibility of being spoofed, he can compare 
the results from multiple publishers and/or rotate among the many publishers.  
But there's no need for the publishers to coordinate among themselves, except 
for the standard format, and there's no need for a formal quorum of witnesses.  
(I guess if someone wanted to advocate a best practice of using a quorum of 
witnesses, that's ok with me, but I view that as an added layer, not 
necessarily required.)

Steve



On Apr 19, 2013, at 4:41 PM, Tony Finch  wrote:

> This is a followup to my comments on ICANN's root zone KSK rollover
> consultation. In the last section, responding to question 7 about "other
> considerations", I made a number of suggestions for improvements to the
> trust anchor publication mechanism.
> http://forum.icann.org/lists/comments-root-zone-consultation-08mar13/msg00013.html
> 
> The most important is the last paragraph:
> 
> : I understand that ICANN would like to include third party signatures on
> : the root trust anchor publication web site. This would be a very good
> : thing, since it would allow out-of-band update software to require a
> : quorum of valid signatures instead of just one. This improves
> : security, since compromise of a single key does not compromise the
> : whole process. It improves robustness, since signing keys will be able
> : to change without breaking existing software that uses those keys for
> : validation, so long as a quorum of old-enough keys remain in use.
> 
> Basically I want a machine-verifiable version of this:
> http://dns.icann.org/ksk/ds19036/
> 
> The risk is that the key used to sign the KSK, and the CA used to
> authenticate the key, are both single points of failure. There is no
> single point of failure in the quorum-of-witnesses scheme. The keys can
> all be simply self-signed since individual keys are only slightly trusted;
> the trust comes from agreement between several independent signatures.
> 
> Here are some more suggestions.
> 
> Related to the previous risk, there are some operational and
> organizational single points of failure in the publication web site - for
> instance it is vulnerable to DNS and BGP screwups. This can be mitigated
> using a system of mirror sites.
> 
> A more serious risk: the current publication scheme is vulnerable to
> replay attacks. If the KSK is compromised, an attacker might be able to
> force a victim to download and trust an old version of the trust anchor
> publication document. To mitigate this the trust anchor document (or its
> signatures) should have an explicit lifetime. Validators should refresh
> their copy of the trust anchor document before it expires. They should
> remember the most recent version they have seen and refuse to downgrade to
> an old version. They should probably also keep track of which DNSKEYs have
> been retired and refuse to trust them forever more.
> 
> There is perhaps an opportunity to improve on RFC 5011, in particular to
> reduce the time to recover from a compromised KSK without pre-publishing
> standby keys. If a validator sees a change in the set of KSKs, it fetches
> and verifies the trust anchor document in order to authenticate the
> change. This can lead to the validator immediately trusting the new KSK
> and distrusting the old one. A rollover should take effect globally in
> roughly the TTL of the DNSKEY RRset - two days for the root at the moment.
> 
> The old KSK has to remain actively used for signing the DNSKEY RRset
> during the rollover for a couple of reasons: first, you seriously do not
> want an attacker to be able to use a bogus DNSKEY RRset to force a
> validator to attempt a trust anchor update; second, it's desirable to let
> the validator continue using its existing trust anchor during the update
> process since that will be relatively slow.
> 
> I think it makes sense to distinguish between a trust anchor refres

Re: [DNSOP] Adoption of as a WG work item?

[Steve Crocker]

On Mar 15, 2013, at 11:21 AM, Hugo Salgado  wrote:

> 
> On 03/14/2013 07:44 PM, Joe Abley wrote:
>> (Aside: if AS112++ servers were happy to slave the zone, e.g. from ICANN, we 
>> could sign it and install a DS RRSet in the ARPA zone. This would have the 
>> side benefit that we could track from ICANN's distribution masters who is 
>> retrieving the zone, and hence where the AS112++ operators were. So, this is 
>> also AS112 with DNSSEC, and it's measurable.)
>> 
> 
> Also has the benefit of penalizing when a slave becomes stalled,
> going bogus when signatures expires.
> 
> A resolver which falls in a bogus nameserver should try with the
> next one. So I think the organisations should host only one NS of the
> complete set, giving the chance of diversity.

It feels like there are two distinct issues here.  If the signatures expire, 
all copies of those records will be affected, so diversity of name servers 
won't help.

Diversity of name servers is certainly helpful in countering operational 
failures of equipment or network connectivity.

Steve



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