Re: [IPsec] WG Adoption call for draft-btw-add-ipsecme-ike

Paul Wouters <paul@nohats.ca> Mon, 08 November 2021 15:20 UTC

Return-Path: <paul@nohats.ca>
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 A06B83A1118 for <ipsec@ietfa.amsl.com>; Mon, 8 Nov 2021 07:20:38 -0800 (PST)
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 loKvg1vPBhCT for <ipsec@ietfa.amsl.com>; Mon, 8 Nov 2021 07:20:33 -0800 (PST)
Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::85]) (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 2E98F3A1166 for <ipsec@ietf.org>; Mon, 8 Nov 2021 07:19:57 -0800 (PST)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 4HnvtL0C7Lz3M9; Mon, 8 Nov 2021 16:19:54 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1636384794; bh=/eihdZzJX7oqsYblKdlx92HiDx6g4ex6mpGytuK7CGc=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=YfSs3HiRTh3luUINx1oXQtZqFOMHVOMcAmzZFZRaF6FtI+dmem0cLOWHCSLhMbNlX IaB6kLM3EzAUa5GfnuL92HIszbWPNHR9VXasaAN91spO0wxO4k/zM8HrnVmveX/RRD o3J3hPPvJEECR+7T/qcBNHw+GXHZvokPRSRWFy/0=
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 bseW6uFkn9Rw; Mon, 8 Nov 2021 16:19:53 +0100 (CET)
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; Mon, 8 Nov 2021 16:19:52 +0100 (CET)
Received: by bofh.nohats.ca (Postfix, from userid 1000) id F2722132190; Mon, 8 Nov 2021 10:19:51 -0500 (EST)
Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id F16F213218F; Mon, 8 Nov 2021 10:19:51 -0500 (EST)
Date: Mon, 08 Nov 2021 10:19:51 -0500
From: Paul Wouters <paul@nohats.ca>
To: Tero Kivinen <kivinen@iki.fi>
cc: ipsec@ietf.org
In-Reply-To: <24969.12660.103330.619294@fireball.acr.fi>
Message-ID: <ccdfdc-634-5989-839b-3cbd17e86d99@nohats.ca>
References: <24969.12660.103330.619294@fireball.acr.fi>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"; format="flowed"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/wvCMAJm4Y1wvQBzyYMAMQMeM_uI>
Subject: Re: [IPsec] WG Adoption call for draft-btw-add-ipsecme-ike
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.29
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, 08 Nov 2021 15:20:44 -0000

On Mon, 8 Nov 2021, Tero Kivinen wrote:

> Subject: [IPsec] WG Adoption call for draft-btw-add-ipsecme-ike
> 
> This is the start of 2 week WG adoption call for this document, ending
> 2021-11-22. Please send your reply about whether you support adopting
> this document as WG document or not.

I support the idea of conveying a list of DNS servers that support
encryption. I am not sure if this draft's format and content is the
right way forward.

Note the text of the draft claims it updates RFC 8598 but doesn't do so
via an Updates: statement. Also, I think the relaxing of the requirement
is actually wrong, as it might cause lack of interop between newer
servers and older clients not being able to negotiate working DNS if
the new servers no longer serve INTERNAL_IP*_DNS CFG payloads.

I am also not clear on the real use of negotiating hash algorithms for
the digest receiving of the ADD server "identity?", as the document
states the authentication happens as per Section 8 of [RFC8310]
which lists WebPKI or DANE authentication against the name and these
methods do not use this digest. I also do not understand the use of the
digest. For authentication, is it not needed as the entire IKEv2 exchange
is authenticated.

Paul