Subject: [domainrep] Proposed draft names

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 17 Nov 2011 20:30:06 -0800

Here are some proposed draft names for the initial document set for which there was consensus to import:

1) "draft-kucherawy-reputation-model" becomes "draft-ietf-repute-model", edited by Nathaniel.

2) "draft-kucherawy-reputation-media-type" becomes "draft-ietf-repute-media-type", edited by yours truly.

3) "draft-kucherawy-reputation-query-http" becomes "draft-ietf-repute-query-http", ditto.

4) "draft-kucherawy-reputation-vocab-identity" becomes "draft-ietf-repute-email-identifiers", ditto.

The lightweight one can be decided after we've looked into the DNS/UDP/COAP thing a little further, plus it needs an editor.

And the one about recommended practices can get a name when someone steps up to edit it as well.

Let's get started!

-MSK

---

From: Frank Ellermann <[email-masked]>
Date: Fri, 18 Nov 2011 05:55:07 +0100

On 18 November 2011 05:30, Murray S. Kucherawy wrote:

> The lightweight one can be decided after we’ve looked into the DNS/UDP/COAP
> thing a little further, plus it needs an editor.

I've just looked into the COAP draft and feel that it is too complex for the
purposes of REPUTE.  88 pages is almost the size of RFC 5321, and it takes
years to grok SMTP.

-Frank

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 18 Nov 2011 12:58:05 +0800

> purposes of REPUTE.  88 pages is almost the size of RFC 5321, and it takes

I still would like to hear more about the reasons why people think they
might want to use CoAP (sorry, I missed that part of the discussion in
the WG session the other day).

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 17 Nov 2011 21:01:43 -0800

> -----Original Message-----
> From: Peter Saint-Andre [mailto:[email-masked]]
> Sent: Thursday, November 17, 2011 8:58 PM
> To: Frank Ellermann
> Cc: Murray S. Kucherawy; [email-masked]
> Subject: Re: [domainrep] Proposed draft names
> 

I don't know the specific technical reasons (perhaps others can dive in there) but I think the general idea is to give us a lightweight alternative to DNS that doesn't involve creating a whole new UDP thing and all the usual operational issues that would create.

---

From: Frank Ellermann <[email-masked]>
Date: Fri, 18 Nov 2011 06:15:45 +0100

On 18 November 2011 06:01, Murray S. Kucherawy <[email-masked]> wrote:

> I think the general idea is to give us a lightweight alternative to DNS
> that doesn't involve creating a whole new UDP thing and all the usual
> operational issues that would create.

RFC 4993 (IRIS LWZ) needs only 18 pages.  RFC 3912 (port 43 incl. UDP)
needs 4 pages, admittedly one line with a normative reference to RFC 5198
is missing.  Let's just say a "reputon" is no "light bulb", and therefore
out of scope for CORE/COAP.

-Frank

---

From: "John Levine" <[email-masked]>
Date: 18 Nov 2011 07:15:16 -0000

>I don't know the specific technical reasons (perhaps others can dive in
>there) but I think the general idea is to give us a lightweight
>alternative to DNS that doesn't involve creating a whole new UDP thing
>and all the usual operational issues that would create.

I got the impression that a fair amount of the impetus for using
another UDP protocol is "oh, no, not another thing stuffed into the
DNS."  Personally, I don't find that a very compelling argument.

Some people (you know who you are) wince when we point out that we
already have DNS caches and our firewalls know how to pass port 43 UDP
packets but I would really prefer not to reinvent all that unless
there is a showstopper about using the DNS.

The closest thing to a showstopper I can see is that we might want to
allow fuzzy rather than exact match queries, but there's no reason
deal with that until if and when it turns out to be a problem.  I
wouldn't hold up NAPTR as a paragon of excellent design, but it does
manage to wrap a rather complex naming language around simple DNS
queries, so there are options short of using a new protocol on a new
port.

R's,
John

---

From: Dave CROCKER <[email-masked]>
Date: Fri, 18 Nov 2011 16:03:39 +0800

> I don't know the specific technical reasons (perhaps others can dive in there) but I think the general idea is to give us a lightweight alternative to DNS that doesn't involve creating a whole new…

The logic that I extracted:

1. Independent of the religious issues about using the DNS, it's not clear that 
this particular application matches it very well.  Size of responses (and maybe 
queries) is a concern.  Rates of information change in the database might be an 
issue.  Potential complexity of the queries.

2.  Building an entirely new mechanism on top of UDP is quite a lot of work.

