Re: [DNSOP] [EXT] Re: Followup Working Group Last Call for draft-ietf-dnsop-dnssec-bootstrapping

[Jacques Latour]

Yes, agree, we should publish.

4.3 *The Parental Agent receives a new or updated NS record set for a Child;*
4.3 *Any other condition as deemed appropriate by local policy.*

 -> to confirm my understanding, as a registry operator, a trigger could be 
when a domain is new/being registered, and add the DS record at creation when 
bootstrap information is legit, so that the domain is *created* on the onset as 
a signed delegation.

Jacques



CLASSIFICATION:CONFIDENTIAL
-Original Message-
From: DNSOP  On Behalf Of John Levine
Sent: January 21, 2024 9:41 AM
To: dnsop@ietf.org
Cc: tjw.i...@gmail.com
Subject: [EXT] Re: [DNSOP] Followup Working Group Last Call for 
draft-ietf-dnsop-dnssec-bootstrapping

It appears that Tim Wicinski   said:
>For WGLC, we need positive support and constructive comments; lack of
>objection is not enough.
>So if you think this draft should be published as an RFC, please say so.

I think we should publish it, but I also think we should publish the
NOTIFY draft at the same time so we don't have yet another thing that
requires DNS scanning.

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] Working Group Last Call for draft-ietf-dnsop-dnssec-bootstrapping

[Jacques Latour]

Hi,

I support the dnssec bootstrapping method as proposed 
draft-ietf-dnsop-dnssec-bootstrapping.  .CA is looking at an implementation.

Jacques



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

Re: [DNSOP] [EXT] Re: Current status of draft-ietf-dnsop-dnssec-validator-requirements

[Jacques Latour]

same here, I'm late, but I support this draft and will review and contribute.



CLASSIFICATION:CONFIDENTIAL


From: DNSOP  on behalf of Christian Huitema 

Sent: Wednesday, June 14, 2023 11:55 AM
To: Florian Obser ; Tim Wicinski 
Cc: dnsop ; dnsop-chairs 
Subject: [EXT] Re: [DNSOP] Current status of 
draft-ietf-dnsop-dnssec-validator-requirements

I know that the feedback was due last Sunday, but here comes mine
anyhow, after looking at the latest iteration of the draft.

The draft makes a number of recommendations, which seem all reasonable,
but what struck me was the weak tie between these recommendations and
the security considerations. What also strikes me is the absence of
any consideration relative to secure transports such as DoT or DoQ.

I would love to see a document that addresses the future target, in
which secure transports are use in most or all transactions between stub
and recursive, or between recursive and authoritative. I think that in
such scenarios, the threat model changes quite a bit.

In the old model, we are very concerned about third parties spoofing
responses and polluting resolver caches. In a secure transport model,
the only parties that can spoof responses are the resolvers themselves:
authoritative resolvers abusing their authority to add falsehoods in
additional sections, recursive resolvers abusing the client trust to
send false responses.

I do think that DNSSEC is still useful, even in a secure transport
world. But the focus changes. For example, if we consider that "spoofing
by recursive server" is a threat, then having the recursive set bits to
affirm that the response is verified is not much of a protection -- the
emphasis should move to verification by the client. I would love to see
this discussed.

-- Christian Huitema

On 6/7/2023 10:38 AM, Florian Obser wrote:
> On 2023-06-07 13:08 -04, Tim Wicinski  wrote:
>> Just a reminder we're looking for any feedback on continuing work on this
>> document.  The Chairs/OverLord Warren feel significant work on this
>> document is needed, but that may not be relevant.
>
> The document seems to have a rather pessimistic view on running a
> validator. It has this huge list of things that an operator has to do
> and does not assign any importance to them - everything seems to be
> equally important.
>
> If I were to read this as the person responsible for running the
> recursive resolver at an enterprise or at an ISP I'd think: That sounds
> like effort and incredibly fragile, it's probably best to not enable
> validation.
>
> It would be nice to have an informational RFC on the topic, but I'm not
> convinced this is it. Maybe Andrew's suggestion to split this up is the
> way forward. Maybe have one document with minimum requirements (correct
> time, stuff like that) and take it from there.
>
>>
>> We're wrapping this feedback up this Sunday 11 June.
>>
>> (and Thanks Andrew for your comments)
>>
>> tim
>

___
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] Re: Call for Adoption: draft-mglt-dnsop-dnssec-validator-requirements

[Jacques Latour]

I support the adoption of this document as well, perhaps a bit long but as 
Stéphane stated with draft-ietf-dnsop-extended-error, it would nice to have a 
good story on understanding why resolvers return SERVFAIL.
 
