Re: [DNSOP] New Version Notification for draft-muks-dns-message-checksums-00.txt

Hi Paul On Tue, Sep 29, 2015 at 01:33:57AM -0400, Paul Wouters wrote: > On Tue, 29 Sep 2015, Mukund Sivaraman wrote: > > >On the other hand, DNSSEC requires signatures for each RRset bloating > >messages > > Just like TLS is bloating HTTP? :) TLS and HTTP are irrelevant here, no? The bloat by

Re: [DNSOP] New Version Notification for draft-muks-dns-message-checksums-00.txt

On Tue, 29 Sep 2015, Mukund Sivaraman wrote: On the other hand, DNSSEC requires signatures for each RRset bloating messages Just like TLS is bloating HTTP? :) Anyway, I'll explain with an example why DNSSEC is not sufficient to protect against DNS message modifications. Assume a company prov

Re: [DNSOP] New Version Notification for draft-muks-dns-message-checksums-00.txt

Hi Paul On Mon, Sep 28, 2015 at 02:36:25PM -0400, Paul Wouters wrote: > On Mon, 28 Sep 2015, Paul Vixie wrote: > > >those things should also be done in the short term. > > > >but it's the internet. it'll outlive us all. we ought to have a long > >term plan as well. > > It's called DNSSEC. Zone

Re: [DNSOP] New Version Notification for draft-muks-dns-message-checksums-00.txt

Hi Robert On Mon, Sep 28, 2015 at 02:20:04PM -0400, Robert Edmonds wrote: > Mukund Sivaraman wrote: > > Hi Robert > > > > On Mon, Sep 28, 2015 at 01:30:28PM -0400, Robert Edmonds wrote: > > > 16 bits is an awful lot of space for the ALGORITHM field. Compare to > > > the DNSSEC algorithm number f

[DNSOP] Fw: New Version Notification for draft-yao-dnsop-root-cache-00.txt

Dear all, I submit a draft about Decreasing Fetch time of DNS Root Data. Many DNS recursive resolvers have long round trip times to the DNS root server. It has been an obstacle to increse the performance of DNS query. In order to decrease fetch time of DNS root data, this do

Re: [DNSOP] New Version Notification for draft-muks-dnsop-dns-message-checksums-00.txt

In message , "Joe Abley" writ es: > > On 28 Sep 2015, at 11:51, Mukund Sivaraman wrote: > > > o draft-muks-dnsop-dns-message-checksums-00 > >Initial draft (renamed version). Removed the NONCE-COPY field as > >it is no longer necessary. Doubled the size of the NONCE field to > >128 b

Re: [DNSOP] New Version Notification for draft-muks-dnsop-dns-message-checksums-00.txt

On 28 Sep 2015, at 11:51, Mukund Sivaraman wrote: > o draft-muks-dnsop-dns-message-checksums-00 >Initial draft (renamed version). Removed the NONCE-COPY field as >it is no longer necessary. Doubled the size of the NONCE field to >128 bits. Added sample checksum algorithms. Fixed

Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-edns-client-subnet

On Wed, Sep 16, 2015 at 12:05:58PM -0400, Suzanne Woolf wrote: > The current version is at: > http://datatracker.ietf.org/doc/draft-ietf-dnsop-edns-client-subnet/ > I have some concerns, which I describe below. I've attempte

Re: [DNSOP] New Version Notification for draft-muks-dns-message-checksums-00.txt

On Mon, 28 Sep 2015, Paul Vixie wrote: those things should also be done in the short term. but it's the internet. it'll outlive us all. we ought to have a long term plan as well. It's called DNSSEC. Paul ___ DNSOP mailing list DNSOP@ietf.org https

Re: [DNSOP] New Version Notification for draft-muks-dns-message-checksums-00.txt