3. CoAP sounds as if it might be somewhat close to an HTTP use, with the 
possibility of re-using more code than we could do otherwise.

Before making any choices, the we'd need to assess the reality of these points 
and the tradeoffs among the different choices.  (I haven't seen anyone lobbying 
for new UDP, so DNS vs. CoAp seems to be the current choices to debate.)

Obviously a related question is whether both heavy- and light-weight mechanisms 
are required and if they aren't, which of the two is preferred...

d/

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: Dave CROCKER <[email-masked]>
Date: Fri, 18 Nov 2011 16:06:40 +0800

<chair>

> DNS."

Although that line of attack is often used I have not noticed it in the context 
of Repute.  Perhaps I've missed it?

If so, those with that view need to speak up (again?)

Certainly the group needs to be clear about the reasons that its choices are 
made, whatever they are.  I just sent a separate note trying to list the issues 
I think we are seeing with respect to this particular question.

</chair>

d/
-- 

   Dave Crocker

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 18 Nov 2011 08:58:55 -0500

On 11/18/2011 03:03 AM, Dave CROCKER wrote:
>> I don't know the specific technical reasons (perhaps others can dive
>> in there) but I think the general idea is to give us a lightweight
> 1. Independent of the religious issues about using the DNS, it's not
> clear that this particular application matches it very well.  Size of
> responses (and maybe queries) is a concern.  Rates of information change
> in the database might be an issue.  Potential complexity of the queries.
> 
> Before making any choices, the we'd need to assess the reality of these
> points and the tradeoffs among the different choices.  (I haven't seen
> anyone lobbying for new UDP, so DNS vs. CoAp seems to be the current
> choices to debate.)
> 
> Obviously a related question is whether both heavy- and light-weight
> mechanisms are required and if they aren't, which of the two is
> preferred...

It sounds to me like we might do better to focus on what information
exchange is required and then once that's fleshed out a bit better see
what data exchange mechanism fits that.

Scott K

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 18 Nov 2011 10:01:15 -0500

> DNS."  Personally, I don't find that a very compelling argument.

The question I think I asked at the mic, and which I would like
answered before we grab hold of DNS, raw UDP, magic new IRIS
solutions, an entirely new protocol (over UDP or whatever), or COaP, is,
"What problem are we trying to solve?"

For instance, large payloads, of the sort that seem all but guaranteed
from REPUTE "any" queries, might well push the responses over the most
usual EDNS0 limits (especially if signed), even if such payloads fit
in the theoretical EDNS0 limits.  If these are really needed and at
all common (and I have no sense at all about whether they are -- and
neither does anyone else, since we haven't worked out the use cases
too well yet), then DNS is a lousy fit: the hard cases all switch to
TCP instead of UDP.  That might or might not be a reasonable
trade-off, but without doing any analysis, we're simply guessing.

BR,
A

-- 
Andrew Sullivan
[email-masked]

---

From: Peter Koch <[email-masked]>
Date: Mon, 21 Nov 2011 10:30:45 +0100

On Fri, Nov 18, 2011 at 04:06:40PM +0800, Dave CROCKER wrote:

> Although that line of attack is often used I have not noticed it in the 
> context of Repute.  Perhaps I've missed it?
> 

when I was at the microphone, I did not say DNS was the wrong protocol
but I asked for a confirmation that DNS would fit the catalog of
necessary features, referring to other examples where DNS might look
like the perfect fir except that it needed this one or another tweak.

Now, looking at the draft, there are several indicators that DNS is
at least not perfectly suited:

1) hashing the domain name to mitigate length issues
2) using a 'hook namespace', i.e. the DNS namespace is only leveraged
   to get to the reputation servers; there's no generic or universal use
3) use of the TXT RR; the sentence
	In line with [DNS-EXPAND], the TXT resource record type is used for
	this application.
   is especially puzzling.
4) Furthering (3), the query format is particularly complex, using two
   additional labels to parametrize the query

Some more items to consider:

o Are there any confidentiality requirements, either for the data published,
  for the queries/responses or both?
o Is bulk access to the published data envisioned?
o Is caching needed and what are consistency and coherency requirements?
o Is authenticity of the data of interest?
o Is authentication/authorization of the querying party needed?
o What is the change frequency and lifteime of the published data?
o What is the client/server ratio, i.e. how many different providers (O(n))
  are envisioned?
o [...]

