Subject: A nuance of interoperability reports

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 21 Feb 2012 14:56:41 -0800

We like to see interoperability reports contain information about features of a protocol that are used vs. unused, so that if and when the protocol seeks advancement along the standards track, we can decide whether we want to keep it in the revision.

Should we consider a protocol feature only used by abusive actors to be one that deserves to be kept, or is only legitimate use worth considering?

-MSK

---

From: Richard Barnes <[email-masked]>
Date: Tue, 21 Feb 2012 20:44:54 -0500

Seems like it depends on your definitions of "abusive" and "legitimate".  Do you have an example?  

On Feb 21, 2012, at 5:56 PM, Murray S. Kucherawy wrote:

> _______________________________________________
> Ietf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 22 Feb 2012 14:55:06 +0000

> -----Original Message-----
> From: Richard Barnes [mailto:[email-masked]]
> Sent: Tuesday, February 21, 2012 5:45 PM
> To: Murray S. Kucherawy
> Cc: [email-masked]
> Subject: Re: A nuance of interoperability reports
> 

For a contrived example, let's say a registered HTTP header field that's only ever found to be present in web pages used by bad actors, but lots of them.  Then HTTPbis comes up for standards track advancement and they're cleaning out the cruft.  Would marking that field as deprecated or removing it completely be justified?

-MSK

---

From: Randy Bush <[email-masked]>
Date: Wed, 22 Feb 2012 20:32:05 +0530

i think what richard was trying to hint is that the same tool can be
used for both good and bad.  and we can't predict that, just because it
has been used for bad yesteday, it will not be used for good in the rosy
future.

randy

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 22 Feb 2012 10:12:56 -0500

> has been used for bad yesteday, it will not be used for good in the rosy

Yes, but the same argument can be made about unused features.  Just because a 
feature wasn't used so far, we can't predict the future.  It may be useful.

If there's not non-abusive deployment, then it seems reasonable to treat that 
as non-deployment of the feature.

Scott K

---

From: Randy Bush <[email-masked]>
Date: Wed, 22 Feb 2012 21:19:26 +0530

>> used for both good and bad.  and we can't predict that, just because
>> it has been used for bad yesteday, it will not be used for good in
>> the rosy future.
> 
> Yes, but the same argument can be made about unused features.  Just
> because a feature wasn't used so far, we can't predict the future.  It
> may be useful.
> 
> If there's not non-abusive deployment, then it seems reasonable to
> treat that as non-deployment of the feature.

i thought that an interop report is about what has been implemented, not
what has been used.

randy

---

From: Martin Rex <[email-masked]>
Date: Wed, 22 Feb 2012 21:21:20 +0100 (MET)

Murray S. Kucherawy wrote:
> For a contrived example, let's say a registered HTTP header field
> that's only ever found to be present in web pages used by bad actors,
> but lots of them.

Such as "P3P:" ?   :-D

-Martin

http://www.h-online.com/security/news/item/Google-also-bypassed-cookie-settings-in-Internet-Explorer-1438781.html

---

From: Hector <[email-masked]>
Date: Thu, 23 Feb 2012 09:43:11 -0500

>> that's only ever found to be present in web pages used by bad actors,

Be afraid, be very afraid!

> http://www.h-online.com/security/news/item/Google-also-bypassed-cookie-settings-in-Internet-Explorer-1438781.html

Thanks for the link Martin, helping to make sense of all the GooKids 
Inc., hoopla and no thanks for needing the pencil in time to get our 
operator P3P resources updated. :)

--
HLS

---

From: Suzanne Woolf <[email-masked]>
Date: Wed, 22 Feb 2012 17:12:06 +0000

On Tue, Feb 21, 2012 at 02:56:41PM -0800, Murray S. Kucherawy wrote:
> We like to see interoperability reports contain information about
> features of a protocol that are used vs. unused, so that if and when
> the protocol seeks advancement along the standards track, we can
> decide whether we want to keep it in the revision.

I'd support Randy's point about implemented vs. used for an
"interoperability" report, but only because I think of the
"assessment" part as separate, not unnecessary.

Such assessments need to consider what's implemented, what's used, and
yes, probably some element of context for both. However:

> Should we consider a protocol feature only used by abusive actors to
> be one that deserves to be kept, or is only legitimate use worth
> considering?

....is an overly simplistic way to pose the question.

Aside from the difficulty of judging "legitimate" use, there's the
question of why the feature is in the protocol in the first
place. Presumably protocol features exist because people anticipate
some net benefit from including them, and it seems that the right
question when deciding whether to keep a feature is not only whether
it's provided some benefit so far (i.e. it's implemented and used) but
also, if it hasn't, why not? 

In answering the "why" question, "We haven't needed it yet but we
expect to in the following use case in the next 18 months" leads in a
very different direction to "so far, it's useful only to attackers
working against us" or to "the problem still exists but we have a
better way to solve it" or to "the use case never materialized in
practice."

A slightly broader discussion of how the real-world deployment of the
protocol resembles (or doesn't) the anticipated deployment seems more
useful than trying to answer the question you're posing here.

It's difficult to have such a discussion without ratholing, but it
seems to me that the same can be said of trying to define "legitimate"
use.

Suzanne