Subject: [secdir] Secdir review of draft-ietf-ippm-6man-pdm-option-05

From: Tero Kivinen <[email-masked]>
Date: Mon, 19 Sep 2016 17:12:38 +0300

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of the
security area directors.  Document editors and WG chairs should treat
these comments just like any other last call comments.

This document describes adding new IPv6 destination option header to
allow performance metrics calculations.

I think this document has serious issues.

It proposes that the new Destination option MUST be put before the ESP
so it is sent in clear. This will leak out the traffic information
from the ESP, allowing easy traffic analysis of encrypted packets, as
passive attacker can see which encrypted ESP packets belong to which
5-tuple flow. The PDM option header includes the incrementing sequence
numbers, so checking those will allow see which packet belongs to
which flow.

It claims that PDM MUST be placed before the ESP header in order to
work, which is untrue. This is destination option, thus it is meant to
be checked on the destination host, i.e., the packet capture after the
ESP decryption will allow seeing the PDM header values without issues.

--

Also the Time Base definations seem to be inconsistent. The section
3.2 says:

   That is, for a value of 00 in the Time Base field, a value of 1 in
   the DELTA fields indicates 1 microsecond.

Section 4.4 on other hand claims:

   That is, for a value of 00 in the Time Base field, a value of 1 in
   the DELTA fields indicates 1 picosecond.

On the other hand looking at the table in both 3.2 and 4.4 it seems
that time base value field value of 00 means milliseconds, not
microseconds or picoseconds.

Again section 4.5 says that "TimeBase of picosecond (or 00)", and
again I think picoseconds was supposed to be Time Base of 11...

The whole section 4 seems to be wierd. It is talking about different
encodings, and time units on different systems, and it also talks
about the limitations on TCP Timestamp Option, but this option uses
different encoding so I have no idea why this text is here. It would
be more useful to count what are the limits on the encoding method
used here (16 bit value, 7 bit signed scaling value), instead of what
some other option use.

In section 5.3 in the example it converts 4 seconds to hex value of
3A35 and scale of 25. On the other hand it is using milliseconds as
Time Base, so I think those values are wrong, i.e. 4 seconds in
milliseconds is 4000 milliseconds, thus FA0 with scale of 0 would be
correct represetnation. Same mistake in 5.4.

--

I skipped most of the section 6 and 7, so cannot say if similar
mistakes are in those sections.

--

The section 8 is wrong as it claims

	"PDM does not introduce any new security weakness."

while this will leak lots of information about the traffic flows
inside the encrypted transport mode ESP packets.

Also another thing the PDM leaks is exact host timings, i.e., it can
be used to launch timing attacks against crypto protocols. In general
those are hard as it is very hard to know how much of n ms rtt is
network delay and how much was the actual host processing the packet.
Now if we can see that that host used 123 nanoseconds to process the
signature verification packet, and next time it uses 1755 nanoseconds,
this might allow attacker to get information out from the key. The
actual round trip times might have been 123 ms in both cases, and the
1 microsecond difference in the processing time would have been lost
by the network latencies.

In addition to that the abstract is not very clear, it does not do
very good job of telling that this draft tries to do, and having the
Background section to duplicate most of that text does not still what
this document really tries to do. 
-- 
[email-masked]

---

From: <[email-masked]>
Date: Mon, 19 Sep 2016 14:57:15 +0000 (UTC)

Tero,
Thank you for your comments.  We will review and get back to you on them later today.  But, first, let me address one thing which may be a misunderstanding of PDM.
1.  PDM is OFF initially at the end hosts (client and server)
2.  It is turned ON for diagnostics then turned OFF afterwards.  If someone chooses to leave PDM ON always, then that is explicitly chosen for their network.
3.  PDM is an OPTIONAL feature.  One may choose not to implement it at all.

To address some of your comments about leakage, etc.
Let's discuss how this might happen:
1.  Attacker obtains access to either or both end host client and server and turns on PDM 
2.  Attacker watches passively.
Actually the problem is 1.  If you have done that, what do you need PDM for?   Many other things can be found - such as type of device, etc without resorting to PDM.  Thanks,
Nalini ElkinsInside Products, Inc.www.insidethestack.com(831) 659-8360

      From: Tero Kivinen <[email-masked]>
 To: [email-masked]; [email-masked]; [email-masked] 
 Sent: Monday, September 19, 2016 7:12 AM
 Subject: Secdir review of draft-ietf-ippm-6man-pdm-option-05

--

--

--

---

From: <[email-masked]>
Date: Fri, 23 Sep 2016 15:24:28 +0000 (UTC)

Tero,

Thanks for your comments.  We have posted a new draft with corrections at: 
https://tools.ietf.org/html/draft-ietf-ippm-6man-pdm-option-06

Our responses inline.
 
Nalini Elkins

Inside Products, Inc.
www.insidethestack.com
(831) 659-8360

________________________________

>numbers, so checking those will allow see which packet belongs to

