Re: [DNSOP] New Version Notification for draft-sury-deprecate-obsolete-resource-records-00.txt

Michael Casadevall <michael@casadevall.pro> Mon, 26 March 2018 18:33 UTC

Return-Path: <michael@casadevall.pro>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF8C2126CE8 for <dnsop@ietfa.amsl.com>; Mon, 26 Mar 2018 11:33:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level:
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id axsVCxPd3zle for <dnsop@ietfa.amsl.com>; Mon, 26 Mar 2018 11:33:26 -0700 (PDT)
Received: from casadevall.pro (casadevall.pro [45.33.112.193]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C25AE1250B8 for <dnsop@ietf.org>; Mon, 26 Mar 2018 11:33:26 -0700 (PDT)
Received: from [192.168.2.2] (cpe-68-174-119-246.nyc.res.rr.com [68.174.119.246]) by casadevall.pro (Postfix) with ESMTPSA id 0F0571F81B for <dnsop@ietf.org>; Mon, 26 Mar 2018 18:33:26 +0000 (UTC)
References: <7CF21F70-9419-4D6A-B555-FC229F90E8A9@isc.org> <5AB546CB.3030408@redbarn.org> <CCAE4014-67F8-4E73-A893-AA06B83E880B@isc.org> <20180324124958.GA29255@puck.nether.net> <CAJhMdTPRn=mUQ6xh_HFdFLBk109b_M2+saS86KFxsttb8_oVvw@mail.gmail.com> <20180325080558.GA18671@isc.org> <066C83F5-5E1C-4DF8-8D45-A7E9F3A44673@vpnc.org> <DCE31CFA-534E-451F-B743-E022F62C7516@isc.org> <20180326124544.GA32080@isc.org> <552cfda4-572b-7c88-b5b8-0cda5c49e2fd@casadevall.pro> <20180326145729.GA35023@isc.org> <446d939d-5353-2f31-3b3f-7097e2c13a54@casadevall.pro> <6e31543d-f8ec-acde-8dc5-bd5435bae579@oracle.com>
From: Michael Casadevall <michael@casadevall.pro>
To: dnsop@ietf.org
Message-ID: <23c3bd8e-9ec9-60c6-064f-e099af0720cc@casadevall.pro>
Date: Mon, 26 Mar 2018 14:33:29 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0
MIME-Version: 1.0
In-Reply-To: <6e31543d-f8ec-acde-8dc5-bd5435bae579@oracle.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/-znEZk_aw0gTLiIdryWs8q6pJeM>
Subject: Re: [DNSOP] New Version Notification for draft-sury-deprecate-obsolete-resource-records-00.txt
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 26 Mar 2018 18:33:28 -0000


On 03/26/2018 02:05 PM, Richard Gibson wrote:
> TSIGs cover "A whole and complete DNS message in wire format, before the
> TSIG RR has been added to the additional data section and before the DNS
> Message Header's ARCOUNT field has been incremented to contain the TSIG
> RR" (RFC 2845 section 3.4.1), and would therefore be sensitive to
> decompression.
> 

I'll go through the TSIG specification in-depth tomorrow, but is that
actually a problem? More specifically, is there a case where a DNS
server is signing TSIG records when it doesn't control the wire
representation of what's being sent?

If it is, then that's a rather large one.

I brought up RRSIG came to mind because a DNS server may be relaying
information it's unable to change/modify (i.e., a signed zone with a
MAILA record). Since RRSIGs sign the canonical form of the record, the
actual wire representation shouldn't matter if I understand the spec
correctly (i.e. compressed/decompressed); an uncompressed MAILA record
would essentially be equivalent to any other RFC 3597 record.

If I'm completely off base here, let me know. I'll follow up with my
findings, but I'm guessing someone will beat me to it.
Michael