Re: [ippm] New Version Notification for draft-elkins-ippm-encrypted-pdmv2-00.txt

[Tommaso Pecorella <[e-mail]>]

Hi all,

I’d like to share my 2cents on some points that have been mentioned about encryption use in PDMv2.

Yes, encryption will add some delays to the PDM processing. In particular we expect delays in the following points:
- Encryption and decryption time
- Packet transmission
- Key renewal
- Registration phase time

Encryption and decryption time shouldn’t be a major concern since PDMv2 is an end-to-end header, and we assume that end devices will have enough processing power. Moreover, the data to encrypt is small and fixed-length. Hence, the encryption can be considered as a near-constant-time operation (caveats apply, we’ll discuss about them in the presentation). 

Packet transmission (encrypted headers are larger) can be taken into account as well, as the size is known in advance.

Key renewal can be optimized, so that it doesn’t affect the packet processing time.

Registration phase is a one-time phase that should happen very infrequently, and it is not going to affect the actual PDMv2 packet flow.

We do not expect any other significant points of time degradation due to encryption and decryption. Of course we might find something we don’t expect, and that’s why we always welcome comments and suggestions.

Last but not least, even if Encryption is important (for confidentiality and integrity), we want to stress that encryption is optional.
If the network administrator can be reasonably sure that an attacker can not leverage PDMv2 headers to build an attack on the infrastructure, then encryption can be skipped.

In the RFC we will fully describe why confidentiality and integrity are important, what kind of attacks we foresee if the headers are not protected, and what countermeasures the network administrator can use as a substitute of header encryption.

Best regards,

Tommaso and Adnan



