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

[Ben Campbell <[e-mail]>]

> On May 24, 2018, at 2:24 PM, Benjamin Kaduk <[e-mail]> wrote:
> 
> 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”?

Good point.

> 

>> 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?)

That is my understanding. But in both cases, I suggest holding your DISCUSS until the updates show up in a revised draft.

Thanks!

Ben.