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

From: Spencer Dawkins at IETF <[email-masked]>
Date: Sun, 25 Jun 2017 14:11:48 -0500

Hi, Nalini,

On Mon, May 22, 2017 at 10:40 AM, Nalini J Elkins <
[email-masked]> wrote:

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

I'm not seeing this text in -12. Did I miss it?

Spencer

> Thanks,
> Nalini Elkins
> CEO and Founder
> Inside Products, Inc.
> www.insidethestack.com
> (831) 659-8360

---

From: Nalini J Elkins <[email-masked]>
Date: Mon, 26 Jun 2017 17:04:26 +0000 (UTC)

Spencer,

Thank you for catching that.  I had not received a reply from Eric, so I had not made the changes.   I was waiting to hear if he had any objection to the suggestion.

I have now posted a new draft incorporating the change.

Thanks,

Nalini Elkins
CEO and Founder
Inside Products, Inc.
www.insidethestack.com
(831) 659-8360

________________________________
From: Spencer Dawkins at IETF <[email-masked]>
To: Nalini J Elkins <[email-masked]> 
Cc: Eric Rescorla <[email-masked]>; The IESG <[email-masked]>; "[email-masked]" <[email-masked]>; Bill Cerveny <[email-masked]>; "[email-masked]" <[email-masked]>; Al Morton <[email-masked]>; "[email-masked]" <[email-masked]>
Sent: Sunday, June 25, 2017 12:11 PM
Subject: Re: Eric Rescorla's No Objection on draft-ietf-ippm-6man-pdm-option-09: (with COMMENT)

Hi, Nalini,

On Mon, May 22, 2017 at 10:40 AM, Nalini J Elkins <[email-masked]> wrote:

>
>
>>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
>
>>https://datatracker.ietf.org/ doc/draft-ietf-ippm-6man-pdm- option/
>
>
>
>
>
>>----------------------------- ------------------------------ -----------
>
>>COMMENT:
>
>>----------------------------- ------------------------------ -----------
>
>
>
>   Having said that, if a PDM aware middle box or an implementation (destination
>   information, it could take action to block, discard, or alert on this traffic.
>
>
>
>
>
>
>>  timing of the cryptographic operations traffic keys as well (cf. Lucky 13),

Spencer