>-Original Message-
>From: DNSOP  On Behalf Of Stephane Bortzmeyer
>Sent: May 6, 2020 4:49 AM
>To: Tim Wicinski 
>Cc: dnsop ; dnsop-chairs 
>Subject: [EXT] Re: [DNSOP] Call for Adoption: 
>draft-mglt-dnsop-dnssec-validator-requirements
>
>On Mon, May 04, 2020 at 03:08:20PM -0400,
> Tim Wicinski  wrote
> a message of 64 lines which said:
>
>> This starts a Call for Adoption for
>> draft-mglt-dnsop-dnssec-validator-requirements
>
>I think it is important to have such a document, because DNSSEC
>failures may seriously endanger the deployment of DNSSEC (which is
>already too low). The current draft seems a good starting point and I
>support its adoption.
>
>I'm willing to review. Let's start immediately with -09:
>
>draft-ietf-dnsop-extended-error (recently approved by the IESG) should
>be mentioned, since one of the biggest operational problem with DNSSEC
>is the difficulty to understand why a resolver returns a SERVFAIL to
>you.
>
>> More often, to date, failed validation is due to operator error and
>> not an attempt to forge data.
>
>It can be a bug in software, too. Specially with complicated things
>like NSEC3+optout+ENT+dynupdate :-{
>
>The draft apparently do not mention advices on expiration slack (such
>as val-sig-skew-min and val-sig-skew-max in Unbound). Is there a
>consensus on (I quote Unbound documentation) "The signature inception
>and expiration dates are allowed to be off by 10% of the signature
>lifetime"?
>
>> However, a DNSSEC validator is not able to determine other than by
>> trying whether a signature scheme is supported by the authoritative
>> server.
>
>This one is unclear. First, the signer is not always an authoritative
>server, signature can be done offline. Second, querying the DNSKEY is
>enough, no? (Or querying the signatures, but I assume a zone won't
>publish a DNSKEY without being able to sign with this algorithm.)
>
>Section 12 "Invalid Reporting Recommendations" is questionable. Since
>most DNSSEC validation errors are not attacks, reporting these errors
>may overload the DRO with problems she can do nothing
>about. Monitoring is a good idea but monitoring what? "Important" (for
>the DRO) domains?
>
>Also, the draft has many, it seems, grammar / language
>problems. ("This introduces a potentially huge vector for
>configuration errors, but due to human intervention as well as
>potential misunderstanding of ongoing operations.")
>
>
>___
>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] DNS over XMPP - DoX

[Jacques Latour]

https://xmpp.org/extensions/xep-0418.html

XEP-0418: DNS Queries over XMPP (DoX)
Abstract:  This specification defines an XMPP protocol extension 
for sending DNS queries and getting DNS responses over XML streams. Each DNS 
query-response pair is mapped into an IQ exchange.
Author: Travis Burtrum

Should be added to https://developers.cloudflare.com/1.1.1.1/fun-stuff/


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

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

[Jacques Latour]

Plus! 
Is anyone looking at adding DoH and DoT servers as part of DHCP/SLAAC?  So the 
local resolver and apps and browsers can go the _appropriate_ name resolution 
resource(s) using the protocol of choice. That would be much simpler for 
default configuration in enterprise and ISP.

>From: DNSOP  On Behalf Of Ralf Weber

>You can not get on a network with at least trusting some of its 
>infrastructure, be
>it SLAAC or DHCP (which BTW both carry information for DNS resolving). The
>question is where you draw the line and IMHO DNS or name resolution is a basic
>network function and not an application setting.
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Jacques Latour]

It's not what you access, it's what you block, since reverse DNS is not a good 
solution in this instance, you need to map the DNS block list to it's IP 
addresses and block those IPs, and readjust based on TTL, you'll end up 
blocking more stuff than intended, huge mess, but if you can't trust the DNS to 
be clean then that's one option to enforce a security policy when browsers are 
using DoH. This should probably go in 
draft-livingood-doh-implementation-risks-issues

Jacques

>-Original Message-
>From: Adam Roach 
>Sent: March 20, 2019 2:15 PM
>To: Jacques Latour ; Jared Mauch
>; Brian Dickson 
>Cc: Ted Hardie ; DoH WG ; dnsop
>; paul vixie ; Michael Sinatra
>; Stephen Farrell 
>Subject: Re: [Doh] [DNSOP] New I-D: draft-reid-doh-operator
>
>On 3/20/19 12:59 PM, Jacques Latour wrote:
>> I'm trying to balance in my mind the requirements to protect the DNS
>> vs. what is happening on the wire, in the end, the browser will
>> connect to an IP address which can be (in most case) mapped to a
>> domain name
>
>
>I don't think this second assertion is true in 2019. See if you can make even a
>first-order reasonable guess what I'm accessing at 172.217.1.129 or
>23.227.38.32 or 52.40.19.98 or 216.105.38.15 or 104.20.1.85.
>
>(Hint: I took these all from sites I visit frequently, and none are 
>particularly
>obscure sites)
>
>/a

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

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

[Jacques Latour]

I'm trying to balance in my mind the requirements to protect the DNS vs. what 
is happening on the wire, in the end, the browser will connect to an IP address 
which can be (in most case) mapped to a domain name, which we're trying to 
protect/hide with all sorts of encryption.  Someone that has access to the DNS 
on the wire can see what is queried, someone with wire access can see who is 
connecting where.  Where's the privacy protected here? Do we need to balance 
both?

DoH is going to force enterprises/network operator to beef up their security 
policies by enforcing higher level of outbound IP address filtering. Having a 
matching DNS block list in corresponding outbound IP address filters. Going to 
be messy :-)

Jacques

 

