ietf
[Top] [All Lists]

Re: [ietf] DNS spoofing at captive portals

2010-09-24 13:18:47


c) draft-livingood-dns-redirect and draft-livingood-dns-malwareprotect

draft-livingood-dns-malwareprotect concerns what is primarily an opt-in
service to block known malware sites for end users.  Hopefully that is
less controversial than the redirect one, but who knows.

draft-livingood-dns-redirect was written to do two things.  First was to
document a relatively long-standing process in a reference-able IETF
document where no documentation previously existed.  Second was to
document the best or least worst way to approach it, if a party was
planning to do so.  Since that time, I've added a bunch of stuff related
to DNSSEC to make clear an incompatibility there.  I'm a bit conflicted
though about whether to keep it as informational or consider historic.

In any case, as noted below, I'm more than happy to consider any text that
might improve these document by providing more information on opposing
viewpoints, etc.


  descibe these "services" in a much too friendly tone;
  terms like "service" and "benefits for users" are clearly
  abuse of language -- the above IAB statement already indicates

Sorry you feel that way.  Operators view these as services and describe
them as such, so I am simply using that language.  As I do my next pass
through the documents I will review it for any non-neutral descriptors. Of
course, also feel free to email me a list of the ones you think I should
consider revising in some manner.

  that similar interference with the DNS causes severe damage
  to user perception and performance.

The 2nd draft concerns protection from malware, which is generally assumed
to be a service that users opt-into (a la OpenDNS, etc.).  Those users who
have decided to use such services very likely are much more concerned with
malware than the fact that FQDNs associated with malware would be blocked.
 Again, I'm quite willing to include text you wish to propose to capture
alternative viewpoints and criticisms, as that's an important part of such
a document IMHO.

  These drafts should clearly spell out the downside of these
  methods and their fundamental nature, being MitM attacks.

I'm happy to consider any text you would like to propose, and am quite
willing to include specific notes that some in the community consider the
techniques MitM attacks, in order to try to capture all viewpoints on the
subject.  Feel free to send any proposed text to me via email.

Regards,
Jason

_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf