Re: [DNSOP] CDS/CDNSKEY RRSet authentication

[Richard Lamb]

Good catch. Thanks for identifying this and making it signed by both.  -Rick


> -Original Message-
> From: DNSOP [mailto:dnsop-boun...@ietf.org] On Behalf Of Mark Andrews
> Sent: Saturday, July 29, 2017 5:39 PM
> To: Tony Finch 
> Cc: dnsop@ietf.org
> Subject: Re: [DNSOP] CDS/CDNSKEY RRSet authentication
> 
> 
> In message ,
> Tony Finch
>  writes:
> > I think I have spotted a lacuna or possibly erratum in RFC 7344.
> >
> > In section 4.1 bullet 2 it says:
> >
> >o  Signer: MUST be signed with a key that is represented in both the
> >   current DNSKEY and DS RRsets, unless [unusual case]
> 
> It just means that signers that know about ksk/zsk have special rules for cds
> and cdnskey.  This is from BIND's dnssec-signzone and causes the cds and
> cdnskey rrsets to be signed with both ksk and zsk dnskeys.
> 
> } else if (set->type == dns_rdatatype_cds ||
>set->type == dns_rdatatype_cdnskey ||
>iszsk(key)) {
> 

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

Re: [DNSOP] [iesg-secret...@ietf.org: Results of IETF-conflict review for draft-klensin-dns-function-considerations-04]

[Richard Lamb]

Thanks for calming fears.  With "..document asks the question of whether it is 
time to either redesign and replace the DNS.." in the abstract of a doc by 
Klensin, I was a bit worried.  -Rick

> -Original Message-
> From: DNSOP [mailto:dnsop-boun...@ietf.org] On Behalf Of Paul Hoffman
> Sent: Monday, December 18, 2017 11:31 AM
> To: Stephane Bortzmeyer 
> Cc: dnsop@ietf.Org
> Subject: Re: [DNSOP] [iesg-secret...@ietf.org: Results of IETF-conflict review
> for draft-klensin-dns-function-considerations-04]
> 
> On 18 Dec 2017, at 11:16, Stephane Bortzmeyer wrote:
> 
> > Probably relevant for this group.
> 
> Surprisingly not. An IETF-conflict review is just the IESG's way of giving 
> input
> on a document that the Independent Submissions Editor (ISE) might publish
> in the future.
> 
> Having said that, if anyone has comments on the document that you feel
> that the ISE should consider before publishing it, the ISE generally likes to
> hear them. You can send them to rfc-...@rfc-editor.org.
> 
> FWIW, all the documents that the ISE is considering can be found at
> . More about the ISE's role can be
> found at .
> 
> --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] Regarding draft-jabley-dnssec-trust-anchor-11

[Richard Lamb]

I have carefully read this draft and now have implemented its contents
twice.  Once at the root and now on a root key rollover test setup*.  The
draft looks good to me.

-Rick

* http://icksk.dnssek.info/fauxroot.html
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Expiration impending:

[Richard Lamb]

Sheesh..I thought we were talking about engineering issues.

Speaking only as the humble engineer who helped develop the publication methods 
and wrote the software that generates all the pieces, the most recent draft 
does describe what my programs, scripts, and other pieces do.  If there is any 
technical variance, please let me know I don’t pretend to be perfect.  I run 
another copy of some of the pieces on my KSK rollover test setup now, so id 
like to know.

I have no opinion regarding the more abstract discussion regarding where such a 
description belongs and look to learn from those better versed in that subject.

-Rick



From: DNSOP [mailto:dnsop-boun...@ietf.org] On Behalf Of George Michaelson
Sent: Monday, October 5, 2015 8:07 AM
To: Joe Abley 
Cc: dnsop WG ; Paul Hoffman 
Subject: Re: [DNSOP] Expiration impending: 


If its on the internet, its not out of band.

On Mon, Oct 5, 2015 at 9:55 AM, Joe Abley 
mailto:jab...@hopcount.ca>> wrote:


On 5 Oct 2015, at 10:42, George Michaelson wrote:

> Something very left field for me, but I believe important, is that we need
> to also publish the out-of-band publication point of the trust material.

This draft is exclusively concerned with publishing trust anchors out-of-band 
of the protocol.

> I mentioned this to Joe some time ago and was very correctly told "out of
> scope" but I believe its nonsensical to exclude physical publication, eg in
> newspapers of record for at least 3 economies worldwide, of the hash of the
> public key as a standing event.

This draft aims to document current practice. To my knowledge, nobody has ever 
published a trust anchor (or even a pointer to it) in print media.

> In-band only has some issues for me, if we are talking about trust.

Me too, hence the decision by ICANN to publish trust anchors using out-of-band 
mechanisms in 2009/2010, as this draft aims to document.


Joe

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

Re: [DNSOP] Expiration impending:

[Richard Lamb]

Given that there are least three implementations based on this draft in 
widespread use, IMHO, I believe this draft should move forward as is.  As 
mentioned below, a stable reference would be useful for implementers like 
myself. -Rick