>-Original Message-
>From: DNSOP  On Behalf Of Jared Mauch
>Sent: March 20, 2019 6:10 AM
>To: Brian Dickson 
>Cc: Ted Hardie ; DoH WG ; dnsop
>; paul vixie ; Michael Sinatra
>; Stephen Farrell 
>Subject: Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator
>
>
>
>> On Mar 19, 2019, at 11:17 PM, Brian Dickson
> wrote:
>>
>>
>>
>> On Tue, Mar 19, 2019 at 6:42 PM Stephen Farrell 
>wrote:
>>
>> Hiya,
>>
>> One individualistic data point on this sub-topic, and a real point:
>>
>> On 20/03/2019 01:13, Jared Mauch wrote:
>> > My impression is there are people who will not be satisfied until
>> > all traffic looks identical and you have zero way to protect your
>> > home,
>>
>> I do not claim that everyone ought do the same, but I absolutely do
>> claim that encouraging voluntary policy adherence by dealing with the
>> people using the n/w is preferable to many egregiously invasive
>> attempts to force technical policy enforcement on unwilling serf-like
>> users.
>>
>> So, this is the problem:
>> - If a network operator has any policy that is enforceable, ONLY the 
>> technical
>policy enforcement model scales.
>> - In such an environment, there are only, ever, "willing users", because, in
>order to use the network, they are required to agree to the policies.
>>
>> This makes the argument you have above, a vacuously defined one.
>> You want to encourage voluntary policy adherence for a non-existent set of
>otherwise unwilling users.
>>
>> I understand your position: you would prefer that {some,all} networks were
>not employing policies that {you,some people} disagree with.
>> I sympathize, but I disagree. What we need are mechanisms that scale.
>> My position (personally) is that we find ways to have scalable, technical
>mechanisms.
>> They should allow users (or machine administrators) to be as compliant as
>they are willing, and no more.
>> They should allow networks to enforce their policies, while treading as 
>> lightly
>as possible.
>> It should be possible to use technical means to handle this negotiation with
>little to no user input required.
>> The analogy is roughly that of escalation-of-force in law enforcement, 
>> starting
>at a level of "polite requests".
>>
>> You can disagree, but I implore you: please don't stand in the way of those
>wanting to find consensus on scalable, flexible, technical solutions that
>encompass a wide range of network policies and enforcement needs.
>>
>> The main point is, I believe the end result will be mechanisms that allow you
>to deploy networks that meet your needs, and software that you can configure
>to bypass such controls, but that neither of those should ever be the default
>configurations.
>>
>> If the results allow you to do what you want/need, and also allow others to 
>> do
>what they want/need, everyone should be happy enough with the result.
>>
>> Can we at least agree on this as a desired goal for this work?
>
>Often as an industry we may discuss various solutions that are great for 
>oneself
>but don’t scale when looking at the big picture.  I’m of the feeling that not
>everything should be a standard, even things that look like they might be
>standard-ish.  I could encode many things over TCP over TLS over QUIC over
>HTTP.  I’ve seen unencoded data stored in DNS TXT records that have
>sorted/ordered information so you can do interesting things.
>
>Just because one can do these things doesn’t mean one should, or that the
>entirety of the industry should (or even will).
>
>Goals and motivations are key here, if the goal is to make it such that 
>dissidents
>whose lives may be threatened (this is an example a co-worker always uses on
>me in these types of conversations to support their position) by the local 
>regime
>may face a threatening situation or die as a result of using technology, it’s 
>not
>the fault of the protocol.  Should we improve for every corner case like this? 
> As
>vixie has pointed it, it may be an innocuous device like a chromecast where the
>ISP provided DNS is horrible.  (I can think of many bad devices in the consumer
>space that break the DNS spec in really unique ways).  It’s entirely possible 
>that
>the appliance works best when not using that ISP service, but it is also data
>leakage to a lar

Re: [DNSOP] Acceptance processing in draft-ietf-regext-dnsoperator-to-rrr-protocol-04 section 3.4

[Jacques Latour]

The intent of the document at bootstrap is for the parent to perform sufficient 
tests to ensure they are conformable in bootstrapping the chain of trust, I 
agree with you that these tests and other could be performed by the parent to 
ensure the child/DNS Operator is "well behaved" and/or has "good DNSSEC 
hygiene".

I think defining the criteria for good DNSSEC hygiene is not in scope for this 
document, but this document could certainly reference something like 
https://tools.ietf.org/html/draft-wallstrom-dnsop-dns-delegation-requirements-03
  with your details in section 8 "DNSSEC Requirements".

Also, I'm thinking at registration time to check immediately if the newly 
domain is suitable for DNSSEC bootstrapping, meaning the domain has a proper 
CDS or CDNSKEY and has good hygiene and all, so that when we publish the zone 
file with that new domain the DS record is included right away.  Any issues 
with that?


 

-Original Message-
From: DNSOP  On Behalf Of Viktor Dukhovni
Sent: May 15, 2018 4:11 PM
To: dnsop 
Subject: Re: [DNSOP] Acceptance processing in 
draft-ietf-regext-dnsoperator-to-rrr-protocol-04 section 3.4



> On May 15, 2018, at 3:57 PM, John Levine  wrote:
> 
> I think it's a swell idea to offer people DNSSEC testing services but
> it's hopeless to conflate it with key rotation.

I completely agree with you on key rotation, once the zone has already
been operating signed.  But the document also covers enrollment:

   This document describes a simple protocol that allows a third party
   DNS operator to: establish the initial chain of trust (bootstrap
---
   DNSSEC) for a delegation; update DS records for a delegation; and,
   
   remove DS records from a secure delegation.  The DNS operator may do
   these things in a trusted manner, without involving the Registrant
   for each operation.  This same protocol can be used by Registrants to
   maintain their own domains if they wish.

It is at the time of initial enrollment that I'd like to propose greater
due diligence.

-- 
Viktor.

