Re: [DNSOP] Kaminsky on djbdns bugs (fwd)

2008-08-13 Thread Wes Hardaker
On Wed, 13 Aug 2008 19:21:44 +0200, Ralf Weber [EMAIL PROTECTED] said: RW Hmm, assuming that we both did use the same name server software my RW experiences are different. Compared to regular DNS setting up and more RW importantly maintaining DNSSEC is much more work than normal DNS stuff RW

Re: [DNSOP] Proposed changes to RFC 4641: rollovers

2008-09-29 Thread Wes Hardaker
On Sun, 28 Sep 2008 21:14:34 -0700, Paul Hoffman [EMAIL PROTECTED] said: Overall I think the changes seem reasonable. However, I don't think everything is taken into account... I understand the desire for removing the specified timing associated with key-age based on modern analysis. But

Re: [DNSOP] WGLC: Requirements for Management of Name Servers for the DNS

2009-04-27 Thread Wes Hardaker
On Sat, 21 Mar 2009 22:44:42 -0700, Doug Barton do...@dougbarton.us said: DB I've read the draft at the URL above and am generally supportive of DB its moving forward. Doug, Thanks for responding with a review about the Management Requirements document. I've applied all your very useful

Re: [DNSOP] WGLC: Requirements for Management of Name Servers for the DNS

2009-04-27 Thread Wes Hardaker
On Sun, 22 Mar 2009 13:42:39 -0700, SM s...@resistor.net said: s From the Abstract: ... Thanks for the comments on the draft; I've incorporated all of your changes. -- In the bathtub of history the truth is harder to hold than the soap, and much more difficult to find. -- Terry Pratchett

Re: [DNSOP] WGLC: Requirements for Management of Name Servers for the DNS

2009-04-28 Thread Wes Hardaker
On Tue, 28 Apr 2009 10:25:15 -0700, Doug Barton do...@dougbarton.us said: OLD: Reloading zone data NEW: Reloading some or all of the zone data sets DB That wording may imply granularity at less than the zone level, which DB I'm not suggesting but would not be opposed to. Ok, how

Re: [DNSOP] WGLC: Requirements for Management of Name Servers for the DNS

2009-05-01 Thread Wes Hardaker
On Thu, 30 Apr 2009 16:18:43 -0700, Doug Barton do...@dougbarton.us said: Reloading of all of the zone data Reloading of individual zone data sets DB That seems clearer to me. Ok, I've changed the draft to that. -- In the bathtub of history the truth is harder to hold than the soap, and

Re: [DNSOP] WGLC: DNSSEC Trust Anchor Configuration and Maintenance

2009-05-04 Thread Wes Hardaker
I'll pass on my comments on the draft. I've removed my comments that were duplicates of those submitted by Ed and Paul W. I'm not an English language expert (even though it is my first and primary language; I just defer to those with better knowledge than I), but I did find the draft well

[DNSOP] Updated: Requirements for Management of Name Servers for the DNS

2009-05-04 Thread Wes Hardaker
The Requirements for Management of Name Servers for the DNS document has been updated to reflect the comments received during last call. The diff can be found via the link below. The changes were minor and thus I think the document is ready for submission to the IESG (and thus my finger is now

[DNSOP] comments about draft-morris-dnsop-dnssec-key-timing

2009-05-07 Thread Wes Hardaker
As I stated in the meeting, I think this document is a great idea as an addition to the RFCs about DNS(SEC). Kudos for writing it, and great kudos for the diagrams and generally clear text. Comments though: *** Biggest one: I still believe that this document would be horribly remiss

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

2009-05-19 Thread Wes Hardaker
On Tue, 19 May 2009 13:03:09 +0100, stephen.mor...@nominet.org.uk said: * 3.1, bullets 2 and 3: technically ZSKs can be pointed to by a DS and can be used as trust anchors. It would probably be easiest if you declared that aspect out of scope as it isn't the recommend usage case. SM This

Re: [DNSOP] nameserver control protocol

2009-12-24 Thread Wes Hardaker
time ago. They've repeatedly said they'd get to it but haven't succeeded in getting it to the IESG yet. It's still on their plate. -- Wes Hardaker Cobham Analytic Solutions ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo

Re: [DNSOP] Publication Request (Informational) for draft-ietf-dnsop-name-server-management-reqs-04.txt

2010-10-18 Thread Wes Hardaker
this opportunity to say Yay! -- Wes Hardaker Cobham Analytic Solutions ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Want this to be a WG doc?

2012-04-05 Thread Wes Hardaker
. -- Wes Hardaker SPARTA, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] New I-D on Negative Trust Anchors