-Original Message-
From: DNSOP [mailto:dnsop-boun...@ietf.org] On Behalf Of W.C.A. Wijngaards
Sent: Tuesday, October 6, 2015 1:53 AM
To: dnsop@ietf.org
Subject: Re: [DNSOP] Expiration impending: 


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi,

On 05/10/15 23:42, Suzanne Woolf wrote:
> All,
> 
> First, thanks to the engaging on this.
> 
> On Oct 5, 2015, at 5:20 PM, "Joe Abley" 
> wrote:
>> 
>> Perhaps it's time to sit back and wait for others here to express an 
>> opinion.
> 
> I'd like to hear opinions from others in the WG with an operational 
> interest in the DNSSEC root trust anchor.

It documents a procedure we implemented, and a stable reference would be a good 
thing.

> Does this document meet a need you have? If so, how well does it meet 
> the need, and what would it take (if anything) for the document to 
> meet that need more effectively?

Unbound implements the draft in open source, in its own command-line tool 
'unbound-anchor'.  It combines a compiled-in root-anchor, with
RFC5011 rollover and this draft.  At the first start it has failover over from 
the initial anchor to the next option, and this draft is the fallback.  On 
subsequent invocations it keeps state, a rolling anchor that it keeps track of. 
 If RFC5011 tracking fails, it uses this draft to fetch the xml file with the 
new key.  The tool is organisation-agnostic and can also be configured to 
perform the same mechanics in another environment (eg. test environments).

Best regards, Wouter
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJWE4vbAAoJEJ9vHC1+BF+NxPMQAIAmFaUaF6ZKQvzMLZ+yAuDm
66MaTO2i68q6LH3ZHCEl6dXMz3sGL+8RaKCN1IK6EyvXUIoCaulkJdbem4MeFsGk
/w1Bxxfybgao5+pBPd3Ciz6caYfMHrfkqFL7broBsCLNBlfwVUEUPBJpfYQbF8i+
TQaqyGm/oH2VPtFq03HL/o/CJUgbZNQWT1CKdzEEuoyrmyotzXQkfsnXrW79t/hW
tt8Aeq5VSHpBbkSlrq8EYDunhjwQKgJwhx/YUVpqF/JrjO7KDqzO7QabYY4i1h95
LTdcZmrWUfKSPnzN0lD3MSmSvJMMgz18VBXQLO2cHj0QDaDFd9pe0mud0em9gIPz
hLhyWvbxeNasT8CbH5vwJ77p/6xmhMsYT4C2EHtJacPmG9Y4BfUDyo1d0hec0eF5
uLmpbp+TCicd3dHNNcIPWjDcxyCT7lTNOLPS78fSOhdju2khijn9b7RPnTqjtmUV
Wf8IIYnN0fIapymNsiNXqarV3uC8ly7XhnqK+XQ6z7KgArh/OkrFcGiJAcHn1wlr
mSkSKeeGpF8snSlbnMX9+Y9TvBCFrNOP+awzDvKqBnV3yS5Cu2bPottH9Yp/xs96
E36eMwX35WUuh7uOCKR4IswpjChds0jSW75oJ6GYb9ItLfy6ehuGbyUFD2AW130y
SrOmADZfr8SG6aGxUokH
=4snr
-END PGP SIGNATURE-

___
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-maintain-ds

[Richard Lamb]

Olafur-

Read it.  Liked it. No changes needed. Now implementing it.

Thank you for doing this and finishing/clarifying the CDS work.  Will send you 
a note when I have things running.

-Rick


From: DNSOP [mailto:dnsop-boun...@ietf.org] On Behalf Of Ólafur Guðmundsson
Sent: Sunday, April 3, 2016 8:26 PM
To: Tim Wicinski 
Cc: dnsop 
Subject: Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-maintain-ds


Dear colleagues,
a new version of the document has been posted that fixes few minor grammatical 
and spelling errors.

this is version 02
URL:
https://www.ietf.org/internet-drafts/draft-ietf-dnsop-maintain-ds-02.txt
Status: https://datatracker.ietf.org/doc/draft-ietf-dnsop-maintain-ds/
Htmlized:   https://tools.ietf.org/html/draft-ietf-dnsop-maintain-ds-02
Diff:   
https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-maintain-ds-02

Olafur

On Sun, Apr 3, 2016 at 6:29 PM, Tim Wicinski 
mailto:tjw.i...@gmail.com>> wrote:
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] Working Group Last Call for draft-ietf-dnsop-maintain-ds

[Richard Lamb]

Just to complete the thought. As promised here’s the link to my demo 
implementation.  https://www.co.tt/cdstest.cgi   -Rick



From: Richard Lamb
Sent: Wednesday, April 6, 2016 9:34 AM
To: 'Ólafur Guðmundsson' ; Tim Wicinski 

