Re: [saag] SHA-1 is a Shambles: First Chosen-Prefix Collision on SHA-1

["Black, David" <[e-mail]>]

> [0] Watch out for an April 1 RFC "The attackerControlledData extension for
>     X.509" :-).

Be careful what you wish for ... after all, RFC 1149 was implemented :-) !!

https://en.wikipedia.org/wiki/IP_over_Avian_Carriers

Thanks, --David

> -----Original Message-----
> From: saag <[e-mail]> On Behalf Of Peter Gutmann
> Sent: Thursday, January 9, 2020 2:17 AM
> To: Phillip Hallam-Baker; [e-mail]
> Cc: IETF SAAG
> Subject: Re: [saag] SHA-1 is a Shambles: First Chosen-Prefix Collision on SHA-
> 1
> 
> 
> [EXTERNAL EMAIL]
> 
> Phillip Hallam-Baker <[e-mail]> writes:
> 
> >Those certificates are not actually at risk because they were originally
> >signed when SHA-1 was still trusted. It is the intermediate and EE certs that
> >are the concern.
> 
> In terms of the web PKI, they're also not at risk because they're not
> defending against anything that non-nation-state attackers care about.  And
> I'm not being snarky there, I mean that literally, there's no point in
> attackers investing anything more than the minimum necessary in trying to
> forge certs for web sites because they can do just as well without them (Refs:
> Too many to list here, but start with the APWG data if you need something to
> go from).
> 
> However, let's look at the actual threat a bit more closely, and in particular
> from the point of view of someone who has legacy infrastructure they need to
> work with and wants to know where and what needs shoring up.  The attack
> requires that someone be able to stuff arbitrary binary data that the victim
> won't check into a signed message, as well as causing the victim to
> reinterpret the message in an entirely different manner than originally
> intended.
> 
> This happens to work quite well for OpenPGP/GPG, but is more tricky for certs
> both because there's no attackerControlledData extension (yet [0]) and because
> of the amount of decoration that ASN.1 adds to anything that's being encoded.
> So what the attacker would have to do is define a new extension
> attackerControlledData and create a cert where it's present in there, to
> mirror the (mis-)use of JPEG images with attached binary garbage in OpenPGP/
> GPG (this is from reading the paper on-screen, I still need to get a printed
> version to study properly, in particular to try and understand whether the
> process described in section 6.1 can even be applied to an X.509 cert), and
> also to figure out how to get the victim to reinterpret what's being signed as
> was done for the OpenPGP data.
> 
> A simple countermeasure there for long-lived signatures where this type of
> attack is a threat (assuming the ASN.1-reinterpretation is achievable), e.g.
> X.509 certs in legacy deployments, is that if SHA-1 is being used, reject
> certs with an unknown extension, or one with type-and-value fields of unknown
> type.
> 
> Peter.
> 
> [0] Watch out for an April 1 RFC "The attackerControlledData extension for
>     X.509" :-).
> 
> _______________________________________________
> saag mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/saag