2012-04-10 Thread Wes Hardaker
: NATs are not an appropriate long-term solution and if they need to be used, they MUST be used only for short periods of time. (it's the two-birds-with-one-stone theory of RFC writing) -- Wes Hardaker SPARTA, Inc. ___ DNSOP mailing list DNSOP

Re: [DNSOP] New I-D on Negative Trust Anchors

2012-04-11 Thread Wes Hardaker
?) implementations to ignore the SHOULD :-( ] -- Wes Hardaker SPARTA, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] New I-D on Negative Trust Anchors

2012-04-12 Thread Wes Hardaker
Joe Abley joe.ab...@icann.org writes: On 2012-04-11, at 12:09, Wes Hardaker wrote: NTA example.com Thu Apr 12 09:06:42 PDT 2012 I realise this is just a thought experiment Well, true it certainly is. And in fact the above thought experiment wasn't meant to imply a resource record

Re: [DNSOP] Maximum negative trust anchor duration, was New I-D on Negative Trust Anchors

2012-04-12 Thread Wes Hardaker
we deliberately did *not* put in a continue anyway button. -- Wes Hardaker SPARTA, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Thoughts on CDS

2013-04-18 Thread Wes Hardaker
: to document concerns and let the real world make their decisions based on that discussion. -- Wes Hardaker SPARTA, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Thoughts on CDS

2013-04-19 Thread Wes Hardaker
explains why it needs to be signed with the KSK instead (also). -- Wes Hardaker SPARTA, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Thoughts on CDS

2013-04-22 Thread Wes Hardaker
. -- Wes Hardaker SPARTA, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Thoughts on CDS

2013-04-22 Thread Wes Hardaker
, if it didn't change the what-must-sign it rule, would you come to support it? -- Wes Hardaker Parsons ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Thoughts on CDS

2013-04-22 Thread Wes Hardaker
Wes Hardaker wjh...@hardakers.net writes: For what it's worth: I'm sort of on the fence when it comes to needing to sign with the KSK. There are so very very few key-split owners out there that it's not a huge market for them, and I doubt any of them will want to do CDS anyway

Re: [DNSOP] Thoughts on CDS

2013-04-23 Thread Wes Hardaker
and this is new isn't correct either. 5011 has a number of similar semantics. Consider the revoke bit for the simplest and closest to this case. -- Wes Hardaker Parsons ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Thoughts on CDS

2013-04-23 Thread Wes Hardaker
understand that you don't want to use the technology. The solution there is still simple: offer a fix (or replacement suggestion) to make it what you want, or don't use it! Which box are you picking? [please don't be the last one; please don't be the last one] -- Wes Hardaker Parsons

Re: [DNSOP] Thoughts on CDS

2013-04-23 Thread Wes Hardaker
with the revoke bit set, but you shouldn't actually act on it because it wasn't signed by the key itself. See RFC5011, section 2.1, last sentence for the quick summary. The key would still be considered valid by a validator but you shouldn't act on the knowledge of the data in the key. -- Wes Hardaker

Re: [DNSOP] Thoughts on CDS

2013-04-23 Thread Wes Hardaker
Doug Barton do...@dougbarton.us writes: On 04/23/2013 02:02 PM, Wes Hardaker wrote: Objecting to the notion without offering fixes is like saying I don't want soup to exist because watching people eat it might make me want it in the future. Wes, that's not only not true, it's at best

