Re: [IPsec] Shepherd review of the draft-ietf-ipsecme-add-ike

Valery Smyslov <smyslov.ietf@gmail.com> Tue, 31 January 2023 08:19 UTC

Return-Path: <smyslov.ietf@gmail.com>
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 BB35EC14CE3D; Tue, 31 Jan 2023 00:19:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.095
X-Spam-Level:
X-Spam-Status: No, score=-7.095 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dc7BKBQulCAm; Tue, 31 Jan 2023 00:19:40 -0800 (PST)
Received: from mail-lf1-x130.google.com (mail-lf1-x130.google.com [IPv6:2a00:1450:4864:20::130]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F178AC15154F; Tue, 31 Jan 2023 00:19:39 -0800 (PST)
Received: by mail-lf1-x130.google.com with SMTP id v17so17152420lfd.7; Tue, 31 Jan 2023 00:19:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-language:thread-index:content-transfer-encoding :mime-version:message-id:date:subject:in-reply-to:references:cc:to :from:from:to:cc:subject:date:message-id:reply-to; bh=W8VDMgj1IzCUwoMgugDoPzvuJnc5NlXLmidOWNvTYO0=; b=j7T28C6dZZnAsF3mHWtu20Cclzqc0XtXZBQarO/j4SDqTG+y82ySGVUssrH+sW9HJ3 WC8dxdpIx4CNjqytQwNDwQ2b9Ob66rX93t0QKSXPpeafIbPPe0dzUrYcTIIVvX40v7Dl GdEUjnxAkC6/gqxmHBwiyaqJD0iqSkSb5zDhbvXTnEVGXzHCbEFm9pN0bqvB5yVTfvyV wRRt+0hX1++aZIj6sXLIhcpjBmLlYgHhfii3xUPnC1QTpZdoeoedpHkN9f1FpDvsd9JM dJIwst5z5Gro4ZUfBKcUtacWLBYGi9fF6QHPLaPCncW1/8OywX9qC5c51tOiZ2bb4jX/ Iobw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-language:thread-index:content-transfer-encoding :mime-version:message-id:date:subject:in-reply-to:references:cc:to :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=W8VDMgj1IzCUwoMgugDoPzvuJnc5NlXLmidOWNvTYO0=; b=cAuUrUeG1gvJvBs0/Ty4DzUT5enWwHI72qDoj6oyFtqi2q62OpOIMOQXIPKGM6Ftoo EG/9CG7mS19QgdZ5axFp/6ceBuW7Ij6KUuCyXzvA+NhzgZc7oMLDQMiSglLDU6JczlGJ +DrqqnvJBcyEYx3TR6l45UVukRbCbWWd1lc7a+OyKWBDFUP5aWOa3EXhNS3hiqRUF23F QxiHRVdf6J3W3aaODLwXVRzF9FUlRN2iIqqV3IofyrinIhqlf1BgIaG3IuGY9P2/dT/M RSYZLsTCV3PvMIVGryEAcOPLz2gw9o7HehEN/tRkO1u5aPSgYamf1/Wxz3YxLYjXx92b YPtA==
X-Gm-Message-State: AFqh2kpXNnQoJQbXwOBh9jEOpjYvdSPGgw9hX22AOYZr9rM8RxLTzmM/ tS2cOuW5o5p7qIwif8p3M2HjysB7bBY=
X-Google-Smtp-Source: AMrXdXuZV+hq3lrpJrNofu/TXtLs/L7GQZytE2eVA7qLZg1hkRJuSZ9ZjEkH2HhSVsmRAe5ZASkaQQ==
X-Received: by 2002:a05:6512:3e29:b0:4b5:26f3:2247 with SMTP id i41-20020a0565123e2900b004b526f32247mr17745421lfv.69.1675153177651; Tue, 31 Jan 2023 00:19:37 -0800 (PST)
Received: from buildpc ([93.188.44.204]) by smtp.gmail.com with ESMTPSA id m1-20020a195201000000b004d5c88eb19esm937157lfb.43.2023.01.31.00.19.36 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 31 Jan 2023 00:19:37 -0800 (PST)
From: Valery Smyslov <smyslov.ietf@gmail.com>
To: 'Tero Kivinen' <kivinen@iki.fi>, draft-ietf-ipsecme-add-ike@ietf.org
Cc: ipsec@ietf.org
References: <25560.18262.145478.996578@fireball.acr.fi>
In-Reply-To: <25560.18262.145478.996578@fireball.acr.fi>
Date: Tue, 31 Jan 2023 11:19:36 +0300
Message-ID: <013a01d9354c$c1fe37b0$45faa710$@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQCAgn2bCmto1LxXAYW0RtdIvBG6K7FpiJ1w
Content-Language: ru
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/3PobDRv8eDdNtJ0B5pUgdrFN1zs>
Subject: Re: [IPsec] Shepherd review of the draft-ietf-ipsecme-add-ike
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.39
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, 31 Jan 2023 08:19:43 -0000

Hi Tero,

thank you for the review. Please see inline.

> Here are some my review comments while reading
> draft-ietf-ipsecme-add-ike:
> 
> ----------------------------------------------------------------------
> The text in section 3.1 should say that if length is 0, then no
> Service Priority, Num Addresses etc fields are present.
> 
> I.e., add text in first bullet under Length saying that if length is
> zero, then later fields are not present.

Makes sense.

> --
> 
> Also the text in Num Addresses indicate that it would be valid to send
> CFG_REQUEST with proposed Service Priority, but having Num Addresses
> set to zero?
> 
> Is this intended? I.e., is the client allowed to request data, but not
> propose IP address? If so, perhaps add sentence to Num Addresses
> explaining that it can be 0 for CFG_REQUEST when no specific address
> is request, but other parameters are requested.

Hm... I think my co-authors can comment on this.

> --
> 
> In IP Address(es) explictly mention that it is field contain 4 octet
> IPv4 addresses, or 16 octet IPv6 address without any delimeters etc.
> This can be derived from the calculation of the length field, but I
> think it should be mentioned here, even when it is obvious.

OK.

> --
> 
> In section 3.2 it is not clear what the length of the Hash Algorithm
> Identifiers fields is. It contains list of hash algorithms or one hash
> algorithm if this is response, but it is not clear what is response.

What was meant is that a list of hashes is sent by a client (in CFG_REQUEST) and
a single hash is sent by a server (in CFG_REPLY).

> We have CFG_REQUEST, CFG_REPLY, CFG_SET, and CFG_ACK. Most likely
> CFG_REPLY and CFG_ACK are sent in IKE exchange response. On the other
> hand CFG_SET is usually used to set the parameters, thus the
> Certificate Digest would be required there.

True, but IKEv2 doesn't currently use CFG_SET/CFG_ACK and
it explicitly allows implementations to ignore them.

> I would assume that there is only one Hash Algorithm Identifier for
> CFG_REPLY and CFG_SET, and then the Certificate Digest field is
> present. For CFG_REQUEST the Hash Algorithm Identifier is a list of
> two octet hash algorithm identifiers and the Certificate field is
> omitted. For the CFG_ACK only first 4 octets are included and Length
> is set to zero.
> 
> I think it would be better to split the Figure 2 to three different
> figures:
> 
> 
>                         1                   2                   3
>     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>    +-+-----------------------------+-------------------------------+
>    |R|         Attribute Type      |            Length             |
>    +-+-----------------------------+---------------+---------------+
>    |                    RESERVED                   |  ADN Length   |
>    +-----------------------------------------------+---------------+
>    ~                  Authentication Domain Name                   ~
>    +---------------------------------------------------------------+
>    ~              Hash Algorithm Identifier (2 octets)             ~
>    +---------------------------------------------------------------+
>    ~                     Certificate Digest                        ~
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
>   Figure 2: ENCDNS_DIGEST_INFO Attribute Format for CFG_REPLY and CFG_SET
> 
> 
> 
>                         1                   2                   3
>     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>    +-+-----------------------------+-------------------------------+
>    |R|         Attribute Type      |            Length             |
>    +-+-----------------------------+---------------+---------------+
>    |                    RESERVED                   |  ADN Length   |
>    +-----------------------------------------------+---------------+
>    ~                  Authentication Domain Name                   ~
>    +---------------------------------------------------------------+
>    ~              List of Hash Algorithm Identifiers               ~
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
>      Figure 3: ENCDNS_DIGEST_INFO Attribute Format for CFG_REQUEST
> 
>                         1                   2                   3
>     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>    +-+-----------------------------+-------------------------------+
>    |R|         Attribute Type      |            Length             |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
>      Figure 4: ENCDNS_DIGEST_INFO Attribute Format for CFG_ACK.
> 
> and then explain the Hash Algorithm Identifier and List of Hash
> Algorithm Identifiers separately.

We may do this for completeness, but as I've already mentioned
CFG_SET/CFG_ACK are not currently used in IKEv2.
So I'm in not sure if this is really needed and won't further confuse implementers...

> Actually is there any point of having ADN Length and Authenticated
> Domain Name in CFG_REQUESTS ever? Why would someone calculate hashes
> with certain domain names with different hash algorithms? Perhaps we
> should define the format for CFG_REQUEST as follows:
> 
> 
>                         1                   2                   3
>     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>    +-+-----------------------------+-------------------------------+
>    |R|         Attribute Type      |            Length             |
>    +-------------------------------+-------------------------------+
>    ~              List of Hash Algorithm Identifiers               ~
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
>      Figure 3: ENCDNS_DIGEST_INFO Attribute Format for CFG_REQUEST

I'm confused, since CFG_REQUEST doesn't include Digest.
Am I missing your point?

> --
> 
> In section 4 there is text:
> 
>    If the CFG_REPLY includes an ENCDNS_DIGEST_INFO attribute, the DNS
>    client has to create a digest of the DNS resolver certificate
>    received in the TLS handshake using the negotiated hash algorithm in
>    the ENCDNS_DIGEST_INFO attribute.
> 
> But this does not specify how the digest of the DNS resolver
> certificate is calculated. There are multiple ways of doing this (only
> Subject Public Key Info element like RFC7296 or SPKI(1) selector field
> of RFC7671, or full certificate like Cert(0) selector field of
> RFC7671).
> 
> I would prefer the SPKI (Subject Public Key Info) selector field way
> of RFC7671, as then it does not matter if the certificate is renewed
> etc.

Does certificate renewal matter in this case?

In my reading "digest of the certificate" means the digest over whole certificate
(Cert(0)), but I'd rather hear from my co-authors.

> --
> 
> I do not think the [Hash] is normative reference. I did not need to
> read and understand that to somewhat understand this document :-)

