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

[<[e-mail]>]

Thanks, Tero.  Again, my comments inline. Nalini Elkins
Inside Products, Inc.www.insidethestack.com(831) 659-8360

      From: Tero Kivinen <[e-mail]>
 To: [e-mail] 
Cc: "[e-mail]" <[e-mail]>; "[e-mail]" <[e-mail]>; "[e-mail]" <[e-mail]>
 Sent: Wednesday, September 28, 2016 9:20 AM
 Subject: Re: Secdir review of draft-ietf-ippm-6man-pdm-option-05
   
[e-mail] writes:
> 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 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.

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

OK.  I am convinced.  I will tell you though that some of us in IPPM, we were quite excited (possibly naively) about being able to get some performance metrics for ESP.
I wonder if it would be acceptable to say that PDM could be put into the Destination Option which precedes ESP if it is for an enterprise customer who owns the infrastructure and wishes to manage the network that way.  Otherwise, I can change to say that only the Dest Opt following ESP can be used.

> 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.
OK.  Pls see above.

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

>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.
Pls see above.

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

>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.
Let me review this again with one of my co-authors.

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

The time base is so that one does not have to be committed to picoseconds / milliseconds, etc.    Even in your example, I believe you used "unit" or time base.  Our thinking was that we wanted future proof so as to be able to handle very small values and very large (as may be needed for DTN, for example).   We can see if we can express years in picoseconds and see what happens.   Then, the unit would always be picoseconds.

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

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

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

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

Will change to say that it MUST be turned on only by the stack and default value should be OFF.
"The PDM destination options extension header MUST be turned on only by administrative action at
  each stack on a host node.  The default mode for PDM is OFF."

> 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. 
OK.  So, are you saying that PDM is attack vector for TLS and not just for ESP?
> 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. 
OK.

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

>My current take is that this option proposes and attack vector against
>several different protocols, and as such it does quite good job...
Maybe I have missed my calling.   I should be designer of attack vectors!   (Just kidding.  HAHAHA.  Meant only as a  joke!)  

>I have a feeling that this is not for which this draft was meant to do. 
No, obviously not.   So, now I am not sure where we are.   Is there a complete objection to this draft or are there changes which can be made which would make this acceptable?

-- 
[e-mail]