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 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lwip