___
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] CDS polling, was Re: [Ext] Re: Clarifying referrals (#35)

[Jacques Latour]

Parental synchronization is inevitable so we would be better to find the
best way to make it happen.  I think there are 3 plausible methods to do
the synchronization.

1. Child Notification: Child sends NOTIFY to a predefined parental
destination. The parent then polls the child zone for changes and EPP
commands issued to reflect the changes.

2. DNS Operator Notification: DNS Operator changes the child zone. DNS
Operator finds parental agent API via RDAP or TCKL to notify of changes to
be performed. The parent then polls the child zone for changes and EPP
commands issued to reflect the changes.

- 
https://tools.ietf.org/html/draft-ietf-regext-dnsoperator-to-rrr-protocol-0
4
- parental agent can be the registrar or the registry

3. Parent Polling*: On a batch/regular basis, the parent then polls all
child zones for changes and EPP commands issued to reflect the changes.
 *The parent can be the registrar or the registry.

- a la cz.nic, full zone polling
(https://en.blog.nic.cz/2017/06/21/lets-make-dns-great-again/)
- it would be nice to send an EPP poll message to the registrar when a
domain is changed by the TLD
- some of the research we¹ve done shows that there are no ICANN policy
impact of doing #3 across the board (ccTLD and gTLD).

Personally, I like a mix of #3 and #1, on a regular basis poll the entire
zone for changes, and have a mechanism to listen to child notifications
for urgent changes.

_AND_ remember, the preferred method by far is to submit a DS/DNSKEY
record is via the RRR EPP model.  The above is when that RRR EPP model is
non functional.

Jack


On 2017-11-14, 7:08 AM, "DNSOP on behalf of Tony Finch"
 wrote:

>Evan Hunt  wrote:
>>
>> In the present context, I was only suggesting this method be used for
>> NOTIFY, not UPDATE -- to signal the parent that it should poll the child
>> for CDS/CDNSKEY.  (I guess CSYNC could be included in the mix as well,
>> though, for updating NS and glue.)
>
>Yes.
>
>> I would suggest the child should be polled periodically regardless. If
>> the SRV record were spoofed, causing the child to send a NOTIFY to the
>> wrong address, synchronization should still occur, just not as quickly.
>
>The starting point for this thread was parental agents saying they don't
>like polling, but having thought about this a bit more I think I agree
>that it would be unwise not to poll. If there's a way to get polled early
>by NOTIFY then that's probably still good for both parent and child -
>parent can poll more slowly, and child can get prompt updates.
>
>I read Mark Elkins' article with interest. I would prefer to use NOTIFY
>rather than a web hook because it's much more plausible to imagine
>supporting this inside a DNS server with some kind of notify-parent
>feature.
>
>I like the idea of being able to automatically discover where to send
>parental notifies. But this can only work if the parental agent doesn't
>require TSIG. On the other hand, we can't rely on autodiscovery because
>I wouldn't bet on the registries publishing the necessary SRV records...
>
>Any opinions on whether this is worth pursuing?
>
>Tony.
>-- 
>f.anthony.n.finchhttp://dotat.at/  -  I xn--zr8h
>punycode
>Viking, North Utsire: Northwesterly backing westerly 5 to 7. Moderate or
>rough, occasionally very rough later in north. Squally showers. Good.
>
>___
>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] WGLC on "redact" and "homenet-dot"

[Jacques Latour]

This would probably a good use case for homenet to use its own DNS class, Class 
2 - 0x0002 – Homenet (HN). How to implement is beyond my paygrade.
This would make homenet DNS very distinctive, which it is.

If we want to solve this problem, it’s going to require an extension to the DNS 
that provides a way to mark zones of this sort.   I would be more willing to 
fall on this sword if we actually got more security out of it, but I don’t 
think we do.

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

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

[Jacques Latour]

Ted, very clear summary, thank you.

I read the DNSSEC related homenet and dnsop comments and I don’t see how you 
can have DNSSEC validation for a homenet without a properly signed & delegated 
domain.  If we want a one shoe fits all solution then we need to have a single 
common domain used by all homenet, and all homenet need to use/share the same 
private homenet DNSSEC keys where these common keys can be validated against a 
common DS record inside the { homenet. home. homenet.arpa. etc } domain.

I think homenet users should have the choice of a generic homenet domain (as 
above, essentially an unsecure domain) or have the choice to use their own 
domain name for their homenet, ‘myhome.ca’ along with their own private keys 
and all. One domain per household. Then you could use your ‘myhome.ca’ DNSSEC 
infrastructure to secure your home IoT devices ☺

Where do you delegate homenet to? Advanced DNSSEC validation may check for 
proper delegation?

My 2 cents.

Jacques




From: homenet [mailto:homenet-boun...@ietf.org] On Behalf Of Ted Lemon
Sent: December-12-16 10:46 AM
To: HOMENET
Subject: Re: [homenet] WGLC on "redact" and "homenet-dot"

One thing that I think the working group should be aware of, although I don't 
know if this awareness will change anything, is that the situation with the 
.homenet allocation is less simple than we would prefer: it's not really simply 
a matter of adding .homenet to the special use domain names registry.   The 
reason is that we need DNS resolution to work properly for domains under 
.homenet, and this has to work even if a host is doing DNSSEC validation.

At present, if you were to configure a homenet router with .home or .homenet as 
the local domain, this would work perfectly nicely until you turned on DNSSEC 
validation, at which point all the names in either hierarchy would disappear.   
The reason for this is that the root zone provides proof of nonexistence for 
nonexistent names in that zone.

It is possible to address this problem by requesting ICANN to put an insecure 
delegation in the root zone.   The problem is that from a process perspective, 
this is a _lot_ more heavyweight than doing a special-use domain name 
allocation, and has no guarantee of success.   This wasn't such an issue for 
.onion when we did it, because .onion _wants_ a secure denial of existence--we 
_never_ want a .onion query to actually happen if the name has been handed to a 
resolver that doesn't understand .onion explicitly.   This is not true for 
.homenet.

There are two approaches we can take to this.   One is to proceed--ask ICANN to 
do the delegation and see what happens.   The other is to take the more 
expedient, less satisfying approach: use .home.arpa instead of .homenet.   I'm 
not in love with this as an end solution, but it has the advantage that the IAB 
controls .arpa, and so we can get an unsecure delegation right away assuming 
the IAB agrees.   I see no reason to think they would not.   It's a bit more 
typing, and there is the problem that the fourth google result for arpa is 
"Advanced Research Projects Agency.   But it would work, and quickly, and would 
keep the whole process in the family.

The other alternative is to continue with the original plan: do the special-use 
names registry allocation, and send a liason to ICANN asking them to do the 
unsecure delegation.   The downside to this approach is that we won't know 
whether the outcome will be success or failure for a long time, possibly 
several years.   And the outcome could very well be failure.   The upside is 
that we get the name we all want; the downside is that we are a long way down 
the road with no win.

I should point out that whichever way we go, we already have solved the 
immediate problem: we have a name that HNCP can use, the potential liability 
for IETF is dealt with, and our prototypes can be made to work.   So I am 
personally okay with either decision.   Our AD, Terry, may have more of a sense 
of what ICANN will do (but to some extent he really can't know, because it's up 
to committees within ICANN to actually make this decision).   I'm mentioning 
this now not to derail the process, but simply to make it really clear what our 
expectations should be.   The reason that this didn't come up in Seoul is that 
it didn't actually click for me that we had a serious problem until several of 
us were chatting on the way out of the room, after the working group had 
already decided to proceed.

On Thu, Dec 1, 2016 at 9:02 AM, Ray Bellis 
mailto:r...@bellis.me.uk>> wrote:


On 21/11/2016 13:25, Ralph Droms wrote:
> (Updated comments on draft-ietf-homenet-dot originally posted prior to the WG 
> last call)

Thanks Ralph.

I'd like to remind the WG that the LC is due to run until Friday
December 16th, so please anyone else with comments please get them in.

Ray

___
homenet mailing list
home...@ietf.org
https://www.ietf.o

Re: [DNSOP] DNSSEC operational issues long term

[Jacques Latour]

Make sure your CPE supports IPv6 only operations before putting on the shelf, 
it's hopefully IPv4 will be decommissioned 10 years from now, so DNSSEC 
bootstrap could be moot point.


>-Original Message-
>From: DNSOP [mailto:dnsop-boun...@ietf.org] On Behalf Of Mikael
>Abrahamsson
>Sent: November-16-16 8:45 PM
>To: Ondřej Surý
>Cc: dnsop
>Subject: Re: [DNSOP] DNSSEC operational issues long term
>
>On Thu, 17 Nov 2016, Ondřej Surý wrote:
>
>> Again, you are using unfair arguments.  The devices have to cope with
>> that and it doesn't have to be a protocol design.
>
>Agreed. It can also be method design. There have been some suggestions in this
>thread for ways to handle the problem. I have not seen any that is actually an
>RFC, preferrably a BCP type document that descibes the problem and suggests
>how it can be handled.
>
>Or is there a document I have missed I can point vendors and IETF people to, to
>understand and handle this DNSSEC property (that doesn't seem to be well
>known, I talked to several people this morning who had no idea this DNSSEC
>limitation existed).
>
>--
>Mikael Abrahamssonemail: swm...@swm.pp.se

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

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

[Jacques Latour]

> -Original Message-
> From: Paul Wouters [mailto:p...@nohats.ca]
> Sent: April-11-16 3:18 PM
> To: Jacques Latour
> Cc: Olafur Gudmundsson; dnsop
> Subject: Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-maintain-
> ds
> 
> On Fri, 8 Apr 2016, Jacques Latour wrote:
> 
> > two things I see;
> >
> > 1) the CDNSKEY, since CDS and CDSNKEY are used interchangeably in the
> > document, "inserts the corresponding DS RRset as requested" does not
> > work for the CDNSKEY, the parental agent must compute a DS and pick an
> algorithm & digest type based on the Parental Agent policy.
> 
> Agreed. We will fix it in the next version.
> 
> > 2) if the parental agent does not 'like' the requested CDS parameters,
> > then the parental agent can create a DS as per Parental agent policy, with
> algorithm & digest type of choosing.
> >
> > This supports parental agent that publish the DS as requested by the
> > child, and support parental agent that want to publish DS conform to their
> policies.
> 
> If the child uses CDS, and requests a DS type, and the parent does not like
> the DS type, I think the parent should refuse the update.