It is not clear to me how knowing which ESP packets belong to which traffic flow helps a passive attacker.   The attacker still does not know what is in the packet - the contents of the payload.  Indeed, ESP would normally mask TCP or UDP ports.  With PDM you can tell that there ARE multiple flows but you don't know if they are TCP, UDP, ICMP or anything else.  Most importantly, you don't know what is in the payload. 
 
If one follows the thinking of your objection, isn't any encrypted flow over TCP or UDP a problem since a passive attacker knows the 5-tuple for such flows?  For example, all TLS flows can be analyzed for traffic in your sense.  So, a flow over TLS (without PDM) actually leaks more information than an ESP flow WITH PDM.  Because with TLS, we even know that the flow is TCP and the port number.   Neither of which you know with PDM with ESP.

--

>again I think picoseconds was supposed to be Time Base of 11...

Thanks for catching those.  Should now be fixed.

>some other option use.

Thanks.  Should now be fixed.

>correct represetnation. Same mistake in 5.4.

Thanks. Should now be fixed.

--

--

>inside the encrypted transport mode ESP packets.

Please see above.

>Also another thing the PDM leaks is exact host timings, i.e., it can>be used to launch timing attacks against crypto protocols. In general

>by the network latencies.

1. The intent of PDM is as a diagnostic feature.  PDM is OFF initially at the end hosts (client and server).  It is turned ON for diagnostics and then turned OFF afterwards.  If someone chooses to leave PDM ON always, then that is explicitly chosen.  Also, PDM is an OPTIONAL feature.  Either client or server operating system may choose not to implement it or use it. 

2. In your example above, it assumes that the signature verification packet (please let me know which exact packet and protocol you are referring to) is passing in the clear so that the attacker knows that it is the signature verification packet.  Possibly this is also a problem. 

3.  Protocols often use blinding techniques to remove correlations between key and encryption time.   Other cryptographic algorithms can be implemented (or masked by a proxy) in a way that reduces or eliminates data dependent timing information.   So if timing information is being leaked, this is a flaw in the algorithm or the protocol.   In this case, we may be "blaming the messenger".  PDM is only reporting what is done.  The algorithm or protocol is the problem. 

>this document really tries to do. 

If you can give me a hint as to what is not clear or what you think this draft DOES propose, then we will be happy to rewrite the abstract / background section.