Cc: dnsop 
Subject: RE: [DNSOP] Working Group Last Call for draft-ietf-dnsop-maintain-ds

Olafur-

Read it.  Liked it. No changes needed. Now implementing it.

Thank you for doing this and finishing/clarifying the CDS work.  Will send you 
a note when I have things running.

-Rick


From: DNSOP [mailto:dnsop-boun...@ietf.org] On Behalf Of Ólafur Guðmundsson
Sent: Sunday, April 3, 2016 8:26 PM
To: Tim Wicinski mailto:tjw.i...@gmail.com>>
Cc: dnsop mailto:dnsop@ietf.org>>
Subject: Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-maintain-ds


Dear colleagues,
a new version of the document has been posted that fixes few minor grammatical 
and spelling errors.

this is version 02
URL:
https://www.ietf.org/internet-drafts/draft-ietf-dnsop-maintain-ds-02.txt
Status: https://datatracker.ietf.org/doc/draft-ietf-dnsop-maintain-ds/
Htmlized:   https://tools.ietf.org/html/draft-ietf-dnsop-maintain-ds-02
Diff:   
https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-maintain-ds-02

Olafur

On Sun, Apr 3, 2016 at 6:29 PM, Tim Wicinski 
mailto:tjw.i...@gmail.com>> wrote:
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
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] .arpa

[Richard Lamb]

 +1 to all from  frmr usgovie.  We ain't that clever.



On Wednesday, March 22, 2017, Jim Reid  wrote:

>
> > On 21 Mar 2017, at 14:53, Suzanne Woolf  > wrote:
> >
> > RFC 3172 was written in 2001…
>
> RFC 3172 was an attempt to rewrite history and contrive an acronym:
> Address and Routing Parameter Area - really?
>
> > Respectfully, I’ve always wondered who has this problem (US or non-US)
> besides network infrastructure geeks Of a Certain Age (yes, including
> myself, and many IETF participants).
>
> It's a convenient tool for those hostile to USG "control" of the Internet:
> ie the US military is responsible for everything under .arpa, the US
> military's ARPA has still got some special status in the
> operation/development/control of the Internet, etc, etc. [And say things
> like "if .arpa isn't for US military control, why can't the string be
> changed?" or ".arpa hasn't been renamed since the Internet started 25-30
> years ago. That proves ARPA/DoD is in charge of the Internet.".] It's utter
> nonsense of course. But that doesn't stop government officials and
> policymakers from making these arguments. I have seen them do this many
> times. Sigh. RFC3172 didn't make things better.
>
> ___
> 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] Cache poisoning on DNSSEC

[Richard Lamb]

Another 10 year delay would benefit all our respective businesses ;-) But to 
move forward you sometimes have to take chances.
-Rick

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David Ulevitch
Sent: Tuesday, August 19, 2008 9:09 AM
To: David Conrad
Cc: dnsop@ietf.org WG
Subject: Re: [DNSOP] Cache poisoning on DNSSEC

David Conrad wrote:

>> which you could have argue against 10 years ago but not now.
>
> It's such a shame that computer processing technology for doing stuff
> like cryptography hasn't advanced in 10 years.
>

Unfortunately, the Internet has grown in 10 years, too.

Do you want to fund my costs of supporting (and encouraging my clients
to use) DNSSEC?

If I'm going to spend cycles on improving the state of the art, it will
be with a solution that is:

1) Solving a real customer need
2) Possible to evaluate
3) Realistic to implement

I've yet to be shown how DNSSEC is any of those things. D-H key
exchanges, DTLS, DNS PING, all sound far more appealing.

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

Re: [DNSOP] draft-morris-dnsop-dnssec-key-timing-00

[Richard Lamb]

A very useful piece of work. Particularly the material on emergency key 
rollover. It took me some time to write the scripts to take into account TTL, 
propagation delays, and various key compromise scenarios.  The approach your 
work takes gives the implementer a clear framework.  Wish I had your work 
before.

-Rick


-Original Message-
From: dnsop-boun...@ietf.org [mailto:dnsop-boun...@ietf.org] On Behalf Of 
stephen.mor...@nominet.org.uk
Sent: Tuesday, February 17, 2009 10:21 AM
To: dnsop@ietf.org
Subject: [DNSOP] draft-morris-dnsop-dnssec-key-timing-00

John Dickinson and Johan Ihren and I have just submitted 
http://www.ietf.org/internet-drafts/draft-morris-dnsop-dnssec-key-timing-00.txt

The draft gives a rigorous description of timing considerations in DNSSEC 
key rollovers.

Stephen


 
> A new version of I-D, draft-morris-dnsop-dnssec-key-timing-00.txt 
> has been successfuly submitted by Stephen Morris and posted to the 
> IETF repository.
> 
> Filename:draft-morris-dnsop-dnssec-key-timing
> Revision:00
> Title:   DNSSEC Key Timing Considerations
> Creation_date:2009-02-17
> WG ID:   Independent Submission
> Number_of_pages: 22
> 
> Abstract:
> RFC 4641 gives a detailed overview of the operational considerations
> involved in running a DNSSEC-secured zone, including key rollovers.
> This document expands on the previous work, and discusses timing
> considerations in greater depth.  It explicitly identifies the
> relationships between the various time parameters, and gives a
> suggested algorithm for key rollover in a DNSSEC-secured zone.
>  
> 
> 
> The IETF Secretariat.
> 
> 