Exactly, it's a parent policy issue and should not part of this document.  
Perhaps in more suitable in dnsoperator-to-rrr-protocol draft?

Jack

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

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

[Jacques Latour]

Hi Olafur,

two things I see;

1) the CDNSKEY, since CDS and CDSNKEY are used interchangeably in the document, 
"inserts the corresponding DS RRset as requested" does not work for the 
CDNSKEY, the parental agent must compute a DS and pick an algorithm & digest 
type based on the Parental Agent policy.

2) if the parental agent does not 'like' the requested CDS parameters, then the 
parental agent can create a DS as per Parental agent policy, with algorithm & 
digest type of choosing.

This supports parental agent that publish the DS as requested by the child, and 
support parental agent that want to publish DS conform to their policies.

Jack



From: Olafur Gudmundsson [o...@ogud.com]
Sent: Thursday, April 07, 2016 10:36 PM
To: Jacques Latour
Cc: Tim Wicinski; dnsop; Olafur Gudmundsson
Subject: Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-maintain-ds


On Apr 7, 2016, at 11:40 AM, Jacques Latour 
mailto:jacques.lat...@cira.ca>> wrote:

Read it, like it, and

>3.1 ... The parent retrieves the CDS and inserts the corresponding DS RRset as 
>requested,

I think the parent can accept the CDS and insert the DS RRset as requested or 
as per Parent policy.

Meaning the Parent could take the signed child DNSKEY and create DS RRset based 
on parent policy and not being forced to accept the CDS algorithm &  Digest 
type.

Maybe,  the CDS record allows one to refer to a non published key i.e. one that 
is not in the DNSKEY RRset.
Thus the CDS is “more” flexible than the DNSKEY as one can publish future KSK 
w/o placing one in the DNSKEY set (for size reasons)

Olafur




