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

[Tero Kivinen <[e-mail]>]

[e-mail] 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.
> 
> 1.  PDM is OFF initially at the end hosts (client and server)

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.

> 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.

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.

> ------------------------------------------------------------------------------
> From: Tero Kivinen <[e-mail]>
> To: [e-mail]; [e-mail];
> [e-mail]
> Sent: Monday, September 19, 2016 7:12 AM
> Subject: Secdir review of draft-ietf-ippm-6man-pdm-option-05
> 
> 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.
> --
> [e-mail]
> 

-- 
[e-mail]