DNSSEC is NOT secure end to end

2009-05-30 Thread Masataka Ohta
Mark Andrews wrote: > In a general PKI you need a third party to validated the > name to certificate mapping because there is not natual > method to do this. > > With DNSSEC the naming authority is the introducing authority. Read the paper. Your attempt to modify the mea

Re: DNS over SCTP

2009-05-30 Thread Alessandro Vesely
Paul Wouters wrote: On Fri, 29 May 2009, Alessandro Vesely wrote: It's what the patch has reinforced. SCTP is more secure than the patched bind, yet easier than DNSSEC. where easier means "update all the root and TLD servers and load balancers and what not to support DNS over SCTP. While DNSS

Re: Differing topics (was: IAOC Meeting location selection)

2009-05-30 Thread John C Klensin
--On Friday, May 29, 2009 23:29 -0400 Andrew Sullivan wrote: > On Fri, May 29, 2009 at 11:23:26PM -0400, Andrew Sullivan > wrote: > >> discussed, not always separately, in this thread, > > I should have said "these threads", of course -- I was > implicitly tying this discussion to the recent

Re: IAOC Meeting location selection

2009-05-30 Thread John C Klensin
--On Friday, May 29, 2009 15:24 -0700 David Kessens wrote: > > John, > > On Thu, May 28, 2009 at 03:39:17PM -0400, John C Klensin wrote: >> >> When you have time, I (and I believe others) would like to >> understand better how you evaluate "reasonable costs for the >> IETF and attendees".

Re: DNS over SCTP

2009-05-30 Thread Francis Dupont
In your previous mail you wrote: => I keep this because your answer is not about this... > I don't understand your argument: it seems to apply to UDP over SCTP > but here we have SCTP over UDP. BTW the easiest way to convert DNS > over UDP into DNS over SCTP is to use an ALG (appli

Re: DNSSEC is NOT secure end to end

2009-05-30 Thread Masataka Ohta
Francis Dupont wrote: > => not only this is very arguable (for instance about the resource > exhaustion) but no hop-by-hop/channel security, even something as > strong as TSIG, can provide what we need, i.e., end-to-end/object > security (*). Unless your meaning of end-to-end differs from that of