Re: [lamps] Review draft-ietf-lamps-cms-mix-with-psk-00

[Jim Schaad <[e-mail]>]

Reading the document:


* Spencer complained about the fact that I was using the term quantum
resistant in the COSE re-charter effort rather than something like
"resistant to quantum computer attacks" you may want to pre-empt this.

* Section 5 - did you really mean to use 'inout' here?

* I am missing the discussion about what the KDK length is going to be for a
key agreement algorithm.   Am I just blind?

Jim


> -----Original Message-----
> From: Russ Housley <[e-mail]>
> Sent: Monday, November 19, 2018 8:48 AM
> To: Jim Schaad <[e-mail]>
> Cc: SPASM <[e-mail]>
> Subject: Re: Review draft-ietf-lamps-cms-mix-with-psk-00
> 
> Jim:
> 
> Thanks for the careful review.  I just posted -01 to resolve your
comments.
> 
> The biggest change is the addition of Section 5 on key derivation.
> 
> Russ
> 
> 
> > On Nov 9, 2018, at 2:05 AM, Jim Schaad <[e-mail]> wrote:
> >
> > Abstract:  Needs to be re-worded " if existing syntax the does not
> > accommodated them."
> >
> > Section 1: Needs to be re-worded "if current syntax the does not
> > accommodated them."
> >
> > Section 1: Needs to be re-worded: " by mixing with a strong PSK with
> > the output"
> >
> > Section 2 -  Which key? "generates the key"  Pushing something from
> > the next two sentences forward would be useful.  Not talking about
> > generating the ephemeral DH key.
> >
> > Section 2 - you have not introduced the KDK yet and now I am creating
one.
> > Perhaps a simple discussion on how what happens is that an additional
> > key wrap is inserted using ...
> >
> > Section 2 - It would be nice to add a sentence where you say that you
> > are introducing two new management techniques to say that they are
> > agnostic towards the underlying key management technique.
> >
> > Section 3 - I am wondering if it would make more sense to use the
> > KEKIdentifier structure instead of just having an octet string for the
> > PreSharedKeyIdentifier type?
> >
> > Section 4 - This is twice that I have read this and am unclear what we
> > are doing.  The sentence "private key and recipient's public key to
> > generate a pairwise key"  From this and from information in my mind I
> > am not completely clear that this is the DH pairwise key or something
else.
> >
> > Summary:  Is it your thought that I should be able to implement this
> > document as written?  A the moment I do not believe that this is
possible.
> > Do we need to define how the KDF function operates?
> >
> > Jim
> >
> >
> >
> >
> >