Re: [DNSOP] Thoughts on CDS

2013-04-23 Thread Wes Hardaker
lack of communication. -- Wes Hardaker Parsons ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] DS transfer requirements

2013-04-24 Thread Wes Hardaker
/mail-archive/web/dnsop/current/msg10293.html -- Wes Hardaker Parso ns ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] DS transfer requirements

2013-04-24 Thread Wes Hardaker
Antoin Verschuren antoin.verschu...@sidn.nl writes: Op 24-04-13 15:18, Wes Hardaker schreef: + operate on a single record at a time (publish this DS, don't touch the rest) I don't understand the rationale behind this one. Can someone please explain to me? I would think a child knows what

[DNSOP] draft-hardaker-dnsop-csync-00.txt

2013-06-05 Thread Wes Hardaker
that a parental agent may copy and process certain records from the child zone. The existence and change of the record may be monitored by a parental agent to either assist in transferring or automatically transfer data from the child to the parent. The IETF Secretariat -- Wes Hardaker

Re: [DNSOP] draft-hardaker-dnsop-csync-00.txt versus draft-kumari-ogud-dnsop-cds-02.txt

2013-07-03 Thread Wes Hardaker
key. I agree with you, assuming you can publish your DNSKEY as a separate record (or else people may read it, cache it, memorize it, run tests with it, etc). But no matter how much I agree with you it won't stop others from wanting an oxymoron: the private public key. -- Wes Hardaker Parsons

Re: [DNSOP] request draft-hardaker-dnsop-csync be adopted as a WG item

2013-07-14 Thread Wes Hardaker
I'm somewhat against even trying. It's a very slippery slope, as there are many many other policy statements that need publishing too. -- Wes Hardaker Parsons ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] New Version Notification for draft-hardaker-dnsop-csync-01.txt

2013-07-14 Thread Wes Hardaker
internet-dra...@ietf.org writes: A new version of I-D, draft-hardaker-dnsop-csync-01.txt has been successfully submitted by Wes Hardaker and posted to the IETF repository. Filename: draft-hardaker-dnsop-csync Revision: 01 Title: Child To Parent Synchronization

[DNSOP] [internet-dra...@ietf.org] New Version Notification for draft-hardaker-dnsop-dnssec-roadblock-avoidance-00.txt

2013-07-15 Thread Wes Hardaker
-avoidance-00.txt has been successfully submitted by Wes Hardaker and posted to the IETF repository. Filename:draft-hardaker-dnsop-dnssec-roadblock-avoidance Revision:00 Title: DNSSEC Roadblock Avoidance Creation date: 2013-07-15 Group: Individual Submission

[DNSOP] [internet-dra...@ietf.org] New Version Notification for draft-hardaker-dnsop-csync-02.txt

2013-10-23 Thread Wes Hardaker
, draft-hardaker-dnsop-csync-02.txt has been successfully submitted by Wes Hardaker and posted to the IETF repository. Filename:draft-hardaker-dnsop-csync Revision:02 Title: Child To Parent Synchronization in DNS Creation date: 2013-10-21 Group: Individual

Re: [DNSOP] Call for Adoption: draft-andrews-dnsop-rfc6598-rfc6303

2013-10-24 Thread Wes Hardaker
to be changed. -- Wes Hardaker Parsons ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-child-syncronization

2014-04-22 Thread Wes Hardaker
not be the zone administrator. -- Wes Hardaker Parsons ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] terminology in Re: Working Group Last Call for draft-ietf-dnsop-child-syncronization

2014-04-22 Thread Wes Hardaker
I don't think we want these terminology sets to deviate. -- Wes Hardaker Parsons ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-child-syncronization

2014-04-22 Thread Wes Hardaker
bootstrapping operations, including to get the required initial DNSSEC-secured operating environment in place. I've used your wording, thank you for it! I'll get to your other comments a bit later. -- Wes Hardaker Parsons ___ DNSOP mailing list DNSOP

Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-child-syncronization

