Subject: [ietf-dkim] Requirements on where/how SSP stuff is published...

From: Stephen Farrell <[email-masked]>
Date: Fri, 28 Jul 2006 11:33:23 +0100

Folks,

We all (or almost all) seem to be assuming that the DNS is the
place to put SSP stuff.

I just wanted to raise the question to see if that's a requirement
or just a near-accidental part of the current design proposals.

So is using the DNS in fact necessary? If it is, we may need text
that explicitly says why at some stage.

If not, what are our requirements for where/how to publish SSP
stuff?

Stephen.

_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: <[email-masked]>
Date: Fri, 28 Jul 2006 08:53:12 -0400

According to my DNS admin
"Why are you putting all that crap in DNS? The MTA can do that!! Or use
a web page!"
Just passing along a reaction I got.
Thanks,

Bill Oxley 
Messaging Engineer 
Cox Communications, Inc. 
Alpharetta GA 
404-847-6397 
[email-masked] 

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Stephen Farrell
Sent: Friday, July 28, 2006 6:33 AM
To: ietf-dkim
Subject: [ietf-dkim] Requirements on where/how SSP stuff is published...

Folks,

Stephen.

---

From: "william(at)elan.net" <[email-masked]>
Date: Fri, 28 Jul 2006 07:20:29 -0700 (PDT)

> We all (or almost all) seem to be assuming that the DNS is the

DNS is not the right place to put public keys either - its been
shown here many that it makes DNS systems vulnerable to attack when
you put such large records and it creates series extra overhead for
caching dns servers to be able to support this additional data
(you're basically abusing somebody else's deployed protocol base for 
something it was not designed to do - dns works best as database
of short fixed size locator records).

But this WG made assumption that DNS is right place when it first
started without making objective judgment of the alternatives
so why you're asking this question now is beyond me. If you had
another alternative for SSP that is good but if you relay on some
other system protocol for retrieving policy, that means most
verifiers would support that protocol so you might as well
consider that using that protocol instead of DNS for public
key retrieval and be done.

---

From: Arvel Hathcock <[email-masked]>
Date: Fri, 28 Jul 2006 09:53:00 -0500

> or just a near-accidental part of the current design proposals.

I suppose that since the rest of DKIM is in DNS it seems logical to put 
the policy part of DKIM in DNS also.  So, consistency could be one 
rational for the "policy in DNS" position.

-- 
Arvel

---

From: Dave Crocker <[email-masked]>
Date: Fri, 28 Jul 2006 08:14:56 -0700

> "Why are you putting all that crap in DNS? The MTA can do that!! Or use

The 'stuff' is to be queried, so the mechanism that must be used is a query service.

1. An MTA does not provide a query service, so I do not understand suggesting
putting SSP information there. I could make all sorts of guesses about what your
admin has in mind, but none are viable.

2. Using http as the query service employs a rather heavy-weight service (tcp,
http, html) for what is actually a very simple query. In addition, it implies
that those mechanisms are all that are essential, when in fact a reliable query
service has substantially more service requirements.  (Small example: operative
word of reliable means redundant with established means of getting to the
alternate copy.)  The DNS supplies all that readily.  "A web page" does not.

3. What is wrong with putting the information into the DNS?

d/
-- 

  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: John Levine <[email-masked]>
Date: 28 Jul 2006 18:20:30 -0000

>that explicitly says why at some stage.

I think we're all presuming that if a receipient uses SSP, it'll be
doing a query per message to fetch the SSP info for that message.  If
we expect the query to be small enough that the query and response
will each fit into 512 bytes, DNS is the natural way to handle it
because it's widely available, has good caches, etc., and is really
fast.  If the info is big enough that it'll need a TCP session, then
HTTP makes sense, since it's also widely available, has good caches,
etc., and is about as fast as can be given that it needs a TCP
session.

I'm hoping that we can constrain the SSP info to a modest number of
bits, so DNS is is.  If SSP bloats up to the point where it doesn't
fit in 512, then it's http.

R's,
John

---

From: Dave Crocker <[email-masked]>
Date: Fri, 28 Jul 2006 11:52:33 -0700

> or just a near-accidental part of the current design proposals.

Let me suggest that it will become a requirement, but that considering it one,
now, is a mistake. In other words, use of DNS, or whatever, derives from
functional and operational needs, rather than being a core need, on its own.

In other words, we should be discussing 'requirements' in terms of semantic
functions or practices/reputation/etc services that are need, rather than the
details of the mechanisms that will be used to provide those services.

d/

-- 

  Dave Crocker

---

From: Jim Fenton <[email-masked]>
Date: Fri, 28 Jul 2006 16:47:54 -0700

