On Thu, Mar 10, 2016 at 02:18:51pm -0500, Robert Moskowitz wrote:
> Fair point. I really cannot convert TLS specifications to packet
> content. I suspect there are things exposed?
[snip]
> I do suspect that TLS is different in how it does compression, and if it
> is being abandoned, so sad.
I have looked at both the CRIME and BREACH attacks and neither would
work against IPCOMP within ESP. TLS and HTTP compression are softly done...
It DOES change some of my thoughts about compression as a XML option for
use in DOTS. That is pretty much what CRIME is attacking. Rather you
have
Fair point. I really cannot convert TLS specifications to packet
content. I suspect there are things exposed?
With IPCOMP, it is all within the EXP encrypted block. It is known
text, for the most part and would be open to known text attacks. But
then there is always a fair amount of known
Hi,
I guess it could be a new "IPCOMP" transform similar to the ESP transform:
https://tools.ietf.org/html/rfc7402#section-5.1.2
I think R1-I2 would be enough, no need to confirm it in R2, similarly as
with ESP transform:
https://tools.ietf.org/html/rfc7402#section-5.2.1
On 03/10/2016
I have found comp in TLS, RFC 3749, so HIP's ESP is the only one missing
compression. How did I miss that? It should have been included in 7402
as an option within ESP.
I will figure out a way to get it into some RFC, but perhaps a little
hashing out how it would work is called for first:
Why did we not create a parameter to negotiate IPCOMP (currently RFC 3173)?
In IKEv2 it is negotiated in NOTIFY messages, not the basic exchange and
becomes part of the daughter SA(s).
On contrained networks, IPCOMP could well be of value. Also if HIP is
used to establish the SAs for SSE