2014-05-01 Thread Wes Hardaker
! -- Wes Hardaker Parsons ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-child-syncronization

2014-05-13 Thread Wes Hardaker
ideal, but it's the best choice we have in today's environment. -- Wes Hardaker Parsons ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-child-syncronization

2014-05-13 Thread Wes Hardaker
that proper communication of synchronization efforts exist between the child and the grandchild. [more later on the other subjects; I'm not ignoring them; just splitting them] -- Wes Hardaker Parsons ___ DNSOP mailing list DNSOP@ietf.org https

Re: [DNSOP] WG Secretary for DNSOP

2014-09-09 Thread Wes Hardaker
hat Paul! -- Wes Hardaker Parsons ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Requesting adoption of draft-wkumari-dnsop-root-loopback

2014-11-14 Thread Wes Hardaker
Warren Kumari war...@kumari.net writes: We are requesting a call for adoption of draft-wkumari-dnsop-root-loopback. Support adopting, but we will need to talk about careful wording of when to use it and when not to. -- Wes Hardaker Parsons

[DNSOP] IESG COMMENT/DISCUSSION responses to the dnsop-child-sync draft

2014-11-26 Thread Wes Hardaker
. This is required because the child can not control which nameserver in the existing NS set the parental agent may choose to query when performing CSYNC processing./t -- Wes Hardaker Parsons ___ DNSOP mailing list DNSOP@ietf.org https

Re: [DNSOP] I-D Action: draft-ietf-dnsop-child-syncronization-04.txt

2014-12-01 Thread Wes Hardaker
: Child To Parent Synchronization in DNS Author : Wes Hardaker Filename: draft-ietf-dnsop-child-syncronization-04.txt Pages : 14 Date: 2014-11-26 I previously made some comments on the draft in response to the IETF

Re: [DNSOP] I-D Action: draft-ietf-dnsop-child-syncronization-04.txt

2014-12-01 Thread Wes Hardaker
anything/anything/ (?) if any of the validation results indicate any anything other than WJH: new catch, thank you! -- Wes Hardaker Parsons ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] I-D Action: draft-ietf-dnsop-child-syncronization-04.txt

2014-12-02 Thread Wes Hardaker
, and the definition in the sync draft is a copy of the 7344 text. The problem mentioned was that it's still not a common term. Though it's getting more and more common as we keep using it. -- Wes Hardaker Parsons ___ DNSOP mailing list DNSOP@ietf.org https

Re: [DNSOP] I-D Action: draft-ietf-dnsop-child-syncronization-04.txt

2014-12-04 Thread Wes Hardaker
of the additional operational complexity, parental agents MAY choose not to support this protocol with children making use of records that are authoritative in the grandchildren. (I liked the idea of the MAY) -- Wes Hardaker Parsons

Re: [DNSOP] I-D Action: draft-ietf-dnsop-child-syncronization-04.txt

2014-12-05 Thread Wes Hardaker
神明達哉 jin...@wide.ad.jp writes: Looks good to me. Awesome, thanks! -- Wes Hardaker Parsons ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] IESG COMMENT/DISCUSSION responses to the dnsop-child-sync draft

2014-12-18 Thread Wes Hardaker
. For such a solution, please see the complimentary solution [RFC7344] for maintaining security delegation information. Does this (end-of-a) paragraph solve your problem? -- Wes Hardaker Parsons ___ DNSOP mailing list DNSOP@ietf.org https

Re: [DNSOP] Protocol Action: 'Child To Parent Synchronization in DNS' to Proposed Standard (draft-ietf-dnsop-child-syncronization-07.txt)

2015-01-21 Thread Wes Hardaker
Tim Wicinski tjw.i...@gmail.com writes: I wanted to thank all the folks who offered comments, edits, and text for this document. Ditto! Documents are always better after lots of feedback, so thank you to everyone that contributed to the document. -- Wes Hardaker Parsons

Re: [DNSOP] I-D Action: draft-ietf-dnsop-child-syncronization-07.txt