___
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] HSMs was Re: I-D Action:draft-ietf-dnsop-rfc4641bis-01.txt

[Richard Lamb]

> -Original Message-
> From: dnsop-boun...@ietf.org [mailto:dnsop-boun...@ietf.org] On Behalf
> Of Olaf Kolkman
> Sent: Thursday, January 21, 2010 3:42 AM
> To: dnsop WG
> Subject: Re: [DNSOP] HSMs was Re: I-D Action:draft-ietf-dnsop-
> rfc4641bis-01.txt
> 
> 
> In trying to get a reasonable version 2 out of the door before Anaheim
> I am trying to identify and where possibly close open issues.
> 
> As a reminder: http://www.nlnetlabs.nl/svn/rfc4641bis/trunk/open-
> issues/ has the open issues listed and a per issue highlight of their
> history.
> 
> This thread, about the use of HSMs, is captured in
> http://www.nlnetlabs.nl/svn/rfc4641bis/trunk/open-issues/HSMs the
> content of that page is replicated below.
> 
> I believe I captured the gist of the discussion in a modified version
> of paragraph 3.6 (see below). The first two paragraphs are not
> modified, the text starting with "The ideal situation" has been.
> 
> I welcome editorial comments off-list.
> 
> If the chair believes the current text captures consensus I will move
> this issue to the closed issues list.
> 
> --Olaf
> 
> 
> 
> 
> $Id: cryptography_flawed 14 2009-02-09 18:54:12Z olaf $
> 20100121
>The use of HSMs
>Shane Kerr/Ed Lewis
>Added: 21 jan 2010
>http://www.ietf.org/mail-archive/web/dnsop/current/msg07190.html
>and
>http://www.ietf.org/mail-archive/web/dnsop/current/msg07193.html
> 
>The recommendation to use a HSM is far to strong. Arguments of fate
> sharing
>and operational overhead are being made on the list.
> 

I agree, but I am a strong believer in market driven decisions so, yes, 
encouraging people to make their own decisions is my preference too.
However I will say that even using a $5 HSM (in the form of a smartcard) forces 
certain good IT security practices.  The guys that developed this industry have 
really though through process.

May be out of scope but: Trust in the KSK must still be earned through various 
mechanisms like publicly documented processes, 3rd party auditing, external 
witnesses, key ceremonies.

> 
> 
> 
> Discussion:
> 
>   From:   Shane Kerr 
>   Subject:Re: [DNSOP] I-D Action:draft-ietf-dnsop-rfc4641bis-
> 01.txt
>   Date:   April 21, 2009 1:03:58 PM GMT+02:00
>   Cc: dnsop WG 
> 
> 
> I believe the key of the thread is captured in the following quotes:
> 
> 
> Stephane Bortzmeyer wrote:
> >
> > But the risk for the key is not only people modifying it, it is
> simply
> > people *reading* it (a concern which also exists for the database but
> > is much less important).
> >
> > I have no practical experience with HSMs but, in my mind, the
> > interesting thing is that they guarantee noone will read the key
> > without an authorization (that's quite unlike the database where you
> > certainly prefer a few unauthorized looks to a complete loss).
> 

Agreed.  Read or in the case of an infrequently used KSK (low number of ZSK 
rolls) - make use of the key.

> This is the key point IMHO.
> 
> AIUI, the attack vector that HSM are designed to protect is that
> someone makes a copy of your key signing material without you knowing
> about it.
> Once they do that, they can spoof replies until such time as you roll
> your key.
> 
> If an unauthorized person modifies the contents of the database backing
> your zone, you may or may not know about it, but an observant customer
> will at least notice that the data has changed.
> 
> So the two are not totally equivalent.
> 
> Having said that, I agree that HSM hysteria is a bit overblown, and
> that the actual DNSSEC signing is very, very unlikely to be the weakest
> link in DNS security in any organization.
> 

Agree.

> 


Below looks good.  Take my suggestion or leave it. It is only a minor point and 
might be implemented on a secured o/s as well.

