Subject: [ietf-dkim] New issue: Requirement #10 - Invoking SSP - Suggestion to Remove this.

From: "Hector Santos" <[email-masked]>
Date: Tue, 26 Sep 2006 11:18:17 -0400

Requirement #10 indicates:

   10.  The Protocol MUST NOT be required to be invoked if a
        valid first party signature is found.

Suggestion:

Remove req #10, maybe add a new section that talks about the validation
value of 1st party signatures vs. 3rd party signatures.

Comments:

I don't get it this militant MUST NOT provision for a design decision.  The
statement makes it sound like its already written in stone that software
developers WILL invoke the protocol and the author is trying to STOP it for
his own reasons.

If my software engineering experience gives me any insight into proper
designs, I will surely violate this requirement and I get the sense most
software implementators developing their own DKIM/SSP tools will realize how
this req #10 conflicts with their design needs.

It is unnecessary requirement that attempts to mandate a certain design
approach which has no proof of being the correct approach.

At best, it should be rephrase to maybe serve as a reminder that 1st party
validated signatures have a higher trust value and that by DEFAULT there
should be no conflict with the SSP policy.

But what is there is a conflict?

What does that mean?  Should there be some tagging, notification, logging or
reporting by the receiver?  Not saying this level of logic should be in the
requirements, but you have no control how the implementer will want to
approach this here.

In short, it is a implementator or software decision how they will approach
POLICY vs. SIGNATURE checking.  I already see I will be ignoring this
requirement.  I may check it always regardless of signed or no signed mail
simply because regardless of what the signature says, it must be consistent
with the policy.  If the 1st party signature is valid but there is a
CONFLICT with the POLICY, then someone should be scratching their heads on
this.

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

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

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 26 Sep 2006 16:32:49 +0100

Hector,

It'd make it easier for the WG to make a decision (whether positive
or negative) if you could suggest text for such a new section.

Thanks,
S.

PS: A "MUST NOT be required" is the same as a MAY. Nothing militant
there at all IMO.

---

From: Damon <[email-masked]>
Date: Tue, 26 Sep 2006 12:17:09 -0400

> Hector,
>
> How about:
> " 10.  The Protocol MUST NOT be required to be invoked if a valid
> first party signature *and* valid first party policy is found."
>
> I believe that the _MUST NOT_ was put in so that implementers do not
> continue to process even though a valid sig and policy are found and
> this was the way to enforce it. Taking it out would open up a whole
> new problem with "whose policy is most valid?" etc. My vote is for
> leaving it in but changing the wording to address the issue you
> brought up.
>
> Regards,
> Damon Sauer
>

 Now that I think about it for one second longer... isn't it
considered a "valid first party sig" because of policy? Wouldn't a
broken policy invalidate the first party sig?
Maybe we do not have to change this at all.

Regards,
Damon Sauer

---

From: Damon <[email-masked]>
Date: Tue, 26 Sep 2006 12:14:42 -0400

Hector,

How about:

Regards,
Damon Sauer

---

From: Frank Ellermann <[email-masked]>
Date: Tue, 26 Sep 2006 18:35:07 +0200

Stephen Farrell wrote:
 
> A "MUST NOT be required" is the same as a MAY. Nothing
> militant there at all IMO.

It's misleading.  What "we" want is that no DKIM signer or
verifier is forced to support SSP at all.  As soon as they
(try to) support SSP they're supposed to get it right, and
if that requires "check SSP for signature", then they do
that.

Frank

---

From: "Hector Santos" <[email-masked]>
Date: Tue, 26 Sep 2006 12:54:58 -0400

The requirement attempts to make an implied rule about the flow of software
designs using a valid first party signature and implicit presumption the
policy is proper and/or has no bearing whether it is or not.  Whether that
is true or not, it shouldn't be stated in a way that suggest it isn't
necessary from an *implementation standpoint*.

My first suggestion is to remove req #10, and as a perfect bonus add a
separate section, maybe title

   1.1 Invoking SSP

with reasons why it may or may not be necessary. This is what's going to
help designers with their approaches.  Because its a discussion on possible
optimization, which may include the statement "not required to be invoked
when a valid 1st party is found."

But overall, the key point is that invoking SSP is not just for SMTP
receivers but also other email related software as well, such as a List
Server and others applications where users will be asked for their email
address (atleast that is our plan).

So with that said, if we want some text, I might suggest:

  1.1 Invoking SSP

  How SSP is invoked is out of scope of the SSP requirements. The
  design for SSP implementation and usage may vary depending on the
  mail application. For example, a SMTP receiver may wish to invoke
  SSP immediately to check for various policies prior to performing
  the higher overhead DKIM-BASE has verification process. A LIST
  SERVER may wish to invoke SSP as part of its subscription process.

  It should be noted that valid 1st party signatures is considered
  to be a sufficiently secured valid condition per DKIM-BASE
  specification design goals which may allow for DKIM-SSP
  implementators a method to short circuit SSP queries when 1st
  party signatures are valid.

  However, implementators should keep in mind, it is technically
  possible for an inconsistent policy to exist even for valid 1st
  party signatures.  How implementators address this condition is out
  of scope of the SSP requirements.

That's the best I can say it trying to wear a few different hats here.

----- Original Message -----
From: "Stephen Farrell" <[email-masked]>
To: "Hector Santos" <[email-masked]>
Cc: "IETF-DKIM" <[email-masked]>
Sent: Tuesday, September 26, 2006 11:32 AM
Subject: Re: [ietf-dkim] New issue: Requirement #10 - Invoking SSP -
Suggestion to Remove this.

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 26 Sep 2006 17:58:30 +0100

Frank Ellermann wrote:
> It's misleading.  

Maybe - from earlier mails there do seem to be differing views,
but in any case now that Hector has raised it as an issue, the
WG will address it in jabbering etc.

Cheers,
S.

PS: To be clear: I wasn't saying that "MUST NOT be required" is
better or worse than "MAY", but that neither is "militant"
anything.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 26 Sep 2006 17:59:35 +0100

Thanks Hector,

That'll make it easier to decide this once we get to it in
a jabber,

Cheers,
Stephen.