-- [email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 28 Sep 2016 18:44:21 +0300

[email-masked] writes:
> Thank you for your comments.  We will review and get back to you on them later
> today.  But, first, let me address one thing which may be a misunderstanding
> of PDM.
> 

OFF meaning, that must be explictly turned on in both ends, or off,
meaning we do not send them, but we respond to them if other end sends
them?

> 2.  It is turned ON for diagnostics then turned OFF afterwards.  If someone
> chooses to leave PDM ON always, then that is explicitly chosen for their
> network.

I do not see any warning about that in the draft. Draft says in
section 3.6, that there must be default configuration parameter, but
does not provide default value for it.

> 3.  PDM is an OPTIONAL feature.  One may choose not to implement it at all.

True, but even the optional features can be used to attack systems,
and if we do not expect vendors to implement it, and because of that
it will be safe, then why are we even specifying it.

> Actually the problem is 1.  If you have done that, what do you need PDM for?  
> Many other things can be found - such as type of device, etc without resorting
> to PDM.

Or third option: attacker takes packet from A, and modifies the ESP
packets and inserts PDM header and sends them to B. B thinks A has
turned on PDM, and unless it is explictly forbidden by policy might
think that it should respond to the packets with PDM headers,
especially as section 3.5 says that PDM SHOULD be turned on by each
stack on a host node.

Now the host B starts sending PDM headers to host A, and if host A
does same, i.e., sees that host A has turned PDM on, turns it also on,
then attackers can identify that flow immediately.

This is one packet active attack against traffic flow confidentiality
of the ESP.

The correct fix for this is to make sure that PDM option headers are
only inserted after the ESP header, i.e., in the encrypted and
authenticated part of the packet.

> ------------------------------------------------------------------------------
> To: [email-masked]; [email-masked];
> [email-masked]

-- 
[email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 28 Sep 2016 19:20:53 +0300

[email-masked] writes:
> It is not clear to me how knowing which ESP packets belong to which
> traffic flow helps a passive attacker.   The attacker still does not
> know what is in the packet - the contents of the payload.  Indeed,
> ESP would normally mask TCP or UDP ports.  With PDM you can tell
> that there ARE multiple flows but you don't know if they are TCP,
> UDP, ICMP or anything else.  Most importantly, you don't know what
> is in the payload.

Sometimes that is only what is needed, and ESP tries to provide
protection against traffic flow confidentiality, and this option
breaks it.

For example finding out that this flow of packets is the control
traffic of the video stream, and this other flow of packets is the
actual video stream, the attacker can for example block the control
traffic, and make it so that user on the other end cannot stop the
video feed.

Or if there is 3 simultaneous video streams going out, it is much
harder to identify which video stream is what TV-program. If you can
separate them to 3 different video streams, it is much easier to
identify the actual video being watched by checking the packet
lengths.

There are most likely also other kind of attacks, and as this is
service as ESP provides, it is not for PDM to break it unless you
explictly spell it out that this is meant to break property of the
ESP. 

> If one follows the thinking of your objection, isn't any encrypted
> flow over TCP or UDP a problem since a passive attacker knows the
> 5-tuple for such flows?  For example, all TLS flows can be analyzed
> for traffic in your sense.  So, a flow over TLS (without PDM)
> actually leaks more information than an ESP flow WITH PDM.  Because
> with TLS, we even know that the flow is TCP and the port number.
> Neither of which you know with PDM with ESP.

Yes. And to fix that issue, people use IPsec which will hide the
information about separate TCP and UDP flows.

And now with PDM the IPsec will not provide that service anymore.

> >ESP decryption will allow seeing the PDM header values without issues.

You did not respond to this part, i.e., why is the PDM header outside
the ESP encrypted part, and why it is not inside the ESP?

It is supposed to be destination option, which is only meaningful to
the final destination of the packet, thus it can easily be inside the
ESP protection, as the final destination do know the keys etc will see
the decrypted option header.

> Thanks.  Should now be fixed.

What is the meaning of the section 4?

It is good background information, and might be moved to the appendix,
but I do not think it belongs here. It has text that mostly covers
other formats, not the format used here. Also it does not really
specify what does negative scaling values mean, and when are they
used.

If I understand correctly the actual timevalue conversion is so that

   delta_time = delta_time_from_packet * 2^Scale

where delta_time_from_packet is between 0x0000 and 0xffff, and scale
is between -127 and 128, and the units are either milliseconds,
microseconds, nanoseconds or picoseconds.

So the smallist time we can express with this is

delta_time_from_packet = 0x0001
scale = -127
unit = 11 = picoseconds

   delta_time = 0.0000000000000000000000000000000000000058 picoseconds
   = .0000000000000000000000000058 joktoseconds == 5.8 * 10^-51 seconds
   
and the maximum value is

delta_time_from_packet = 0xffff
scale = 128
unit = 00 = milliseconds

   delta_time = 22300404916163702203072254898040929737768960 milliseconds
   = 707141201045272139874183628172277 years...

so the range is definately enough. The question is that if the scale
is from -127 to 128, why do we even need the Time Base?

> >inside the encrypted transport mode ESP packets.

Leaking this information is new security weakness for the protocol,
which was designed to protect against those attacks. 

> 1. The intent of PDM is as a diagnostic feature.  PDM is OFF
> initially at the end hosts (client and server).  It is turned ON for
> diagnostics and then turned OFF afterwards.  If someone chooses to
> leave PDM ON always, then that is explicitly chosen.  Also, PDM is
> an OPTIONAL feature.  Either client or server operating system may
> choose not to implement it or use it.

The draft disagrees with this. It says there is configuration option
for it, but does not give default value for it, and says:

3.5 Implementation Considerations

   The PDM destination options extension header SHOULD be turned on by
   each stack on a host node. It MAY also be turned on only in case of
   diagnostics needed for problem resolution.

so it seems it is on by default. 

> 2. In your example above, it assumes that the signature verification
> packet (please let me know which exact packet and protocol you are
> referring to) is passing in the clear so that the attacker knows
> that it is the signature verification packet.  Possibly this is also
> a problem.

Key management packets are usually in clear, as they are there before
we have the actual keys we can use to protect the messages. Also it is
not very difficult to guess that 3rd and 4th message in port 500, are
the IKE AUTH packets, which will contain signatures.

Same thing with TLS.

Attackers will knows which packets contain signatures. Currently
attackers usually send those signature packets themselves, and measure
the time it takes for the device to calculate response. They can also
send garbage packets, and detect how far in checking the packets got
by checking how long it took for the other end to send error message
back.

All this kind of timing attacks are usually considered hard, as the
network delays cause big jitter on the timings, and they need to try
multiple times, and average the response times to get the information
they need.

This method will provide them easy way to bypass that issue. 

> 3.  Protocols often use blinding techniques to remove correlations
> between key and encryption time.   Other cryptographic algorithms
> can be implemented (or masked by a proxy) in a way that reduces or
> eliminates data dependent timing information.   So if timing
> information is being leaked, this is a flaw in the algorithm or the
> protocol.   In this case, we may be "blaming the messenger".  PDM is
> only reporting what is done.  The algorithm or protocol is the
> problem.

Yes. This option makes it easy for the attacker to use those broken
algorithms, protocols and implementations.

This is again new security weakness that this option opens. It was
harder before, after this it is easier. 

> If you can give me a hint as to what is not clear or what you think
> this draft DOES propose, then we will be happy to rewrite the
> abstract / background section. 

My current take is that this option proposes and attack vector against
several different protocols, and as such it does quite good job...

I have a feeling that this is not for which this draft was meant to
do. 
-- 
[email-masked]