[doseta-discuss] suggestions/concerns on spec

[Dave CROCKER]

On 6/2/2011 11:04 AM, Bill Burke wrote:
> Sorry, this might get very long...
>
> We're looking seriously to promote Doseta as a means to sign messages for
> restful web services.

Bill, obviously this is delightful news.

Please assume that henceforth, discussions are standard IETF development 
discussions, rather than worrying about anything like "the owners of DOSETA 
might say no and go away".  I'm sure I/we will have vigorous comments and most 
probably vigorous disagreements, but that's just normal IETF process.

I view the formalities of IETF chartering and IESG approval as useful, but not 
essential, to the development and promotion of protocols.  On the other hand, I 
view the /style/ of IETF work to be absolutely essential and the style is about 
group ownership, group debate and group agreement.

The goal of DOSETA has been to parameterize and promote the core technologies 
that DKIM demonstrates.  The process of producing DKIM -- even before it came to 
the IETF -- was a pretty typical, IETF-style collaboration and that's what I/we 
intend for DOSETA.

And a last broad statement:  DOSETA is still quite formative.  A group wanting a 
concrete deliverable will help direct and solidify things quite a bit.


>  After implementing Doseta in Java, talking to various
> engineers when I was at a recent JBoss/Red Hat conference, and talking to a
> couple of users that have signing requirements, here's some of my thoughts on
> doseta.

Hmmm.  It occurs to me that we need to get the DOSETA web presence up to snuff, 
possibly including a wiki, but definitely including things like the DKIM 
"implementation" page that points to software and products.

(Just did my first google search for "doseta" and the resulting list is 
understandably short and relevant, with one exception.  Glad to see Bill's blog 
entry, but I especially liked the one unexpected entry:

    <http://www.youtube.com/watch?v=56WkstsmMY4>)

google ignores whitespace...)


> * Maybe I'm unclear or new to the current notation, but the spec is a little
> unclear on the signing and verification algorithm. Either better examples are
> needed or clearer language. I can suggest some changes to that section if the
> doc if you're open.

Well, I basically meant to merely copy the text from DKIM, with only the changes 
needed to remove DKIM-specificity.  Since folks have been succeeding with 
efforts to implementation of DKIM, I assumed that the existing text would be 
sufficient.  (That said, for the recent DKIM wg effort to develop incremental 
revisions to the DKIM spec, I did find some rather interesting deficiencies.)

On the other hand, the DOSETA effort is hoping to recruit a much broader 
audience, so it makes sense that it might need more/better documentation.

In other words, yes, suggest away, in the usual style for editing working group 
docs.


> * I've discussed with a few people and one of the biggest suggestions is to
> split the document(s) into various pluggable parts:
>
> - Public key discovery should be fully broken out with DKIM as one possible
> solution for public key discover. One of the problems I had was to actually find
> somebody that has deployed DKIM. I could not find anybody as of yet. The people
> I talked to thought using DNS was an interesting idea, but the biggest concern
> was the lack of knowledge/deployment of DNS Sec. Security sounds like it might
> be an issue with public key publication. I don't know enough about DNS to say
> whether or not something like DNS SEc would be required to ensure the integrity
> of the public key you are obtaining to verify a signature.

Several reactions and comments:

1. I've always felt that key-lookup service OA&M was the primary barrier to 
adoption for DKIM and, hence, for DOSETA.  That's because key management has 
/always/ been a major barrier to adoption for security services over the open 
Internet.

2. Establishing a new, standardized Internet-wide query service tends to proceed 
poorly.  That's why folks keep trying to adapt to use the DNS.