> 
> 
> Resolution:
> 
> Following the suggestion from:
>   From:   Peter Koch 
>   Subject:Re: [DNSOP] HSMs was Re: I-D Action:draft-ietf-dnsop-
> rfc4641bis-01.txt
>   Date:   April 27, 2009 1:19:45 PM GMT+02:00
>   To: IETF DNSOP WG 
> 
> I rewrote the text to highlight the economic tradeoff, the relevant
> part of section 3.6 is copied below.
> 
> 
> 
> 3.6.  Private Key Storage
> 
>It is recommended that, where possible, zone private keys and the
>zone file master copy that is to be signed be kept and used in off-
>line, non-network-connected, physically secure machines only.
>Periodically, an application can be run to add authentication to a
>zone by adding RRSIG and NSEC RRs.  Then the augmented file can be
>transferred.
> 
>When relying on dynamic update to manage a signed zone [11], be
> aware
>that at least one private key of the zone will have to reside on the
>master server.  This key is only as secure as the amount of exposure
>the server receives to unknown clients and the security of the host.
>Although not mandatory, one could administer the DNS in the
> following

Re: [DNSOP] Comments on draft-ietf-dnsop-dnssec-dps-framework-02

[Richard Lamb]

IMHO since the DPS is the only public document , section 4.4 and its DR aspects 
should be in the DPS to at least indicate to the public that these issues have 
been considered.


4.8 ought to be there as an optional reminder for those writing such a 
framework.

-Rick


> -Original Message-
> From: dnsop-boun...@ietf.org [mailto:dnsop-boun...@ietf.org] On Behalf
> Of Stephen Morris
> Sent: Thursday, September 30, 2010 11:39 AM
> To: dnsop@ietf.org
> Subject: [DNSOP] Comments on draft-ietf-dnsop-dnssec-dps-framework-02
> 
> (Hat off)
> 
> I've had a look at draft-ietf-dnsop-dnssec-dps-framework-02 and have
> the following main comments:
> 
> Section 4.4 Facility, Management and Operational Controls
> There is a lot in here about disaster recovery planning that an
> organisation should already have documented.  Ought this document
> simply concentrate on the DNSSEC aspects and just assume that such
> plans exist?
> 
> Section 4.8, Legal Matters
> I can't help feeling that the section goes well beyond the scope of
> what should be in a DNSSEC policy statement.  A lot of this would be
> applicable to any contract between two parties, so does it really
> belong in this draft?
> 
> There were a number of other issues about phrasing and typos - I have
> sent those directly to the editors.
> 
> (Hat on)
> 
> The working group adopted the draft last year but since then there has
> been little discussion of it on the list.  With DNSSEC at last looking
> as if it is really starting to take off, this is a timely document.
> Please have a look at it and give feedback.
> 
> Stephen
> ___
> 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] watching for signature expiration in zones you don't sign

[Richard Lamb]

I still think, stale or not, having some idea of what the zone's policy is 
regarding signature updates would be useful.  I've been running signature 
expiry monitoring scripts for a few years and having some idea of what is "ok" 
for a zone would be very helpful - particularly those zones that have a policy 
of not refreshing signatures a day or two before expiry (e.g. red ones on 
http://www.dnssek.info/ )- which I would normally consider a concern and start 
firing off warning emails.

-Rick

> -Original Message-
> From: dnsop-boun...@ietf.org [mailto:dnsop-boun...@ietf.org] On Behalf Of Joe 
> Abley
> Sent: Thursday, June 02, 2011 3:22 AM
> To: João Damas
> Cc: IETF DNSOP WG
> Subject: Re: [DNSOP] watching for signature expiration in zones you don't sign
> 
> 
> On 2011-06-02, at 13:17, João Damas wrote:
> 
> > at first glance it might look useful, but this is the kind of info that 
> > tends to go stale and then
> what do you do when there is a mismatch?
> 
> I guess you flag it for manual investigation. The alternative is that you 
> don't really know when a
> situation is actually bad until the signature expires, and it'd be nice to 
> have some early warning.
> 
> I could maintain a manual table of what "bad" means for particular zones 
> based on observation, but
> that seems even more likely to become stale.
> 
> > Would you invalidate a still-valid signature if it doesn't conform to 
> > policy in case someone else is
> signing the zone other than the authorised party?
> 
> Nope, but (especially in these early days of deployment) perhaps it might 
> merit a note to an
> administrator, or a heads-up to a public list.
> 
> > Would you send mail to the zone admin? (and knowing the people on this 
> > list, that would be a lot
> email on top of that admin) :)
> >
> > Shouldn't this sort of admin work be done by the admin, either internally 
> > or by outsourcing to some
> other organisation?
> 
> I guess my point is that unless you're the person involved in signing a 
> particular zone, telling when
> there's a signature expiration problem looming is not easy.
> 
> 
> 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] watching for signature expiration in zones you don't sign

[Richard Lamb]

Good point. Make it adaptive.

> -Original Message-
> From: dnsop-boun...@ietf.org [mailto:dnsop-boun...@ietf.org] On Behalf Of 
> Paul Hoffman
> Sent: Thursday, June 02, 2011 8:43 AM
> To: Joe Abley
> Cc: IETF DNSOP WG
> Subject: Re: [DNSOP] watching for signature expiration in zones you don't sign
> 
> Another thought is to simply keep a detailed history and watch the 
> replacements. For each zone, you
> should be able to determine what their normal renewal buffer is. You would 
> only need to be concerned
> about those that get too close to the edge from their normal operations.
> 
> --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] WGLC: draft-ietf-dnsop-dnssec-dps-framework-04.txt