-Peter

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 21 Nov 2011 12:03:36 -0800

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Andrew Sullivan
> Sent: Friday, November 18, 2011 7:01 AM
> To: [email-masked]
> Subject: Re: [domainrep] DNS vs. other UDP, was Proposed draft names
> 
> usual EDNS0 limits (especially if signed), even if such payloads fit in
> the theoretical EDNS0 limits.  If these are really needed and at all
> common (and I have no sense at all about whether they are -- and
> neither does anyone else, since we haven't worked out the use cases too
> well yet), then DNS is a lousy fit: the hard cases all switch to TCP
> instead of UDP.  That might or might not be a reasonable trade-off, but
> without doing any analysis, we're simply guessing.

So far, at least in the HTTP implementation, I haven't had to generate an XML reply that came anywhere close to the UDP DNS reply size limit.  And if we switch to JSON, they get even smaller.  So as far as I'm concerned, size isn't the interesting argument, but that makes some obvious presumptions about possible extensions into other applications where the reputon will be more complicated.

What's more interesting to me is the query.  Setting aside the URI template discussion for the moment, the query has the subject and probably the application to encode in the query somehow, at minimum.  Some services might also want more, like the specific assertion about which a reputation is sought, the particular application space for the query, or maybe some client credentials.  Once the question being asked is more complex than the subject and maybe an assertion, it gets pretty hard to find a way to encode all of that into a DNS query, i.e., a hierarchical set of dot-separated labels.  That leads me away from thinking DNS is the right answer.

So I guess a starting place for a requirement set for the lightweight query might be:

- uses UDP or some other lightweight, stateless transport medium
- no specific authentication or security requirements
- can contain a query of at least 256 bytes
- can contain a reply of at least 1024 bytes
- sending a dozen or more of these for each candidate message (in the case of email evaluation) shouldn't make anything flinch

My thinking right now is that if you need authentication or encryption, then switch to the heavyweight thing.  But if there's an easy way to get those things in a lightweight context, then that's fine too.

-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 21 Nov 2011 12:16:59 -0800

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Peter Koch
> Sent: Monday, November 21, 2011 1:31 AM
> To: [email-masked]

Shooting from the hip mostly, but also based on the one existing implementation I did:

> o Are there any confidentiality requirements, either for the data
> published, for the queries/responses or both?

I'm inclined to say that if this is a requirement, HTTP has lots of mechanisms around protection of all of that.  Right now for example, SpamAssassin launches a number of DNSBL queries per message, which reveals at least the domain name and IP address of the original message, so some data leakage happens there and that community seems to be fine with it.

That said, if doing some lightweight thing can get confidentiality as low-hanging fruit, we should definitely include support for it.

> o Is bulk access to the published data envisioned?

I imagine such things will be needed for truly high-volume sites.  I use as a basis for this the current DNSBL service providers who do allow full zone transfers for large sites.

> o Is caching needed and what are consistency and coherency requirements?

So far this hasn't been much of a consideration, because the HTTP side has the "Expires:" field, and we make use of that, plus there's an implication that the values are computed daily.  But that latter point isn't something we should codify.

> o Is authenticity of the data of interest?

I'd say yes, though so far that's only expressed by parameters in the reply where the service provider indicates the reputation, and also the number of data points were used and from how many reporting sites they came.  Together they can be taken as an expression of confidence in the data.  I'm not sure though how one would expose the raw data to scrutiny such that its authenticity could be determined.

> o Is authentication/authorization of the querying party needed?

Probably; it's a service, and most providers will want to offset their costs.  You might also want to tailor your reply based on who's asking.  (I have an extension in mine that, for example, recommends a message rate based on who's asking, since different sites get different flows of email.)

> o What is the change frequency and lifteime of the published data?

My implementation updates its values daily, or whenever I manually run some update scripts.  The specifications right now don't mandate a specific frequency.  I imagine this would either be part of the reply, or something understood out-of-band when the client and server establish a relationship.

> o What is the client/server ratio, i.e. how many different providers (O(n))

Some liken this to a credit reporting service, so I'd guess at a number under 100 once things are well-established.  But that's just a hunch.  At first, there might be a lot more.

The protocol should also work "locally", such as within a single ADMD if they choose to trust only their own data.

-MSK

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 21 Nov 2011 16:56:49 -0500

> - can contain a reply of at least 1024 bytes

This suggests the size issue could in fact be a deal-breaker too.
While EDNS0 itself comfortably goes up to 4k, actual deployments
don't.  Recently-shipping versions of BIND try out EDNS0 with, IIRC,
2048 and if that fails fall back to 512 (in apparent contravention of
the EDNS0 specifications).  It's this particular failure mode I was
worried about (especially once we add DNSSEC to the mix).  I have been
assuming that DNSSEC would be required for this service, in order to
avoid problems with spoofing of reputations; but maybe we don't think
that's importat (though I do).

Nevertheless, I agree with you about the query, too, and I think your
proposed list is a good starting point.

A

-- 
Andrew Sullivan
[email-masked]

---

From: SM <[email-masked]>
Date: Mon, 21 Nov 2011 15:18:50 -0800

At 12:16 PM 11/21/2011, Murray S. Kucherawy wrote:
>I'm inclined to say that if this is a requirement, HTTP has lots of 
>mechanisms around protection of all of that.  Right now for example, 
>SpamAssassin launches a number of DNSBL queries per message, which 
>reveals at least the domain name and IP address of the original 
>message, so some data leakage happens there and that community seems 
>to be fine with it.

This is not specific to SpamAssassin and it is likely out of 
scope.  There is a non-trivial amount of data leakage.  I would put 
it as "the community is not really aware of the issue".  It's more 
than the domain name and IP address of the original message.  I would 
not rate it as a problem except in sensitive environments.

Regards,
-sm

---

From: SM <[email-masked]>
Date: Mon, 21 Nov 2011 15:05:21 -0800

>the WG session the other day).

