Subject: RE: [ietf-dkim] Attempted summary, SSP again

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Fri, 27 Jan 2006 11:07:49 -0800

I suggest that a good way to try to focus the discussion here would be
to abandon the punctuation syntax while we discuss the semantics, work
out what semantics should be there and then decide whether the
punctuation syntax is worth keeping.

I would also suggest that meta discussion, that is discussion about
whether we should be having a discussion on a particular topic cease
unless it comes from the chairs. It is quite reasonable to point out to
a poster that their point has been made and rejected, telling them that
their point should not be debated yet serves no useful purpose.

In my view the design of the policy statement should be based on the
folowing principles:

* It is the exclusive right of the domain name owner to decide 
  how the domain name is used.
	* for the purpose of the spec the domain name owner should 
	  be presumed to be the party that controls the DNS records
	* The domain name owner can decide the importance of edge 
	  cases such as mail that does not pass through the
	  approved gateways.

* A policy record does not modify the semantics of a DKIM digital 
  signature
	* The semantics of the signature are exclusively defined by the
	  DKIM signature header and the referenced key record (or other
	  key distribution/assertion mechanism referenced in the header
	  or key record)

* The purpose of a policy record is to assist a recipient interpret
	the absence of a valid signature record.

* A policy record describes the intended outbound signing policy of 
  the sender.
	SEND = ALWAYS | SOMETIMES{detail} | NEVER SIGN | NEVER SEND

* A policy record may contain additional information to guide
interpetation
  of the absence of a signature, for example that the sender is a 
  frequent target of phishing attack.
	TARGET = PHISHING{detail}

* A policy mechanism may advertise support for specific incident
reporting
  mechanisms in the case that an invalid signature is found.
	REPORT = RID | ...

* A policy mechanism may specify certain characteristics of a valid
signature,
  for example the signature algorithm used &ct.

_______________________________________________
ietf-dkim mailing list
http://dkim.org

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 27 Jan 2006 19:52:20 +0000

Hi Phil,

Hallam-Baker, Phillip wrote:
> telling them that

Except perhaps when the debate has degenerated so quickly as
happened in this case.

As the rest of your mail discusses, there's work to be done on
policy but we don't want get sidetracked there (yet:-).

The charter is very clear on the order of our milestones and
on the fact that the threats draft is a pre-requisite before
base or ssp, quoting the threats milestone:

   "IESG approval of this document is a prerequisite for the
   submission of the standards-track specifications."

(To be fair though, Hector is one of the few posters who
has already commented the threats draft.)

Stephen.

---

From: "Hector Santos" <[email-masked]>
Date: Fri, 27 Jan 2006 16:46:03 -0500

----- Original Message -----
From: "Hallam-Baker, Phillip" <[email-masked]>

> I suggest that a good way to try to focus the discussion
> here would be to abandon the punctuation syntax while we
> discuss the semantics, work out what semantics should be
> there and then decide whether the punctuation syntax is
> worth keeping.

I agree. When I "suggested" the terms, I clearly left it up to the
authors to make the final call on them.  But I did think Exclusive and
Neutral were obvious terms.  I could care less what we call them. But
using OH equal This or that, doesn't cut it during technical
conversations.  Thats for software to understand.

> In my view the design of the policy statement should be
> based on the folowing principles:

>  how the domain name is used.

I agree, but he needs to be made aware what that right entails, meaning
don't park your BMW in a bad neighorhood and expect it to be safe!

>   be presumed to be the party that controls the DNS records

Ok.

>   cases such as mail that does not pass through the

Ok, but by doing so, he puts a burden on the edge software too. In order
words, should we be responsible in maintain the domain security?

> * A policy record does not modify the semantics of a DKIM digital

Hmmm, not sure what you mean.  Can the signature exhibit a policy that
is conflictive with the publish policy?

>   key distribution/assertion mechanism referenced in the header

Ok.

> the absence of a valid signature record.

No I disagree.  This is the Michael Thomas's assertion:

     SSP is not for signed messages, only for unsigned messags.

and it is reflective in his pseudo-code which the current API I believe
follows.

This is a Major Loophole. What if there is no domain signing policy and
the message is signed?   There is something wrong here with this and
other similar policy/signature conflicts.  They presents clear loopholes
in the protocol.

I have not been convinced that a valid signature is sufficient enough to
bypass, skip any further validation on the transaction and that the
message should be accepted with 100% trust behind it.

> * A policy record describes the intended outbound signing policy of

Ok, but think about it. If this assertion is to be true, then the
previous assertion needs to be corrected. :-)

> * A policy record may contain additional information
> to guide interpetation of the absence of a signature,
> for example that the sender is a frequent target of
> phishing attack.

Ok, this is new stuff that was touched on by Earl and I with "Failure
Action attributes".  But in principle, there is a default expectation
when a policy states a requirement that isn't honored.  So if a
signature is expected, and its not there, that should be a failed
condition.  The default is reject (and by reject, I mean it is marked
for the local policy to decide).  Me?  Reject it!! In the waste basket.

> * A policy mechanism may advertise support for specific incident
reporting mechanisms in the case that an invalid signature is found.

Ok. Similar logic worked out in SPF with some implementations. Need to
watch for Report Attacks.  So maybe 1 report concepts are recommended.

> * A policy mechanism may specify certain characteristics of
> a valid signature, for example the signature algorithm used.

Isn't this already there?

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

---

From: <[email-masked]>
Date: Sat, 28 Jan 2006 17:26:17 -0500

Hector,

If a bad actor gets an account behind my domain, sets up dkim signing locally on his machine then spews spam to the net what will that do to the reputation of the ISP? Edge software will need to be aware and target such bad actors. 
thanks,
Bill