LTANS WG had produced an RFC (RFC 5698) to protect the relying parties from weak algorithms.
If that RFC is implemented on the certificate consuming side, these attacks will be thwarted. From: therightkey [mailto:therightkey-boun...@ietf.org] On Behalf Of Phillip Hallam-Baker Sent: Thursday, January 02, 2014 4:58 PM To: Leif Johansson Cc: therightkey@ietf.org; Paul Hoffman; Jacob Appelbaum Subject: Re: [therightkey] DNSNMC deprecates Certificate Authorities and fixes HTTPS security On Thu, Jan 2, 2014 at 4:00 PM, Leif Johansson <le...@mnt.se<mailto:le...@mnt.se>> wrote: 2 jan 2014 kl. 21:25 skrev Phillip Hallam-Baker <hal...@gmail.com<mailto:hal...@gmail.com>>: > Please don't overstate the results of > the excellent research that you did; doing so diminishes the > research. I'm not overstating anything. I think you don't understand what we actually did if you think that later, patching things will somehow magically stop previously successful attacks... You are confusing people by using a valid attack against the algorithm to argue against the trust model. PKIX is designed on the assumption that the digest algorithm chosen is secure against a second preimage attack. The fundamental flaw in the pkix trust model is that there is no deployable mechanism for limiting the impact of such an attack. That realization should inform future design and that bit is certainly on topic ;-) It is on topic but not limited to PKIX. We have since learned that algorithm agility is not quite the security benefit we once thought as the security of the system is determined by the weakest algorithm you support, not the strongest one you implement. Problem is that I can't see a way to really control this type of attack without a very considerable cost in usability and I think it would constrain other defenses. Anyone using Windows XP in the Enterprise for any purpose other than finding viruses is guilty of security malpractice at this point. It is an obsolete OS that would have been at EOL if lazy sysadmins hadn't begged to keep it. My current solution in my email project is to attempt to require SHA512 for all certificates. But I am not sure that is actually sustainable. -- Website: http://hallambaker.com/
_______________________________________________ therightkey mailing list therightkey@ietf.org https://www.ietf.org/mailman/listinfo/therightkey