Well, it's only 58 words including title, you may read them in few seconds :-)
Kidding aside, how this can be informative? The document uses these codepoints.

Or did you mean [I-D.ietf-dnsop-svcb-https]?

> --
> 
> IANA-IKE is bit misleading reference name when you are actually
> refering to the IKEv2 Configuration Payload Attribute Types. Perhaps
> using IANA-IKE-HASH for the [Hash] above, and IANA-IKE-CFG for this.

OK.

> --
> 
> It would actually be useful to have example configuration for some of
> the deployment scenarios in Appendix A, similar than in 3.15.2 of
> RFC7296.
> 
> i.e.,
> 
>   CP(CFG_REQUEST) =
>     INTERNAL_IP6_ADDRESS()
>     INTERNAL_IP6_DNS()
>     ENCDNS_IP6()
>     ENCDNS_DIGEST_INFO(0, "", (SHA2-256, SHA2-384, SHA2-512))
> 
> and getting reply
> 
>   CP(CFG_REPLY) =
>     INTERNAL_IP6_ADDRESS(2001:DB8:0:1:2:3:4:5/64)
>     ENCDNS_IP6(23, 1, 16,
>                (2001:DB8:99:88:77:66:55:44),
>     	       "doh1.example.com",
> 	       "???")
>     ENCDNS_DIGEST_INFO(0, "", SHA2-256,
>                        00112233445566778899aabbccddeeff)
> 
> where the data in ECNDNS_IP6 is in the same order they are in the
> actual packet, i.e., 23 is the Service Priority, 1 is num address, 16
> is ADN Length and then is list of IPv6 addresses and so on.
> 
> I for example have no idea what could be in the Service Parameters
> field for some specific service (for example DoH), and how it would be
> different for DoT...

Adding an example makes sense, IMHO.

Regards,
Valery.

> --
> kivinen@iki.fi
> 
> _______________________________________________
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec