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

Tero Kivinen <kivinen@iki.fi> Wed, 28 September 2016 16:21 UTC

Return-Path: <kivinen@iki.fi>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF05712B1F5; Wed, 28 Sep 2016 09:21:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.121
X-Spam-Level:
X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DdChhqZsnB4n; Wed, 28 Sep 2016 09:20:59 -0700 (PDT)
Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A829D12B0FA; Wed, 28 Sep 2016 09:20:58 -0700 (PDT)
Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id u8SGKsUa014782 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 28 Sep 2016 19:20:54 +0300 (EEST)
Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id u8SGKrG6029638; Wed, 28 Sep 2016 19:20:53 +0300 (EEST)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-ID: <22507.60901.665544.878052@fireball.acr.fi>
Date: Wed, 28 Sep 2016 19:20:53 +0300
From: Tero Kivinen <kivinen@iki.fi>
To: nalini.elkins@insidethestack.com
In-Reply-To: <1264225155.363685.1474644268281@mail.yahoo.com>
References: <22495.62038.771947.984586@fireball.acr.fi> <1264225155.363685.1474644268281@mail.yahoo.com>
X-Mailer: VM 8.2.0b under 24.5.1 (x86_64--netbsd)
X-Edit-Time: 35 min
X-Total-Time: 35 min
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/8a1lluE1Uc9qmgXeEdyFe6c7mm8>
Cc: "iesg@ietf.org" <iesg@ietf.org>, "draft-ietf-ippm-6man-pdm-option.all@tools.ietf.org" <draft-ietf-ippm-6man-pdm-option.all@tools.ietf.org>, "secdir@ietf.org" <secdir@ietf.org>
Subject: Re: [secdir] Secdir review of draft-ietf-ippm-6man-pdm-option-05
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 28 Sep 2016 16:21:00 -0000

nalini.elkins@insidethestack.com 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
> (831) 659-8360
> 
> 
> 
> ________________________________
> From: Tero Kivinen <kivinen@iki.fi>
> To: iesg@ietf.org; secdir@ietf.org; draft-ietf-ippm-6man-pdm-option.all@tools.ietf.org 
> 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. 

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

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

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

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

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

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

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

I have a feeling that this is not for which this draft was meant to
do. 
-- 
kivinen@iki.fi