The DHCP changes look good.  You can get multiple selection tuples in DHCPv4 if 
you want, but you seem to have decided its not important, which is fine by me.  
 Let me know if you want me to explain how to do that.

However, I reread the text on server selection, and it still has a serious and 
easily exploited security flaw.   In order for DNSSEC validation to save you 
from an attack, it has to be the case that you look the name up on every 
possible name server to see if any claim it's in a signed zone.   If one does, 
it has to be validated.   Right now it looks like if the "trusted" server 
doesn't sign the zone, the DNSSEC validation will never happen.   We dealt with 
this by trusting some networks more than others, and that eliminates a lot of 
the risk.

For example, in the case of a hotel net we're okay, because it will be less 
trusted than the 3G network.   The case I am most concerned with is when you 
VPN to a site that is not trusted: the default behavior will be to prefer the 
VPN link, because we presume it is more trustworthy.  A consultant who VPNs to 
multiple corporate sites could be spoofed here though, as could a user of a 
firewall bypass VPN.

Unfortunately, I don't know of a way to fix this that doesn't fire up both 
radios for every query.   Leaving this off by default is probably the best we 
can do, but it might be good to add more text to the security considerations 
section describing specific exploit scenarios.   The text in 10.1 and 10.2 
doesn't address this particular attack vector.

I would propose adding a requirement that there be a mode, off by default, 
enabled by UI, in which the resolver just fires up both radios, battery be 
damned, but I am not sure anyone would use it, because it would be difficult to 
explain why and when they should.

So practically speaking, I am just proposing a tweak to the security 
considerations.   I will send text if you don't object.   Sorry for the late 
review.
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop

Reply via email to