Re: [Lwip] [IPsec] The LWIG WG has placed draft-mglt-lwig-minimal-esp in state "Call For Adoption By WG Issued"
Paul Wouters <paul@nohats.ca> Wed, 13 February 2019 18:09 UTC
Return-Path: <paul@nohats.ca>
X-Original-To: lwip@ietfa.amsl.com
Delivered-To: lwip@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3900129532 for <lwip@ietfa.amsl.com>; Wed, 13 Feb 2019 10:09:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] 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 MwOPiRDUIqm4 for <lwip@ietfa.amsl.com>; Wed, 13 Feb 2019 10:09:03 -0800 (PST)
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 73D57128766 for <lwip@ietf.org>; Wed, 13 Feb 2019 10:09:03 -0800 (PST)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 4406wW6NCZzK87; Wed, 13 Feb 2019 19:08:59 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1550081339; bh=/RNnqvO0yteRH5veMcvLEVLOW6ywJ3vxWM4Xkj67Dhw=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=PBBOfMPYdGxJqi4HHJxQMrT8b+WOmAKnxZuom+Xdk7I/A4cryBSgJKnktuL//r4qm wAh+QttpOO7izBZpwB8uO+tLTXwk2T5wobL7CD4xpMZZAaFNdWSG1ErU67LoxmawYc HE7TurzitwZU+P5eRSmYW1TiDeqj0bn3bwzbQ8AQ=
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 EkODUDqA02xk; Wed, 13 Feb 2019 19:08:57 +0100 (CET)
Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Wed, 13 Feb 2019 19:08:56 +0100 (CET)
Received: by bofh.nohats.ca (Postfix, from userid 1000) id 0FC662FCBF; Wed, 13 Feb 2019 13:08:56 -0500 (EST)
DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 0FC662FCBF
Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 04F5A40D358A; Wed, 13 Feb 2019 13:08:56 -0500 (EST)
Date: Wed, 13 Feb 2019 13:08:55 -0500
From: Paul Wouters <paul@nohats.ca>
To: Daniel Migault <daniel.migault@ericsson.com>
cc: Mohit Sethi M <mohit.m.sethi@ericsson.com>, Tero Kivinen <kivinen@iki.fi>, Heinrich Singh <heinrich.ietf@gmail.com>, "lwip@ietf.org" <lwip@ietf.org>
In-Reply-To: <CADZyTk=hYhJH8yU5TU6m_dsEr_u+iEfd=c=oasV5=JEHM4dc1g@mail.gmail.com>
Message-ID: <alpine.LRH.2.21.1902131236040.458@bofh.nohats.ca>
References: <CAP_kZQqckPJhCn083sg8=PVpiO_+Ke=GhOKre=qujkk4k=dU7A@mail.gmail.com> <CADZyTk=dtJS7bS8oJtSa1bW-Xv3-AkuboX1QoJTFG+DyuN94ow@mail.gmail.com> <CAP_kZQrnmJJaLtzSJ5MeDYSme2mV6sAfGZrE5tnx8P6hbMib7g@mail.gmail.com> <23433.17795.580382.531001@fireball.acr.fi> <alpine.LRH.2.21.1808311231250.27198@bofh.nohats.ca> <VI1PR07MB4717173E61C887FDF4E4D3ABD0F70@VI1PR07MB4717.eurprd07.prod.outlook.com> <CADZyTk=hYhJH8yU5TU6m_dsEr_u+iEfd=c=oasV5=JEHM4dc1g@mail.gmail.com>
User-Agent: Alpine 2.21 (LRH 202 2017-01-01)
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"; format="flowed"
Archived-At: <https://mailarchive.ietf.org/arch/msg/lwip/xDcICiuALZ2ExF3qwRCnhCQC3A0>
Subject: Re: [Lwip] [IPsec] The LWIG WG has placed draft-mglt-lwig-minimal-esp in state "Call For Adoption By WG Issued"
X-BeenThere: lwip@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Lightweight IP stack. Official mailing list for IETF LWIG Working Group." <lwip.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lwip>, <mailto:lwip-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lwip/>
List-Post: <mailto:lwip@ietf.org>
List-Help: <mailto:lwip-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lwip>, <mailto:lwip-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 13 Feb 2019 18:09:06 -0000
On Tue, 12 Feb 2019, Daniel Migault wrote: > I am wondering what is currently the status of the draft. Feel free to let me know if I something is expected on my side. I cannot answer that question, I'll leave that to the chairs, but I do have several strong reservations on the document. Especiallt with the complex framework to reduce a number of bytes. In section 3 there is a discussion about not using randomness for a SPI. It argues why this is not needed. My issue is that there I can see three ways of a system needing to generate an IPsec SPI: 1) It has an IKEv2 stack 2) It has nother (eg 3GPP??) protocol that does not provide a SPI, but handles all other keying. 3) Manual keying In the case of 1) the implementation clearly needs to generate randomness anyway, at least for the IKE SPIs which really must be strong random. (It saved us from an IKEv1 attack 2 years ago!) In the case of 2), why isn't the other protocol dictating the SPI? As for case 3), well manual keying is strongly discouraged outside of using a keying protocol that provides the same safeguards as IKE. So I don't know which implementations would actually qualify for using non-random static like SPI's Perhaps you can clarify this with some use cases where this would apply? Section 4 is about the sequence number. While in principle i see nothing wrong with relaing the requirement for increasing by 1 and using another source for increasing numbers, I do find the reasoning weak. For example, with this counter you would also check the number of bytes encrypted with that key to ensure you are not encrypting more than 2^20 or 2^32 packets. While I guess these devices likely wouldn't ever get there, shouldn't there still be a formal check in the code to prevent this anyway? Additionally, if resources matter that much, you are using AES-GCM or CHACHA20POLY1305, meaning you need a counter anyway. So you can just re-use that one anyway. So I'm not convinced this is actually a needed use case. Section 5, while TFC deployment might be used a lot (yet?), it is part of many stacks, so the claim about not being widely adopted for standard ESP traffic is partially true. I am not sure what you are trying to say with this paragraph: As a result, TFC cannot not be enabled with minimal, and communication protection that were relying on TFC will be more sensitive to traffic shaping. This could expose the application as well as the devices used to a passive monitoring attacker. Such information could be used by the attacker in case a vulnerability is disclosed on the specific device. In addition, some application use - such as health applications - may also reveal important privacy oriented informations. Are you suggesting to obsolete TFC ? Section 5 does not actually propose a change that I can see. It implies padding support and any and all kind of padding should be able to be omited? Similarly, section 6 does not seem to propose a change to strip out the Next Header, though it is suggesting it. I think BEET is not a real consideration, as I dont think many implementations support it and I don't know anyone using it? But I'm not convinced this 1 byte is really a goal we should consider. This sentence is confusing: ESP can be used to authenticate only or to encrypt the communication. Since IPsec-v2 allowed ESP without authentication, and IPsec-v3 only has authenticated ESP. It's better to say ESP allows null-encryption and not mention authentication (which always happens) It talks about "Cipher Suites" which is really a TLS term. For example if the device benefits from AES hardware modules and uses AES-CTR, it may prefer AUTH_AES-XCBC for its authentication. Note that AES-XCBC is not a FIPS approves integrity algorithm :) But more importantly, you do not want a non-AEAD at all if battery usage is so important. use AES-CCM or AES-GCM or when not having AES HW support, chacha20-poly1305. All in all, I think the document should more clearly seperate the issues of a minimal ESP implementation, and any proposed modifications to ESP. And if that is done, the protocol shouldn't be ESP but something new, unless it is completely backwards compatible (like IPsec-v2 to-> IPsec-v3 was) If the document is defining a minimum/battery optimized ESP configuartion, I have no problems with it and I will review further text and welcome adoption. If it makes changes to the ESP protocol, then I think there should be more discussion before adoption. Paul
- [Lwip] The LWIG WG has placed draft-mglt-lwig-min… Heinrich Singh
- Re: [Lwip] [IPsec] The LWIG WG has placed draft-m… Daniel Migault
- Re: [Lwip] [IPsec] The LWIG WG has placed draft-m… Heinrich Singh
- Re: [Lwip] The LWIG WG has placed draft-mglt-lwig… Zhen Cao
- Re: [Lwip] [IPsec] The LWIG WG has placed draft-m… Tero Kivinen
- Re: [Lwip] [IPsec] The LWIG WG has placed draft-m… Daniel Migault
- Re: [Lwip] [IPsec] The LWIG WG has placed draft-m… Michael Richardson
- Re: [Lwip] [IPsec] The LWIG WG has placed draft-m… Paul Wouters
- Re: [Lwip] [IPsec] The LWIG WG has placed draft-m… Mohit Sethi
- Re: [Lwip] [IPsec] The LWIG WG has placed draft-m… Daniel Migault
- Re: [Lwip] The LWIG WG has placed draft-mglt-lwig… Heinrich Singh
- Re: [Lwip] The LWIG WG has placed draft-mglt-lwig… Daniel Migault
- Re: [Lwip] [IPsec] The LWIG WG has placed draft-m… Mohit Sethi M
- Re: [Lwip] [IPsec] The LWIG WG has placed draft-m… Daniel Migault
- Re: [Lwip] [IPsec] The LWIG WG has placed draft-m… Paul Wouters
- Re: [Lwip] [IPsec] The LWIG WG has placed draft-m… Valery Smyslov
- Re: [Lwip] [IPsec] The LWIG WG has placed draft-m… Paul Wouters
- Re: [Lwip] [IPsec] The LWIG WG has placed draft-m… Daniel Migault
- Re: [Lwip] [IPsec] The LWIG WG has placed draft-m… Mohit Sethi M