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

Richard Gibson <richard.j.gibson@oracle.com> Mon, 26 March 2018 18:05 UTC

Return-Path: <richard.j.gibson@oracle.com>
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 80E221277BB for <dnsop@ietfa.amsl.com>; Mon, 26 Mar 2018 11:05:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.011
X-Spam-Level:
X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=oracle.com
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 oxiLz-Y8aiLJ for <dnsop@ietfa.amsl.com>; Mon, 26 Mar 2018 11:05:15 -0700 (PDT)
Received: from userp2130.oracle.com (userp2130.oracle.com [156.151.31.86]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05FE0126CC4 for <dnsop@ietf.org>; Mon, 26 Mar 2018 11:05:14 -0700 (PDT)
Received: from pps.filterd (userp2130.oracle.com [127.0.0.1]) by userp2130.oracle.com (8.16.0.22/8.16.0.22) with SMTP id w2QI4vPR011825; Mon, 26 Mar 2018 18:05:13 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=subject : to : references : from : message-id : date : mime-version : in-reply-to : content-type : content-transfer-encoding; s=corp-2017-10-26; bh=ZuqDCSBU4EcXXZfaQ4It7fLtBHVY2b+sH1unRs5ddUU=; b=uXWJQsIx+6d/g2bD48OYGXeAW6X12zhvXU5agMC5CwjKK0DaTVOrsJ8XlOKDSTTmJai+ Al/XYWEv2rKcYO4C9Ze9xtlli47vjXlsnN3psj5BeVeFBL/ue5uYLQ1lso+eRHAkMJqA YNzYwFmJnltIR6/LfNr5XyOhs1CBVqUXBPkSVkJLHGw/GQPtfT1PqrJl6RHwERifNzN1 RZCszKBqLYmRLwxORi+0ZxvlxiBJITxqeuNHLtmbbF5b1ZvCGXNC62MsWkrBB6Lg751f hEE/zY9EEQv5qYKI3bd/FmFzEMKkYiFZp3LK0Z2fczAJT3czprF55vz4O3RfdT44KUM7 hA==
Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by userp2130.oracle.com with ESMTP id 2gy5u1801k-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 26 Mar 2018 18:05:13 +0000
Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by aserv0022.oracle.com (8.14.4/8.14.4) with ESMTP id w2QI5BOp031813 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 26 Mar 2018 18:05:12 GMT
Received: from abhmp0019.oracle.com (abhmp0019.oracle.com [141.146.116.25]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id w2QI5AHt028069; Mon, 26 Mar 2018 18:05:11 GMT
Received: from [172.19.128.82] (/216.146.45.33) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 26 Mar 2018 11:05:10 -0700
To: Michael Casadevall <michael@casadevall.pro>, dnsop@ietf.org
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>
From: Richard Gibson <richard.j.gibson@oracle.com>
Message-ID: <6e31543d-f8ec-acde-8dc5-bd5435bae579@oracle.com>
Date: Mon, 26 Mar 2018 14:05:08 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0
MIME-Version: 1.0
In-Reply-To: <446d939d-5353-2f31-3b3f-7097e2c13a54@casadevall.pro>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=8844 signatures=668695
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=965 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1803260185
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/_Y8kecIGWT-FSHacbsv3JOvOGHI>
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:05:16 -0000

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.


On 03/26/2018 11:33 AM, Michael Casadevall wrote:
> 2. Resolvers MUST never generate obsolete RRtypes in a compressed
> format. If (in line with below) the resolver receives a record in
> compressed form, it MUST be decompressed before being sent to downstream
> resolvers as though. Resolvers SHOULD warn that they are unpacking
> records in transit.
>
> How's that sound? I'm still somewhat iffy on my understanding of DNSSEC
> RRSIG canonical forms, but if I understood the RFCs correctly, the
> uncompressed record should match the canonical form the RRSIG validates
> against to which in turn is identical to RFC 3597 (aside from WKS,
> although RFC 2136 suggests it only applies in the case of DNS update and
> not validation)
>
> It specifically states you're allowed to understand, but thou must not
> speak. If there's a DNSSEC concern, it should be noted though I don't
> think it's a showstopper in and of itself. As previously stated, I very
> much doubt these records are commonly if ever signed.