> -Original Message-
> From: DNSOP [mailto:dnsop-boun...@ietf.org] On Behalf Of Tim Wicinski
> Sent: April-03-16 5:29 PM
> To: dnsop
> Subject: [DNSOP] Working Group Last Call for draft-ietf-dnsop-maintain-ds
>
> This starts a Working Group Last Call  for draft-ietf-dnsop-maintain-ds
>
> Current versions of the draft is available here:
>
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-maintain-ds/
>
> Please review the draft and offer relevant comments. Also, if someone feels
> the document is *not* ready for publication, please speak out with your
> reasons.
>
> Feel free to show up at DNSOP's Wednesday session and voice your approval
> or disapproval.
>
> This starts a two week Working Group Last Call process, and ends on
>17 April 2016
>
> thanks
> tim
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org<mailto:DNSOP@ietf.org>
> https://www.ietf.org/mailman/listinfo/dnsop
___
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] Working Group Last Call for draft-ietf-dnsop-maintain-ds

[Jacques Latour]

Read it, like it, and

>3.1 ... The parent retrieves the CDS and inserts the corresponding DS RRset as 
>requested,

I think the parent can accept the CDS and insert the DS RRset as requested or 
as per Parent policy.

Meaning the Parent could take the signed child DNSKEY and create DS RRset based 
on parent policy and not being forced to accept the CDS algorithm &  Digest 
type.



> -Original Message-
> From: DNSOP [mailto:dnsop-boun...@ietf.org] On Behalf Of Tim Wicinski
> Sent: April-03-16 5:29 PM
> To: dnsop
> Subject: [DNSOP] Working Group Last Call for draft-ietf-dnsop-maintain-ds
>
> This starts a Working Group Last Call  for draft-ietf-dnsop-maintain-ds
>
> Current versions of the draft is available here:
>
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-maintain-ds/
>
> Please review the draft and offer relevant comments. Also, if someone feels
> the document is *not* ready for publication, please speak out with your
> reasons.
>
> Feel free to show up at DNSOP's Wednesday session and voice your approval
> or disapproval.
>
> This starts a two week Working Group Last Call process, and ends on
>17 April 2016
>
> thanks
> tim
>
> ___
> 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] Any interest in draft-latour-dnsoperator-to-rrr-protocol ?

[Jacques Latour]

Hi,

I think it would fall under REGEXT once it's up? The REGEXT charter has a 
section about DNS Operator.

> The working group will also identify the requirements for a
> registration protocol where a third-party DNS provider is involved.
> These requirements will be documented in an Informational RFC.

Jack


> -Original Message-
> From: DNSOP [mailto:dnsop-boun...@ietf.org] On Behalf Of John Levine
> Sent: February-13-16 4:45 PM
> To: dnsop@ietf.org
> Subject: [DNSOP] Any interest in draft-latour-dnsoperator-to-rrr-protocol ?
> 
> I noticed the -02 of this draft go by yesterday.
> 
> It's a very rough version of a DNSSEC key record bootstrap design in which the
> operator of the delegated zone pokes the operator of the upper level zone
> using http, which tells the upper level zone to import keys from the delegated
> zone's CDS and CDNSKEY records.
> 
> Is there much interest in this?
> 
> On my tiny DNS server I have over 100 signed zones where I can't install the
> upper level DS records because I'm not the registrant, I'm just running their
> DNS.  It would be nice to have a way to do that that scales better than
> walking each of the registrants through their registrars' DNSSEC update
> processes.
> 
> 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] DNS Delegation Requirements

[Jacques Latour]

Hi,



Sent something relating to this on DNS-OARC this morning, but it seems to be 
legit to have delegation for a “_tcp.example.ca”, which fails the syntax 
requirements defined in section  “8.1.  Illegal characters MUST NOT be in the 
domain name".



A delegation can happen to a valid domain name, not necessarily a valid 
hostname.



Zonemaster fails on delegations like “_sips._tcp.cam.ac.uk”



# dig _sips._tcp.cam.ac.uk  ns +short

rnb-uls2-jabber.phone.cam.ac.uk.

cnh-uls2-jabber.phone.cam.ac.uk.

wolf-uls2-jabber.phone.cam.ac.uk.





Jack




From: DNSOP [mailto:dnsop-boun...@ietf.org] On Behalf Of Warren Kumari
Sent: February-08-16 6:51 PM
To: Darcy Kevin (FCA); dnsop
Subject: Re: [DNSOP] DNS Delegation Requirements


On Mon, Feb 8, 2016 at 3:38 PM Darcy Kevin (FCA) 
mailto:kevin.da...@fcagroup.com>> wrote:
My 2 cents…

I don’t think any DNS RFC should be tied to any specific element of Internet 
routing technology. Keep it relatively generic and avoid mention of “ASes” and 
the like, since this RFC may outlive the use of ASes for Internet routing. 
”Path diversity”, “link diversity”, “network-level redundancy”, those are all 
fine.

That works too -- RFC 2182, 3.1. ? :-)

W




- Kevin

From: DNSOP [mailto:dnsop-boun...@ietf.org] On 
Behalf Of Warren Kumari
Sent: Monday, February 08, 2016 9:21 AM
To: Ralf Weber; Jakob Schlyter
Cc: dnsop; Patrik Wallström
Subject: Re: [DNSOP] DNS Delegation Requirements


On Mon, Feb 8, 2016 at 2:00 AM Ralf Weber 
mailto:d...@fl1ger.de>> wrote:
Moin!

On 8 Feb 2016, at 9:57, Jakob Schlyter wrote:
> At this point, we're seeking more public comments - on this mailing
> list (unless the chairs disapproves), on the our issue tracker [4] or
> via email to the authors.
Thanks a lot for this work. I certainly would like dnsop to work on
this.

I would soften some of language and have a question.