2015-01-06 Thread Wes Hardaker
on your slide 10 indicates that a parent can trust the child information because of dnssec, which is what we're making use of certainly. Your slides seem to hint at a much more active update request though, which is not the way the CSYNC record works. -- Wes Hardaker Parsons

Re: [DNSOP] [Editorial Errata Reported] RFC7477 (4307)

2015-03-19 Thread Wes Hardaker
RFC Errata System rfc-edi...@rfc-editor.org writes: Notes - confusing typo, confirmed with author. Yep. And I was sure that was fixed at some point too. -- Wes Hardaker Parsons ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org

Re: [DNSOP] RFC 7477 on Child-to-Parent Synchronization in DNS

2015-03-23 Thread Wes Hardaker
as is it's not awful, but not ideal. I'm not sure an errata would be sufficient for such a change and if it'd be allowed for such a major processing change. I'll speak to some people about it this week and see what others say. -- Wes Hardaker Parsons ___ DNSOP

Re: [DNSOP] Ben Campbell's No Objection on draft-ietf-dnsop-dnssec-roadblock-avoidance-04: (with COMMENT)

2016-08-10 Thread Wes Hardaker
s assume a level of security does not exist." That's well worded. Thanks for providing text, and I'll use it! -- Wes Hardaker Parsons ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] new dnsop related draft: RFC5011 security considerations

2016-08-02 Thread Wes Hardaker
d be "validator" Fixed, thank you! (the draft is far from done, but catching those early is always a good thing) -- Wes Hardaker Parsons ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] new dnsop related draft: RFC5011 security considerations

2016-08-03 Thread Wes Hardaker
the missing half can cause security implications if you can't self-derive the values. And judging buy our survey of experts, I don't think the average Joe will pick a safe value (hence the need for the document). -- Wes Hardaker Parsons ___ DNSOP mailin

Re: [DNSOP] new dnsop related draft: RFC5011 security considerations

2016-08-03 Thread Wes Hardaker
While this makes the DNSKEY rollover duration even longer, it is now > secured against the outlined attack. I don't think we need to modify 5011 itself. Just how to use it. -- Wes Hardaker Parsons ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Stephen Farrell's Discuss on draft-ietf-dnsop-dnssec-roadblock-avoidance-04: (with DISCUSS and COMMENT)

2016-08-11 Thread Wes Hardaker
aft-ietf-dnsop-dnssec-roadblock-avoidance/ -- Wes Hardaker Parsons ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] The DNSOP WG has placed draft-wkumari-dnsop-multiple-responses in state "Candidate for WG Adoption"

2016-07-06 Thread Wes Hardaker
nd parent). -- Wes Hardaker Parsons ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] The DNSOP WG has placed draft-wkumari-dnsop-multiple-responses in state "Candidate for WG Adoption"

2016-07-06 Thread Wes Hardaker
tive answers a user will likely ask for next, before it knows what to ask. -- Wes Hardaker Parsons ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] I-D Action: draft-ietf-dnsop-dnssec-roadblock-avoidance-04.txt

2016-07-08 Thread Wes Hardaker
hink not, because if the DO bit was set and you understand it but need to return non-DNSSEC protected data, I think we should be returning the DO bit but no AD or DNSSEC data. I suppose you could argue that since we can't do DNSSEC we shouldn't say we're DO (DNSSEC) compliant? -- Wes Hardaker Pars

Re: [DNSOP] Benoit Claise's No Objection on draft-ietf-dnsop-dnssec-roadblock-avoidance-04: (with COMMENT)

2016-07-08 Thread Wes Hardaker
ance > practices; however the document does not specify exactly how to do that." > and later "Else return an useful error code" which will make > interoperation (API portability) complex. I need to speak to the author of that sentence to determine his attention and will

Re: [DNSOP] Spencer Dawkins' No Objection on draft-ietf-dnsop-dnssec-roadblock-avoidance-04: (with COMMENT)

