I was trying to be somewhat sarcastic or at least trying to make a point
based on the response I was expecting, though it appears you took my
words too seriously (note that I'm not saying its good or bad to do
verification by dns, its just one of the options). I'll have to be more
direct with what I was going to say...
The point was that its not the problem with requiring persistant connection
for verification server, because we already do that by using dns protocol.
So really the issue being raised is about choosing (or creating) verification
protocol to be flexible enough for many enviroments. It does not mean we
can not create dns-like protocol for verification that will work just find
for usually disconnected nodes or for that matter if http is used, its
also quite flexible, widely deployed, has cashing system, etc.
On Thu, 3 Apr 2003, Justin Mason wrote:
william(_at_)elan(_dot_)net said:
So if say we have porkhash but for verification is somehow done through
dns server. Then you would have no problem?
Yep -- there's nothing saying the verification server can't respond
via DNS queries. The only issues I'd see would be (a) max size of DNS
query packets (the query has to contain the sender_id data, which could
be an entire Received header), and (b) current DNS server software does
not have an easily-extensible design for dynamic responses (a la HTTP's
CGI).
DNS would definitely be more lightweight, in terms of network traffic
and latency, though.
Also, regarding cachability. Note that the verification query operation
uses the following data:
- sender_id (usually email addr?)
- timestamp
- opaque_md5_sum = md5(sender_id, timestamp, secretkey)
For each unique message, regardless of which recipient is doing the query,
those pieces of data will not change; so the response is cacheable.
Also worth noting that in the original design, there's no state held on
the verification server, apart from the shared secret. So a farm of
verification servers (whether using DNS as the transport or not), can be
used to deal with heavy load. (adding state, such as a db of valid
Message-Ids, would complicate this of course.)
--j.
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg