Re: [ippm] Eric Rescorla's No Objection on draft-ietf-ippm-6man-pdm-option-09: (with COMMENT)

[Nalini J Elkins <[e-mail]>]

     >Eric Rescorla has entered the following ballot position for draft-ietf-ippm-6man-pdm-option-09: No Objection
>Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
>for more information about IESG DISCUSS and COMMENT positions.


>The document, along with other ballot positions, can be found here:
>https://datatracker.ietf.org/doc/draft-ietf-ippm-6man-pdm-option/


>----------------------------------------------------------------------
>COMMENT:
>----------------------------------------------------------------------

>I think the description of timing attacks could use a bit more work.

>Specifically:

>- I am assuming that you should discard rather than using as timestamp
>  sources packets which fail ESP. This shouldn't be an issue for
>  transport mode because you process ESP first, but in tunnel mode
>  you allow either order, so it's a potential issue.


I believe some of this is addressed in section 4.3.   I can add that thedestination host may also wish to look at this behavior and to discard such packets.   

OLD------
4.3 PDM as a Covert Channel
   PDM provides a set of fields in the packet which could be used to   leak data.   But, there is no real reason to suspect that PDM would   be chosen rather than another part of the payload or another   Extension Header.
   A firewall or another device could sanity check the fields within the   PDM but randomly assigned sequence numbers and delta times might be   expected to vary widely.   The biggest problem though is how an   attacker would get access to PDM in the first place to leak data.    The attacker would have to either compromise the end host or have Man   in the Middle (MitM).  It is possible that either one could change   the fields.   But, then the other end host would get sequence numbers   and deltas that don't make any sense.   
   It is conceivable that someone could compromise an end host and make   it start sending packets with PDM without the knowledge of the host.    But, again, the bigger problem is the compromise of the end host.     Once that is done, the attacker probably has better ways to leak   data.
   Having said that, if a PDM aware middle box or an implementation   detects some number of "nonsensical" sequence numbers it could take   action to block (or alert on) this traffic.

New------ 4.3 PDM as a Covert Channel
   PDM provides a set of fields in the packet which could be used to   leak data.   But, there is no real reason to suspect that PDM would   be chosen rather than another part of the payload or another   Extension Header.
   A firewall or another device could sanity check the fields within the   PDM but randomly assigned sequence numbers and delta times might be   expected to vary widely.   The biggest problem though is how an   attacker would get access to PDM in the first place to leak data.    The attacker would have to either compromise the end host or have Man   in the Middle (MitM).  It is possible that either one could change   the fields.   But, then the other end host would get sequence numbers   and deltas that don't make any sense.   
   It is conceivable that someone could compromise an end host and make   it start sending packets with PDM without the knowledge of the host.    But, again, the bigger problem is the compromise of the end host.     Once that is done, the attacker probably has better ways to leak   data.
   Having said that, if a PDM aware middle box or an implementation (destination   host) detects some number of "nonsensical" sequence numbers or timing   information, it could take action to block, discard, or alert on this traffic.


>- It seems like you could use this technique for fine-grained>  timing of the cryptographic operations traffic keys as well (cf. Lucky 13),>  not just long-term keys as you say in S 4.4.

> Note that both of these attacks are not ameliorated by restricting
> to host and ports because one assumes that the attacker controls
> the network per 3552
I can change the language in section 4.4 as follows:
Old----   Depending on the nature of the cryptographic protocol used, it may be   possible to leak the long term credentials of the device.  For   example, if an attacker is able to create an attack which causes the   enterprise to turn on PDM to diagnose the attack, then the attacker   might use PDM during that debugging time to launch a timing attack   against the long term keying material used by the cryptographic   protocol.
New----   Depending on the nature of the cryptographic protocol used, it may be   possible to leak the credentials of the device.  For   example, if an attacker is able to create an attack which causes the   enterprise to turn on PDM to diagnose the attack, then the attacker   might use PDM during that debugging time to launch a timing attack   against the keying material used by the cryptographic protocol.

 Thanks,

Nalini Elkins
CEO and Founder
Inside Products, Inc.
www.insidethestack.com
[phone]