Re: [lamps] Martin Duke's Discuss on draft-ietf-lamps-cmp-updates-20: (with DISCUSS and COMMENT)

Martin:

The separation of the protocol from the algorithm document allows the algorithms to updated in the future without any changes to the protocol.  This lead to the removal of the mandatory algorithm profile in RFC 4210 Appendix D.2.

The new version is needed because of use of EnvelopedData instead EncryptedValue.  EnvelopedData (defined in RFC 5652) is better because it has built-in key management.

Other additions are essentially optional features, but these do not offer an opportunity for downdrade attack that I can see:
  *  Add new extended key usages for the registration authority and certification authority.
  *  Better support for batch processing of messages.
  *  Optional hashAlg field in CertStatus for signature algorithms that do not have a separate hash algorithm (like EdDSA).
  *  New general message types to request CA certificates, a root CA update, a certificate request template, or a CRL update.
  *  Extend the usage of polling to p10cr, certConf, rr, genm, and error messages.

Russ

> On Jun 2, 2022, at 10:52 AM, Martin Duke <martin.h.duke@gmail.com> wrote:
> 
> Hendrik,
> 
> Thanks for clarifying that the error messages are always authenticated. I agree that there is then no risk of downgrade, and I will clear my DISCUSS.
> 
> Although it doesn't affect anything given the above, I disagree that a V3 -> V2 downgrade would have no consequences. IIUC V3 is about introducing crypto agility, so presumably at one point V3 will have more advanced algorithms, and downgrading to V2 would prevent use of those. But again, that's an academic discussion now.
> 
> Martin
> 
> On Wed, Jun 1, 2022 at 11:05 AM Brockhaus, Hendrik <hendrik.brockhaus@siemens.com <mailto:hendrik.brockhaus@siemens.com>> wrote:
> 
> 
> > Von: Spasm <spasm-bounces@ietf.org <mailto:spasm-bounces@ietf.org>> Im Auftrag von Martin Duke via
> > Datatracker
> > 
> > 
> > ----------------------------------------------------------------------
> > DISCUSS:
> > ----------------------------------------------------------------------
> > 
> > As far as I can tell, CMP provides multiple optional levels of encryption and
> > authentication to protect its messages and components of that message.
> > However,
> > I gather that the transport substrate is allowed to be HTTP without TLS.
> > 
> > Given that, how does this protocol defend against version downgrade attacks? If
> > an on-path attacker responds to a client message with an error message
> > requiring an older version, do all configurations of CMP detect the
> > intervention?
> 
> There are only two changes to the ASN.1 syntax that require a V3 indication. To offer maximum backward compatibility with existing implementations the WG decided to go with an approach regarding version handling like with CMS. Therefore, we only use V3 for EnvelopedData and hashAlg filed in CertConf messages. The version handling is described in Section 2.20.
> 
> As CMP V3 does not resolve weaknesses of CMP V2, I do not see the risk of downgrade attacks. In addition all CMP messages should be either signature- or MAC-protected.
> 
> Hendrik
> _______________________________________________
> Spasm mailing list
> Spasm@ietf.org
> https://www.ietf.org/mailman/listinfo/spasm