[Richard Lamb]

I've reviewed it and have nothing to add. I find it very useful and support it 
being published as Informational.

-Rick


> -Original Message-
> From: dnsop-boun...@ietf.org [mailto:dnsop-boun...@ietf.org] On Behalf Of 
> Stephen Morris
> Sent: Monday, June 13, 2011 10:23 AM
> To: dnsop@ietf.org
> Subject: [DNSOP] WGLC: draft-ietf-dnsop-dnssec-dps-framework-04.txt
> 
> Dear DNSOP WG,
> 
> This is to initiate a working group last call (WGLC) on
> 
>   "DNSSEC Policy & Practice Statement Framework"
>draft-ietf-dnsop-dnssec-dps-framework-04.txt
> 
> Owing to the length of the document, the WGLC will last for three weeks
> instead of the usual two, and will therefore end on
> 
>  Monday, 4 July 2011, 23:59 UTC
> 
> The IETF tools site gives easy access to the current and previous
> versions, as well as differences and the like, at:
> 
> http://tools.ietf.org/html/draft-ietf-dnsop-dnssec-dps-framework-04
> 
> The document is aimed at a status of "Informational".
> 
> Please review the document and send any comments you may have to the
> list.  If you have no comments but support (or do not support) the
> document being published, please send that information to the list.
> 
> The document is subject to the normal five reviewer threshold.
> 
> Stephen and Peter
>  DNSOP co-chairs
> ___
> 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 draft-livingood-negative-trust-anchors-04

[Richard Lamb]

Jason-

FWIW: The -04 draft looks good.  It is clear and well written and I think it is 
a valuable resource.
As I am late to looking at this draft please take this only as a comment from a 
narrow minded engineer ;-)   After the rationale, explanations and caveats I 
kept looking for how to implement a NTA.  After initially thinking this would 
be the introduction of some new functionality and RRset manipulation, I only 
found a reference to how Unbound implements it.
So it might be useful to have section 2 "Definition .." make that clear for 
slow people like me - that the NTA is not an RR and is more of a configuration. 
 Maybe simply replacing "placed" with "implemented" in section 2?  "This NTA 
can potentially be [placed][implemented] at any level within the chain of 
trust..."
Feel free to ignore of this thread has already been covered.   Regardless of 
whether my comment makes sense, I do this this is a useful draft to have.

-Rick



From: dnsop-boun...@ietf.org [mailto:dnsop-boun...@ietf.org] On Behalf Of 
Livingood, Jason
Sent: Sunday, February 17, 2013 7:22 AM
To: dnsop@ietf.org
Subject: [DNSOP] New draft-livingood-negative-trust-anchors-04

Based on feedback yesterday on the list, I did a quick -04 update, which is now 
at https://datatracker.ietf.org/doc/draft-livingood-negative-trust-anchors/.


The are seven open issues documented at the end of the I-D. But the most 
important questions for this WG are:
1 - Is this worth consideration as a WG I-D or should it continue only as an 
individual I-D?
2 - If the answer to #1 is that it should be a WG I-D, would you like a brief 
discussion of the open issues at IETF 86?

Thanks!
Jason


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

Re: [DNSOP] fyi: draft-jabley-dnsext-eui48-eui64-rrtypes as AD sponsored individual sumission...

[Richard Lamb]

FWIW I don't see any problem with having RRtypes for MAC addresses in the DNS.  
I am not an old DNS salt like many on this list, but seems there are many other 
RRtypes out there that have less interest.  I see the reference to the IEEE 
"Guidelines for use of a ...EUI-48" but for the sake of equal billing to this 
"other lookup table" it might be nice to add a reference/link to the IEEE 
Registration authority for OUIs, e.g.,  
http://standards.ieee.org/develop/regauth/oui/public.html , in your references 
section.

-Rick


-Original Message-
From: dnsop-boun...@ietf.org [mailto:dnsop-boun...@ietf.org] On Behalf Of Mark 
Andrews
Sent: Monday, April 15, 2013 10:42 PM
To: Edward Lewis
Cc: IETF DNSOP WG
Subject: Re: [DNSOP] fyi: draft-jabley-dnsext-eui48-eui64-rrtypes as AD 
sponsored individual sumission...


In message , Edward Lewis 
writes:
> I have no problem with this in spirit.  But I always wonder why the 
> presentation formats, as in section 3.2 and 4.2, have MUST concerning 
> how the record is "written."  I've never considered the presentation 
> format to be subject to a standard...I realize that's just my opinion, 
> but the on-the-wire format is what is subject to interoperability concerns.

It's a MUST because master file format is a interchange standard.

RFC 1034

