Re: [saag] NSA bug in Windows 10

[Dan Brown <[e-mail]>]

> -----Original Message-----
> From: Benjamin Kaduk <[e-mail]>
> >
> > If my presumption above is correct, then it seems that this part of
> > RFC3280 was not followed in this bug, since the parameters were taken
from
> an
> > untrustworthy in-band delivery.   That said, I wonder if RFC3280
adequately
> > emphasized this point? Could it have used a MUST?
> 
> I remember reading something that involved taking an existing signature
made
> by a trusted root from a legitimate certificate issued by that root, and
re-using
> that signature with different domain parameters.  That would seem to imply
> that the trusted root is properly being used, but the validation code for
the
> signatures in the chain was flawed.

Well, that attack does not match what I read.  

In what I read, a fake root cert is sent, and the receiver uses it.    Some
claim the bug is an incomplete match between the fake and real root cert,
but I claim the real bug is using the received cert at all. 

The receiver should just use the real root cert.  The receiver should keep a
full copy of the real root cert, to do this.  The receiver should discard
received root cert.   (But, perhaps, if the sender sends a root cert, then
the receiver may insist on an exact match, although such checks might allow
some kind of weak profiling attack - if there a multiple versions of the
real cert.)  Actually, the sender should not even send a copy C0' the root
cert, since C1, being allegedly issued by C0, should already identify C0
sufficiently, through the issuer field, no?  Who is the sender to tell the
receiver to trust C0'?

RFC 3280 is written as if the receiver did not have the real root cert C0,
but, for some reason has enough information about C0 to conduct a partial -
but secure if all the steps are done - match with a sent version C0' of C0.

To repeat, my view is that several claims of the fragility arising from the
excess of parameters in ECC certs is actually red herring. The fragility is
in RFC 3280, which seems to imply that the receiver does not keep C0' and
does some kind of secure, but partial match.  

By the way, new algorithms, from the land of PQC, are arriving soon, to a
PKI near you.  Off hand, I have no clue what parameters these new
algorithms. But I guess that they will ship with some kind of parameters,
since both the new algorithms and quantum computer are a moving target.
Instead of decrying parameters, just verify the signed parameters, use a
real root for the root parameters.


----------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.