Subject: RE: [ietf-dkim] Lean vs. Fat 'requirements'

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Thu, 10 Aug 2006 12:57:23 -0700

> [mailto:[email-masked]] On Behalf Of Jon Callas

> Subject: Re: [ietf-dkim] Lean vs. Fat 'requirements'
> 
> On 10 Aug 2006, at 6:55 AM, Dave Crocker wrote:
> 
> > Some of us believe, rather strongly, that this is a particularly 
> > important "bias" to the development of the requirements list.  It 
> > occurs, to me, however, that it might not be clear whether there is 
> > working group consensus on it.
> >
> > I would be interested in seeing statements of preference for, or 
> > against, having the requirements be minimalist, and include 
> only those 
> > items for which there is clear rough consensus to include.
> >
> > If an item engenders real wg controversy, it is *not* included.
> >
> > Comments?
> >
> 
> Minimalist good.

Blank checque vetoes bad.

The best way to make the requirements discussion interminable is to allow groups to exercise a veto by filibustering requirements they dislike.

I don't care about the complexity of a requirements document. All I care about is that the complexity of the solution be minimized.

I rate the skill of a protocol designer by their ability to find simple solutions to complex requirements.

Time after time the IETF has produced worthless trash because the requirements analysis was either incomplete or arbitrarily constrained. If you look at the protocols that have become overly complex the root cause is frequently inadequate requirements analysis in the first instance leading to protocols that acrete a missmash of ad-hoc extensions.

The only reason that PKIX has CRLs, OCSP, SCVP, Attribute certificates all as add on mechanisms to basic certs is because the original requirements analysis was incomplete. The complexity of the resulting spec is enormous.

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

---

From: <[email-masked]>
Date: Thu, 10 Aug 2006 16:13:18 -0400

Requirements,

What do I sign
Who does my signing
When does my DKIM Public Key expire
Who do I sign for
Who shall I never sign for (I sign no mail)
What receiver expectation shall I set (perhaps dodgy)

What else should be on the list?

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 Hallam-Baker,
Phillip
Sent: Thursday, August 10, 2006 3:57 PM
To: Jon Callas; [email-masked]
Cc: [email-masked]
Subject: RE: [ietf-dkim] Lean vs. Fat 'requirements'

The best way to make the requirements discussion interminable is to
allow groups to exercise a veto by filibustering requirements they
dislike.

I don't care about the complexity of a requirements document. All I care
about is that the complexity of the solution be minimized.

I rate the skill of a protocol designer by their ability to find simple
solutions to complex requirements.

Time after time the IETF has produced worthless trash because the
requirements analysis was either incomplete or arbitrarily constrained.
If you look at the protocols that have become overly complex the root
cause is frequently inadequate requirements analysis in the first
instance leading to protocols that acrete a missmash of ad-hoc
extensions.

The only reason that PKIX has CRLs, OCSP, SCVP, Attribute certificates
all as add on mechanisms to basic certs is because the original
requirements analysis was incomplete. The complexity of the resulting
spec is enormous.

---

From: Douglas Otis <[email-masked]>
Date: Thu, 10 Aug 2006 13:53:42 -0700

> When does my DKIM Public Key expire

Key expiry seems problematic.  A domain may have hundreds of keys  
having different expirations.

> Who do I sign for

This can be a separate policy that might represent a 2821.MAIL_FROM  
list or perhaps a 2821.EHLO list.

> What receiver expectation shall I set (perhaps dodgy)

Covered by a combination of assertions of Who:What:Where with Only:All.

"Only" asserts exclusivity.
"All" asserts all initial emails are signed.
"Where" would be the policies associated with MAIL_FROM and EHLO.

Only+All = DKIM Signer Complete
All = DKIM Signer Extended

-Doug

---

From: "Hector Santos" <[email-masked]>
Date: Thu, 10 Aug 2006 22:34:15 -0400

----- Original Message -----
From: <[email-masked]>

> What else should be on the list?

Signer POV.  Cool. :-)

Now lets look at a "Lean Fly Squatting" Verifier POV:

First Stage: Incoming Mail:

 - Does he ever distribute mail? (Never Send Mail)
 - Does he expect the mail to be unsigned? (Never Sign)
 - Does he expect the mail to be sign? (Always Sign)
 - Does he care? (Neutral)
 - Does he allow others to sign?   (Allow 3PS w/o Allow List)
 - SSP Result Disposition based on Local Policy (Default Reject)

This is a low overhead, highly efficient DKIM consideration, where the need
for verification overhead is short circuited - this helps comply with the
discovery requirements of a DKIM-SSP design.

Second Stage:

 - Ok, got something, it is expired?
 - Ok, got something, does it hash out (signature verify)?
 - DKIM Result Disposition based on Local Policy (Default Reject)

Remember, we have to do the dissemination of all the mail traffic coming our
way.

I (verifier, traditional SMTP receiver) really does not care for:

  - "What" kind of mail you sign, and
  - "Who" signed for you (as long as you said its ok)

This WHAT/WHO is really none of my business.  That could be moved to a
trusted layer or mail content heuristic system.

But for this particular DKIM-BASE model? The above questions are items I
would like to know  before I even bother with the DKIM-BASE signature
verification overhead.

To me, this is simple and lean and it adds a tremendous benefit in securing
the DKIM signing practices and expectations.

This simple and lean model, helps the signer by adding weight to his
signature validity by eliminating the most obvious of potential
inconsistencies and by doing that, I am helping my own system by getting rid
of the most obvious unauthorized DKIM-based abuse.

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

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 11 Aug 2006 09:24:48 +0100

Folks,

There's nothing wrong with Bill's message, but I'd really
rather not see it being the start of a long thread that
effectively amounts to re-doing the work that Mike did to
produce the requirements I-D.

Can we concentrate on comments-on/changes-to our WG
requirements draft?

Thanks,
Stephen.