> If not, what are our requirements for where/how to publish SSP
I'll throw out a few generic requirements:

1. Low-cost query/response, in terms of latency time and the number of
packets involved.  UDP has a definite advantage over TCP here:  it's
very nice to be able to send one packet, receive one packet, and have
the answer you need.  With TCP you have 3-way handshake in each
direction, query, response, and then teardown.

2. Minimize DoS potential.  SSP for a high-value domain is potentially a
high-value DoS target, especially since the unavailability of an SSP
record could make unsigned messages less suspicious.

3. Easily cached.  If the infrastructure doesn't provide caching (ala
DNS), the records retrieved will need time-to-live values to allow
querying verifiers to maintain their own caches.

4. High availability.  Multiple, geographically and topologically
diverse servers must be supported.

-Jim

---

From: Dave Crocker <[email-masked]>
Date: Sat, 29 Jul 2006 16:00:36 -0700

> I'll throw out a few generic requirements:

Jim, these all look pretty reasonable, but they are all about the mechanism
rather than being about sender signing practices, per se.

d/
-- 

  Dave Crocker

---

From: "Hector Santos" <[email-masked]>
Date: Sat, 29 Jul 2006 23:26:59 -0400

----- Original Message -----
From: "Dave Crocker" <[email-masked]>
To: "Jim Fenton" <[email-masked]>

> Jim, these all look pretty reasonable, but they are all about
> the mechanism rather than being about sender signing practices,
> per se.
>

+1

It is probably a good idea if we can break down the requirements into three
categories;  system vs. security vs. application requirements.

Here's my short list breakdown. Includes those already discussed.  Of
course, depending on the style of your hat, some of these may fall into
different and/or multiple categories. I am just listing them, not locked
into any one, with the goal to help speed things up (I should also note that
I do not believe these in any way fall into a "featurlitis" syndrome, but I
do hope we are good enough to see what's required and then go from there).

o System Requirements:

  - DNS based

  - DNS TXT RR

  - Low-cost query/response
        - Minimal Lookup

  - Easily cached (Implied by DNS requirement?)

  - High availability (Implied by DNS requirement?)

  - System Integration flexibility (can work outside of 821)

  - Support MLS (Mailing List Servers)??

  - Support for MFA (Mail Filter Agents) such as SA, SIEVE, etc.

o Security Requirements:

  - Protection of OA domain signature is paramount.

  - Protect against unauthorized policies.

  - Minimize DoS potential

  - Consideration for high Failure/Success ratio.

o Application Requirements:

  - Allows for high efficiency implementation

  - Ease of definition

  - Flexible syntax for growth

  - Definition should expose the following DKIM signer attributes:

      - Support OA Mail/DKIM Policy definitions

            - No mail expected from OA
            - Never Signed expected from OA
            - Always signed expected from OA
            - Sometime signed expected from OA

      - Support 3PS Mail/DKIM Policy definitions

            - Not expected by OA
            - Always expected by OA
            - Sometimes expected by OA

      - Highest Signature Hashing method Possible

      - List of allowable 3PS signers

      - Reporting address

      - Failure handling

  - DKIM Verifiers with SSP implementators do not need to
    support DKIM signing. (This helps with migration)

  - Does not required CAR (Certification, Accreditation, Reputation)
    service layer.

--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com

---

From: Jim Fenton <[email-masked]>
Date: Sat, 29 Jul 2006 20:46:17 -0700

> rather than being about sender signing practices, per se.
Sure.  I was responding to Stephen's question about where/how SSP stuff
is published.  I wasn't trying to address what the SSP consists of.

-Jim

---

From: Douglas Otis <[email-masked]>
Date: Sun, 30 Jul 2006 02:18:53 -0700

>       - List of allowable 3PS signers

The term third-party signer should not be used to avoid confusion with
designated signing domains and non-designated domains. The list should
be a list of designated signing domains which includes the OA domain
when that domain is used for signing and non-designated domains are
flagged as not being used.

>             - No mail expected from OA
             (No designated domain & only designated domains used.)  
>             - Never Signed expected from OA
             (OA not designated & only designated domains used.)
>             - Always signed expected from OA
             (Only OA designated & only designated domains used.)
>             - Sometime signed expected from OA
	     (OA not designated & non-designated domains used.)

By utilizing a list of designated signers, all of these policy
definitions reduce to a single flag that indicates whether
non-designated domains are used.

>       - Support 3PS Mail/DKIM Policy definitions
	     (Only OA designated & only designated domains used.)
>             - Always expected by OA
	     (OA not designated & only designated domains used.)
>             - Sometimes expected by OA
	     (OA and designated & only designated domains used or
              non-designated domains used?)            

It makes little sense to indicate "sometimes expected."  How would that
be useful?

A list of designated signing domains eliminates the need to separately
specify use of OA domain or designated signing domains.  The OA domain
is self apparent when contained within the list.  Only flagging the use
of non-designated domains is required. 

When annotating the message, the signing domain must be:
 - a non-designated originator domain 
   (For bogus invalids when only designated domains used.)
 - a designated originator domain
 - a designated non-originator domain
 - a non-designated non-originator domain

The originator domain is self apparent. A list indicates which domains
have been designated.  A flag indicates whether non-designated domains
are used.

When non-designated domains are used, there should be no expectation
that DKIM is always employed by these domains.  The default for policy
should be an empty designated signing list and a flag indicating use of
non-designated domains.

>       - Highest Signature Hashing method Possible

For less overhead, this information should be included within the key
when an alternative algorithm is required to accompany that signature.
This information should also include the algorithm, service method, and
signature version.

-Doug

---

From: "Hector Santos" <[email-masked]>
Date: Sun, 30 Jul 2006 16:11:03 -0400

----- Original Message -----
From: "Douglas Otis" <[email-masked]>

> It makes little sense to indicate "sometimes expected."  How
> would that be useful?

First, lets keep in mind that "sometimes" or the neutral policy is currently
the DKIM-BASE default behavior.  It is also the default policy for the
current SSP specs.  If no policy is started, equivalent to not having a
policy at all, the behavior is that of a Neutral "It might be sign or not"
behavior.

I agree relaxed provisions, designs and policies will always be the most
problematic.  After all, this is what got us here in the first place. :-)
But I would not question the usefulness just yet though.