The standard format of master files allows them to be exchanged between hosts 
(via FTP, mail, or some other mechanism); this facility is useful when an 
organization wants a domain, but doesn't want to support a name server.  The 
organization can maintain the master files locally using a text editor, 
transfer them to a foreign host which runs a name server, and then arrange with 
the system administrator of the name server to get the files loaded.

Mark
 
> The document can have the MUSTs but I'd prefer SHOULDs.  It's right 
> that there's only one way these addresses ever get written, so the 
> MUST seems logical, OTOH, it just seems over the top to demand it be 
> written one way or another.  I certainly understand it is INTENDED to 
> be written as documented, but is it a sin if I implement something 
> else?  (How would an alternate form hinder interoperability.)
> 
> Apparently I am a little cranky today.
> 
> On Apr 14, 2013, at 12:08, joel jaeggli wrote:
> 
> >  Original Message 
> > Subject:draft-jabley-dnsext-eui48-eui64-rrtypes as AD sponsored 
> individual sumission...
> > Date:   Sun, 14 Apr 2013 08:55:52 -0700
> > From:   joel jaeggli 
> > To: dns...@ietf.org, dns...@ietf.org
> > CC: draft-jabley-dnsext-eui48-eui64-rrty...@tools.ietf.org
> > 
> > 
> > 
> > I've been asked to take this document on as AD sponsored individual 
> > submission.
> > 
> > http://tools.ietf.org/html/draft-jabley-dnsext-eui48-eui64-rrtypes-0
> > 2
> > 
> > If there's anyone who has strenuous objections to that, please let 
> > me
> know.
> > 
> > joel
> > 
> > 
> > 
> > ___
> > DNSOP mailing list
> > DNSOP@ietf.org
> > https://www.ietf.org/mailman/listinfo/dnsop
> 
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> -=-=
> -
> Edward Lewis 
> NeuStarYou can leave a voice message at 
> +1-571-434-5468
> 
> There are no answers - just tradeoffs, decisions, and responses.
> 
> 

--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Root zone KSK rollover

[Richard Lamb]

Here are updates from the recent ICANN BA meeting.

http://buenosaires48.icann.org/en/schedule/wed-dnssec/presentation-dnssec-ssac-key-rollover-20nov13-en.pdf
 

http://buenosaires48.icann.org/en/schedule/wed-dnssec/presentation-root-zone-ksk-20nov13-en.pdf
 



-Original Message-
From: DNSOP [mailto:dnsop-boun...@ietf.org] On Behalf Of Chris Thompson
Sent: Wednesday, November 27, 2013 9:09 AM
To: dnsop@ietf.org
Subject: [DNSOP] Root zone KSK rollover

Everything seems to have gone very quiet since the ICANN consultation earlier 
this year. Can anyone in a position to know say what is going on?

The very last contribution on the website, 

http://forum.icann.org/lists/comments-root-zone-consultation-08mar13/msg00022.html

says "To this end, the IAB suggests the rollover of the Root Zone KSK before 
the end of the year, with significant prior notice to all involved parties, 
including vendors, implementors, TLD operators, and end-users."

I think we can be fairly confident *that* isn't going to happen... :-)

-- 
Chris Thompson   University of Cambridge Computing Service,
Email: c...@ucs.cam.ac.ukRoger Needham Building, 7 JJ Thomson Avenue,
Phone: +44 1223 334715   Cambridge CB3 0RB, United Kingdom.
___
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] beta release of getdns stub resolver

[Richard Lamb]

Thank you guys!

This is exactly the kind of leadership the rest of the IT industry needs to 
help take DNSSEC to the next level.  Many of us were just going to hack up some 
code for Windows out of frustration but were stymied by what sort of interface 
would be the most attractive to developers (and therefore widespread DNSSEC 
adoption).  So we were waiting for someone else to take the first step.  You 
did it.

Thanks !!
-Rick Lamb (with entrepreneur hat on)



From: DNSOP [mailto:dnsop-boun...@ietf.org] On Behalf Of Wiley, Glen
Sent: Wednesday, February 26, 2014 10:47 AM
To: dnsop@ietf.org
Subject: [DNSOP] beta release of getdns stub resolver

Verisign and NLnet Labs are pleased to announce the first beta release (0.1.0) 
of an open source implementation of the getdns API specification.  The 
project's home page is at http://getdnsapi.net.

getdns is a modern asynchronous DNS API. It implements DNS entry points from a 
design developed and vetted by application developers, in the specification at 
http://www.vpnc.org/getdns-api/ edited by Paul Hoffman. With the development of 
this API, we intend to offer application developers a modernized and flexible 
way to access DNS security (DNSSEC) and other powerful new DNS features; a 
particular hope is to inspire application developers towards innovative 
security solutions in their applications.

We invite everyone to take a look at the project and to provide feedback to us 
and even contribute back to the project!  We expect to have successive releases 
over the next few months that move us toward a more complete implementation and 
includes ports to even more platforms.