5.1. There are use cases where the serial number rarely if ever is the
same on all servers and it's only really used inside communication for a
given domain and not during resolution. So the only people who know if a
divergent serial number is a problem are the domain owners. So we
shouldn't tell the public that this is a problem. I would say that a
different SOA serial number could be seen as an indicator of an
inconsistent setup, but that further analysis is required to really
conclude that.

6.2 The name servers SHOULD NOT belong to the same AS
I would drop that requirement altogether or make it a MAY. We really
should not tell people how to build networks from the DNS world.


I think that the SHOULD NOT is actually correct here -- from RFC1771: The use 
of the term Autonomous System
here stresses the fact that, even when multiple IGPs and metrics are
used, the administration of an AS appears to other ASs to have a
single coherent interior routing plan and presents a consistent
picture of what destinations are reachable through it.

An AS is a "network", run by one organization. This means that there is a 
monkey sitting somewhere making all of the routing decisions, and sometimes 
monkeys screw up. Having a nameserver in an AS that is run by a different 
monkey means that you need multiple monkeys messing up at the same time[0]. 
Also, a significant amount of routing and traffic engineering decisions are 
made at the AS level ("Meh, I'll local-pref AS 42 down to move this traffic 
$there") - this means that sometimes folk screw up and accidentally block 
access to some set of ASes - SIDR may or may not make this more likely :-)

This is *not* telling people how to build their network - it is simply 
*suggesting* that they consider putting some net of nameservers in a network 
run by someone else.  If you understand the implications of putting all of your 
nameservers in one AS, good for you. If not, chances are it's safer to put at 
least some elsewhere...

W
[0]: This (obviously) isn't really true, both ASs could share the same 
upstream, router, etc. RFC 2182, 3.1. says it best:
"They should also be connected to
the net via quite diverse paths.  This means that the failure of any
one link, or of routing within some segment of the network (such as a
service provider) will not make all of the servers unreachable."






8.7 We should point out here that neither an MX nor an A record are
required at the zone apex or do you want either of them mandatory?

On the SOA settings I do have a question. Would the following SOA be
legitimate according to this draft?
localhost. root.localhost. 1115106304 16384 2048 1048576 2560
If not why not, as my spot checking didn't find anything that made it
invalid.

So long
-Ralf

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

Re: [DNSOP] The DNSOP WG has placed draft-ogud-dnsop-maintain-ds in state "Candidate for WG Adoption"

[Jacques Latour]

> -Original Message-
> From: DNSOP [mailto:dnsop-boun...@ietf.org] On Behalf Of Jan Vcelák
> Sent: November-08-15 3:50 PM
> To: Olafur Gudmundsson; Shane Kerr
> Cc: dnsop@ietf.org
> Subject: Re: [DNSOP] The DNSOP WG has placed draft-ogud-dnsop-maintain-ds
> in state "Candidate for WG Adoption"
> 
> >> * Perhaps "Accept with challenge" should provide some advice on how
> >> this works. For example, a TXT record with a unique key for each zone
> >> (or customer) seems like a good recommendation. It might also make
> >> sense if each child domain (or customer) has a unique ownername to
> >> look for, to prevent 3rd parties from detecting such bootstrapping.
> >>  (Yes a 3rd party can see the CDS update followed by the DS update,
> >> but they won't know the verification used.) Also to note that after
> >> the trust is established that the challenge record should no longer
> >> be necessary and can be removed.
> >
> > There are many different ways to do this
> > a) generate a random name with arecord with defined content
> > b) put a  record at a fixed name with random content
> > c) require resigning the CDS/CDNSKEY record with defined expiration
> > time etc. it is just a question of imagination what people come up with.
> > If the working group wants to recommend one standard way, that is fine.
> > Text welcome
> 
> The value determined by the parent need not be random but can actually
> authenticate the CDS RDATA content. What about something like this:
> 
> --8<--
> 
> Parent instructs the requestor to add a TXT RR into the zone with owner name
> matching the zone name prefixed with the '_cds' label. The RDATA of the record
> contain a value determined by the parent and provided to the client by a 
> secure
> channel (e.g. domain registration system).
> 
> The parent constructs the value as follows:
> 
> HEX(HMAC-SHA256-64(parent_secret, cds_owner|cds_rdata))
> 
> Where:
> 
> - HEX is a conversion from binary to lowercase hexadecimal digits.
> - HMAC-SHA256-64 is an authentication code as specified in RFC 6234.
> - server_secret is a cryptographically strong secret key known only
>   to the parent.
> - cds_owner is the wire format representation of the child zone name
>   in the canonical form.
> - cds_rdata is the wire format representation of the CDS RDATA in the
>   canonical form.
> 
> --8<--
> 
> However, this trust establishing dance still requires interaction with the 
> parent
> via an out-of-band channel. So there is a little difference from giving the 
> parent
> the initial DS records directly.
> 

Jan, this is exactly where we started and ended up where we are today;

We originally started looking at a trust dance with secret keys and out of band 
key exchange, it's not what we were looking for since we're trying to avoid any 
out of band exchange. However, the outcome of this process would prove the DNS 
operator is in control of the child zone, here I'm not sure we need to trust 
that the DNS operator is in control of the child zone, we need to prove DNS 
Operator control, not trust.

* When a registrant submits a DS record via RRR/EPP to the registry, we 
(registry) trust the registrant to submit a DS, we have no proof it's the 
right/correct DS. (compromised registrant credentials, bad cut and paste)

Then we looked at simpler trust/proof dances with/without challenge token as 
TXT record " _delegate DNSKEY ID ChallengeToken", again, this proves the DNS 
operator is in control of the child zone, and that it proved it interacted with 
the parent to get the challenge token. We also looked at having just an initial 
CDS record instead of a TXT record as a proof of control.

