Re: [lamps] WG Last Call for draft-ietf-lamps-cms-mix-with-psk

[Tim Hollebeek <[e-mail]>]

Thanks for doing this, this is really interesting and useful.

-Tim

> -----Original Message-----
> From: Spasm <[e-mail]> On Behalf Of Hammell, Jonathan F
> Sent: Monday, May 27, 2019 9:31 AM
> To: '[e-mail]' <[e-mail]>
> Subject: Re: [lamps] WG Last Call for draft-ietf-lamps-cms-mix-with-psk
> 
> Classification: UNCLASSIFIED
> 
> Sorry for the late comment.  My colleagues and I did review the draft and
we
> have no suggestions for text changes.  We also produced a ProVerif model
> (attached) in an attempt to verify some of the cryptographic properties.
> Details are below.  Let me know if you have any questions or issues.
> 
> # Assumptions/limitations
> The model is limited to the Key Agreement algorithm and is bounded with
two
> hardwired originators and hardwired recipients.
> 
> We assume the DH key exchange is broken using a quantum computer such
> that the recipient private keys are known at the outset. We have modeled
this
> by revealing the recipient's DH private key on the channel.
> 
> All recipients have DH certificates signed by a trusted CA. These are
shared
> with all at beginning of the protocol.
> 
> In an effort to model configuration choices of key encryption and kdf
> algorithms, we included settings for using strong or weak algorithms (in
the
> quantum perspective). The model allows the attacker to modify the settings
to
> both the originator and the receivers' algorithm configuration to use
quantum-
> vulnerable algorithms.
> 
> # Security queries
> Our interpretation of the draft is that it is attempting to solve the
problem of
> maintaining the confidentiality of an encrypted cek from an opponent with
the
> ability to break the DH public keys with a quantum computer. Therefore our
> model is limited to proving confidentiality of the cek in the face of such
an
> attacker.
> 
> The model contains two types of queries:
> 
> 1. Sanity - Whenever a sender s sends an encrypted version of cek to an
> intended recipient r then recipient r receives the same cek from sender s
.
> 
> 2. Confidentiality-  An attacker cannot learn the cek during a protocol
run
> unless the sender uses weak crypto (in the quantum perspective).
> 
> # Running the model
> proverif -graph . Using_PSK_in_CMS_Keyagree.pv
> 
> ProVerif spits out a lot of info, but the important statements about the
queries
> are prefixed by the string "RESULT".
> 
> 
> 
> ---
> Re: [lamps] WG Last Call for draft-ietf-lamps-cms-mix-with-psk Russ
Housley
> <[e-mail]> Fri, 10 May 2019 15:00
> UTChttps://mailarchive.ietf.org/arch/browse/spasm/?q=mix-with-psk
> The only comment that I received is to add <CODE BEGINS> at the top of the
> ASN.1 module and <CODE ENDS> at the bottom of the ASN.1 module.  I will do
> that now.
> 
> Russ
> 
> 
> > On May 10, 2019, at 10:52 AM, Tim Hollebeek
> <mailto:[e-mail]&gt; wrote:
> >
> > It appears no one has any further comments on this document, and it is
> ready to proceed.
> >
> > -Tim
> >
> > From: Spasm <mailto:[e-mail]
> > <mailto:[e-mail]>> On Behalf Of Tim Hollebeek
> > Sent: Friday, April 19, 2019 10:45 AM
> > To: SPASM <mailto:[e-mail] <mailto:[e-mail]>>
> > Subject: [lamps] WG Last Call for draft-ietf-lamps-cms-mix-with-psk
> >
> > This is the LAMPS WG Last Call for "Using Pre-Shared Key (PSK) in the
> Cryptographic Message Syntax (CMS)" <draft-ietf-lamps-cms-mix-with-psk>.
> Please review the document and send your comments to the list by 6 May
> 2019.
> >
> > The datatracker page for the document is
> > https://datatracker.ietf.org/doc/draft-ietf-lamps-cms-mix-with-psk/
> > <https://datatracker.ietf.org/doc/draft-ietf-lamps-cms-mix-with-psk/%3
> > E
> >
> > Thanks,
> >
> > Tim
>