3. DNS admin for DKIM has, indeed, proved a barrier for some folk.  Tools aren't 
quite up to snuff; DNS service providers don't tend to support it; sdmin and ops 
folks aren't used to it; etc.  The danger, here, is in thinking that an 
alternative approach will automatically be better.  Let's keep in mind that 
there is no other successful, integrated query service on the net other than the 
DNS.  (Lest one think that the web qualifies, I'll note that it's not designed 
as an integrated query service in the sense of providing standardized 
transactional data across all nodes.)  So the basic point is that /any/ service 
of this type has a collection of admin and ops requirements and that they aren't 
trivial; in the case of alternatives, they also have no experiential base to 
build upon.

4. DKIM facilitates the DNS ops work associated with it, a bit, by having the 
underscore naming convention.  This means that the DKIM-specific parts of the 
DNS can be delegated to a different group from the one that does 'regular' DNS 
admin within an organization.

5. At the last IETF I did notice the HTTP-oriented preference for key management 
and have been thinking that DOSETA needs to be designed in a way that permits 
variants and I certainly took note of the documentation split that the 'other' 
proposal is using.  It certainly seemed to me worth considering for DOSETA, too. 
  After all, DOSETA is an attempt to make a component mechanism, or rather, to 
make a collection of components.  So the interesting part of the question, here, 
is what to define as the stable core and what to define as variable (but with at 
least one concrete and viable exemplar?)

    One easy answer is that use of a domain name as identifier and use of a few 
crypto-related parameters are the solid and stable core to doseta.  This may 
well be the right answer, too.


> - Many people I talked to thought DNS would be difficult to deploy and manage
> for a public key infrastructure.

So far, it's been working well for about 6 years.  I'm not aware of any other 
Internet-scale, distributed-administration and standardized query service that 
can say that.

I'm going to guess that folks you've been talking to are outside the existing 
sphere of DKIM use.  I believe that use has been primarily among large (bulk) 
email senders and large email operators.  This leaves quite a lot of other email 
ops folk, as well as many more non-email folk, unfamiliar with DKIM.


>  I myself had difficulties finding a DNS
> solution that I could embed in unit tests (even then I had to hack it). Then I
> had to learn how to configure DNS text records (yeah, its easy, but...).

The deeper point here is that any alternative is going to have the same issues, 
I think.


> Generally application developers just don't have the know-how or permission to
> set up a DNS server. I and others I've talked to would really like to have
> HTTP-based solution to publish keys.

Here's a proposal, just to start the juices flowing:

      Postulate a DNS query service that happens to use HTTP for transport, 
rather than UDP.

      That is, take the existing DOSETA definition for querying the DNS and 
specify it as operating over HTTP.  (This is a kind of transport independence.)

That will give you an alternative operational choice, without messing with 
semantics or syntax or even with much application code.


> - A very generic signature header specification that describes how the signature
> header is created, canonicalized, and how the hash and signing algorithms are
> applied. Very few fields should be required. And only a few defined (like bh, v,
> h only). SOme of the people talked to are interested in a signature header spec,
> but uninterested in DKIM. Like for instance, they want to be able to use a

I'm one of the folk who wanted the revision effort for DKIM to slim it down 
quite a bit.  So, for DOSETA I felt the freedom to pursue that goal as 
aggressively as I could justify.  However it didn't go as far as I would have 
liked and I'm beginning to think that what's needed is possibly a smaller core, 
with some defined, standard add-on "packages" for particular kinds of common 
tailoring

But I haven't pursued this very far.  However I think it might satisfy the 
concern you are expressing and having multiple folk discussing it would be 
excellent.


> signature header to sign requests and not necessarily a body. It would be good
> to define something that people can refer to and innovate with on their own for
> their own purposes.

That's certainly one of the goals for DOSETA.


> - A field registry where people can register their own custom fields for the
> signature header

By 'fields' what do you mean?  I'm guessing you mean DOSETA signature parameters 
(or 'tags')?


> - Separate specs for different use cases: Email, HTTP. Not sure how different
> they'd actually be, but, who knows.

MIMEAUTH is an attempt to start that sequence.


> I'd be willing to draft any part of these suggestions. Let me know.

Your offer is readily accepted!

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net