DNS v/s UDP was an item of discussion.  Someone mentioned CoAP as:

  (a) UDP is too difficult for programmers

  (b) CoAP is light-weight

  (c) There are several libraries that are available for free

The last point seems to be the selling point.  It also avoids the 
usual DNS discussion.

Regards,
-sm

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 21 Nov 2011 15:21:36 -0800

> From: [email-masked] [mailto:[email-masked]] On Behalf Of SM
> Sent: Monday, November 21, 2011 3:19 PM
> To: [email-masked]
> Subject: [domainrep] Data leakage (was: DNS vs. other UDP, was Proposed draft names)
> 
> This is not specific to SpamAssassin and it is likely out of scope.
> There is a non-trivial amount of data leakage.  I would put it as "the
> community is not really aware of the issue".  It's more than the domain
> name and IP address of the original message.  I would not rate it as a
> problem except in sensitive environments.

Not in scope for the lightweight protocol, or not in scope for the working group?

---

From: Douglas Otis <[email-masked]>
Date: Mon, 21 Nov 2011 15:51:07 -0800

> The last point seems to be the selling point.  It also avoids the 
Agreed.

CoAP is restful and employs simplified syntax that easily translates to 
HTTP.

-Doug

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 21 Nov 2011 23:57:17 +0000

> Not in scope for the lightweight protocol, or not in scope for the working group?

Good question. I'd hope (no hats etc.) that privacy does
get considered here. That's not something solved via TLS
though, for example the DNS approach arguably has better
privacy properties in a sense since the query may be answered
by a cache that doesn't go tell the service-provider that
Alice just asked is Bob ok or not. Turning on TLS and forcing
a TCP connection back to the service provider gives that service
provider more information about which Alice is interested
in which Bob's reputation when, from where etc. So I'd
hope that repute really think about how to handle that
tussle between confidentiality on-the-wire and privacy. Of
course, if the queries are such that few of them are cache
hits, then its more-or-less the same, but, again, I do hope
you guys think this through and come to some reasonable
conclusions. And making use of TLS is a fine thing to do
for on-the-wire confidentiality, so there probably aren't
really many slam-dunk ways to handle both on-the-wire
confidentiality and privacy for a protocol like repute.

I would note that the browsers have adopted solutions for
the "bad URL" problem that might be similar and worth a
look. I've no idea how that'd map to the queries and
responses needed here though.

For the email application with an MTA sending the query
this is maybe less of an issue than it'd be for other
applications though. Again, I'm not sure how best to take
that into account without actually figuring out details
for some other use-case which is maybe not really on
the agenda for most folks here.

S.

PS: To be honest, that's not quite "no hat" stuff. (I wonder
how often that's the case really.) If repute did a horrible
job in privacy terms I'd likely want to discuss that. But I
don't have a hat when it comes to figuring out what to do
since I don't understand the email application like some of
the folks who are really active here and I'm not sure any of
us understand the trade-offs for other applications. So its
a mixture of hats and no hats, maybe cap-slightly-askew
would be the better metaphor here;-)

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

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 21 Nov 2011 16:05:22 -0800

