Re: [DNSOP] draft-tale-dnsop-edns-clientid

2017-03-27 Thread Olafur Gudmundsson
> On Mar 27, 2017, at 5:49 PM, Dave Lawrence wrote: > > One of the two drafts I wanted to talk about at dnsop today for WG > adoption was "Client ID in Forwarded DNS Queries": > https://datatracker.ietf.org/doc/draft-tale-dnsop-edns0-clientid/ > > The core idea of this document is

Re: [DNSOP] on staleness of code points and code (mentions MD5 commentary from IETF98)

2017-03-27 Thread Mukund Sivaraman
Hi Evan On Tue, Mar 28, 2017 at 02:41:27AM +, Evan Hunt wrote: > On Mon, Mar 27, 2017 at 12:45:04PM -0700, Paul Vixie wrote: > > also, a validator that outputs "secure" based on MD5 inputs is making a > > promise it can't keep. > > MD5 is known to be breakable, but it's not *as* breakable

Re: [DNSOP] on staleness of code points and code (mentions MD5 commentary from IETF98)

2017-03-27 Thread Evan Hunt
Oopsie: On Tue, Mar 28, 2017 at 02:41:27AM +, Evan Hunt wrote: > MD5 is known to be breakable, but it's not *as* breakable as a zone > that hasn't been signed -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ DNSOP mailing list

Re: [DNSOP] on staleness of code points and code (mentions MD5 commentary from IETF98)

2017-03-27 Thread Evan Hunt
On Mon, Mar 27, 2017 at 12:45:04PM -0700, Paul Vixie wrote: > also, a validator that outputs "secure" based on MD5 inputs is making a > promise it can't keep. MD5 is known to be breakable, but it's not *as* breakable that hasn't been signed, or a resolver that hasn't turned on validation. A

Re: [DNSOP] draft-tale-dnsop-serve-stale

2017-03-27 Thread Jared Mauch
> On Mar 27, 2017, at 6:46 PM, Robert Edmonds wrote: > > Jared Mauch wrote: >> IOn Mar 27, 2017, at 5:59 PM, P Vix wrote: >>> >>> I agree to review and comment. Note that I am provisionally negative to the >>> idea itself, and my review may reflect that.

Re: [DNSOP] draft-tale-dnsop-serve-stale

2017-03-27 Thread Jared Mauch
> On Mar 27, 2017, at 5:56 PM, Dave Lawrence wrote: > > Warren and I are hoping for WG adoption. [clarification] I support adoption when the chairs request it. - Jared ___ DNSOP mailing list DNSOP@ietf.org

[DNSOP] draft-tale-dnsop-edns-clientid

2017-03-27 Thread Dave Lawrence
One of the two drafts I wanted to talk about at dnsop today for WG adoption was "Client ID in Forwarded DNS Queries": https://datatracker.ietf.org/doc/draft-tale-dnsop-edns0-clientid/ The core idea of this document is to be able to provide device-specific identification in an EDNS option sent to

Re: [DNSOP] draft-tale-dnsop-serve-stale

2017-03-27 Thread Robert Edmonds
Jared Mauch wrote: > IOn Mar 27, 2017, at 5:59 PM, P Vix wrote: > > > > I agree to review and comment. Note that I am provisionally negative to the > > idea itself, and my review may reflect that. Vixie > > > I will note there are other implementations out there as well,

Re: [DNSOP] draft-tale-dnsop-serve-stale

2017-03-27 Thread Jared Mauch
IOn Mar 27, 2017, at 5:59 PM, P Vix wrote: > > I agree to review and comment. Note that I am provisionally negative to the > idea itself, and my review may reflect that. Vixie I will note there are other implementations out there as well, such as in unbound. serve-expired

Re: [DNSOP] draft-tale-dnsop-serve-stale

2017-03-27 Thread P Vix
I agree to review and comment. Note that I am provisionally negative to the idea itself, and my review may reflect that. Vixie On March 27, 2017 4:56:58 PM CDT, Dave Lawrence wrote: >One of the two drafts I wanted to talk about at dnsop today for WG >adoption was "Serving Stale

[DNSOP] draft-tale-dnsop-serve-stale

2017-03-27 Thread Dave Lawrence
One of the two drafts I wanted to talk about at dnsop today for WG adoption was "Serving Stale Data to Improve DNS Resiliency": https://datatracker.ietf.org/doc/draft-tale-dnsop-serve-stale/ In short, this describes a method for increasing DNS resiliency by treating the inability to refresh data

Re: [DNSOP] on staleness of code points and code (mentions MD5 commentary from IETF98)

2017-03-27 Thread George Michaelson
also +1. if we define them beyond deprecated to REMOVED then we get some confidence its the pool of dead code who remain at risk, should threats emerge. if we leave them in validation, we can't tell if 'modern' technology is exposed to risk we didn't understand as attacks get better. RC4 got

Re: [DNSOP] on staleness of code points and code (mentions MD5 commentary from IETF98)

2017-03-27 Thread Jim Reid
> On 27 Mar 2017, at 20:45, Paul Vixie wrote: > > all code has bugs, eventually. or at least, there is no > existence proof to the contrary, and also, no reason to suspect > otherwise. so, code that is not used will not be reviewed or maintained. > it's a risk, just by

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

2017-03-27 Thread Ondřej Surý
I support this. And found a nit, the document says: The most confusing element of the above equation comes from the "3 * (DNSKEY RRSIG Signature Validity) / 2" but the formula just before doesn't include "3 *" anywhere in it. Cheers, Ondrej -- Ondřej Surý -- Technical Fellow

