Re: Root name server changes -> bind

[Mark J Cox <mjc () redhat com>]

> #3: Second solution, and the better one that is harder to implement I
> imagine, is to care a lot less about where it is contacting and care a lot
> more about the information it is receiving. Digital signatures, MD5 hashes
> (where would it get those from though) or some other form of validation of
> the content it receives would help reduce risk significantly.

This is what I bet most of the vendors represented here do; for example 
the Red Hat Network client 1) contacts the server at Red Hat over SSL, 2) 
verifies that the certificate of the site it's connecting to was issued by 
a CA hardcoded into the distro, 3) will only install packages without 
prompting that are digitally signed by a previously-imported public key.

If any one of those mechanisms failed I would expect it to generate a CVE 
(even though the security of the system as a whole isn't broken unless all
of them break together).

This sort of update mechanism isn't that difficult to implement.  So 
should you give a CVE to an update mechanism that fails to implement a 
secure update process?  absolutely.

Mark