Re: [DNSOP] DNS versioning, was The DNSOP WG has placed draft-woodworth-bulk-rr in state "Candidate for WG Adoption"

2017-07-21 Thread Woodworth, John R
> -Original Message- > From: DNSOP [mailto:dnsop-boun...@ietf.org] On Behalf Of Andrew Sullivan > > On Thu, Jul 20, 2017 at 02:34:48PM +0100, Tony Finch wrote: > > This basically means that BULK is a master-only feature, which implies > > that there's no need for BULK to work across zone

Re: [DNSOP] DNS versioning, was The DNSOP WG has placed draft-woodworth-bulk-rr in state "Candidate for WG Adoption"

2017-07-21 Thread Woodworth, John R
> From: Tony Finch [mailto:d...@dotat.at] > Hi Tony, Thanks for the feedback. > > John R Levine wrote: > > > > BULK absolutely requires online DNSSEC signing, > > This basically means that BULK is a master-only feature, which > implies that there's no need for BULK to work

Re: [DNSOP] DNS versioning, was The DNSOP WG has placed draft-woodworth-bulk-rr in state "Candidate for WG Adoption"

2017-07-21 Thread Woodworth, John R
> -Original Message- > From: John R Levine [mailto:jo...@taugh.com] > Hi John, Thanks again for your feedback. > > On Thu, 20 Jul 2017, Woodworth, John R wrote: > > Camp#2) Don't break DNS, even for a second > > Well, yeah, except that there's no such thing as breaking the > DNS for a

Re: [DNSOP] DNS versioning, was The DNSOP WG has placed draft-woodworth-bulk-rr in state "Candidate for WG Adoption"

2017-07-21 Thread John R Levine
On Fri, 21 Jul 2017, Matthew Pounsett wrote: Dear $VENDOR. I'm a customer who is considering deploying the BULK RR type into my zone, and I would like to know whether your systems support it. Thank you, $CUSTOMER. Dear $CUSTOMER, Thank you for your question. Here at $VENDOR we take pride

Re: [DNSOP] The DNSOP WG has placed draft-woodworth-bulk-rr in state "Candidate for WG Adoption"

2017-07-21 Thread Peter van Dijk
Hello John, On 20 Jul 2017, at 3:17, Woodworth, John R wrote: Although in practice the name would likely be shorter and potentially include other customer attributes, say acmewabbit-21f-5bff-fec3-ab9d.example.com 1. This shows the owner is example.com, customer acmewabbit 2. Reverse

Re: [DNSOP] DNS versioning, was The DNSOP WG has placed draft-woodworth-bulk-rr in state "Candidate for WG Adoption"

2017-07-21 Thread Peter van Dijk
Tim, On 20 Jul 2017, at 14:09, tjw ietf wrote: Another Data Point: One of the Apps Area ADs stopped by to tell the chairs that 1) they like the general idea; 2) their employer has a need for this *outside of the PTR space*; and 3) would be willing to shepherd the work through. Now, they

Re: [DNSOP] DNS versioning, was The DNSOP WG has placed draft-woodworth-bulk-rr in state "Candidate for WG Adoption"

2017-07-21 Thread Matthew Pounsett
On 20 July 2017 at 17:53, John R Levine wrote: > That's why I don't share the fears about BULK: you cannot easily >> deploy a new feature that will require a change in the resolvers, >> because you don't know all the resolvers, and cannot change them even >> if you know they are

Re: [DNSOP] The DNSSEC club and surprises (was Re: New draft: Algorithm Negotiation in DNSSEC)

2017-07-21 Thread Warren Kumari
I've also heard the "changing the keys is good hygiene" argument -- if someone has wandered off with your private keys (like an old administrator) you have limited how long they can reuse them but, a: there is room for argument and b: we have gotten way down into the weeds here... W On Fri,

Re: [DNSOP] The DNSSEC club and surprises (was Re: New draft: Algorithm Negotiation in DNSSEC)

2017-07-21 Thread George Michaelson
A fine bit of epistemology lies in the question: is it the same certificate, if you re-issue it with the same keys? No, because it has a different serial. but the crypto doesn't care, its the validation which cares which is a product of the crypto. so validation cares but cryptographic functions

Re: [DNSOP] The DNSSEC club and surprises (was Re: New draft: Algorithm Negotiation in DNSSEC)

2017-07-21 Thread Warren Kumari
On Fri, Jul 21, 2017 at 1:36 PM, Tony Finch wrote: > Andrew Sullivan wrote: >> >> For instance, people also express astonishment that DNSKEYs don't >> expire. Everyone always has to be reminded that signatures expire, and >> if you want to expire keys you

Re: [DNSOP] The DNSSEC club and surprises (was Re: New draft: Algorithm Negotiation in DNSSEC)

2017-07-21 Thread Tony Finch
Andrew Sullivan wrote: > > For instance, people also express astonishment that DNSKEYs don't > expire. Everyone always has to be reminded that signatures expire, and > if you want to expire keys you take them out of the zone. I agree with your message. It might be

Re: [DNSOP] NSEC/NSEC3 for unsigned zones and aggressive use

2017-07-21 Thread Mukund Sivaraman
On Fri, Jul 21, 2017 at 10:24:35AM +0200, Petr Špaček wrote: > On 19.7.2017 10:50, Francis Dupont wrote: > > In your previous mail you wrote: > > > >> NSEC needs no keys, only their RRSIGs would which wouldn't exist in > >> unsigned zones. In this case the unsigned NSEC would also not be part

Re: [DNSOP] EDNS0 clientID is a wider-internet question

2017-07-21 Thread Suzanne Woolf
George, > On Jul 20, 2017, at 1:00 PM, George Michaelson wrote: > > I probably will not carry the WG with me on this, but I find myself > thinking the PII aspect of client-ID makes it a wider-internet > question and we might have views as a WG, and promote questions as a >

Re: [DNSOP] NSEC/NSEC3 for unsigned zones and aggressive use

2017-07-21 Thread Petr Špaček
On 19.7.2017 10:50, Francis Dupont wrote: > In your previous mail you wrote: > >> NSEC needs no keys, only their RRSIGs would which wouldn't exist in >> unsigned zones. In this case the unsigned NSEC would also not be part of >> the zone (it would have to be synthesized and maintained outside

Re: [DNSOP] I-D Action: draft-ietf-dnsop-session-signal-02.txt

2017-07-21 Thread Ted Lemon
I am hearing from a number of people that this is "a new protocol" and hence requires careful thought and perhaps a new working group, along with the associated delay. I do not _entirely_ disagree with this position, although it would be really inconvenient from my perspective. However, I would