The certificate errors are kind of a design failure. Users are so used to clicking through messages they don't really understand, and this is just one more. Even the most alarming certificate errors are usually innocuous, in my experience - someone forgets to renew a certificate, or fails to get a new one for a domain change. That doesn't mean it's OK to ignore them, but we really need systems that don't cry wolf unless there's a really good chance that there's a wolf.
How do you propose to algorithmically determine if a certificate not matching a domain change is innocuous? This is a bit like suggesting having a "check engine" light that only comes on when there's an immediate risk of an engine fire.
Secondly, the system should make it harder for the administrator to make mistakes. For instance, the web server could refuse to serve https on a domain that it didn't have a certificate for. Or when a certificate nears its expiry date, the administrator should be getting plenty of reminders about it.
Thinking bigger, what if we tied it closer to the sensitive UI? What if only pages loaded securely could show a password field? What if rather than typing credit card numbers into boxes on a webpage, we were used to using a special browser interface that would only light up on secure pages?
"Multi-level insecure operating systems may have special levels for
attack programs; the evil bit MUST be set by default on packets
emanating from programs running at such levels. However, the system
MAY provide an API to allow it to be cleared for non-malicious
activity by users who normally engage in attack behavior."
This should say that the system MUST provide such an api. Otherwise, a you can find a situation where the reciever may have to allow evil packets to pass, because they are sent by a user who has no option of setting the evil bit to 0 for non-malicious activity. Kind of defeats the point.
"Fragments that by themselves are dangerous MUST have the evil bit
set. If a packet with the evil bit set is fragmented by an
intermediate router and the fragments themselves are not dangerous,
the evil bit MUST be cleared in the fragments, and MUST be turned
back on in the reassembled packet."
This places an undue burden on intermediate routers, as they now have to parse the packets and determine if a fragment is evil.
"Intermediate systems are sometimes used to launder attack
connections. Packets to such systems that are intended to be relayed
to a target SHOULD have the evil bit set."
These packets are not 'evil' in any technical sense. They are only a request for another computer to send evil packets.
"In networks protected by firewalls, it is axiomatic that all
attackers are on the outside of the firewall. Therefore, hosts
inside the firewall MUST NOT set the evil bit on any packets."
This is just stupid. If I am attempting to send malicious packets from within the firewall, I am already required to set the evil bit. Now I am also required not to. If I am sending a non malicious packet, I am already required to set the evil bit to 0.
Also, If I am on a computer behind a firewall, and attempt to send malicious packets to a computer outside of my firewall, I am still forbidden by this to set the evil bit. This will force attackers to either, break the spec, or give up their own firewall.
"Because NAT [RFC3022] boxes modify packets, they SHOULD set the evil
bit on such packets. "Transparent" http and email proxies SHOULD set
the evil bit on their reply packets to the innocent client host."
I must be mis-understanding this one, becuase non of those uses seems evil.
"Devices such as firewalls MUST drop all inbound packets that have the
evil bit set. Packets with the evil bit off MUST NOT be dropped.
Dropped packets SHOULD be noted in the appropriate MIB variable."
Dropping packets is a technichal inevitability, and a crucial part of TCP's anti-congestion stragety.
Just becuase the evil bit sounds like a good idea, does not mean we should go ahead and implement it without carfully looking at the technical implecations of the spec.