Re: [DNSOP] Comments regarding the NSEC5

Hi Paul, > This proposal continues to have fundamental problems that are not documented > in the draft. > > - The statement about NSEC3 "offline dictionary attacks are still possible > and have been demonstrated" doesn't take into account trivial changes that an > operator can choose to take i

Re: [DNSOP] Comments regarding the NSEC5

On 23.3.2015 18:26, Bob Harold wrote: > I think we might need to allow for more than one NSEC5 key and chain, > during a transition. Otherwise it might be impossible to later create a > reasonable transition process. This might require us to tag the NSEC5 > records with an id, so that the chains

Re: [DNSOP] Comments regarding the NSEC5

On 3/23/15, 14:08, "Paul Hoffman" wrote: >On Mar 23, 2015, at 10:15 AM, Jan Včelák wrote: >> I just submitted an updated NSEC5 draft into the data tracker. The most >> significant change is fixing the NSEC5 key rollover mechanism; the rest >> are just typo fixes and small clarifications in termi

Re: [DNSOP] Comments regarding the NSEC5

> Paul Hoffman > Monday, March 23, 2015 12:08 PM > > This proposal continues to have fundamental problems that are not > documented in the draft. > > ... > > Overall, this seems like a novel idea that comes with a huge > operational overhead and no actual demand. +

Re: [DNSOP] Comments regarding the NSEC5

On Mar 23, 2015, at 10:15 AM, Jan Včelák wrote: > I just submitted an updated NSEC5 draft into the data tracker. The most > significant change is fixing the NSEC5 key rollover mechanism; the rest > are just typo fixes and small clarifications in terminology. This proposal continues to have fundam

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

Bob Harold writes: > My apologies for not seeing this sooner.  In section "5. Security > Considerations": Hi Bob, I've been stewing over this one in my head for a few days since I saw your message. In short: I agree with you and am now slapping myself silly. I suspect as is it's not "awful",

Re: [DNSOP] Comments regarding the NSEC5

The completed sections of draft looks good to me, with one exception. I think we might need to allow for more than one NSEC5 key and chain, during a transition. Otherwise it might be impossible to later create a reasonable transition process. This might require us to tag the NSEC5 records with a

[DNSOP] admin for IETF 92

Hi, In the interests of keeping our packed agenda moving tomorrow…. Please let the chairs know ASAP if you're willing to be a notetaker or jabber scribe for the meeting. Please volunteer if you can-- it's a good way to learn in-depth what's going on in the WG. Also, I'm told there are shiny s

Re: [DNSOP] Comments regarding the NSEC5

Hi, I just submitted an updated NSEC5 draft into the data tracker. The most significant change is fixing the NSEC5 key rollover mechanism; the rest are just typo fixes and small clarifications in terminology. http://datatracker.ietf.org/doc/draft-vcelak-nsec5/ Also, I will have a 10 minute talk

Re: [DNSOP] discussion for draft-appelbaum-dnsop-onion-tld-00.txt

On 03/23/2015 02:31 PM, Andrew Sullivan wrote: [snip]. > It might be worth adding a sentence or two after the list in section 2 > to that effect. Perhaps, "It is important to note that any > contamination of DNS caches with onion names cannot have a negative > affect on any correctly-operating so

Re: [DNSOP] discussion for draft-appelbaum-dnsop-onion-tld-00.txt

First, sorry, I don't know why I wrote "section 4"; this is section 2, but I think you understood me. On Mon, Mar 23, 2015 at 12:57:53PM +, Alec Muffett wrote: > a) the software in question is talking to a Tor proxy which acts as a > gateway to the Tor network (and to the rest of the internet-

Re: [DNSOP] discussion for draft-appelbaum-dnsop-onion-tld-00.txt

Hi Andrew, If I understand your question correctly, you are asking whether in the instance that a DNS server receives and caches a NXDOMAIN for some/all .onion, whether that could impact software which uses Tor? Software which uses Tor does so via a proxy which internally performs the resolution