Signed...the getdns core team:
Craig Despeaux, Verisign, Inc.
Neel Goyal, Verisign, Inc.
Olaf Kolkman, NLnet Labs
Allison Mankin, Verisign Labs.
Melinda Shore, No Mountain Software LLC
Willem Toorop, NLnet Labs
Wouter Wijngaards, NLnet Labs
Glen Wiley, Verisign, Inc.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] key lengths for DNSSEC

[Richard Lamb]

Speaking for myself:

First:  Thank you Jim and Joe for seeking to increase the signal-to-noise ratio 
on this thread and for explaining what the attack vector would be for lower IQ 
folk like myself.

Second: I have always taken my instructions from the community. So regardless 
of what I believe I will faithfully do my part (with your help) to make it 
happen.

Third: From my vantage point and as author of the code used for the KSK side of 
things, I do not see any immediate barriers  to increasing key lengths.  The 
members of the original root DNSSEC design team have enjoyed a very good 
working relationship and I expect that to continue.  However, like any other 
change at this level it must be one that is approached conservatively and 
thoroughly tested before deployed (software, increased RRSet sizes, IPv6 
impact, new ZSK generation).  This will take human resources and time.

I look forward to following further discussions on this topic.

-Rick



-Original Message-
From: DNSOP [mailto:dnsop-boun...@ietf.org] On Behalf Of Joe Abley
Sent: Wednesday, April 02, 2014 7:50 AM
To: Ted Lemon
Cc: IETF DNSOP WG
Subject: Re: [DNSOP] key lengths for DNSSEC


On 2 Apr 2014, at 10:26, Ted Lemon  wrote:

> The problem with the way you've phrased this question is that there does not 
> seem to be agreement amongst the parties to this discussion whether old keys 
> matter.   If you think they do, you need longer keys.   If you think they 
> don't, you need shorter keys.   So rather than talking about key lengths 
> first, it would be more productive to come to a consensus about which threat 
> model we are trying to address.

I'm trying to understand the time-based attack, but I'm not seeing it.

The gist seems to be that if I can turn back the clock on a remote resolver, I 
can pollute its cache with old signatures (made with an old, presumably 
compromised key) and the results will appear to clients of the resolver to 
validate.

This sounds plausible, but without administrative compromise of the remote 
resolver (in which case you have much simpler options) this attack seems to 
involve:

1. subverting sufficient NTP responses over a long enough period to cause the 
remote resolver's clock to turn back in time (long period suggested due to 
many/most? implementations' refuse large steps in times, and hence many smaller 
steps might be required)

2. replacing every secure response that would normally arrive at the resolver 
with a new one that will validate properly at whatever the resolver's idea of 
the time and date is (or, if not every, sufficient that the client population 
don't see validation failures for non-target queries). This potentially 
involves having factored or otherwise recovered every ZSK and KSK that might be 
used to generate a signature in a response to the resolver, for the time period 
between now and then.

This seems like an intractably difficult thing to accomplish.

What am I missing?


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] MIXFR: Smaller IXFR in the DNSSEC case

[Richard Lamb]

Fwiw i believe there is a clear need for this work.  Having been involved
with various early DNSSec deployment efforts, the diminished value of ixfr
has resulted in a few different home grown hybrid solutions to capture the
efficiency of rsync with added notification functionality.  It would be
good if we just "fixed" ixfr.  -Rick


On Thursday, January 15, 2015, Matthijs Mekking 
wrote:

> Hi wg,
>
> IXFR with DNSSEC is suddenly not so small anymore. Do you recognize
> this? Olafur and I have some ideas on keeping those zone transfers
> small. Your feedback is appreciated.
>
>   http://www.ietf.org/internet-drafts/draft-mekking-mixfr-01.txt
>
> Best regards,
>   Matthijs
>
> ___
> 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] relax the requirement for PTR records?

[Richard Lamb]

FWIW, I agree w/ Paul and Ted.  Customer should have the option to fill in 
reverse IPv6 tree.  
Arent we headed toward a society where we all become content providers with 
"the cloud" just a recurring fad?
-Rick


-Original Message-
From: DNSOP [mailto:dnsop-boun...@ietf.org] On Behalf Of Lee Howard
Sent: Wednesday, May 13, 2015 8:35 AM
To: Tony Finch
Cc: dnsop@ietf.org
Subject: Re: [DNSOP] relax the requirement for PTR records?



On 5/13/15, 11:12 AM, "Tony Finch"  wrote:

>Lee Howard  wrote:
>>
>> Is there consensus now that ISPs don't need to provide PTRs for their 
>> customers?
>
>ISPs should delegate the relevant part of the IPv6 reverse DNS tree to 
>the customer, so the customer can provision PTR records as required.

This is already addressed in the draft.
draft-howard-isp-ip6rdns-07 section 2.3.3 and 2.4, and in the recommendations.

Lee


>
>Tony.
>--
>f.anthony.n.finchhttp://dotat.at/
>Biscay: West or southwest 4 or 5, increasing 6 or 7. Moderate, becoming 
>rough later. Rain or showers. Moderate or 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