> From: Stephen Farrell [mailto:[email-masked]]
> Sent: Monday, November 21, 2011 3:57 PM
> To: Murray S. Kucherawy
> Cc: [email-masked]
> Subject: Re: [domainrep] Data leakage
> 
> Good question. I'd hope (no hats etc.) that privacy does get considered
> here. That's not something solved via TLS though, for example the DNS
> approach arguably has better privacy properties in a sense since the
> query may be answered by a cache that doesn't go tell the service-
> provider that Alice just asked is Bob ok or not. Turning on TLS and
> forcing a TCP connection back to the service provider gives that
> service provider more information about which Alice is interested in
> which Bob's reputation when, from where etc. So I'd hope that repute
> really think about how to handle that tussle between confidentiality
> on-the-wire and privacy. Of course, if the queries are such that few of
> them are cache hits, then its more-or-less the same, but, again, I do
> hope you guys think this through and come to some reasonable
> conclusions. And making use of TLS is a fine thing to do for on-the-
> wire confidentiality, so there probably aren't really many slam-dunk
> ways to handle both on-the-wire confidentiality and privacy for a
> protocol like repute.

In my opinion this is definitely a topic area we should be spending some time.  It goes nicely into both the Security or Privacy Considerations sections of the current drafts, and probably some of it goes into the operational considerations draft that has yet to be started but is in our charter.

The HTTP side of things already has support for caching, and the current "query-http" document even mentions it explicitly with a SHOULD.  Even before thinking about privacy, I think that's an important operational consideration for both clients and servers, especially given the fact that one message could generate numerous queries.

> I would note that the browsers have adopted solutions for the "bad URL"
> problem that might be similar and worth a look. I've no idea how that'd
> map to the queries and responses needed here though.

It's worth asking.  I'll dig up a connection if I can.

There was another implementer that was interested in coming over to a standardized way of things some time ago. I've since heard from him privately so I'll try to drag him in here.  Theirs is a commercial implementation similar to what we have here, so maybe he has some insight into actual customers' privacy and operational concerns, which would be really useful input here.

-MSK

---

From: SM <[email-masked]>
Date: Tue, 22 Nov 2011 06:03:25 -0800

>Not in scope for the lightweight protocol, or not in scope for the 

I labelled it as not in scope for the working group to err on the safe side.

>Alice just asked is Bob ok or not. Turning on TLS and forcing

The caching feature has the side effect of having a privacy property.

>responses needed here though.

Browsers use a hash of the URL to identify "bad" ones.

>the agenda for most folks here.

If the work is about identifiers, which are specific to MTAs, the 
query may not be that much of an issue as there is some 
aggregation.  If anyone is interested in the topic, I suggest looking 
into data linkage,

Regards,
-sm

---

From: "David F. Skoll" <[email-masked]>
Date: Tue, 22 Nov 2011 10:03:32 -0500

On Tue, 22 Nov 2011 06:03:25 -0800

> The caching feature has the side effect of having a privacy property.

It's not a very robust property, though.  At least in the case where
the identifier is an IP address, my tests show that the real-life
cache hit rate for DNSBLs is pretty low (~30% on a busy mail server.)
Most DNSBLs have a reasonably short TTL so that (1) they can delist IP
addresses reasonably quickly and (2) they can keep track of heavy
users so they can cut them off or charge them money.  I imagine
reputation providers will have similar goals for data freshness and
customer billing.

In the case of a reputation provider who charges customers for access
to reputation information, I see no feasible way to hide from the
provider the fact that Client X has asked about Identifier Y's
reputation, other than to allow Client X to download the entire
reputation database or for Client X to make a bunch of spurious
queries to hide the real ones.  Neither of those is particularly
appetizing to most reputation providers.

Regards,

David.

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 22 Nov 2011 10:34:48 -0500

On Mon, Nov 21, 2011 at 11:57:17PM +0000, Stephen Farrell wrote:
> get considered here. 

Given the already-starting deployment of the clientip EDNS0 option
(without an EDNS0 code point assignment, natch), relying on the DNS to
give you a privacy side benefit seems to me to be extremely dodgy.

Besides, you have zero knowledge of what your upstream is doing: why
are you sure it's caching at all?

On the whole, I regard this as an extremely weak reason to prefer DNS
over something else for the purposes of REPUTE.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Frank Ellermann <[email-masked]>
Date: Tue, 22 Nov 2011 22:17:16 +0100

> over something else for the purposes of REPUTE.

For SMTP / e-mail / DNSBL / SPF / DKIM folks DNS is something they know
and trust.  OTOH COAP is something new, nobody knows it yet.  And IRIS
LZW is also not widely known.  And when I mumble something about port 43
UDP it's only theory, I've never tested it in practice and can't tell if
servers support it.

-Frank