For the initial bootstrap, we don't need to prove the registrant controls the 
child, we need to prove the DNS Operator controls the zone.   The trust was 
established during the domain registration process, and subsequently the 
registrant delegated operation of the zone to the DNS Operator.

Something like that, we'll have flexibility on the method to prove control 
(API) to meet the parents' requirements.

Jack


 
> Cheers,
> 
> Jan
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

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

Re: [DNSOP] Call for Adoption draft-wkumari-dnsop-root-loopback

[Jacques Latour]

I think the one big drawback for me is the loss visibility and control for the 
root operators. As an example, DITL, what value will that have if only subset 
of queries make it to root servers? Will DNS-OARC have to collect logs from all 
these loopback authoritative slave recursive?  
-1 for adoption.
 
> -Original Message-
> From: DNSOP [mailto:dnsop-boun...@ietf.org] On Behalf Of Paul Hoffman
> Sent: November-17-14 11:05 PM
> To: Nicholas Weaver
> Cc: dnsop
> Subject: Re: [DNSOP] Call for Adoption draft-wkumari-dnsop-root-loopback
> 
> On Nov 17, 2014, at 5:50 PM, Nicholas Weaver 
> wrote:
> > Trying to be polite here, but this seems just silly, and the only thing 
> > really
> should be "Don't Bother".
> >
> >
> > Root latency frankly speaking does not matter.  Lookups to the root
> themselves should be rare, and the responses have very long TTLs (48 hours!).
> So this is clearly optimizing something that needs no optimization.
> 
> It's fine if you don't want the WG to adopt this draft, but that second 
> sentence is
> clearly wrong. The third paragraph of the introduction says:
> 
>   The primary goal of this design is to provide faster negative
>   responses to stub resolver queries that contain junk queries. This
>   design will probably have little effect on getting faster positive
>   responses to stub resolver for good queries on TLDs, because the data
>   for those zones is usually long-lived and already in the cache of the
>   recursive resolver; thus, getting faster positive responses is a
>   non-goal of this design.
> 
> Lookups to the root for things that don't actually exist in the root happen 
> all the
> time, yes?
> 
> --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

Re: [DNSOP] Working Group Last call for draft-ietf-dnsop-delegation-trust-maintainance

[Jacques Latour]

"The Child may also remove old  keys, but this document does not support 
removing all keys."
"When the Parent DS is "in-sync" with the CDS / CDNSKEY resource records, the 
Child DNS Operator MAY delete the CDS / CDNSKEY record(s);"

Read the whole thing a couple of times and it's not clear to me how to remove 
one or more DS? Once "in-sync", If the parental agent polling/mechanism detect 
a CDS for an existing DS, or a CDNSKEY for a matching DS, then you remove the 
DS but not if it's the last one? Right? Or there's a "ADD/DELETE" parameter to 
the proposed CDS and CDNSKEY resource records to instruct the parental agent on 
the type of operation to perform?

Jack

> -Original Message-
> From: DNSOP [mailto:dnsop-boun...@ietf.org] On Behalf Of Joe Abley
> Sent: April-21-14 9:34 AM
> To: Warren Kumari
> Cc: dnsop; Paul Hoffman
> Subject: Re: [DNSOP] Working Group Last call for draft-ietf-dnsop-
> delegation-trust-maintainance
> 
> 
> On 16 Apr 2014, at 8:02, Warren Kumari  wrote:
> 
> > I think I made it even clearer:
> > The first time a DNS operator signs a zone, they need to communicate
> > the keying material to their parent through some out-of-band method to
> > complete the chain of trust. Depending on the desires of the parent,
> > the child might send their DNSKEY record, a DS record, or both.
> 
> I don't think you mean "the first time a DNS operator signs a zone". You're
> making an assumption that a zone, once signed, will never be unsigned. In
> fact, a zone can be signed, then unsigned, any number of times.
> 
> "Whenever a zone's insecure delegation is replaced by a secure delegation,
> the DNS operator needs to communicate the keying material..."
> 
> 
> Joe
> ___
> 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-kumari-ogud-dnsop-cds-00.txt

[Jacques Latour]

Another "what if scenario" for bypassing the EPP keyrelay with automation, what 
if there was a CKEYRELAY record pointing to the gaining DNS operator name 
servers, where the parent zone operator can grab the new DS record to be 
pre-published prior DNS operator transfer? 

Potentially, parent zone can manage add/delete/transfers automatically, except 
for the initial DNSSEC setup which needs to be authenticated.

Jack
 
> -Original Message-
> From: dnsop-boun...@ietf.org [mailto:dnsop-boun...@ietf.org] On Behalf
> Of Paul Hoffman
> Sent: February-19-13 11:37 AM
> To: dnsop@ietf.org WG
> Subject: Re: [DNSOP] New Version Notification for draft-kumari-ogud-
> dnsop-cds-00.txt
> 
> On Feb 19, 2013, at 8:07 AM, Paul Wouters  wrote:
> 
> > What is missing in this draft doing the same for other parent-child
> > data, such as NS and glue records. Since we have an authenticated
> > parent-child relationship now, why not extend this draft to include
> > CNS/GLUEA/GLUE ? To me it makes sense to integrate it here,
> > because the mechanism will be basically identical, although perhaps
> > some more prevention for shooting one's foot might be required.
> 
> +1. The operational implications of NS record changes are the same as for DS,
> even though the DNS protocol ramifications are different.
> 
> And, before someone suggests it, I am *not* in favor of a kitchen-sink
> approach that defines some record of a random type as being for the parent.
> It is fine for us to specify as many of these records now that we know about
> (DS and NS and glue being mentioned so far), and if someone comes up with
> one later, they can update the RFC with a new type for the new record.
> 
> --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