On 28 Sep 2015, at 11:25, Paul Vixie wrote: Robert Edmonds wrote: ... I am also curious why a cryptographic hash function (SHA-1) is needed for this. Is a fast non-cryptographic checksum not suitable (e.g., CRC-32C, which can be computed in hardware on x86 CPUs)? in currently theorized atta

Re: [DNSOP] New Version Notification for draft-muks-dns-message-checksums-00.txt

Robert Edmonds wrote: > ... > > I am also curious why a cryptographic hash function (SHA-1) is needed > for this. Is a fast non-cryptographic checksum not suitable (e.g., > CRC-32C, which can be computed in hardware on x86 CPUs)? in currently theorized attacks, the udp checksum is fooled by alt

Re: [DNSOP] New Version Notification for draft-muks-dns-message-checksums-00.txt

Mukund Sivaraman wrote: > Hi Robert > > On Mon, Sep 28, 2015 at 01:30:28PM -0400, Robert Edmonds wrote: > > 16 bits is an awful lot of space for the ALGORITHM field. Compare to > > the DNSSEC algorithm number field, which is only 8 bits. > > Do you suggest changing it to 8 bits too? If you keep

Re: [DNSOP] New Version Notification for draft-muks-dns-message-checksums-00.txt

On Mon, Sep 28, 2015 at 09:56:38AM -0700, Paul Vixie wrote: > so i think there's good cause to add a DNS-level checksum even as we add > DNS-level cookies. +1 I would prefer to use checksum and cookies in parallel rather than have the checksum option recapitulate cookie functionality, though. Un

Re: [DNSOP] New Version Notification for draft-muks-dns-message-checksums-00.txt

Hi Robert On Mon, Sep 28, 2015 at 01:30:28PM -0400, Robert Edmonds wrote: > 16 bits is an awful lot of space for the ALGORITHM field. Compare to > the DNSSEC algorithm number field, which is only 8 bits. Do you suggest changing it to 8 bits too? Mukund pgpB1vCaaZvZT.pgp Descri

Re: [DNSOP] EDNS reply option to list unsupported options from query

Hi Paul On Mon, Sep 28, 2015 at 10:19:20AM -0700, Paul Hoffman wrote: > Paul's "no" (which I agree with) shows what might be a fatal flaw in Even if Paul had said "yes", this security consideration still exists (see below). The reason why I sent the EDNS option handling email was because it somet

Re: [DNSOP] New Version Notification for draft-muks-dns-message-checksums-00.txt

Mukund Sivaraman wrote: > This is a new draft on DNS message checksums. I look forward to hearing > review comments. Hi, Mukund: 16 bits is an awful lot of space for the ALGORITHM field. Compare to the DNSSEC algorithm number field, which is only 8 bits. -- Robert Edmonds

Re: [DNSOP] EDNS reply option to list unsupported options from query

Paul Hoffman wrote: > Paul's "no" (which I agree with) shows what might be a fatal flaw in > draft-muks-dnsop-dns-message-checksums: an attacker just needs to send > fragments that look like they say "I don't understand the new EDNS0 > option". Does that make sense? well, that was my reasoning f

Re: [DNSOP] EDNS reply option to list unsupported options from query

Paul's "no" (which I agree with) shows what might be a fatal flaw in draft-muks-dnsop-dns-message-checksums: an attacker just needs to send fragments that look like they say "I don't understand the new EDNS0 option". Does that make sense? --Paul Hoffman ___

Re: [DNSOP] EDNS reply option to list unsupported options from query

On Mon, Sep 28, 2015 at 10:11:56AM -0700, Paul Vixie wrote: > > > Mukund Sivaraman wrote: > > Hi everyone > > > > RFC6891 says this: > > > >> Any OPTION-CODE values not understood by a responder or requestor > >> MUST be ignored. Specifications of such options might wish to > >> include so

Re: [DNSOP] EDNS reply option to list unsupported options from query