I can see where a domain may want to "sometimes" sign mail when he thinks he
sending an important message, maybe based on the target or type of
correspondence versus not caring to sign for normal email targets. I may
want to use santronics.com for this mailing list in non-sign mode, but use
it in signed mode for more important direct email correspondence.

However,  I do think such a relaxed policy should come with absolutely no
tolerance for failure. If we allow for this type relaxed practice, I would
have trouble dealing with situations where there is a high rate of failures.
In other words, just because you relaxed it, should not imply that since it
is optional, the failure should be ignored.

Anyway, I think the idea is useful, but I personally will not argue against
eliminating the "sometimes" policy. If someone comes up with semantics for
protecting it, maybe the new policy option can be added in the future.

> This information should also include the algorithm, service method, and

The purpose of this policy attribute is, as described in the DSAP proposal,

   The main purpose of the a= tag is to allow domain signers the design
   and implementation opportunity to determine the highest strength
   possible by a particular target verifier by looking up the DSAP DNS
   record for the target recipient domain host.  If this query results
   with no a= tag information, the default should be rsa-sha1 is the
   highest strength possible.

   Essentially, this is a negotiation and backward compatibility
   concept.  It is quite possible earlier pre-standard DKIM
   implementations supporting only rsa-sha1 may still exist.  The domain
   DKIM message signer's desire is to achieve the highest protection
   possible.  Instead of signing mail with a particular algorithm and
   hoping for the best, the signer can predetermine what the receiving
   system can handle in terms of hashing strength.

   This verifier lookup concept is best utilize for high-value domains
   in 1 to 1 transactions.  It would not be good practice
   with Mailing List resigners with large distributions to use this
   concept.

I can see high value systems (those who can afford an advanced
implementations) such as a bank, obtaining email addresses from customers
and lowering failure rates by determining the highest security possible at
the target.  We talked about future possible methods beyond SHA256.  Maybe
the bank also supports this new method.  By looking at the target host
domain SSP record, if any, it can see check for the strong hashing
available.

Also, consider this.  A high-value organization investingg in DKIM, might
decide on a new banking policy that all customer email addresses uses for
eBanking are highly secured via DKIM.  So they might not just accept any
address from a customer.  They might double check it before accepting it and
if deemed not secured enough for their new e-Banking policies, they might
have a joint venture with ESP to provide secured secondary email address for
their customers.

---

From: Michael Thomas <[email-masked]>
Date: Sun, 30 Jul 2006 16:00:26 -0700

>details of the mechanisms that will be used to provide those services.
This sounds about right to me too, so what exactly are the things that make
DNS attractive? JohnL mentioned several (caching, widespread availability,
etc)... others? What about TCP's state creation? Is that a good/bad or 
neutral
thing for SSP? What about security properties? Is DNS adequate in this case?
If so, why?

       Mike

---

From: Michael Thomas <[email-masked]>
Date: Sun, 30 Jul 2006 16:08:27 -0700

>rather than being about sender signing practices, per se.
True, but we do need to get both discovery and transport requirements
out in the open too. I have some sections for them in my draft I'm working
on.

       Mike