2016-07-08 Thread Wes Hardaker
in answers greater than 1220 bytes so ideally TCP MUST be >available. Changed to: However, querying many zones will result in answers greater than 1220 bytes so DNS over TCP MUST be available. -- Wes Hardaker Parsons ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Terry Manderson's Discuss on draft-ietf-dnsop-dnssec-roadblock-avoidance-04: (with DISCUSS and COMMENT)

2016-07-08 Thread Wes Hardaker
y poor for an IETF published document. Knowing the > intelligence of the authors I can't see how this was thought of as > passable and made it through WGLC irrespective of how we collectively > view these devices. Thanks Terry. I've removed those words th

Re: [DNSOP] Ben Campbell's No Objection on draft-ietf-dnsop-dnssec-roadblock-avoidance-04: (with COMMENT)

2016-07-08 Thread Wes Hardaker
6 > and 6.1. I think the world is very much at a loss as to the best thing to do in that case. And is likely very case specific. Military installations tend to be a bit more strict about continuing through to a unacceptable security certificate, eg. I'm not sure we can enumerate every conte

Re: [DNSOP] Alexey Melnikov's No Objection on draft-ietf-dnsop-dnssec-roadblock-avoidance-04: (with COMMENT)

2016-07-08 Thread Wes Hardaker
an implementation choice, so use of MAY is not appropriate. > Change to "can" or the like. Good catch. Fixed. -- Wes Hardaker Parsons ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Terry Manderson's Discuss on draft-ietf-dnsop-dnssec-roadblock-avoidance-04: (with DISCUSS and COMMENT)

2016-07-08 Thread Wes Hardaker
about that? Can we list a known one? Must we list a useless one instead? Should we pre-declare the problem? I've been waiting for this to come up :-) > And on s3.1.14 Will "alltypes.res.dnssecready.org" be a stable query > point? I hope so. > s 3.3 Some formatting might

Re: [DNSOP] Mirja Kühlewind's No Objection on draft-ietf-dnsop-dnssec-roadblock-avoidance-04: (with COMMENT)

2016-07-08 Thread Wes Hardaker
possible it SHOULD log the event and/or SHOULD warn user. In the case there is no user no reporting can be performed thus the device MAY have a policy of action, like continue or fail. h -- Wes Hardaker Parsons ___ DNSOP mailing lis

Re: [DNSOP] Definitions of basic DNSSEC terms

2016-08-04 Thread Wes Hardaker
| grep validate | wc -l 6 # rfcfind -n 4034 -m | grep validation | wc -l 2 But, no, 4033 defines terminology with the "validating" thingies. -- Wes Hardaker Parsons ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Ben Campbell's No Objection on draft-ietf-dnsop-dnssec-roadblock-avoidance-04: (with COMMENT)

2016-08-05 Thread Wes Hardaker
he device MAY have a policy of action, like continue or fail. new: Until middle boxes allow DNSSEC protected information to traverse them consistently, software implementations may need to offer this choice to let users pick the security level they

Re: [DNSOP] Stephen Farrell's Discuss on draft-ietf-dnsop-dnssec-roadblock-avoidance-04: (with DISCUSS and COMMENT)

2016-08-05 Thread Wes Hardaker
e is no user? Why not recommend telling > some network observatory? Aren't there some for DNSSEC? There aren't any. We do mention logging the results in section 6 though. -- Wes Hardaker Parsons ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Alissa Cooper's No Objection on draft-ietf-dnsop-dnssec-roadblock-avoidance-04: (with COMMENT)

2016-08-05 Thread Wes Hardaker
"warn" with something like "report an error to the user"? I think that's better so am making that change. -- Wes Hardaker Parsons ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] new dnsop related draft: RFC5011 security considerations

2016-08-01 Thread Wes Hardaker
r of many of the choices: "zone right-hand person". Any other suggestions? -- Wes Hardaker Parsons ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] new dnsop related draft: RFC5011 security considerations

2016-08-01 Thread Wes Hardaker
The following draft, authored by Warren and I, might be of interest to the dnsop crowd: https://tools.ietf.org/html/draft-hardaker-rfc5011-security-considerations-00 [it currently does not have a home] -- Wes Hardaker Parsons ___ DNSOP mailing list