Mukund Sivaraman wrote: > Hi everyone > > RFC6891 says this: > >> Any OPTION-CODE values not understood by a responder or requestor >> MUST be ignored. Specifications of such options might wish to >> include some kind of signaled acknowledgement. For example, an >> option specification

[DNSOP] EDNS reply option to list unsupported options from query

Hi everyone RFC6891 says this: > Any OPTION-CODE values not understood by a responder or requestor > MUST be ignored. Specifications of such options might wish to > include some kind of signaled acknowledgement. For example, an > option specification might say that if a responder sees a

Re: [DNSOP] Expiration impending:

On 28 Sep 2015, at 12:35, Paul Hoffman wrote: We could do that, but the RFC should probably not be published for at least another six months due to terminology / politics / IANAPLAN, so we don't need to rush the WG LC either. For example, the draft uses the phrase "an IANA function performed

Re: [DNSOP] New Version Notification for draft-muks-dns-message-checksums-00.txt

Mukund Sivaraman wrote: > Hi Paul > > On Mon, Sep 28, 2015 at 10:39:04AM -0400, Paul Wouters wrote: >> On Sun, 27 Sep 2015, Mukund Sivaraman wrote: >> >>> UDP has a header checksum that can notice message modification when in >>> use. Sometimes this may be 0 if the sender host did not generate a

Re: [DNSOP] Expiration impending:

On 28 Sep 2015, at 4:59, Joe Abley wrote: Hi all, We don't seem to be getting anywhere with this draft. (Jakob is going to bump it to -12; there have been no real updates apart from the version bump in I appreciate that the methods described in this document are not universally liked. I ha

[DNSOP] Fwd: New Version Notification for draft-muks-dnsop-dns-message-checksums-00.txt

Hi everybody This draft was updated with a new name (thanks to Tomek Mrugalski for pointing this out, nits, and other things) and with the following changes: o draft-muks-dnsop-dns-message-checksums-00 Initial draft (renamed version). Removed the NONCE-COPY field as it is no long

Re: [DNSOP] Fwd: Expiration impending:

On Mon, Sep 28, 2015 at 07:59:00AM -0400, Joe Abley wrote: This document describes existing practice, and provides guidance for people who need to bootstrap a validator using the mechanisms provided by ICANN back in 2009/2010 when the root zone was first published. Preempting a WGLC, I support

Re: [DNSOP] New Version Notification for draft-muks-dns-message-checksums-00.txt

Hi Paul On Mon, Sep 28, 2015 at 10:39:04AM -0400, Paul Wouters wrote: > On Sun, 27 Sep 2015, Mukund Sivaraman wrote: > > >UDP has a header checksum that can notice message modification when in > >use. Sometimes this may be 0 if the sender host did not generate a > >checksum. This draft adds one i

Re: [DNSOP] New Version Notification for draft-muks-dns-message-checksums-00.txt

On Sun, 27 Sep 2015, Mukund Sivaraman wrote: UDP has a header checksum that can notice message modification when in use. Sometimes this may be 0 if the sender host did not generate a checksum. This draft adds one in the application layer alongside a nonce known to the client. Together they are m

[DNSOP] Benoit Claise's No Objection on draft-ietf-dnsop-root-loopback-04: (with COMMENT)

Benoit Claise has entered the following ballot position for draft-ietf-dnsop-root-loopback-04: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer

Re: [DNSOP] Fwd: Expiration impending:

Joe, On Mon, 28 Sep 2015 07:59:00 -0400 "Joe Abley" wrote: > I appreciate that the methods described in this document are not > universally liked. I have a feeling that we would get more discussion if > the question was more open-ended, e.g. how should trust anchors be > published? > > This

[DNSOP] Fwd: Expiration impending:

Hi all, We don't seem to be getting anywhere with this draft. (Jakob is going to bump it to -12; there have been no real updates apart from the version bump in I appreciate that the methods described in this document are not universally liked. I have a feeling that we would get more discussi