[DNSOP] Perl related question on BULK RR

2017-03-27 Thread Woodworth, John R
Apologies but I did not hear the full question regarding BULK RR's and the perl like back-references. If you could please repeat the question we would be happy to comment. Thanks, John -- THESE ARE THE DROIDS TO WHOM I REFER: This communication is the property of CenturyLink and may contain

[DNSOP] on staleness of code points and code (mentions MD5 commentary from IETF98)

2017-03-27 Thread Paul Vixie
evan hunt of isc just spoke at the microphones and said "an md5 validator implementation that isn't used isn't hurting anybody." on pressure of time, the microphones had closed, so i'm commenting here. i disagree. all code has bugs, eventually. or at least, there is no existence proof to the

[DNSOP] algrithm-update table

2017-03-27 Thread Andrew Sullivan
Hi, Further to the comments I made at the mic today, I didn't dig into the history on this, but the syntactic agreement that we finally came up with when we had this bunfight years ago was is in RFC 6944. The idea a the time was that we'd product updates of that. The publication date claims

Re: [DNSOP] I-D Action: draft-ietf-dnsop-attrleaf-01.txt

2017-03-27 Thread Dave Crocker
On 3/27/2017 2:11 PM, Ondřej Surý wrote: The draft is missing TLSA records (RFC 6698). Thanks! d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] I-D Action: draft-ietf-dnsop-attrleaf-01.txt

2017-03-27 Thread Ondřej Surý
Hi, as promised here's copy of my mic comment: The draft is missing TLSA records (RFC 6698). Ondřej On 5 March 2017 18:39:29 internet-dra...@ietf.org wrote: A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Domain Name System

[DNSOP] FW: [Ext] New Version Notification for draft-lewis-domain-names-06.txt

2017-03-27 Thread Edward Lewis
On 3/27/17, 13:52, "internet-dra...@ietf.org" wrote: A new version of I-D, draft-lewis-domain-names-06.txt has been successfully submitted by Edward Lewis and posted to the IETF repository. Name: draft-lewis-domain-names Revision:

[DNSOP] Review of draft-ietf-dnsop-nsec-aggressiveuse-08

2017-03-27 Thread Jouni Korhonen
Reviewer: Jouni Korhonen Review result: Has Nits I think would be ready if it passed IDnits. I found the document good read and found no sinkholes in it. Pointing up two implementations was also great. The Proto Write-up seems not be up to date with what IDnits says e.g., when it comes to

Re: [DNSOP] [Ext] Re: WGLC for draft-ietf-dnsop-sutld-ps

2017-03-27 Thread Edward Lewis
On 3/16/17, 15:59, "Ralph Droms" wrote: >Ed - I think your document is ... With Homenet's session ending early, I removed the "definition" section (and retitled it to reflect that it is a case for clarifying, not to be confused with containing an architectural

Re: [DNSOP] .arpa

2017-03-27 Thread Suzanne Woolf
> On Mar 27, 2017, at 8:41 AM, Ray Bellis wrote: > > > > On 27/03/2017 02:52, Patrik Fältström wrote: > >> One important part is in the letter from NTIA (Karen Rose) to ICANN >> (Louis Touton) in Appendix A. >> >> A letter sent April 28, 2000. > > Is it online? I

[DNSOP] FW: New Version Notification for draft-mglt-dnsop-dnssec-validator-requirements-04.txt

2017-03-27 Thread Daniel Migault
Hi, Please find an update of our draft on requirements for DNSSEC resolver. DNS resolvers hardly enable DNSSEC as 1) resolvers are not robust too DNS authoritative operations – like KSK roll over, signing errors…. – and 2) network administrators have little control on these resolvers to

Re: [DNSOP] .arpa

2017-03-27 Thread Jim Reid
> On 27 Mar 2017, at 13:41, Ray Bellis wrote: > > On 27/03/2017 02:52, Patrik Fältström wrote: > >> One important part is in the letter from NTIA (Karen Rose) to ICANN >> (Louis Touton) in Appendix A. >> >> A letter sent April 28, 2000. > > Is it online? I can't find it

Re: [DNSOP] .arpa

2017-03-27 Thread Patrik Fältström
On 27 Mar 2017, at 14:41, Ray Bellis wrote: > On 27/03/2017 02:52, Patrik Fältström wrote: > >> One important part is in the letter from NTIA (Karen Rose) to ICANN >> (Louis Touton) in Appendix A. >> >> A letter sent April 28, 2000. > > Is it online? I can't find it in the ICANN correspondence

Re: [DNSOP] .arpa

2017-03-27 Thread Ray Bellis
On 27/03/2017 02:52, Patrik Fältström wrote: > One important part is in the letter from NTIA (Karen Rose) to ICANN > (Louis Touton) in Appendix A. > > A letter sent April 28, 2000. Is it online? I can't find it in the ICANN correspondence archive. Ray

Re: [DNSOP] .arpa

2017-03-27 Thread Patrik Fältström
On 26 Mar 2017, at 17:17, Ozgur Karatas wrote: > 22.03.2017, 10:05, "Jim Reid" : > >>>  On 21 Mar 2017, at 14:53, Suzanne Woolf wrote: >>> >>>  RFC 3172 was written in 2001… > > the last updated was made in 2013, right? One important part is in the