Re: [DNSOP] Terry Manderson's Discuss on draft-ietf-dnsop-dnssec-roadblock-avoidance-04: (with DISCUSS and COMMENT)

2016-08-03 Thread Wes Hardaker
ain implements all of these test records. Thus, it may be possible to replace "test.example.com" in this document with "test.dnssec-tools.org" when performing real-world tests. And then everywhere that test.dnssec-tools

[DNSOP] Published: draft-hardaker-rfc5011-security-considerations-04.txt

2017-02-17 Thread Wes Hardaker
For those following along with this draft, I've just published -04. -- Wes Hardaker USC/ISI ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] New Version Notification for draft-hardaker-rfc5011-security-considerations-02.txt

2017-02-16 Thread Wes Hardaker
Wes Hardaker <wjh...@hardakers.net> writes: > Fortunately, after a quick conversation we've recovered the reason. > Publishing a new version with a break-out explanation shortly. The 3/2 > is absolutely is needed. I've published -03 which adds new text just below the equa

Re: [DNSOP] New Version Notification for draft-hardaker-rfc5011-security-considerations-02.txt

2017-02-16 Thread Wes Hardaker
Warren Kumari <war...@kumari.net> writes: > On Thu, Feb 16, 2017 at 11:33 AM, Wes Hardaker <wjh...@hardakers.net> wrote: >> Bob Harold <rharo...@umich.edu> writes: >> >>> Thanks for your work on this. Some minor formatting issues: >> >> Odd.

Re: [DNSOP] Published: draft-hardaker-rfc5011-security-considerations-04.txt

2017-02-21 Thread Wes Hardaker
Petr Špaček <petr.spa...@nic.cz> writes: > If you decide to mention me in the document feel to use "Petr Spacek" as > ASCII version of my name to avoid the Unicode madness. We've been publishing UTF-8 RFCs for a while now I think. --

Re: [DNSOP] New Version Notification for draft-hardaker-rfc5011-security-considerations-02.txt

2017-02-16 Thread Wes Hardaker
Wes Hardaker <wjh...@hardakers.net> writes: > Sadly, we had a reason and now Warren and I have to remember it. Fortunately, after a quick conversation we've recovered the reason. Publishing a new version with a break-out explanation shortly. The 3/2 is absolutely is needed. -- Wes Har

Re: [DNSOP] New Version Notification for draft-hardaker-rfc5011-security-considerations-02.txt

2017-02-16 Thread Wes Hardaker
nt a long time wandering around random streets on Berlin and the 3/2 was a sudden aha (oh no) moment if I recall. Anyway, we'll revamp the document again in the near future with the terms better spelled out, because I agree they need to be. -- Wes Hardake

Re: [DNSOP] New Version Notification for draft-hardaker-rfc5011-security-considerations-02.txt

2017-02-16 Thread Wes Hardaker
Bob Harold <rharo...@umich.edu> writes: > Thanks for your work on this.  Some minor formatting issues: Odd. I think *someone* wasn't using a real editor (*cough*emacs*cough*) and it inserted some odd white space into XML components. Thanks for the catches; fixed on all accounts

[DNSOP] Off topic: DNS and Internet Naming Research Directions (DINR-2016) workshop

2016-09-28 Thread Wes Hardaker
.) -- Wes Hardaker USC/ISI ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] DNSOP Call for Adoption: draft-hardaker-rfc5011-security-considerations

2017-03-17 Thread Wes Hardaker
create one that ensures people can securely use the existing one with proper knowledge. -- Wes Hardaker USC/ISI ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] I-D Action: draft-ietf-dnsop-rfc5011-security-considerations-00.txt

2017-04-06 Thread Wes Hardaker
Bob Harold <rharo...@umich.edu> writes: > This one still needs to be fixed: Thanks Bob. That was a straight copy; I hope to do a new version immediately and will certainly make that change. -- Wes Hardaker USC/ISI ___ DNSOP mailing l

