[ippm] Re: Deb Cooley's Discuss on draft-ietf-ippm-encrypted-pdmv2-09: (with DISCUSS and COMMENT)

["[e-mail]" <[e-mail]>]

Deb,
Thanks for your comments.  There is quite a bit of work needed to respond to you adequately.  I believe we will be able to address your questions but I need to discuss with my co-authors.   I do not want to rush a response so I appreciate your patience while we sort ourselves out.

Thanks,
Nalini Elkins
CEO and Founder
Inside Products, Inc.
https://www.insidethestack.com
PresidentIndustry Network Technology Councilhttps://www.industrynetcouncil.org 

    On Thursday, October 24, 2024 at 01:55:12 PM GMT+2, Deb Cooley via Datatracker <[e-mail]> wrote:  
 
 Deb Cooley has entered the following ballot position for
draft-ietf-ippm-encrypted-pdmv2-09: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-ippm-encrypted-pdmv2/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

This is interesting work, but it currently reads as if it is a guidance
(informational) draft.  There are many missing details and significant issues
with the crypt parts of the draft:

Section 3.3, encrypted PDMv2 header:  If AES GCM is used, then there will be
data expansion for the IV and integrity mechanisms.  The encrypted PDM Data
cannot possibly be the same size as the unencrypted header.

Section 5.1:  Please reference a normative source for how this should be done. 
Using the TLS handshake is a good option.  Referencing it would take care of
many missing details.  Currently, there are not enough details here to make it
possible to implement securely.

Section 6.4:  Again recommend a normative reference that will handle all of
these details.  Currently this section is not sufficient for implementation.


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Section 3.3, Epoch:  please state that this value starts at 0, and is
incremented every time a new SessionTemporaryKey is updated.

Section 3.3, Global Pointer:  Agree w/ John Scudder's comment on this
(including the privacy section comment).  It is not a pointer.  If the name
isn't entrenched, it should be changed.

Section 3.3, reserved bits:  Classically, these should be verified to be
correct (i.e. all 0) and then ignored.  Given this is inside the encrypted
header, it should not cause a DOS.  Please add the 'verify to be all 0'
requirement.

Section 5.2:  Why is this so far down in the draft?  Recommend moving it up
closer to the top of the draft.