> On 5 Jul 2021, at 18:52, Ameya Deshpande <ameyanrd=[e-mail]> wrote:
> 
> Hi Paolo,
> 
> Thanks for your comments. Please check the inline reply.
> 
> > Also,  I assume that PDMv2 is mainly used by end stations (e.g. hosts instead of routers). If this is the case, then I don’t expect that the performance degradation due to encryption is a serious issue. Do you see other different cases where instead degradation may be a concern? 
> 
> When using encrypted PDMv2, we have a bigger packet to send as
> the size of encrypted data is more than the corresponding plaintext data.
> This can increase the timing slightly as the packet size has increased.
> 
> For using encrypted PDMv2, we have an initial registration phase where
> we negotiate the shared secret (using KEM). We have also given a registration
> mechanism for enterprises with many servers and clients. However, this will
> be done before transmitting PDMv2 packets.
> 
> We intend to have a side-meeting where we will explain HPKE and be able
> to thoroughly discuss these points.  When we are able to schedule it, we will
> let you know.  The registration to schedule side meetings has not yet opened.
> 
> Thanks,
> Ameya Deshpande
> On Monday, 5 July, 2021, 10:19:21 pm IST, Ameya Deshpande <ameyanrd=[e-mail]> wrote:
> 
> 
> Hi Robert,
> 
> Thanks for your comments. Please check the inline comments.
> 
> > - The latest HPKE draft expired just last week. That means it's some time before general implementation. I'm a mainframer, mostly, so I suspect that makes it even longer before I'll see implementation for _production_ use. Further, I don't want the implementation of PDM in more secure environments delayed because of encryption-method concerns. 
> 
> We have kept an option for no-encryption in PDMv2 as well. And it is kept exactly for
> the same reason you mentioned. Connections over encrypted medium (say VPN tunnels),
> link-local network, or any secured company domain can choose to use PDMv2 unencrypted.
> 
> > - When we generate the PDM structure and determine the timing, we want that to be as close to the wire as possible. The PDM timing was very granular, so this will add a variable amount of time to the time the packet is determined to be spending in transmission; the encryption delay is now part of the transmission time.
> 
> Yes, for a PDM-to-PDM machine, the round trip time, a.k.a DELTATLS, will include the two encryption
> and two decryption times. We are trying our best to minimize any added timing due to the encryption
> in PDMv2, but we feel that encryption is important, so we're trying to achieve a correct balance.
> 
> Thanks,
> Ameya Deshpande
> 
> On Monday, 5 July, 2021, 9:57:51 pm IST, [e-mail] <[e-mail]> wrote:
> 
> 
> Hi Robert,
> [Posting for some of the co-authors.]
> We fully agree with your concerns. However, we’re confident that HPKE will reach the RFC status soon. Moreover, also other protocols (e.g., MLS, see https://www.ietf.org/archive/id/draft-ietf-mls-architecture-06.txt <https://www.ietf.org/archive/id/draft-ietf-mls-architecture-06.txt>) are using it.
> About HPKE itself, there are two different aspects to consider: HPKE (as an architecture, API, etc.) and the cryptographic functions used by HKPE. While HPKE is still in draft, the cryptographic functions are well-known and proven. Hence, we don’t expect any concern related to the encryption methods used by HPKE.
> The fact that Tommy confirms that it is being implemented and deployed reinforces our confidence on the fact that its availability is not going to be a critical point.
> 
> In any case, we will take this point into consideration, as it is a valid concern.
> 
> Best regards,
> 
> Nalini, Tom, and Adnan
> 
>  
> 
> 
> On Thursday, July 1, 2021, 02:05:31 PM PDT, Hamilton, Robert <rhamilton=[e-mail]> wrote:
> 
> 
> I am interested in the encryption of the PDM header, just because I've done symmetric-key encryption with pseudorandom numbers and pseudorandom obfuscation algorithms for key management. I see that we are interested in using HPKE. I have just a few concerns:
> 
> - The latest HPKE draft expired just last week. That means it's some time before general implementation. I'm a mainframer, mostly, so I suspect that makes it even longer before I'll see implementation for _production_ use. Further, I don't want the implementation of PDM in more secure environments delayed because of encryption-method concerns.
> 
> - When we generate the PDM structure and determine the timing, we want that to be as close to the wire as possible. The PDM timing was very granular, so this will add a variable amount of time to the time the packet is determined to be spending in transmission; the encryption delay is now part of the transmission time.
> 
> Still reviewing; I'll be back with more thoughts.
> 
> R;
> 
> 
> Rob Hamilton
> Infrastructure Engineer
> Chemical Abstracts Service
> 
> -----Original Message-----
> From: ippm <[e-mail] <mailto:[e-mail]>> On Behalf Of [e-mail] <mailto:[e-mail]>
> Sent: Thursday, July 1, 2021 1:45 PM
> To: IETF IPPM WG <[e-mail] <mailto:[e-mail]>>
> Cc: [e-mail] <mailto:[e-mail]>
> Subject: [EXT] Re: [ippm] Fw: New Version Notification for draft-elkins-ippm-encrypted-pdmv2-00.txt
> 
> [Actual Sender is [e-mail] <mailto:[e-mail]>]
> 
> IPPM,
> 
> Please do take a look at this draft.
> 
> I think that iOAM will need encryption as well.   We have spent quite a bit of time thinking over these issues.  We even have 2 cryptographers from Italy involved as co-authors.   I want to do a side meeting where we can have quite a bit more time to discuss this but would love to have comments from the group on the list.
> 
> I am very reluctant to push PDM out to the wider world without encryption.  I feel that we will become the attacker's best friend.
> We have modified the Linux kernel to include PDM but as I say, without encryption, we do not wish to release.
> 
> 
> Thanks,
> 
> Nalini Elkins
> CEO and Founder
> Inside Products, Inc.
> https://smex12-5-en-ctp.trendmicro.com:443/wis/clicktime/v1/query?url=www.insidethestack.com&umid=61654d20-9615-453c-80b2-c06c82268e9d&auth=3c97381e9a30865a1a3f3ad58750d85b2b059558-86a3cb083390e2163fd0daaf45646c2a55adf702 <https://smex12-5-en-ctp.trendmicro.com/wis/clicktime/v1/query?url=www.insidethestack.com&umid=61654d20-9615-453c-80b2-c06c82268e9d&auth=3c97381e9a30865a1a3f3ad58750d85b2b059558-86a3cb083390e2163fd0daaf45646c2a55adf702>
> [phone]
> 
> 
> 
> 
> 
> 
> On Tuesday, June 1, 2021, 09:06:39 AM PDT, [e-mail] <mailto:[e-mail]> <[e-mail] <mailto:[e-mail]>> wrote: 
> 
> 
> 
> 
> 
> Hello IPPMers!
> 
> We have just posted a new draft to encrypt PDM data.   We feel that this is an important feature to add before promoting widespread adoption of PDM.
> 
> We would appreciate any thoughts or comments from the group.
> 
> Thanks,
> 
> Nalini Elkins
> CEO and Founder
> Inside Products, Inc.
> https://smex12-5-en-ctp.trendmicro.com:443/wis/clicktime/v1/query?url=www.insidethestack.com&umid=61654d20-9615-453c-80b2-c06c82268e9d&auth=3c97381e9a30865a1a3f3ad58750d85b2b059558-86a3cb083390e2163fd0daaf45646c2a55adf702 <https://smex12-5-en-ctp.trendmicro.com/wis/clicktime/v1/query?url=www.insidethestack.com&umid=61654d20-9615-453c-80b2-c06c82268e9d&auth=3c97381e9a30865a1a3f3ad58750d85b2b059558-86a3cb083390e2163fd0daaf45646c2a55adf702>
> [phone]
> 
> 
> 
> 
> 
> 
> ----- Forwarded Message -----
> 
> From: "[e-mail] <mailto:[e-mail]>" <[e-mail] <mailto:[e-mail]>>
> To: [e-mail] <mailto:[e-mail]> <[e-mail] <mailto:[e-mail]>>; Adnan Rashid <[e-mail] <mailto:[e-mail]>>; Ameya Deshpande <[e-mail] <mailto:[e-mail]>>; Michael Ackermann <[e-mail] <mailto:[e-mail]>>; Nalini Elkins <[e-mail] <mailto:[e-mail]>>; Tommaso Pecorella <[e-mail] <mailto:[e-mail]>>
> Sent: Tuesday, June 1, 2021, 12:01:47 PM EDT
> Subject: New Version Notification for draft-elkins-ippm-encrypted-pdmv2-00.txt
> 
> 
> 
> A new version of I-D, draft-elkins-ippm-encrypted-pdmv2-00.txt
> has been successfully submitted by Nalini Elkins and posted to the
> IETF repository.
> 
> Name:        draft-elkins-ippm-encrypted-pdmv2
> Revision:    00
> Title:        Encrypted IPv6 Performance and Diagnostic Metrics Version 2 (EPDMv2) Destination Option
> Document date:    2021-06-01
> Group:        Individual Submission
> Pages:        16
> URL:            https://www.ietf.org/archive/id/draft-elkins-ippm-encrypted-pdmv2-00.txt <https://www.ietf.org/archive/id/draft-elkins-ippm-encrypted-pdmv2-00.txt>
> Status:        https://datatracker.ietf.org/doc/draft-elkins-ippm-encrypted-pdmv2/ <https://datatracker.ietf.org/doc/draft-elkins-ippm-encrypted-pdmv2/>
> Htmlized:      https://datatracker.ietf.org/doc/html/draft-elkins-ippm-encrypted-pdmv2 <https://datatracker.ietf.org/doc/html/draft-elkins-ippm-encrypted-pdmv2>
> 
> 
> Abstract:
>   RFC8250 describes an optional Destination Option (DO) header embedded
>   in each packet to provide sequence numbers and timing information as
>   a basis for measurements.  As this data is sent in clear- text, this
>   may create an opportunity for malicious actors to get information for
>   subsequent attacks.  This document defines PDMv2 which has a
>   lightweight handshake (registration procedure) and encryption to
>   secure this data.  Additional performance metrics which may be of use
>   are also defined.
> 
>                                                                                   
> 
> 
> The IETF Secretariat
> 
> 
> 
> 
> _______________________________________________
> ippm mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/ippm <https://www.ietf.org/mailman/listinfo/ippm>
> 
> _______________________________________________
> ippm mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/ippm <https://www.ietf.org/mailman/listinfo/ippm>
> Confidentiality Notice: This electronic message transmission, including any attachment(s), may contain confidential, proprietary, or privileged information from CAS, a division of the American Chemical Society ("ACS"). If you have received this transmission in error, be advised that any disclosure, copying, distribution, or use of the contents of this information is strictly prohibited. Please destroy all copies of the message and contact the sender immediately by either replying to this message or calling 614-447-3600.
> 
> _______________________________________________
> ippm mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/ippm <https://www.ietf.org/mailman/listinfo/ippm>
> _______________________________________________
> ippm mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/ippm <https://www.ietf.org/mailman/listinfo/ippm>
> _______________________________________________
> ippm mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/ippm <https://www.ietf.org/mailman/listinfo/ippm>
> _______________________________________________
> ippm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ippm

--------------------------------------------------------------

When life gives you lemons, don’t make lemonade.
Make life take the lemons back! Get mad!
-- Cave Johnson

--------------------------------------------------------------

Tommaso Pecorella - Ph.D.

Assistant professor
Dpt. Ingegneria dell'Informazione
Università di Firenze

CNIT - Università di Firenze Unit

via di S. Marta 3
50139, Firenze
ITALY

email: [e-mail]
       [e-mail]

phone : [phone]
mobile: [phone]
fax   : [phone]