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

[<[e-mail]>]

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
[phone]



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

Thanks for catching those.  Should now be fixed.

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

Thanks.  Should now be fixed.

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

Thanks. Should now be fixed.

--

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.

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



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. 


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

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.


-- [e-mail]