Re: [IPsec] Comments to the draft-ietf-ipsecme-split-dns-04.txt

Tero Kivinen <kivinen@iki.fi> Tue, 06 February 2018 18:04 UTC

Return-Path: <kivinen@iki.fi>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9713D127241 for <ipsec@ietfa.amsl.com>; Tue, 6 Feb 2018 10:04:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.12
X-Spam-Level:
X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no 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 660ae5xtz58M for <ipsec@ietfa.amsl.com>; Tue, 6 Feb 2018 10:04:16 -0800 (PST)
Received: from mail.kivinen.iki.fi (fireball.acr.fi [212.16.101.130]) (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 1FD4D1270AB for <ipsec@ietf.org>; Tue, 6 Feb 2018 10:04:15 -0800 (PST)
Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id w16I4BXc026251 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 6 Feb 2018 20:04:11 +0200 (EET)
Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id w16I4BI0006329; Tue, 6 Feb 2018 20:04:11 +0200 (EET)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-ID: <23161.60955.207264.333654@fireball.acr.fi>
Date: Tue, 06 Feb 2018 20:04:11 +0200
From: Tero Kivinen <kivinen@iki.fi>
To: Paul Wouters <paul@nohats.ca>
Cc: Tommy Pauly <tpauly@apple.com>, "ipsec@ietf.org WG" <ipsec@ietf.org>
In-Reply-To: <alpine.LRH.2.21.1802061040590.28057@bofh.nohats.ca>
References: <23161.44491.871182.608585@fireball.acr.fi> <alpine.LRH.2.21.1802061040590.28057@bofh.nohats.ca>
X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd)
X-Edit-Time: 5 min
X-Total-Time: 6 min
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/2suuLDWrWp4WfjX57s-bHRyZl2M>
Subject: Re: [IPsec] Comments to the draft-ietf-ipsecme-split-dns-04.txt
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipsec/>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 06 Feb 2018 18:04:17 -0000

Paul Wouters writes:
> > It is bit misleading to say that "Key Tag", "Algorithm", "DS algoritm"
> > etc can either be 0 or 2/1/1 etc octets long. How does the receiver
> > know what is going to be the length of the "Key Tag" value for
> > example?
> 
> It was actually a mistake (partially induced by my memory of rfc-8078
> work and its errata). Those fields are all fixed length. Only the digest
> itself is variable length, and as per 8078 errata, the shortest
> representation would be "00", so two octets.

That does not match the section 3.

I.e., in section 3 you have examples and text saying that initiator
will send empty INTERNAL_DNSSEC_TA attribute in CFG_REQUEST:

   To indicate support for DNSSEC, an initiator includes one or more
   INTERNAL_DNSSEC_TA attributes as defined in Section 4 as part of
   the CFG_REQUEST payload. If an INTERNAL_DNSSEC_TA attriute is
   included in the CFG_REQUEST, the initiator SHOULD also include one
   or more INTERNAL_DNS_DOMAIN attributes in the CFG_REQUEST.

   An initiator MAY convey its current DNSSEC trust anchors for the
   domain specified in the INTERNAL_DNS_DOMAIN attribute. If it does
   not wish to convey this information, it MUST use a length of 0.

but this is not possible with current definition of the section 4.2,
where the DNSKEY Key Tag etc fields are mandatory. Thats why my
proposal was to make whole DNSSEC Trust Anchor Data optional. 

> > I assume the intent has been to say that either all the fields are
> > there with fixed lengths, or they are all omitted, meaning the length
> > is 0 for all of them.
> 
> That was not at all the intent :)
> 
> I've submitted -05. My only question now is what to do with the
> length field of both records. It now says "2 octects, unsigned integer"
> but perhaps it should say "2 octets in network order" ?

In RFC7296 we have:

   All multi-octet fields representing integers are laid out in big
   endian order (also known as "most significant byte first", or
   "network byte order").

which covers everything. You could add similar text here... 
-- 
kivinen@iki.fi