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