IETF Logo Mail Archive

Re: [DNSOP] proposal: Covert in-band zone data

"Wessels, Duane" <dwessels@verisign.com> Mon, 08 July 2019 20:30 UTC

Return-Path: <dwessels@verisign.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 BE9741200C3 for <dnsop@ietfa.amsl.com>; Mon, 8 Jul 2019 13:30:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=verisign.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 yi0PSegxDDgL for <dnsop@ietfa.amsl.com>; Mon, 8 Jul 2019 13:30:19 -0700 (PDT)
Received: from mail6.verisign.com (mail6.verisign.com [69.58.187.32]) (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 18AA01202E9 for <dnsop@ietf.org>; Mon, 8 Jul 2019 13:30:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verisign.com; l=8157; q=dns/txt; s=VRSN; t=1562617819; h=from:to:cc:date:message-id:references:in-reply-to: mime-version:subject; bh=+CUj7DsCeIWQZgaChjBk3Ot5V68RE5xP2cfBJCzGYk4=; b=I11jcYXwInHdSaRFa93HNCnvvPbeJXWgnya+CT4tUATEcjgj3vRcxwmG mjNwc7wYdt12DF0BLnP+fn34mpeOEAHoIJQKTuyXqiUiMa3+A6jZQlOmL p+HijFxnANQ68YEOmpntiyyntfjOD1d4RVgocnrl7Q9OrDTPiAZ3eC2TX RHVeHd2vyvrcZ0PhpPF7hBYGxsJ0t5E3p5xSwHaC5J3Ii443JezunKvCJ WAp39QRcrjaataywapOU4Q5TvWsvf69wbjBFRRz2sSh+87L4jdlyUvplU MlVoFGCjXCL5G3fSaIf7kCwN425sH1pw0XPnt8SOH+5+Y5msxJlz3sR17 Q==;
X-IronPort-AV: E=Sophos; i="5.63,468,1557201600"; d="p7s'?scan'208"; a="7933314"
IronPort-PHdr: 9a23:3yxjSReRxpdvzV/dJRvVxsqflGMj4u6mDksu8pMizoh2WeGdxcS9YB7h7PlgxGXEQZ/co6odzbaP6ea8ASdZvM3JmUtBWaQEbwUCh8QSkl5oK+++Imq/EsTXaTcnFt9JTl5v8iLzG0FUHMHjew+a+SXqvnYdFRrlKAV6OPn+FJLMgMSrzeCy/IDYbxlViDanbr5+MQu6oR/eu8UKjoduN6Y8xxXUqXZUZupawn9lK0iOlBjm/Mew+5Bj8yVUu/0/8sNLTLv3caclQ7FGFToqK2866tHluhnFVguP+2ATUn4KnRpSAgjK9w/1U5HsuSbnrOV92S2aPcrrTbAoXDmp8qlmRAP0hCoBKjU09nzchM5tg6JBuB+vpwJxzZPIYI+bN/R+cKHSfdIGSmVORctRWDBNAoamYocTE+YNI+BVpJT9qVsUqhu+ABGhCO3vxTBWnX/2xrM10+A6EQ3ewQcuEc8Ov27SrNrrOqsZTOe4w7TGzDrddPNWwiny6IzTch06v/GDQ6hwccvKyUkuGAPFiE+cppDiPzOQz+kAtXWQ4el4Ve+3lmIrtxt9riWty8oikIXFm4IYx17e+Sh2w4s5PcC0RFJhbdK5EpZcqzuWO5Z5T84hWW1kpSU3xqUIuZGlfyUG1JEqyhvFZPGEd4WH+RfuWeiPLThlhX9ofamwihKz/EWiz+DxWMe53VRXoSdDj9LCrGoC1wbJ5ciCUvZ9+0Ch1iuR2A3L8eFEJFw0lbLcK5483r48jpoTvlrHHi/xgEj7kbOYeF059ueo8+rpbbTpqoOBO4NulAHxLqMumtanAegiKAcBQnKX+fqm1L34+031WqlFjvozkqXBsZDaI9oUprKhDgNIzoov8QuzAjWo3dgCgHUKLFxIdAiIgoXqI13OJer3Dfa7g1SiijdrwPXGM6X8DZTDMHfDi6zhcqh5605H0wcz085Q54hVCrEaIfLzVUnxuMbEAR8+Ngy42/znB8ll1oMCRWKPBbeUMa3KsV+L/e8vIvKMa5MPtDb6Mfgl6ObkjWUlll8FYampwZwXZWilEfRgOEWZZmLsj8wAEWgUogo+QvbmiFqYUT5cND6OWPcD5y08DI7uLp3OTYGmg73JiDijHbVXfWsADUqDRyTGbYKBDr0zZTmJL8t61nQoSLGnRsVpgR2xuRThxr58BvTZ4CwDtJ3lktNy4ruAxlkJ6TVoApHFgCm2RGZukzZQSg==
X-IPAS-Result: A2FVAACWpiNd/zCZrQplGgEBAQEBAgEBAQEHAgEBAQGBZ4QtCph/g2CXDwkBAQEBAQEBAQEDBAEvAQGEQAKCXDgTAQMBAQEEAQEBAQQBAQECiyyCOiKCbwEBAQECAXkFCwIBCA4KLgIwJQIECgQFDoMUAYF7rBqFR4RbEIE0gVGKJYFBPoERJx+CTD6ELoNSgiYEqlIDBgKCF4Mrgh+OVZd+pG0CBAIEBQIVgWeBenAVZQGCQZEFco1MgSEBAQ
Received: from BRN1WNEX01.vcorp.ad.vrsn.com (10.173.153.48) by BRN1WNEX01.vcorp.ad.vrsn.com (10.173.153.48) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Mon, 8 Jul 2019 16:30:16 -0400
Received: from BRN1WNEX01.vcorp.ad.vrsn.com ([fe80::a89b:32d6:b967:337d]) by BRN1WNEX01.vcorp.ad.vrsn.com ([fe80::a89b:32d6:b967:337d%5]) with mapi id 15.01.1713.004; Mon, 8 Jul 2019 16:30:16 -0400
From: "Wessels, Duane" <dwessels@verisign.com>
To: Witold Krecicki <wpk@isc.org>
CC: "dnsop@ietf.org WG" <dnsop@ietf.org>
Thread-Topic: [EXTERNAL] Re: [DNSOP] proposal: Covert in-band zone data
Thread-Index: AQHVNFKYO7UbQua6wEW9hRWS3r+4laa+hIEAgAADswCAAqQyAIAAEOOAgAAuAQCAAAcFgA==
Date: Mon, 08 Jul 2019 20:30:16 +0000
Message-ID: <4BA5D196-E626-4AD1-AF32-546A37D3F156@verisign.com>
References: <20190706213024.GA56650@isc.org> <CAJhMdTMwCiAS+S_j-i3BXPZ=G1zVhAq+YKH07RsDWRgezPhejg@mail.gmail.com> <caa695e7-21e6-9c41-1814-1f4c1d64df7f@isc.org> <CAJhMdTPK3iqg4sF0Kr+jGAXTf2MZ8FAP0DgwQw1kVBHa65wTNA@mail.gmail.com> <191886397.1948062.1562455685612.JavaMail.zimbra@isc.org> <CAJhMdTNvO=TjNUV=6wHwLJB_c+tqwk4zY24jGbi5a0SqdSUsag@mail.gmail.com> <561203a3-7fd9-94cc-5b13-3639b123f8e2@isc.org> <C467FE93-F6CE-4DB4-80E8-654B1485A1F6@hopcount.ca> <BCD5A218-CF1A-4569-B8A2-7BC8B499CC4B@verisign.com> <a0309614-bd25-08d4-003d-4615779910f6@isc.org>
In-Reply-To: <a0309614-bd25-08d4-003d-4615779910f6@isc.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [10.170.148.18]
Content-Type: multipart/signed; boundary="Apple-Mail=_1A47CD18-AB29-4620-9E1E-AE13E0A6DFA8"; protocol="application/pkcs7-signature"; micalg="sha1"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/nsz5Zuggrr3F9tNp-DET7NinJLg>
Subject: Re: [DNSOP] proposal: Covert in-band zone data
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
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, 08 Jul 2019 20:30:29 -0000


> On Jul 8, 2019, at 1:05 PM, Witold Krecicki <wpk@isc.org> wrote:
> 
> W dniu 08.07.2019 o 19:20, Wessels, Duane pisze:
> 
>> With respect to 2.6. Interaction with ZONEMD, I'd think it should follow handling of DNSSEC.  That is, covert types should not be included in a zone digest.
> 
> As I understand ZONEMD main purpose is to verify the full content of the
> zone, mainly for zone transfer. In that case, I'd include COVERT records
> - as the clients who can transfer the zone using XFR will also be able
> to transfer COVERT records. (but I'm not stuck to that opinion).

If the primary server is allowed to transmit two versions of the zone -- one with covert RRs and one without -- then it only makes sense to omit covert RRs from the digest.  It would be unfortunate, but necessary.

Actually I think the last paragraph of 2.2 would be better with only this:

   If the primary server receives a zone transfer request for a zone with
   Covert RRs, but without the COVERT-OK option, it MUST NOT transfer the zone.

That is, don't allow AXFR of a zone with Covert RRs to an unaware secondary.  Then leaks are much less likely and you can include the covert RRs in the zone digest.  You would need to specify what the server should do in this case.  REFUSED I guess.

DW

v2.23.0 | Report a Bug | By Email