Just to depersonalize it a bit so it's not only Ryan responding - what Ryan
is saying is correct. Mozilla's blog post uses the phrase "impersonating a
website" to describe non-phishing attacks, such as performing active MITM
attacks that modify or replace (or surveil) data in flight, or relying on
cached DNS data from a domain which recently changed hands to otherwise get
"in front" of the connection to the authorized website. This is
impersonation in the more narrow, technical sense of having subverted
technical assurance guarantees that cause a user's client software to be
unable to realize they're not talking to the intended destination -- not in
the sense of impersonating a hostname or organization to deceive humans.

In other words, neither of those are phishing attacks. Phishing isn't
really relevant to this discussion at all, so it would be better to focus
the discussion on the security improvements that Mozilla cites in their
post, which relate to mitigating damage from key compromise, improving the
web's agility in replacing old or compromised ciphers/protocols/techniques,
and giving domain owners stronger assurance over the security of
connections to the domains they acquire.

On Thu, Jul 9, 2020 at 7:17 PM Ryan Sleevi via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> >
> > Now that I have proven beyond a shadow of a doubt that we are talking
> > about phishing, feel free to debate the merits of my points raised in my
> > original email.
> >
>
> Thanks Paul. I think you're the only person I've encountered who refers to
> key compromise as phishing, but I don't think we'll make much progress when
> words have no meaning and phishing is used to describe everything from
> "monster in the middle" to "cache poisoning".
>
> Since, to use the same analogy, everything from speed limits and signs to
> red light cameras to speed traps to roundabouts is being called "speed
> bumps", it's not worth engaging further.
> _______________________________________________
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>


-- 
Eric Mill
617-314-0966 | konklone.com | @konklone <https://twitter.com/konklone>
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Reply via email to