From nobody Tue May 4 02:13:35 2021 Return-Path: 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 9A85A3A2C76 for ; Tue, 4 May 2021 02:13:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 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, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iki.fi 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 xcmRRo3k7dkp for ; Tue, 4 May 2021 02:13:30 -0700 (PDT) Received: from lahtoruutu.iki.fi (lahtoruutu.iki.fi [185.185.170.37]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 175CB3A2C72 for ; Tue, 4 May 2021 02:13:30 -0700 (PDT) Received: from fireball.acr.fi (fireball.acr.fi [83.145.195.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: kivinen) by lahtoruutu.iki.fi (Postfix) with ESMTPSA id 558F01B00E2C; Tue, 4 May 2021 12:13:26 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=lahtoruutu; t=1620119606; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=2CURUEmNxrqD35lczAZZx3hT/Ce057Kn8DcGrPOlP+I=; b=hiuftrGzp4M7J6ACTzOOAutu7eG+RvhLv5/z/FAcP3wfB/7zQDVG8b5fdaXcwTdu25zreC +6OAHc5/kH1NrYww94iKx1oFK9o0kFLMz48XKRK9gYEPPb7ao7kNgXDA7AWHZC7C5ki/ZV W2QM3tAQJSLGSnawG4CnhrDp7KblV8binDerIgO0DBjw3yfWGAJNGWRQGwXwOSoxDfx7t7 +InUy0O++fuQQfNDiGQMg11i0nUULWSWv/Rb2qdN8j8Pv44N+IK9c3Kj0CZQx+ULKO9pjS NxYR/EiMnrxq/V1UF0oZMhwinHe/hAWvxYVoQM7kFOcxNjztLK4bKvDU3gRdPA== Received: by fireball.acr.fi (Postfix, from userid 15204) id F2DED25C12AE; Tue, 4 May 2021 12:13:25 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <24721.4149.949821.591196@fireball.acr.fi> Date: Tue, 4 May 2021 12:13:25 +0300 From: Tero Kivinen To: Christian Hopps Cc: ipsec@ietf.org In-Reply-To: <9A890539-3999-4760-B029-C5628FFBD385@chopps.org> References: <24712.7198.905751.897464@fireball.acr.fi> <24712.20302.263889.288737@fireball.acr.fi> <24716.10525.101692.724097@fireball.acr.fi> <9A890539-3999-4760-B029-C5628FFBD385@chopps.org> X-Mailer: VM 8.2.0b under 26.3 (x86_64--netbsd) X-Edit-Time: 18 min X-Total-Time: 20 min ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=lahtoruutu; t=1620119606; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=2CURUEmNxrqD35lczAZZx3hT/Ce057Kn8DcGrPOlP+I=; b=BBTwF+BjhEurQsOuLqHC+uRKKMVQIYwjhHEpzq5AnU38Ur2M8hI8teoClyVpOmzpv/7cE8 I2qFLG02G5lP9wIMrTbhBX0uD+EfEdAJz+yes3J7ZsVYyGVonoucZDshH4RgN33r/hnvG1 u8uXU8YjLtRMxJoo/lme5kOq27tFYoHMmrGXyBMGQaxfGfUEeemFhZ90sir/3P24yngYqV +U7yd3dvg1FaWZWiHh+E6LE9HMJYf2qNNN0w4XMKoW25TP/iE+CK0Y27UB58bIZE2rGwQH PlwwG3OYHb0VKXyAaApATY/Hrgl1rv8g4KpElHh7VsqrYhHy+WYAcEz2ERlGlg== ARC-Authentication-Results: i=1; ORIGINATING; auth=pass smtp.auth=kivinen smtp.mailfrom=kivinen@iki.fi ARC-Seal: i=1; s=lahtoruutu; d=iki.fi; t=1620119606; a=rsa-sha256; cv=none; b=DA/1jBKd8U88yoHTGxtbb92nNVOCMTIBMPEDTDwawFSI0q3E6J/n6JC7NVfHNTxhiuUiX4 vvHOXXUh2OhxsygxAfQeUzwBrSLEA/Qy0kWQe2cHqiVq3nbIIXPNuwxl3aDNEcyOqFd5gX anktbgpFJOq1kcBkcPJ1a5VAva5yJ/yIkNoJBS1t1rnfW5qb5xCRhE65YKHpgVX1+181tN rYhUMAL4+cSriGTEV48j9bE73L4ou0JXfLI0BpfMePQ4RsoJ5lJvw5wuUTD6BodHzyRbwU +GVdMAJCgc+h+2yJ4+15X2aaz7NvtWoF7KO9rVLkoww8aUqm+7K170QXZdPoWA== Archived-At: Subject: Re: [IPsec] Question about the draft-ietf-ipsecme-iptfs X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 May 2021 09:13:34 -0000 Christian Hopps writes: > The replay window does not need to be the same size as the reorder > window. But effectively it is same as there is no use of having them different. If my reorder window is set to 2, and my replay window is set to 1000, if there is any reorderining happening then even when replay window allow packets 1, 5, 2 to be processed in that order, the reorder window will drop packet 2 as it is outside the reorder window, thus effectively replay window was also set to 2... This is already explained in the draft: When using the AGGFRAG_PAYLOAD in conjunction with replay detection, the window size for both can be reduced to the smaller of the two window sizes. This is because packets outside of the smaller window but inside the larger would still be dropped by the mechanism with the smaller window size. So why does the section 2.5 require in-order processing of the payloads stream to extract the inner-packets? This is not a requirement for the regular IPsec, in regular IPsec it is valid to process packets out-of-order provided they fit in the replay window, but the last paragraph of the 2.5 do say that "the receiver processes the now in-order AGGFRAG_PAYLOAD payload stream to extract the inner-packets", which for me indicates that receiver cannot process packets until it is sure they are in-order, thus it must wait until it knows that missing packet is really lost, not just reordered. This is even explictly said in case the congestion control is enabled when the draft says that: If congestion control is enabled, the receiver considers a packet lost when it's sequence number is abandoned (e.g., pushed out of the re-ordering window, or timed-out) by the reordering algorithm. And I think we should explictly say that it is allowed to process complete inner frames inside the one outer packet even when the outer frame do have frames which are still missing data. I.e. in Appendix A, if the ESP1 is lost, I would expect that recevier is allowed to process ESP2 and forward those 60 and 240 octet packets out even when ESP1 is missing and the first 100 octets in cannot be processed. Also I would propose that receiver is allowed to process those two full packets in ESP2 immediately when ESP2 is received, and not be forced to wait until ESP1 drops out of reorder window before it deems the ESP1 lost, and only after then start processing ESP2, 3, and so on. If you insist on requiring reordering packets always and in-order processing and delivery, then extra text is needed to explain that this is new service that is offered only by this, and not by normal IPsec, and that this causes frames to be delayed by the reorder window length every time there is any packet losses. -- kivinen@iki.fi From nobody Tue May 4 05:44:40 2021 Return-Path: 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 AD02D3A32E4 for ; Tue, 4 May 2021 05:44:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham 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 ZNQenZQg8VUi for ; Tue, 4 May 2021 05:44:34 -0700 (PDT) Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id 4E1CC3A32E1 for ; Tue, 4 May 2021 05:44:34 -0700 (PDT) Received: from ja.int.chopps.org.chopps.org (047-026-251-217.res.spectrum.com [47.26.251.217]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPSA id 9183E803FB; Tue, 4 May 2021 12:44:33 +0000 (UTC) References: <24712.7198.905751.897464@fireball.acr.fi> <24712.20302.263889.288737@fireball.acr.fi> <24716.10525.101692.724097@fireball.acr.fi> <9A890539-3999-4760-B029-C5628FFBD385@chopps.org> <24721.4149.949821.591196@fireball.acr.fi> User-agent: mu4e 1.5.13; emacs 27.2 From: Christian Hopps To: Tero Kivinen Cc: Christian Hopps , ipsec@ietf.org Date: Tue, 04 May 2021 08:37:08 -0400 In-reply-to: <24721.4149.949821.591196@fireball.acr.fi> Message-ID: MIME-Version: 1.0 Content-Type: text/plain; format=flowed Archived-At: Subject: Re: [IPsec] Question about the draft-ietf-ipsecme-iptfs X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 May 2021 12:44:38 -0000 I feel like this is going in circles. If you have a slow link, which is what you were highlighting, you set your re-order window to 0 -- you don't need to guard against reordering. If you still want to detect replay attacks though, you leave your replay window at some large number. The replay window is trying to detect replay attacks, not handle re-order packets. This has nothing to do with packet acceptance at this point, as that job was taken over by the reorder window. They will both do their jobs correctly. I initial objected to the request for adding that text you quote b/c these things are different and I didn't see the value in conflating them just to provide for "advice" for some scenarios. If anything we should remove that section if it's causing you concerns now. Thanks, Chris. Tero Kivinen writes: > Christian Hopps writes: >> The replay window does not need to be the same size as the reorder >> window. > > But effectively it is same as there is no use of having them > different. > > If my reorder window is set to 2, and my replay window is set to 1000, > if there is any reorderining happening then even when replay window > allow packets 1, 5, 2 to be processed in that order, the reorder > window will drop packet 2 as it is outside the reorder window, thus > effectively replay window was also set to 2... > > This is already explained in the draft: > > When using the AGGFRAG_PAYLOAD in conjunction with replay detection, > the window size for both can be reduced to the smaller of the two > window sizes. This is because packets outside of the smaller window > but inside the larger would still be dropped by the mechanism with > the smaller window size. > > So why does the section 2.5 require in-order processing of the > payloads stream to extract the inner-packets? This is not a > requirement for the regular IPsec, in regular IPsec it is valid to > process packets out-of-order provided they fit in the replay window, > but the last paragraph of the 2.5 do say that "the receiver processes > the now in-order AGGFRAG_PAYLOAD payload stream to extract the > inner-packets", which for me indicates that receiver cannot process > packets until it is sure they are in-order, thus it must wait until it > knows that missing packet is really lost, not just reordered. > > This is even explictly said in case the congestion control is enabled > when the draft says that: > > If congestion control is enabled, the receiver > considers a packet lost when it's sequence number is abandoned (e.g., > pushed out of the re-ordering window, or timed-out) by the reordering > algorithm. > > And I think we should explictly say that it is allowed to process > complete inner frames inside the one outer packet even when the outer > frame do have frames which are still missing data. I.e. in Appendix A, > if the ESP1 is lost, I would expect that recevier is allowed to > process ESP2 and forward those 60 and 240 octet packets out even when > ESP1 is missing and the first 100 octets in cannot be processed. > > Also I would propose that receiver is allowed to process those two > full packets in ESP2 immediately when ESP2 is received, and not be > forced to wait until ESP1 drops out of reorder window before it deems > the ESP1 lost, and only after then start processing ESP2, 3, and so > on. > > If you insist on requiring reordering packets always and in-order > processing and delivery, then extra text is needed to explain that > this is new service that is offered only by this, and not by normal > IPsec, and that this causes frames to be delayed by the reorder window > length every time there is any packet losses. From nobody Tue May 4 18:28:37 2021 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B94AC3A1DCE; Tue, 4 May 2021 18:28:35 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: ipsec@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.28.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: ipsec@ietf.org Message-ID: <162017811563.5901.16868724807040240081@ietfa.amsl.com> Date: Tue, 04 May 2021 18:28:35 -0700 Archived-At: Subject: [IPsec] I-D Action: draft-ietf-ipsecme-labeled-ipsec-05.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 May 2021 01:28:36 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Maintenance and Extensions WG of the IETF. Title : Labeled IPsec Traffic Selector support for IKEv2 Authors : Paul Wouters Sahana Prasad Filename : draft-ietf-ipsecme-labeled-ipsec-05.txt Pages : 10 Date : 2021-05-04 Abstract: This document defines a new Traffic Selector (TS) Type for Internet Key Exchange version 2 to add support for negotiating Mandatory Access Control (MAC) security labels as a traffic selector of the Security Policy Database (SPD). Security Labels for IPsec are also known as "Labeled IPsec". The new TS type is TS_SECLABEL, which consists of a variable length opaque field specifying the security label. This document updates the IKEv2 TS negotiation specified in RFC 7296 Section 2.9. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-labeled-ipsec/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ipsecme-labeled-ipsec-05 https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-labeled-ipsec-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-labeled-ipsec-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue May 4 18:30:57 2021 Return-Path: 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 ADFD13A1DEA for ; Tue, 4 May 2021 18:30:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca 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 2hm0SvzY0JMe for ; Tue, 4 May 2021 18:30:51 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (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 2E1E13A1DE7 for ; Tue, 4 May 2021 18:30:51 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 4FZfL046xNzF4Y; Wed, 5 May 2021 03:30:48 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1620178248; bh=HVi5EwSof/O7Yf35+RCnTqjBN9EBKnjziZgrFrBYvbw=; h=Date:From:To:Subject:In-Reply-To:References; b=iGHOjrJbACIEEn8uauJzzVzXECwsZS2naLr+3gPRuJBNNMqkf5NKVJF0FIDxhDC2g RFV88DYCZGxatcWS2TNysn86UVxW9pw66FD7GutgMTWrsBSwHoXIRzC5B3MxDGJd80 xb1k6QYBidNpDgOQlbTwCMhw+yrjqflx5w5LDR90= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id G8qiM-uEDYr1; Wed, 5 May 2021 03:30:46 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [193.110.157.194]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Wed, 5 May 2021 03:30:46 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 715DE4D73F; Tue, 4 May 2021 21:30:45 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 6A3BA4D73E; Tue, 4 May 2021 21:30:45 -0400 (EDT) Date: Tue, 4 May 2021 21:30:45 -0400 (EDT) From: Paul Wouters To: "ipsec@ietf.org WG" In-Reply-To: <162017811563.5901.16868724807040240081@ietfa.amsl.com> Message-ID: References: <162017811563.5901.16868724807040240081@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-labeled-ipsec-05.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 May 2021 01:30:56 -0000 On Tue, 4 May 2021, internet-drafts@ietf.org wrote: > Subject: [IPsec] I-D Action: draft-ietf-ipsecme-labeled-ipsec-05.txt > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-labeled-ipsec-05 No major changes. Mostly a bump to prevent expiration. Updated affiliation, fixed a reference and updated the implementation section. Still looking for another implementation for interop testing. Paul & Sahana From nobody Wed May 5 20:08:45 2021 Return-Path: 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 800453A2D16 for ; Wed, 5 May 2021 20:08:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 R4AFkKiDJ6ox for ; Wed, 5 May 2021 20:08:39 -0700 (PDT) Received: from www.goatley.com (www.goatley.com [198.137.202.94]) (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 5595E3A2D13 for ; Wed, 5 May 2021 20:08:38 -0700 (PDT) Received: from trixy.bergandi.net (cpe-76-176-14-122.san.res.rr.com [76.176.14.122]) by wwwlocal.goatley.com (PMDF V6.8 #2433) with ESMTP id <0QSO05T3P0QEOT@wwwlocal.goatley.com> for ipsec@ietf.org; Wed, 05 May 2021 22:08:38 -0500 (CDT) Received: from blockhead.local ([69.12.173.8]) by trixy.bergandi.net (PMDF V6.7-x01 #2433) with ESMTPSA id <0QSO00HIR0MMIV@trixy.bergandi.net> for ipsec@ietf.org; Wed, 05 May 2021 20:06:23 -0700 (PDT) Received: from 69-12-173-8.static.dsltransport.net ([69.12.173.8] EXTERNAL) (EHLO blockhead.local) with TLS/SSL by trixy.bergandi.net ([10.0.42.18]) (PreciseMail V3.3); Wed, 05 May 2021 20:06:23 -0700 Date: Wed, 05 May 2021 20:08:35 -0700 From: Dan Harkins In-reply-to: <40493aa4-ba3a-ad32-fda2-f5ab24d78296@nohats.ca> To: Paul Wouters , ipsec@ietf.org Message-id: <6297c870-0507-b3e8-ee6e-5517bdc86bba@lounge.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8; format=flowed Content-language: en-US Content-transfer-encoding: 8BIT User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.7.1 X-PMAS-SPF: SPF check skipped for authenticated session (recv=trixy.bergandi.net, send-ip=69.12.173.8) X-PMAS-External-Auth: 69-12-173-8.static.dsltransport.net [69.12.173.8] (EHLO blockhead.local) References: <161962448020.12575.13131318934919776038@ietfa.amsl.com> <40493aa4-ba3a-ad32-fda2-f5ab24d78296@nohats.ca> X-PMAS-Software: PreciseMail V3.3 [210504a] (trixy.bergandi.net) X-PMAS-Allowed: system rule (rule allow header:X-PMAS-External noexists) Archived-At: Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-ikev1-algo-to-historic-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 May 2021 03:08:44 -0000   Paul,   Thanks for doing this. A few comments:   - the first two bullet points in section 3 are basically speculation,     "a number of..." is meaningless. These bullet points are ultimately     not even necessary to make the case being made. Delete these, please.   - fourth bullet in section 3 should be rewritten. The "Often, IKEv1..."     sentence should be removed but the remainder is a decent point. IKEv1     was standardized before modern ciphers were designed, to get support     for modern, accepted ciphers use IKEv2.   - there is another IKEv1 feature not available in IKEv2: a deniable     authentication method. IKEv1 had a very cool deniable exchange     involving encrypted nonces. IKEv2 decided to not support that for     whatever reason. Lack of support for a cool and usefu authentication     method doesn't really make the case to send IKEv1 to historic, but     then, oh well. As an aside, I suggested a way to add an exchange     such an exchange using HPKE [1]. Not that I'm saying this needs to     be added to IKEv2, but if you're gonna talk about IKEv1 features     missing in IKEv2 you should be complete. Other than that, good work.   regards,   Dan. [1] https://mailarchive.ietf.org/arch/msg/cfrg/zjQLxV2u1wUZMFraDuy6KRPIaqU/ On 4/28/21 8:48 AM, Paul Wouters wrote: > On Wed, 28 Apr 2021, internet-drafts@ietf.org wrote: > >> Subject: [IPsec] I-D Action: >> draft-ietf-ipsecme-ikev1-algo-to-historic-00.txt > > Looks like the datatracker email does not post the diff between > different document names :P > > The diff is: > > https://tools.ietf.org/rfcdiff?url1=draft-pwouters-ikev1-ipsec-graveyard-06.txt&url2=https://www.ietf.org/archive/id/draft-ietf-ipsecme-ikev1-algo-to-historic-00.txt > > > Basically, it removes the IANA request to close the IKEv1 registries, > changes draft name / title to avoid "graveyard" and lists some items > as bullet points and sections, and changes some subjective wording to > more objective language. > > I'm not saying this is ready for WGLC, but .... > > Paul > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec -- "The object of life is not to be on the side of the majority, but to escape finding oneself in the ranks of the insane." -- Marcus Aurelius From nobody Wed May 5 20:15:27 2021 Return-Path: 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 A19193A2D61 for ; Wed, 5 May 2021 20:15:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 deZ5Sdg39zIh for ; Wed, 5 May 2021 20:15:21 -0700 (PDT) Received: from www.goatley.com (www.goatley.com [198.137.202.94]) (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 768C73A2D5F for ; Wed, 5 May 2021 20:15:21 -0700 (PDT) Received: from trixy.bergandi.net (cpe-76-176-14-122.san.res.rr.com [76.176.14.122]) by wwwlocal.goatley.com (PMDF V6.8 #2433) with ESMTP id <0QSO05T3S11LOQ@wwwlocal.goatley.com> for ipsec@ietf.org; Wed, 05 May 2021 22:15:21 -0500 (CDT) Received: from blockhead.local ([69.12.173.8]) by trixy.bergandi.net (PMDF V6.7-x01 #2433) with ESMTPSA id <0QSO00C3T0XU5M@trixy.bergandi.net> for ipsec@ietf.org; Wed, 05 May 2021 20:13:06 -0700 (PDT) Received: from 69-12-173-8.static.dsltransport.net ([69.12.173.8] EXTERNAL) (EHLO blockhead.local) with TLS/SSL by trixy.bergandi.net ([10.0.42.18]) (PreciseMail V3.3); Wed, 05 May 2021 20:13:06 -0700 Date: Wed, 05 May 2021 20:15:20 -0700 From: Dan Harkins In-reply-to: <0QSO06S080QG56@wwwlocal.goatley.com> To: ipsec@ietf.org Message-id: <7fb2c199-934f-305b-eda6-07e491076389@lounge.org> MIME-version: 1.0 Content-type: text/plain; charset=windows-1252; format=flowed Content-language: en-US Content-transfer-encoding: 8BIT User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.7.1 X-PMAS-SPF: SPF check skipped for authenticated session (recv=trixy.bergandi.net, send-ip=69.12.173.8) X-PMAS-External-Auth: 69-12-173-8.static.dsltransport.net [69.12.173.8] (EHLO blockhead.local) References: <0QSO06S080QG56@wwwlocal.goatley.com> X-PMAS-Software: PreciseMail V3.3 [210504a] (trixy.bergandi.net) X-PMAS-Allowed: system rule (rule allow header:X-PMAS-External noexists) Archived-At: Subject: [IPsec] mailer childishness... Re: Delivery Notification: Delivery has failed X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 May 2021 03:15:27 -0000 OK, this is ridiculous. "non-inclusive behaviour"? Bullying? Gimme a break. If the editor of a draft in an IETF WG blocks legitimate email concerning the draft then perhaps the editor of the draft shouldn't be editor of the draft anymore. I'll volunteer to take over this draft. I don't block anyone and will tolerate all sorts of inclusive or non-inclusive behavior. Dan. On 5/5/21 8:08 PM, PMDF Internet Messaging wrote: > This report relates to a message you sent with the following header fields: > > Message-id: <6297c870-0507-b3e8-ee6e-5517bdc86bba@lounge.org> > Date: Wed, 05 May 2021 20:08:35 -0700 > From: Dan Harkins > To: Paul Wouters , ipsec@ietf.org > Subject: Re: [IPsec] I-D Action: > draft-ietf-ipsecme-ikev1-algo-to-historic-00.txt > > Your message cannot be delivered to the following recipients: > > Recipient address: paul@nohats.ca > Reason: Remote SMTP server has rejected address > Diagnostic code: smtp;550 5.7.1 : Sender address rejected: Refusing email from Dan Harkins for repeated bullying and non-inclusive behaviour > Remote system: dns;mx.nohats.ca (TCP|198.137.202.94|47303|193.110.157.68|25) (mx.nohats.ca ESMTP Postfix) > -- "The object of life is not to be on the side of the majority, but to escape finding oneself in the ranks of the insane." -- Marcus Aurelius From nobody Wed May 5 21:25:41 2021 Return-Path: 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 3FBA33A00D3 for ; Wed, 5 May 2021 21:25:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca 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 RS1ij55n7U2Q for ; Wed, 5 May 2021 21:25:34 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (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 3B6ED3A00C4 for ; Wed, 5 May 2021 21:25:34 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 4FbL925Tjmz3Dj for ; Thu, 6 May 2021 06:25:26 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1620275126; bh=+2oJ7vDnMA6i+nGyMbztbshFPMx8elM1I8T0ywmEnFo=; h=Date:From:To:Subject; b=HR78JiFjGFQbmiG4ky+nPc2egdboBB/+kNt2W7YM6Mk9QmuU1Xbpbh/09UjfMKGWH cg9AYeTTZndN3RDkUxaGT7ixhPrp2T/MCKMTzt2mR030HRknVugWMg6Rj64j7EmNLq pzb5i3fSjCGZCekYCh+vRU46FpahQS/kGjhPEMmY= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id wB46h5to33Li for ; Thu, 6 May 2021 06:25:25 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [193.110.157.194]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS for ; Thu, 6 May 2021 06:25:25 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id AED1B5016F; Thu, 6 May 2021 00:25:23 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id AB0B25016E for ; Thu, 6 May 2021 00:25:23 -0400 (EDT) Date: Thu, 6 May 2021 00:25:23 -0400 (EDT) From: Paul Wouters To: "ipsec@ietf.org WG" Message-ID: <2096e599-55ac-fa3c-b9a8-67f94c44b89e@nohats.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT Archived-At: Subject: Re: [IPsec] mailer childishness... Re: Delivery Notification: Delivery has failed X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 May 2021 04:25:39 -0000 On May 5, 2021, at 23:15, Dan Harkins wrote: > >  > OK, this is ridiculous. "non-inclusive behaviour"? Bullying? Gimme > a break. I actually tried giving you a break last time you brought this up, but literally days laters you repeated the same behaviour again. Actions have consequences, so I exercised my right to not have to listen to your personal emails to me. > If the editor of a draft in an IETF WG blocks legitimate email > concerning the draft then perhaps the editor of the draft shouldn't > be editor of the draft anymore. I have no problem responding to emails on this list, even sent by you. They are not blocked and we can have IPsec related conversations in public. > I'll volunteer to take over this draft. I don't block anyone and > will tolerate all sorts of inclusive or non-inclusive behavior. As someone who added a mocking Human Rights Considerations section to promote the right to bear arms in RFC 8492 and as someone who used a “Lester White” persona to publish a draft mocking (and targetting) a number of vulnerable groups of people, while throwing in a personal attacks on me and ekr under the guise of “sarcasm is freedom of speech”, I would urge the chairs to pick another alternative author, if they deem one is necessary. I will process your on-topic comments to the draft in a separate email, and if needed rev the document to address the issues and we can discuss that further on this email list. I will not further comment on your opinion about my personal email server configuration, because that is out of scope for this list, AND because it is still my desire and right not to talk or listen to you about anything other than IETF work covered by the Note Well and IETF anti-harassment policy. Paul > .On 5/5/21 8:08 PM, PMDF Internet Messaging wrote: >> This report relates to a message you sent with the following header fields: >> Message-id: <6297c870-0507-b3e8-ee6e-5517bdc86bba@lounge.org> >> Date: Wed, 05 May 2021 20:08:35 -0700 >> From: Dan Harkins >> To: Paul Wouters , ipsec@ietf.org >> Subject: Re: [IPsec] I-D Action: >> draft-ietf-ipsecme-ikev1-algo-to-historic-00.txt >> Your message cannot be delivered to the following recipients: >> Recipient address: paul@nohats.ca >> Reason: Remote SMTP server has rejected address >> Diagnostic code: smtp;550 5.7.1 : Sender address rejected: Refusing email from Dan Harkins for repeated bullying and non-inclusive behaviour >> Remote system: dns;mx.nohats.ca (TCP|198.137.202.94|47303|193.110.157.68|25) (mx.nohats.ca ESMTP Postfix) > -- > "The object of life is not to be on the side of the majority, but to > escape finding oneself in the ranks of the insane." -- Marcus Aurelius > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Wed May 5 22:51:15 2021 Return-Path: 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 1AD033A0E50 for ; Wed, 5 May 2021 22:51:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 HYYHhzp9wESi for ; Wed, 5 May 2021 22:51:08 -0700 (PDT) Received: from www.goatley.com (www.goatley.com [198.137.202.94]) (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 810BB3A0E4F for ; Wed, 5 May 2021 22:51:08 -0700 (PDT) Received: from trixy.bergandi.net (cpe-76-176-14-122.san.res.rr.com [76.176.14.122]) by wwwlocal.goatley.com (PMDF V6.8 #2433) with ESMTP id <0QSO05T50897OT@wwwlocal.goatley.com> for ipsec@ietf.org; Thu, 06 May 2021 00:51:08 -0500 (CDT) Received: from blockhead.local ([69.12.173.8]) by trixy.bergandi.net (PMDF V6.7-x01 #2433) with ESMTPSA id <0QSO00J2T85FXN@trixy.bergandi.net> for ipsec@ietf.org; Wed, 05 May 2021 22:48:52 -0700 (PDT) Received: from 69-12-173-8.static.dsltransport.net ([69.12.173.8] EXTERNAL) (EHLO blockhead.local) with TLS/SSL by trixy.bergandi.net ([10.0.42.18]) (PreciseMail V3.3); Wed, 05 May 2021 22:48:52 -0700 Date: Wed, 05 May 2021 22:51:05 -0700 From: Dan Harkins In-reply-to: <2096e599-55ac-fa3c-b9a8-67f94c44b89e@nohats.ca> To: ipsec@ietf.org Message-id: MIME-version: 1.0 Content-type: text/plain; charset=utf-8; format=flowed Content-language: en-US Content-transfer-encoding: 8BIT User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.7.1 X-PMAS-SPF: SPF check skipped for authenticated session (recv=trixy.bergandi.net, send-ip=69.12.173.8) X-PMAS-External-Auth: 69-12-173-8.static.dsltransport.net [69.12.173.8] (EHLO blockhead.local) References: <2096e599-55ac-fa3c-b9a8-67f94c44b89e@nohats.ca> X-PMAS-Software: PreciseMail V3.3 [210504a] (trixy.bergandi.net) X-PMAS-Allowed: system rule (rule allow header:X-PMAS-External noexists) Archived-At: Subject: Re: [IPsec] mailer childishness... Re: Delivery Notification: Delivery has failed X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 May 2021 05:51:13 -0000   WRONG! You got exactly ZERO emails since your last hissy fit yet you went out of your way to send me one accusing me of bullying you. Your passive-aggressive attacks are getting ridiculous and really tiring.   Oh, and cryptography is deemed an armament by your own government. So maybe petition your PM to stop such "mocking."   Again, I'd be happy to take over this I-D. I'll accept emails from anyone.   Dan. P.S. telling someone they should be "culled" (which means to be slaughtered) is against the IETF's anti-harassment policy. You might want to stop being such a hypocrite. On 5/5/21 9:25 PM, Paul Wouters wrote: > On May 5, 2021, at 23:15, Dan Harkins wrote: >> >>  >>  OK, this is ridiculous. "non-inclusive behaviour"? Bullying? Gimme >> a break. > > I actually tried giving you a break last time you brought this up, > but literally days laters you repeated the same behaviour again. > Actions have consequences, so I exercised my right to not have to listen > to your personal emails to me. > >> If the editor of a draft in an IETF WG blocks legitimate email >> concerning the draft then perhaps the editor of the draft shouldn't >> be editor of the draft anymore. > > I have no problem responding to emails on this list, even sent by you. > They are not blocked and we can have IPsec related conversations in > public. > >> I'll volunteer to take over this draft. I don't block anyone and >> will tolerate all sorts of inclusive or non-inclusive behavior. > > As someone who added a mocking Human Rights Considerations section to > promote the right to bear arms in RFC 8492 and as someone who used a > “Lester White” persona to publish a draft mocking (and targetting) > a number of vulnerable groups of people, while throwing in a personal > attacks on me and ekr under the guise of “sarcasm is freedom of > speech”, I would urge the chairs to pick another alternative author, > if they deem one is necessary. > > I will process your on-topic comments to the draft in a separate email, > and if needed rev the document to address the issues and we can discuss > that further on this email list. > > I will not further comment on your opinion about my personal email > server configuration, because that is out of scope for this list, AND > because it is still my desire and right not to talk or listen to you > about anything other than IETF work covered by the Note Well and IETF > anti-harassment policy. > > Paul > >> .On 5/5/21 8:08 PM, PMDF Internet Messaging wrote: >>> This report relates to a message you sent with the following header >>> fields: >>>  Message-id: <6297c870-0507-b3e8-ee6e-5517bdc86bba@lounge.org> >>>  Date: Wed, 05 May 2021 20:08:35 -0700 >>>  From: Dan Harkins >>>  To: Paul Wouters , ipsec@ietf.org >>>  Subject: Re: [IPsec] I-D Action: >>>   draft-ietf-ipsecme-ikev1-algo-to-historic-00.txt >>> Your message cannot be delivered to the following recipients: >>>  Recipient address: paul@nohats.ca >>>  Reason: Remote SMTP server has rejected address >>>  Diagnostic code: smtp;550 5.7.1 : Sender >>> address rejected: Refusing email from Dan Harkins for repeated >>> bullying and non-inclusive behaviour >>>  Remote system: dns;mx.nohats.ca >>> (TCP|198.137.202.94|47303|193.110.157.68|25) (mx.nohats.ca ESMTP >>> Postfix) >> -- >> "The object of life is not to be on the side of the majority, but to >> escape finding oneself in the ranks of the insane." -- Marcus Aurelius >> >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec -- "The object of life is not to be on the side of the majority, but to escape finding oneself in the ranks of the insane." -- Marcus Aurelius From nobody Thu May 6 12:22:05 2021 Return-Path: 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 56F913A2D9D for ; Thu, 6 May 2021 12:22:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca 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 O9kH8Alwy3l5 for ; Thu, 6 May 2021 12:21:59 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (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 A712E3A2D9A for ; Thu, 6 May 2021 12:21:59 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 4Fbk3S15WPzKHm for ; Thu, 6 May 2021 21:21:56 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1620328916; bh=03nuLH4R+qkFAYgl782vtBqRr+iTiDDk0EER6QZgejM=; h=Date:From:To:Subject:In-Reply-To:References; b=GoPQsO4r+1/PEKbT58lf/ezLiQxsM8bfTOOLeV6vz0rkImR4/3P60O6HI1tUbhC9C RQoIHEGobqw6P8W4QBu9dcNtuvDoBQe56+7t+bJBkrmr51F7BUJ8Z/S+v7VPR3x3w3 hUz/LmkIAB/R60Tk8Z/c80zpBm89oI0ag1dtJkLY= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id zN5LRuWzt6l0 for ; Thu, 6 May 2021 21:21:55 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [193.110.157.194]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS for ; Thu, 6 May 2021 21:21:54 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id B30915173D; Thu, 6 May 2021 15:21:53 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id ABB065173C for ; Thu, 6 May 2021 15:21:53 -0400 (EDT) Date: Thu, 6 May 2021 15:21:53 -0400 (EDT) From: Paul Wouters To: "ipsec@ietf.org WG" In-Reply-To: <6297c870-0507-b3e8-ee6e-5517bdc86bba@lounge.org> Message-ID: <1fcc66b-aca1-6a5-e275-35bd29b3580@nohats.ca> References: <161962448020.12575.13131318934919776038@ietfa.amsl.com> <40493aa4-ba3a-ad32-fda2-f5ab24d78296@nohats.ca> <6297c870-0507-b3e8-ee6e-5517bdc86bba@lounge.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8BIT Archived-At: Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-ikev1-algo-to-historic-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 May 2021 19:22:04 -0000 On Wed, 5 May 2021, Dan Harkins wrote: >   - the first two bullet points in section 3 are basically speculation, >     "a number of..." is meaningless. These bullet points are ultimately >     not even necessary to make the case being made. Delete these, please. I have heard from vendors, so I don't think this is speculation. I think it is important to get these points across. Especially the second bullet point, as people might think IKEv1 is still being supported because their devices are still seeing regular updates, without realizing that the IKEv1 code on those devices in fact will not receive any further updates. >   - fourth bullet in section 3 should be rewritten. The "Often, IKEv1..." >     sentence should be removed but the remainder is a decent point. IKEv1 >     was standardized before modern ciphers were designed, to get support >     for modern, accepted ciphers use IKEv2. How about: OLD: * IKEv1 systems most likely do not support modern cryptographic algorithms. AES-GCM is only defined for ESP and not IKE, and often not implemented for ESP. And CHACHA20_POLY1305 is not defined for IKEv1. Often, IKEv1 is configured with the very weak Diffie-Hellman Groups 2 and 5 and some implementatipons do not support any stronger alternatives. NEW: * The IKEv1 protocol pre-dates modern cryptographic algorithms. While a limited number of more modern cryptographic algorithms were added to the IKEv1 specification, interoperability concerns means that the defacto algorithms deployed for IKEv1, AES-CBC, SHA1, DH2 and DH5, are no longer recommended and a migration to IKEv2 is the best method to deploy modern cryptographic algorithms with the IKE and IPsec protocols. Or if you have an altnerative proposal, I'm happy to hear it. >   - there is another IKEv1 feature not available in IKEv2: a deniable >     authentication method. IKEv1 had a very cool deniable exchange >     involving encrypted nonces. IKEv2 decided to not support that for >     whatever reason. Lack of support for a cool and usefu authentication >     method doesn't really make the case to send IKEv1 to historic Can you clarify this a bit further for me? Is this deniable authentication method part of all IKEv1 auth methods? Or is this a specific feature that needed to be specifically enabled? That said, if the WG deemed this feature no longer required when specifying IKEv2, then I do not think we need to mention this here when we are talking about motivations for people to move from IKEv1 to IKEv2. If there is a good reason and people are prevented from upgrading to IKEv2 because of this, I would be expecting an IKEv2 draft to be developed to address this shortcoming. But it seems to me (I wasn't here when these decisions were made) that the WG did not think this issue was a concern ? >     then, oh well. As an aside, I suggested a way to add an exchange >     such an exchange using HPKE [1]. Not that I'm saying this needs to >     be added to IKEv2, but if you're gonna talk about IKEv1 features >     missing in IKEv2 you should be complete. I was mostly listing the features in IKEv1 that were missing in IKEv2 that actually were motivations for certain people to not upgrade to IKEv2. It is surely not meant as a list of IKEv1 vs IKEv2 features. > Other than that, good work. Thanks. Paul From nobody Thu May 6 17:05:07 2021 Return-Path: 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 949C53A123D for ; Thu, 6 May 2021 17:05:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_PASS=-0.001] autolearn=ham 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 J1Rz5FV-ZsFm for ; Thu, 6 May 2021 17:05:03 -0700 (PDT) Received: from www.goatley.com (www.goatley.com [198.137.202.94]) (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 379C53A123F for ; Thu, 6 May 2021 17:05:03 -0700 (PDT) Received: from trixy.bergandi.net (cpe-76-176-14-122.san.res.rr.com [76.176.14.122]) by wwwlocal.goatley.com (PMDF V6.8 #2433) with ESMTP id <0QSP09K7NMWE0S@wwwlocal.goatley.com> for ipsec@ietf.org; Thu, 06 May 2021 19:05:02 -0500 (CDT) Received: from blockhead.local ([69.12.173.8]) by trixy.bergandi.net (PMDF V6.7-x01 #2433) with ESMTPSA id <0QSP001L2MSIJX@trixy.bergandi.net> for ipsec@ietf.org; Thu, 06 May 2021 17:02:44 -0700 (PDT) Received: from 69-12-173-8.static.dsltransport.net ([69.12.173.8] EXTERNAL) (EHLO blockhead.local) with TLS/SSL by trixy.bergandi.net ([10.0.42.18]) (PreciseMail V3.3); Thu, 06 May 2021 17:02:44 -0700 Date: Thu, 06 May 2021 17:04:59 -0700 From: Dan Harkins In-reply-to: <1fcc66b-aca1-6a5-e275-35bd29b3580@nohats.ca> To: Paul Wouters , "ipsec@ietf.org WG" Message-id: <872b98a9-a6fe-db41-276c-5d0a7e3aa9c5@lounge.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8; format=flowed Content-language: en-US Content-transfer-encoding: 8BIT User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.7.1 X-PMAS-SPF: SPF check skipped for authenticated session (recv=trixy.bergandi.net, send-ip=69.12.173.8) X-PMAS-External-Auth: 69-12-173-8.static.dsltransport.net [69.12.173.8] (EHLO blockhead.local) References: <161962448020.12575.13131318934919776038@ietfa.amsl.com> <40493aa4-ba3a-ad32-fda2-f5ab24d78296@nohats.ca> <6297c870-0507-b3e8-ee6e-5517bdc86bba@lounge.org> <1fcc66b-aca1-6a5-e275-35bd29b3580@nohats.ca> X-PMAS-Software: PreciseMail V3.3 [210506] (trixy.bergandi.net) X-PMAS-Allowed: system rule (rule allow header:X-PMAS-External noexists) Archived-At: Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-ikev1-algo-to-historic-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 May 2021 00:05:06 -0000 On 5/6/21 12:21 PM, Paul Wouters wrote: > On Wed, 5 May 2021, Dan Harkins wrote: > >>   - the first two bullet points in section 3 are basically speculation, >>     "a number of..." is meaningless. These bullet points are ultimately >>     not even necessary to make the case being made. Delete these, >> please. > > I have heard from vendors, so I don't think this is speculation.   I don't doubt that such vendors exist but the wording sounds very speculative, "a number of IKEv1 systems...will never be patched." It begs the question, who? which ones? and I don't think we need to get into specifics like that. > I think it is important to get these points across. Especially the > second bullet point, as people might think IKEv1 is still being > supported because their devices are still seeing regular updates, > without realizing that the IKEv1 code on those devices in fact will > not receive any further updates.   OK, for the second one how about if it's rewritten to say: "* IKEv1 development ceased over a decade ago and no new work will    happen. This poses the risk of unmaintained code in an otherwise    supported product which can result in security vulnerabilities." That way it's not talking about "a number of vendors" but still gets the point across that dead code is not good. >>   - fourth bullet in section 3 should be rewritten. The "Often, >> IKEv1..." >>     sentence should be removed but the remainder is a decent point. >> IKEv1 >>     was standardized before modern ciphers were designed, to get support >>     for modern, accepted ciphers use IKEv2. > > How about: > > OLD: > >   *  IKEv1 systems most likely do not support modern cryptographic >       algorithms.  AES-GCM is only defined for ESP and not IKE, and >       often not implemented for ESP.  And CHACHA20_POLY1305 is not >       defined for IKEv1.  Often, IKEv1 is configured with the very weak >       Diffie-Hellman Groups 2 and 5 and some implementatipons do not >       support any stronger alternatives. > NEW: > >    * The IKEv1 protocol pre-dates modern cryptographic algorithms. While >      a limited number of more modern cryptographic algorithms were added >      to the IKEv1 specification, interoperability concerns means that > the defacto >      algorithms deployed for IKEv1, AES-CBC, SHA1, DH2 and DH5, are no > longer >      recommended and a migration to IKEv2 is the best method to deploy >      modern cryptographic algorithms with the IKE and IPsec protocols. > > Or if you have an altnerative proposal, I'm happy to hear it.   That's much better but its a bit tortured. How about:    "* Great strides have been made in cryptography since IKEv1 development       ceased. While some modern cryptographic algorithms were added to       IKEv1, interoperability concerns mean that the defacto algorithms       negotiated by IKEv1 will consist of dated or deprecated algorithms       like AES-CBC, SHA1, and Diffie-Hellman groups 2 and 5. IKEv2 provides       state-of-the-art suite of cryptographic algorithms that IKEv1 lacks." Or maybe just make the whole bullet point be the last sentence. All that needs to be said is that "IKEv2 provides state-of-the-art cryptographic algorithms that IKEv1 lacks." That's the reason right there. >>   - there is another IKEv1 feature not available in IKEv2: a deniable >>     authentication method. IKEv1 had a very cool deniable exchange >>     involving encrypted nonces. IKEv2 decided to not support that for >>     whatever reason. Lack of support for a cool and usefu authentication >>     method doesn't really make the case to send IKEv1 to historic > > Can you clarify this a bit further for me? Is this deniable > authentication method part of all IKEv1 auth methods? Or is this a > specific feature that needed to be specifically enabled?   It was one of the authentication methods: PSK, certs, encrypted nonces. The encrypted nonce method was completely deniable. Honest participants would get strong authentication but they could prove to a court-of-law that the whole exchange could be fabricated by a third party and deny ever taking part in it. > That said, if the WG deemed this feature no longer required when > specifying IKEv2, then I do not think we need to mention this here when > we are talking about motivations for people to move from IKEv1 to IKEv2. > > If there is a good reason and people are prevented from upgrading to > IKEv2 because of this, I would be expecting an IKEv2 draft to be > developed to address this shortcoming. But it seems to me (I wasn't here > when these decisions were made) that the WG did not think this issue was > a concern ?   I walked away from the WG after I produced -02 of the draft that became IKEv2 so I have no idea what the was thinking after April of 2002 (nearly two decades! Yikes). There were a number of decisions that the WG made that looking back were odd. This is just one of them. Deniability is a valuable property and I don't know why it was ditched. >>     then, oh well. As an aside, I suggested a way to add an exchange >>     such an exchange using HPKE [1]. Not that I'm saying this needs to >>     be added to IKEv2, but if you're gonna talk about IKEv1 features >>     missing in IKEv2 you should be complete. > > I was mostly listing the features in IKEv1 that were missing in IKEv2 > that actually were motivations for certain people to not upgrade to > IKEv2. It is surely not meant as a list of IKEv1 vs IKEv2 features.   OK, well I'm not aware of anyone pining for that IKEv1 authentication method, or using that as an excuse to not upgrade to IKEv2, so maybe forget it. >> Other than that, good work. > > Thanks.   regards,   Dan. -- "The object of life is not to be on the side of the majority, but to escape finding oneself in the ranks of the insane." -- Marcus Aurelius From nobody Sun May 9 04:21:47 2021 Return-Path: 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 1A3D43A0BCE for ; Sun, 9 May 2021 04:21:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.201 X-Spam-Level: X-Spam-Status: No, score=-0.201 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=iki.fi 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 A2Y4qr-cF-NS for ; Sun, 9 May 2021 04:21:42 -0700 (PDT) Received: from meesny.iki.fi (meesny.iki.fi [195.140.195.201]) (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 ABFEC3A0BCB for ; Sun, 9 May 2021 04:21:42 -0700 (PDT) Received: from fireball.acr.fi (fireball.acr.fi [83.145.195.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: kivinen) by meesny.iki.fi (Postfix) with ESMTPSA id EC82B20B77; Sun, 9 May 2021 14:21:33 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=meesny; t=1620559294; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=8YNdFtdwKQVH84uQAxizGEiSsgRFwEr0gNUbrgX98FM=; b=VVt14mNqwAQAyW0yYQlZ4NpG8Z8LW9/xPIovHj0edFkjGu/Y2t5sv5iBOhiVO2Ismx1grS JmZP8lkhXCXiS736V0aIt7QlAnCh5eDaA8T/+k/R6BgtdJaphxvOM/kRfeQrAuds/8iZ46 3KEFiFJVnn6SOkA7HI6puVdOp7KwOns= Received: by fireball.acr.fi (Postfix, from userid 15204) id 6F55A25C12A6; Sun, 9 May 2021 14:21:32 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Message-ID: <24727.50620.391438.681442@fireball.acr.fi> Date: Sun, 9 May 2021 14:21:32 +0300 From: Tero Kivinen To: Dan Harkins Cc: Paul Wouters , "ipsec\@ietf.org WG" In-Reply-To: <872b98a9-a6fe-db41-276c-5d0a7e3aa9c5@lounge.org> References: <161962448020.12575.13131318934919776038@ietfa.amsl.com> <40493aa4-ba3a-ad32-fda2-f5ab24d78296@nohats.ca> <6297c870-0507-b3e8-ee6e-5517bdc86bba@lounge.org> <1fcc66b-aca1-6a5-e275-35bd29b3580@nohats.ca> <872b98a9-a6fe-db41-276c-5d0a7e3aa9c5@lounge.org> X-Mailer: VM 8.2.0b under 26.3 (x86_64--netbsd) X-Edit-Time: 17 min X-Total-Time: 19 min ARC-Authentication-Results: i=1; ORIGINATING; auth=pass smtp.auth=kivinen smtp.mailfrom=kivinen@iki.fi ARC-Seal: i=1; s=meesny; d=iki.fi; t=1620559294; a=rsa-sha256; cv=none; b=siae47KmQEwt4vHp7L6m6Rfq2IOYcgqnZhgvWYgVI2S6cfgneykfo5Pse+f7V/cGFbu4NH KH9zJG6aNop2t7EVvNr/4bOadHzizBjYw8yXlObo7mRZ6FWALbPRcbKhYTlSwP11hClhBU /fHlvnGLb6VLPk4zbhYk2hd2HzZ1/lo= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=meesny; t=1620559294; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=8YNdFtdwKQVH84uQAxizGEiSsgRFwEr0gNUbrgX98FM=; b=qWYOoK0EyrSbiHPIWveG7Y1j+LsJtPoadLXGqHQj918w1bEiRHY84RcvkmnFzEN5n5JCVT 2YwVq52b03U01Ed2tqQ4cPZEFkN1H/K4GD/B61BV56hNzb7fssSq/8qbmSlR26aLJopdK9 3/Wno6qvZYmfAhnxriY+/VuHbdEgEbU= Archived-At: Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-ikev1-algo-to-historic-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 May 2021 11:21:46 -0000 Dan Harkins writes: > >> =A0 - there is another IKEv1 feature not available in IKEv2: a den= iable > >> =A0 =A0 authentication method. IKEv1 had a very cool deniable exch= ange > >> =A0 =A0 involving encrypted nonces. IKEv2 decided to not support t= hat for > >> =A0 =A0 whatever reason. Lack of support for a cool and usefu auth= entication > >> =A0=A0=A0 method doesn't really make the case to send IKEv1 to his= toric > > > > Can you clarify this a bit further for me=3F Is this deniable > > authentication method part of all IKEv1 auth methods=3F Or is this = a > > specific feature that needed to be specifically enabled=3F >=20 > =A0 It was one of the authentication methods: PSK, certs, encrypted > nonces. The encrypted nonce method was completely deniable. Honest > participants would get strong authentication but they could prove > to a court-of-law that the whole exchange could be fabricated by a > third party and deny ever taking part in it. The draft-ietf-ipsec-ikev2-00.txt draft only included digital signatures, -01 version added shared secret authentication, but encrypted rsa was never even considered for IKEv2, i.e., it was never explcitly removed, it was simply never taken in to the IKEv2. If I remember correctly (this discussion happened around year 2002 or so) the reason was that there were no requirement for it. While there were IKEv1 implementations which supported authentication with public key encryption mode, not all implementations had it. Also support for the revised method of authentication with public key encryption was even less common. Also VPN and remote access people did not consider benefits from the authentication with public key encryption mode useful for them. Having two different keys, one for signing and one for encryption, for authentication was considered complicated, and reusing same key for both signing and for encryption was considered bad idea. And also I think shared key authentication also offeres exactly same benefits than authentication with public key encryption for the deniability point of view (i.e., either end can calculate everything as long as they know the shared secret). > > That said, if the WG deemed this feature no longer required when > > specifying IKEv2, then I do not think we need to mention this here = when > > we are talking about motivations for people to move from IKEv1 to I= KEv2. > > > > If there is a good reason and people are prevented from upgrading t= o > > IKEv2 because of this, I would be expecting an IKEv2 draft to be > > developed to address this shortcoming. But it seems to me (I wasn't= here > > when these decisions were made) that the WG did not think this issu= e was > > a concern =3F >=20 > =A0 I walked away from the WG after I produced -02 of the draft that= became > IKEv2 so I have no idea what the was thinking after April of 2002 (ne= arly > two decades! Yikes). There were a number of decisions that the WG mad= e that > looking back were odd. This is just one of them. Deniability is a val= uable > property and I don't know why it was ditched. It was not ditched, it was never included. I.e. the public key encryption was not in the -00 version. Shared secret (which provide deniability) was added in version -01. --=20 kivinen@iki.fi From nobody Mon May 10 08:03:03 2021 Return-Path: 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 0CA723A201A for ; Mon, 10 May 2021 08:03:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 hF80Zvl7pndk for ; Mon, 10 May 2021 08:02:56 -0700 (PDT) Received: from www.goatley.com (www.goatley.com [198.137.202.94]) (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 26BD83A201C for ; Mon, 10 May 2021 08:02:55 -0700 (PDT) Received: from trixy.bergandi.net (cpe-76-176-14-122.san.res.rr.com [76.176.14.122]) by wwwlocal.goatley.com (PMDF V6.8 #2433) with ESMTP id <0QSW0P67RCGVEH@wwwlocal.goatley.com> for ipsec@ietf.org; Mon, 10 May 2021 10:02:55 -0500 (CDT) Received: from blockhead.local ([69.12.173.8]) by trixy.bergandi.net (PMDF V6.7-x01 #2433) with ESMTPSA id <0QSW00K98CCIEW@trixy.bergandi.net> for ipsec@ietf.org; Mon, 10 May 2021 08:00:19 -0700 (PDT) Received: from 69-12-173-8.static.dsltransport.net ([69.12.173.8] EXTERNAL) (EHLO blockhead.local) with TLS/SSL by trixy.bergandi.net ([10.0.42.18]) (PreciseMail V3.3); Mon, 10 May 2021 08:00:19 -0700 Date: Mon, 10 May 2021 08:02:53 -0700 From: Dan Harkins In-reply-to: <24727.50620.391438.681442@fireball.acr.fi> To: Tero Kivinen Cc: "ipsec@ietf.org WG" , Paul Wouters Message-id: <491ac483-a062-3793-0a09-2df394509c01@lounge.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8; format=flowed Content-language: en-US Content-transfer-encoding: 8BIT User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.7.1 X-PMAS-SPF: SPF check skipped for authenticated session (recv=trixy.bergandi.net, send-ip=69.12.173.8) X-PMAS-External-Auth: 69-12-173-8.static.dsltransport.net [69.12.173.8] (EHLO blockhead.local) References: <161962448020.12575.13131318934919776038@ietfa.amsl.com> <40493aa4-ba3a-ad32-fda2-f5ab24d78296@nohats.ca> <6297c870-0507-b3e8-ee6e-5517bdc86bba@lounge.org> <1fcc66b-aca1-6a5-e275-35bd29b3580@nohats.ca> <872b98a9-a6fe-db41-276c-5d0a7e3aa9c5@lounge.org> <24727.50620.391438.681442@fireball.acr.fi> X-PMAS-Software: PreciseMail V3.3 [210506] (trixy.bergandi.net) X-PMAS-Allowed: system rule (rule allow header:X-PMAS-External noexists) Archived-At: Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-ikev1-algo-to-historic-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 May 2021 15:03:02 -0000   Hi Tero,   Thanks for the clarification. I don't want to resurrect the idea here but I feel compelled to respond to this: On 5/9/21 4:21 AM, Tero Kivinen wrote: > And also I think shared key authentication also offeres exactly same > benefits than authentication with public key encryption for the > deniability point of view (i.e., either end can calculate everything > as long as they know the shared secret).   With public key encryption, anyone is able to construct what looks like a valid IKE conversation between any two participants by using publicly available information (i.e. their certificates). For that capability to be done with shared key authentication it would require the shared key used for "authentication" to be known by everyone, which sort of voids the whole security of the protocol.   Basically, the shared key authentication mode would only be the equivalent of public key encryption authentication mode when using the Pre-shared Key for the Internet [1], which was an April Fools draft and (I think this bears repeating these days) was not intended to be taken seriously.   regards,   Dan. [1] https://datatracker.ietf.org/doc/html/draft-ietf-ipsec-internet-key -- "The object of life is not to be on the side of the majority, but to escape finding oneself in the ranks of the insane." -- Marcus Aurelius From nobody Fri May 21 06:05:08 2021 Return-Path: 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 13A923A0E01; Fri, 21 May 2021 06:05:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.796 X-Spam-Level: X-Spam-Status: No, score=-2.796 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, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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=orange.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 Ko8mSqsvjZtY; Fri, 21 May 2021 06:05:02 -0700 (PDT) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.70.34]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9C173A0E00; Fri, 21 May 2021 06:05:01 -0700 (PDT) Received: from opfednr01.francetelecom.fr (unknown [xx.xx.xx.65]) by opfednr23.francetelecom.fr (ESMTP service) with ESMTP id 4FmmzZ1ckdz636d; Fri, 21 May 2021 15:04:58 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1621602298; bh=sE5kkWnBnKleQnW9r8vL2XSYHJn9P0PeAlhwDd8aPZY=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=sthp9e7FVpkjGto2zyOzCYBhKVXbWX2BPJXglu4OYy+pRN8x55RJspPJ4aRqldnzK +Bjz5/RIUYpcwlNcHQzUkT+R88EhTYr1hoNOG4fO8756Vy+MA9JoSAh0i3Eobi9B9g 5berNyRmg2cUq6oQ2pHr0F5hbXA0Peie/Onmb5SzGeyPk+6+xUnNtW9LdMzlosGvrG YTDmkmPxDmDUI832UNOFoGWlHlH1QwOKnLbOe3wEFcYfEsn9jmwGK0wolL07iSS38j FZJ3eVdMqNF4yC+sangcnBFA+fSh9oQjBv5Wqf7EoSpd79cN9yh037AnVqQdwW6F/W 6cp1IQoiCJDhw== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.92]) by opfednr01.francetelecom.fr (ESMTP service) with ESMTP id 4FmmzZ0yw6zDq7V; Fri, 21 May 2021 15:04:58 +0200 (CEST) From: To: "ipsec@ietf.org" CC: "draft-btw-add-ipsecme-ike@ietf.org" Thread-Topic: New Version Notification for draft-btw-add-ipsecme-ike-03.txt Thread-Index: AQHXSwDaufrxMGfBaEyHw3kaxexOvqrt61Kw Date: Fri, 21 May 2021 13:04:57 +0000 Message-ID: <6796_1621602298_60A7AFFA_6796_24_1_787AE7BB302AE849A7480A190F8B93303538C3CB@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <162124450260.24368.2588430228921726378@ietfa.amsl.com> In-Reply-To: <162124450260.24368.2588430228921726378@ietfa.amsl.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.245] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: [IPsec] TR: New Version Notification for draft-btw-add-ipsecme-ike-03.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 May 2021 13:05:08 -0000 SGkgYWxsLA0KDQpGV0lXLCB3ZSB1cGRhdGVkIHRoZSBkcmFmdCB3aXRoIHRoZSBmb2xsb3dpbmcg Y2hhbmdlczoNCiogYWxpZ24gd2l0aCB0aGUgQUREIHdvcmtpbmcgZ3JvdXAgDQoqIGFsbG93IHRv IG5vdCByZWx5IG9uIFBLSSBmb3IgdmFsaWRhdGluZyB0aGUgRW5jcnlwdGVkIEROUyBzZXJ2ZXIg Y2VydGlmaWNhdGUgYnkgY29udmV5aW5nIHRoZSBlbmQtZW50aXR5IGNlcnRpZmljYXRlDQoqIHJl bW92ZSBTZWN0aW9uIDMgZnJvbSB0aGUgY29yZSBkb2N1bWVudA0KDQpUaGUgbGFzdCB0d28gcG9p bnRzIGFyZSBjb21tZW50cyB0aGF0IHdlcmUgcmFpc2VkIGR1cmluZyBJRVRGIzExMC4NCg0KQ2hl ZXJzLA0KTWVkDQoNCi0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KRGXCoDogaW50ZXJuZXQt ZHJhZnRzQGlldGYub3JnIFttYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnXSANCkVudm95 w6nCoDogbHVuZGkgMTcgbWFpIDIwMjEgMTE6NDINCsOAwqA6IFRpcnVtYWxlc3dhciBSZWRkeS5L IDx0aXJ1bWFsZXN3YXJyZWRkeV9rb25kYUBtY2FmZWUuY29tPjsgRGFuIFdpbmcgPGR3aW5nLWll dGZAZnVnZ2xlcy5jb20+OyBCT1VDQURBSVIgTW9oYW1lZCBUR0kvT0xOIDxtb2hhbWVkLmJvdWNh ZGFpckBvcmFuZ2UuY29tPjsgVGlydW1hbGVzd2FyIFJlZGR5IDxUaXJ1bWFsZXN3YXJSZWRkeV9L b25kYUBNY0FmZWUuY29tPjsgVmFsZXJ5IFNteXNsb3YgPHN2YW5AZWx2aXMucnU+DQpPYmpldMKg OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWJ0dy1hZGQtaXBzZWNtZS1pa2Ut MDMudHh0DQoNCg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWJ0dy1hZGQtaXBzZWNtZS1p a2UtMDMudHh0IGhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgTW9oYW1lZCBCb3Vj YWRhaXIgYW5kIHBvc3RlZCB0byB0aGUgSUVURiByZXBvc2l0b3J5Lg0KDQpOYW1lOgkJZHJhZnQt YnR3LWFkZC1pcHNlY21lLWlrZQ0KUmV2aXNpb246CTAzDQpUaXRsZToJCUludGVybmV0IEtleSBF eGNoYW5nZSBQcm90b2NvbCBWZXJzaW9uIDIgKElLRXYyKSBDb25maWd1cmF0aW9uIGZvciBFbmNy eXB0ZWQgRE5TDQpEb2N1bWVudCBkYXRlOgkyMDIxLTA1LTE3DQpHcm91cDoJCUluZGl2aWR1YWwg U3VibWlzc2lvbg0KUGFnZXM6CQkxMw0KVVJMOiAgICAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYu b3JnL2FyY2hpdmUvaWQvZHJhZnQtYnR3LWFkZC1pcHNlY21lLWlrZS0wMy50eHQNClN0YXR1czog ICAgICAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1idHctYWRkLWlw c2VjbWUtaWtlLw0KSHRtbGl6ZWQ6ICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv ZG9jL2h0bWwvZHJhZnQtYnR3LWFkZC1pcHNlY21lLWlrZQ0KSHRtbGl6ZWQ6ICAgICAgIGh0dHBz Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1idHctYWRkLWlwc2VjbWUtaWtlLTAzDQpEaWZm OiAgICAgICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWJ0dy1h ZGQtaXBzZWNtZS1pa2UtMDMNCg0KQWJzdHJhY3Q6DQogICBUaGlzIGRvY3VtZW50IHNwZWNpZmll cyBhIG5ldyBJbnRlcm5ldCBLZXkgRXhjaGFuZ2UgUHJvdG9jb2wgVmVyc2lvbg0KICAgMiAoSUtF djIpIENvbmZpZ3VyYXRpb24gUGF5bG9hZCBBdHRyaWJ1dGUgVHlwZXMgZm9yIGVuY3J5cHRlZCBE TlMNCiAgIHByb3RvY29scyBzdWNoIGFzIEROUy1vdmVyLUhUVFBTIChEb0gpLCBETlMtb3Zlci1U TFMgKERvVCksIGFuZCBETlMtDQogICBvdmVyLVFVSUMgKERvUSkuDQoNCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICANCg0KDQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9m IG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uIHVudGlsIHRoZSBodG1saXplZCB2 ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQoNClRoZSBJ RVRGIFNlY3JldGFyaWF0DQoNCg0KCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18KCkNlIG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBq b2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyBjb25maWRlbnRpZWxsZXMg b3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYwpwYXMgZXRyZSBkaWZmdXNlcywgZXhw bG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2Ug bWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlcgphIGwnZXhwZWRpdGV1ciBl dCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXMg ZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLApPcmFuZ2UgZGVj bGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVm b3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuCgpUaGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50 cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0 IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3Owp0aGV5IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQs IHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlvbi4KSWYgeW91IGhhdmUgcmVjZWl2 ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxl dGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuCkFzIGVtYWlscyBtYXkgYmUgYWx0 ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1v ZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC4KVGhhbmsgeW91LgoK From nobody Fri May 21 12:26:57 2021 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 82D783A1DD0; Fri, 21 May 2021 12:26:55 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: ipsec@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.30.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: ipsec@ietf.org Message-ID: <162162521550.1334.14013885414393054186@ietfa.amsl.com> Date: Fri, 21 May 2021 12:26:55 -0700 Archived-At: Subject: [IPsec] I-D Action: draft-ietf-ipsecme-mib-iptfs-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 May 2021 19:26:56 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Maintenance and Extensions WG of the IETF. Title : Definitions of Managed Objects for IP Traffic Flow Security Authors : Don Fedyk Eric Kinzie Filename : draft-ietf-ipsecme-mib-iptfs-00.txt Pages : 19 Date : 2021-05-21 Abstract: This document describes managed objects for the the management of IP Traffic Flow Security additions to IKEv2 and IPsec. This document provides a read only version of the objects defined in the YANG module for the same purpose. This is an unpublished work in progress. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-mib-iptfs/ There is also an htmlized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-mib-iptfs-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/