Re: [Dime] Benjamin Kaduk's Discuss on draft-ietf-dime-rfc4006bis-08: (with DISCUSS and COMMENT)

[Benjamin Kaduk <[e-mail]>]

On Thu, May 24, 2018 at 02:17:31PM -0500, Ben Campbell wrote:
> 
> 
> > On May 24, 2018, at 8:16 AM, Benjamin Kaduk <[e-mail]> wrote:
> > 
> > ... it's unclear to me that this document is the right place for
> > such guidance.  That is, instead of a concrete recommendation, I had
> > in mind just giving some extra facts that would allow the reader to
> > consider the security implications of their deployment (this is the
> > Security Considerations, after all), as in something like:
> > 
> > This document includes a redirection facility whereby the service
> > provider can redirect (in an application-specific way) the end user
> > to an alternate location when their credits have expired.  This is
> > useful in that it allows for the user to return to normal service
> > quickly, but also exposes additional risks and attack surface.  In
> > particular, this redirection can potentially occur at an
> > arbitrary point in a user's session, potentially without any
> > additional contextual confirmation available to the user that the
> > redirection is driven by the network.  Such a confirmation is
> > important because, in many application protocols, the communication
> > peer is also capable of inducing redirection, and when the peer is
> > an attacker, the redirection can be to an attacker-controlled site.
> > In particular, such sites may be "phishing" sites designed to appear
> > similar to legitimate payment sites in an attempt to obtain users'
> > payment information for fraudulent uses.  Because of the potentially
> > harmful consequences of arbitrary redirection by an attacker (such
> > as to phishing sites), it can be important for users and service
> > providers to be aware of the risk and take measures to ensure that
> > sensitive information (such as payment information) is only used for
> > legitmiate purposes.  If an out-of-band signalling channel is
> > available to provide contextual information that a redirection is
> > triggered by the network as opposed to a communications peer, that
> > can provide a highly effective mechanism for remediating this class
> > of risk.
> > 
> > (The above may well be too wordy and could benefit from editing, of
> > course.)
> 
> Based on our discussion on the telechat, how about something like the following?
> 
> "This document includes a redirection facility whereby the service
> provider can redirect (in an application-specific way) the end user
> to an alternate location when their credits have expired.  This is
> useful in that it allows for the user to return to normal service
> quickly, but also exposes additional risks and attack surface.  In
> particular, this redirection can potentially occur at an
> arbitrary point in a user's session, potentially without any
> additional contextual confirmation available to the user that the
> redirection is driven by the network.  This lack of confirmation matters
> because, in many application protocols, the communication
> peer is also capable of inducing redirection. When the peer is
> an attacker, the redirection can be to an attacker-controlled site.
> In particular, such sites may be "phishing" sites designed to appear
> similar to legitimate payment sites in an attempt to obtain users'
> payment information for fraudulent uses. When users become used
> to such redirection, they may have difficulty distinguishing such

"such" might be ambiguous here; maybe "network-induced" or
"network-driven"?

> attacks from legitimate redirections.
> 
> Because of the potentially
> harmful consequences of arbitrary redirection by an attacker (such
> as to phishing sites), it can be important for users and service
> providers to be aware of the risk and take measures to ensure that
> sensitive information (such as payment information) is only used for
> legitmiate purposes. Operators should follow industry best practices

I see my typo for "legitimate" is preserved :)

> for the specific application layer protocol to reduce the chances that
> such attacks could be mistaken for legitimate redirection. The details
> of such practice are out of scope for this document."

The above nitpicking aside, I think this text suffices to resolve my
DISCUSS point.  (And I guess we're going with removing "instead of"
to resolve the other one?)

-Benjamin