Re: [IPsec] Éric Vyncke's No Objection on draft-ietf-ipsecme-ikev2-auth-announce-09: (with COMMENT)

Valery Smyslov <svan@elvis.ru> Mon, 15 April 2024 07:43 UTC

Return-Path: <svan@elvis.ru>
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 1FFA5C14F6FD; Mon, 15 Apr 2024 00:43:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.095
X-Spam-Level:
X-Spam-Status: No, score=-2.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, HTML_MESSAGE=0.001, 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 (1024-bit key) header.d=elvis.ru
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 LvBQb6PiikLH; Mon, 15 Apr 2024 00:43:41 -0700 (PDT)
Received: from dpmail.elvis.ru (dpmail.elvis.ru [93.188.44.211]) (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 83A90C14F68D; Mon, 15 Apr 2024 00:43:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=elvis.ru; s=mail; h=Content-Type:MIME-Version:Message-ID:Date:Subject:In-Reply-To: References:CC:To:From:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=VjoVQ7LAnukdj12BOew9zOehCkavANpOgw4pPpAW3ak=; b=i8AMeEFJoatp56GmxFqZQT+hHw pEOsg6jM4oRvYoINv7EPvaK6D+xtDNasLr3ueJPLQeUsaziDNxh/u4VSQhjn27krqSkqF0NZie4lT kyTC/akddRQW2G1MQajLElY335whSiQd54Ug3iUkGoq0kUIoxrcsx2usHgKZjFNXP3ng=;
Received: from kmail2.elvis.ru ([93.188.44.210]) by dpmail.elvis.ru with esmtp (Exim 4.89) (envelope-from <svan@elvis.ru>) id 1rwGzs-0007qV-I5; Mon, 15 Apr 2024 10:43:24 +0300
Received: from mail.office.elvis.ru ([10.111.1.29]) by kmail2.elvis.ru with esmtp (Exim 4.94.2) (envelope-from <svan@elvis.ru>) id 1rwGzs-00Dpzz-9F; Mon, 15 Apr 2024 10:43:24 +0300
Received: from MAIL16.office.elvis.ru (10.111.1.29) by MAIL16.office.elvis.ru (10.111.1.29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1779.2; Mon, 15 Apr 2024 10:43:24 +0300
Received: from BuildPC (10.111.10.33) by MAIL16.office.elvis.ru (10.111.1.29) with Microsoft SMTP Server id 15.1.1779.2 via Frontend Transport; Mon, 15 Apr 2024 10:43:24 +0300
From: Valery Smyslov <svan@elvis.ru>
To: "'Eric Vyncke (evyncke)'" <evyncke@cisco.com>, 'The IESG' <iesg@ietf.org>
CC: draft-ietf-ipsecme-ikev2-auth-announce@ietf.org, ipsecme-chairs@ietf.org, ipsec@ietf.org, kivinen@iki.fi
References: <171282942898.60208.16082104712999966299@ietfa.amsl.com> <039901da8c13$72cb6310$58622930$@elvis.ru> <PH0PR11MB49665734085725294196F6BAA9052@PH0PR11MB4966.namprd11.prod.outlook.com> <043701da8cac$a5ec20b0$f1c46210$@elvis.ru> <PH0PR11MB49663F83A9F2D4C0E381C7B0A9042@PH0PR11MB4966.namprd11.prod.outlook.com>
In-Reply-To: <PH0PR11MB49663F83A9F2D4C0E381C7B0A9042@PH0PR11MB4966.namprd11.prod.outlook.com>
Date: Mon, 15 Apr 2024 10:43:24 +0300
Message-ID: <051201da8f08$9876be00$c9643a00$@elvis.ru>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0513_01DA8F21.BDC3F600"
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQKQ/B+n20FMeIdPXc9TaztnjeCv8AI++YmHATuB8K4Cx/PgwAIDahubr7npF+A=
Content-Language: ru
X-CrossPremisesHeadersFilteredBySendConnector: MAIL16.office.elvis.ru
X-OrganizationHeadersPreserved: MAIL16.office.elvis.ru
X-Spam-Scanner: Rspamd work in kmail2.elvis.ru, WHITELIST
X-KLMS-Rule-ID: 1
X-KLMS-Message-Action: clean
X-KLMS-AntiSpam-Status: not scanned, disabled by settings
X-KLMS-AntiPhishing: Clean, bases: 2023/02/21 22:47:00
X-KLMS-AntiVirus: Kaspersky Security for Linux Mail Server, version 8.0.3.30, bases: 2023/02/21 21:02:00 #20887462
X-KLMS-AntiVirus-Status: Clean, skipped
X-Spam-Scanner: Rspamd work in dpmail.elvis.ru, WHITELIST
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/w58ziDD4T1KEX8SFcX9ejHtoBOE>
Subject: Re: [IPsec] Éric Vyncke's No Objection on draft-ietf-ipsecme-ikev2-auth-announce-09: (with COMMENT)
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: Mon, 15 Apr 2024 07:43:46 -0000

Hi Éric,

 

please see inline (I removed parts of the message where we are in
agreement).

 

Thank you, Valery, for your 2nd reply and for allowing me to reply w/o
on-line access to the I-D when I replied.

 

One last comment below as EVY2>

 

All comments were non-blocking anyway :)

 

-éric

 

[…]

> ## Section 3.1
> 
> `Regardless of whether the notification is received,` may be I am
mis-reading
> this, but why would the responder send the notification if the initiator
does
> not care anyway ?

The responder doesn't know if the initiator cares or not.
There is no negotiation of this feature, each party just makes its mind 
whether to send and whether to process this notification (if it is ever
supported). 

EVY> sure it will work like described in the I-D, but I find it really weird
that the initiator does not send its own list.

         In fact it does, but it sends this after the responder, in the
following exchange. So, the responder sends its list first.
         This is to have the announcements and the list of trust anchors (in
the CERTREQ payload) co-located in the same message.

 

EVY2> then this may be useful to write the above justification in the
document itself.

       I’ve added the following text in the Section 3:

To simplify
  the receiver's task of linking the announced authentication methods
  with the trust anchors, the protocol ensures that the
  SUPPORTED_AUTH_METHODS notification is always co-located with the
  CERTREQ payload in the same message.

       Does it help?

       Regards,
       Valery.


[…]