Re: [DNSOP] requesting WGLC for 5011-security-considerations

2017-07-06 Thread Wes Hardaker
e after cut-off). -- Wes Hardaker USC/ISI ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] requesting WGLC for 5011-security-considerations

2017-07-06 Thread Wes Hardaker
Michael StJohns <m...@nthpermutation.com> writes: > On 7/6/2017 1:40 PM, Wes Hardaker wrote: >> Michael StJohns <m...@nthpermutation.com> writes: >> >>> I'm sure you think that... but the small changes you've made to >>> address some of my co

Re: [DNSOP] requesting WGLC for 5011-security-considerations

2017-07-12 Thread Wes Hardaker
ations draft, I agree with your point that the right amount of time to wait should be changed to replayTime + queryInterval + slop. Thanks for pointing that out. (though it's worth noting that replayTime + queryInterval can be longer than 30 days). -- Wes H

[DNSOP] requesting WGLC for 5011-security-considerations

2017-07-05 Thread Wes Hardaker
? -- Wes Hardaker USC/ISI ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] requesting WGLC for 5011-security-considerations

2017-07-05 Thread Wes Hardaker
Michael StJohns <m...@nthpermutation.com> writes: > That's not actually a plus you understand.   Mike Sure it is. We're down to the point where large changes aren't needed :-P -- Wes Hardaker USC/ISI ___ DNSOP mailing list DNSOP@ietf.

Re: [DNSOP] requesting WGLC for 5011-security-considerations

2017-07-05 Thread Wes Hardaker
"Paul Hoffman" <paul.hoff...@vpnc.org> writes: > Just a note that the actual filename for the draft is > draft-ietf-dnsop-rfc5011-security-considerations, and it can be found Whoops; thanks Paul. -- Wes Hardaker USC/ISI ___ DN

Re: [DNSOP] requesting WGLC for 5011-security-considerations

2017-07-05 Thread Wes Hardaker
y small: https://www.ietf.org/rfcdiff?url1=draft-ietf-dnsop-rfc5011-security-considerations-01=draft-ietf-dnsop-rfc5011-security-considerations-02 -- Wes Hardaker USC/ISI ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] requesting WGLC for 5011-security-considerations

2017-08-04 Thread Wes Hardaker
ard to remember which is which. -- Wes Hardaker USC/ISI ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Ext] Call for Adoption: draft-wkumari-dnsop-extended-error

2017-08-08 Thread Wes Hardaker
o quote someone recently: > I mean, bring it on. -- Wes Hardaker USC/ISI ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] I-D Action: draft-ietf-dnsop-rfc5011-security-considerations-01.txt

2017-05-25 Thread Wes Hardaker
's purely the "if you exclusively sign with a (any) new key before it has been published for this length of time, you're vulnerable to attack". -- Wes Hardaker USC/ISI ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] I-D Action: draft-ietf-dnsop-rfc5011-security-considerations-01.txt

2017-05-24 Thread Wes Hardaker
visioning for the rest. We really only care about the replay time of the RRSIGs on only the K_old set. [There are certainly more complex examples we could throw into the mix, such as publishing multiple keys over lapping in time periods, but I don't see the benefit of confusing the reader with an

Re: [DNSOP] I-D Action: draft-ietf-dnsop-rfc5011-security-considerations-03.txt

2017-09-13 Thread Wes Hardaker
Bob Harold <rharo...@umich.edu> writes: > "T-29" should be "T+29" Good catch; thank you! -- Wes Hardaker USC/ISI ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] Responding to MSJ review of the previous rfc5011-security-considerations

2017-09-13 Thread Wes Hardaker
version based on your review from July. Wes Hardaker Table of Contents _ 1 Notes / Edits from Mike StJohn on <2017-07-06 Thu> .. 1.1 ACCEPTED Use "exclusively" rather than "only" where you can - "only" has .. 1.2 ACCEPTED In the introd

  1   2   3   >