Subject: Re: [ietf-dkim] draft-allman-dkim-ssp-02 // local-part encoding

From: Douglas Otis <[email-masked]>
Date: Thu, 31 Aug 2006 21:51:36 -0700

On Aug 31, 2006, at 5:09 PM, Douglas Otis wrote:

> Interesting.  A new RR type must be used.  Are the issues related  
> to a new RR type resolved?
>
> Rather than dropping characters in the local-part section, this  
> might impose a security problem when a character repertoire in the  
> local-part is unknown.  DNS permits case-folding.  Even without  
> case folding, the DNS code space represents about 25% of the  
> possible code points.  It would be safer using base32 encoding.   
> This encoding could provide a means to concatenate up to a maximal  
> domain name size and still provide about 100 byte answers.  With  
> base32, 63 bytes can encode 315 bits which represent 39 bytes and 3  
> bits. This would represent a 62% increase in the label size  
> needed.  The padding for the base32 could not be "=" as defined in  
> rfc3548, but instead could be "8" for padding.  Use of "_user"  
> reduces available name space by 6 bytes.  The draft did not  
> indicate whether truncation removed the left-most or right-most  
> portion of the local-part. Consider the answer carefully.  How is  
> truncation assured to occur at the same limit uniformly among the  
> verifiers?

On second thought.  To always ensure a consistent query size, pass  
the local-part address through an sha-1 hash and then encode this  
into base32.  This will produce a consistent 32 byte label size that  
also does not expose the underlying local-part address.  The risk of  
collision is fairly small.

-Doug

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

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 01 Sep 2006 07:54:00 +0100

No, not yet. As a WG, we're still on requirements.

After we've gotten consensus on those, we should look at the
various proposals.

Of course, I'm sure all of the authors of all of the
proposals will welcome comments off list.

S.

Hector Santos wrote:
> Are we seeking comments on this new draft now?
> 
> 
> ----- Original Message ----- 
> From: "Jim Fenton" <[email-masked]>
> To: "IETF-DKIM" <[email-masked]>
> Sent: Thursday, August 31, 2006 4:12 PM
> Subject: [ietf-dkim] [Fwd: I-D ACTION:draft-allman-dkim-ssp-02.txt]
> 
> 
>> FYI, an updated version of the Allman/Delany/Fenton SSP draft is now
>> available.  The changes from -01 are fairly extensive; see the summary
>> of changes near the end of the document.
>>
>> -Jim
>>
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts
>> directories.
>>
>>
>> Title : DKIM Sender Signing Practices
>> Author(s) : E. Allman, et al.
>> Filename : draft-allman-dkim-ssp-02.txt
>> Pages : 18
>> Date : 2006-8-31
>>
>> DomainKeys Identified Mail (DKIM) defines a domain-level
>> authentication framework for email using public-key cryptography and
>> key server technology to permit verification of the source and
>> contents of messages by either Mail Transport Agents (MTAs) or Mail
>> User Agents (MUAs).  The primary DKIM protocol is described in
>> This document describes the records that senders may use to advertise
>> how they sign their outgoing mail, and how verifiers should access
>> and interpret those results.
>>
>> A URL for this Internet-Draft is:
>> http://www.ietf.org/internet-drafts/draft-allman-dkim-ssp-02.txt

---

From: Frank Ellermann <[email-masked]>
Date: Fri, 01 Sep 2006 11:02:47 +0200

Dave Crocker wrote:
 
> TXT and HTML versions are also available at
> <http://mipassoc.org/dkim/ietf-dkim.htm>.

For SSP I found only the TXT of version -01
on this page and got no access on .../specs.

The IETF tools server had -02.

http://tools.ietf.org/id/draft-whatever    => latest
http://tools.ietf.org/id/draft-whatever-0x => draft 0x
http://tools.ietf.org/html/draft-whatever  => simple HTML
http://tools.ietf.org/wg/dkim              => DKIM drafts

Frank

---

From: Douglas Otis <[email-masked]>
Date: Mon, 04 Sep 2006 14:49:55 -0700

With the continued use of per-user policy in the ssp update...

Perhaps the following should be added to a requirements document.  DNS
encodes about 40 code points, which does not cover the 7-bit code point
range allowed by RFC2822 for the local-part.  Soon atext will extend to
also include UTF-8, less characters already excluded.  There will be 1-4
byte sequences of encoded characters as well.

For per-user policies:

- The entire code-point range of the local-part must be incorporated
  after canonicalization into forming a policy query.

- There be a means to in policy to indicate desired annotations based
  upon the local-part.  Such as <some-account@> is trustworthy.

-Doug

---

From: Frank Ellermann <[email-masked]>
Date: Tue, 05 Sep 2006 03:26:56 +0200

Douglas Otis wrote:
 
> DNS encodes about 40 code points

More like 230 octets if you treat US ASCII case insensitive.

IMO this SSP draft has more serious problems.  RFC 2822 etc.
clearly allow PRA != From, a "policy" or "practises" trying
to "forbid" RFC 2822 just makes no sense.

Let's build on RFC 4407 or drop SSP.  What is the precise
Message-ID where one of the Chairs stated that it's the
consensus of this WG to rename "policy" to "practises" ?

Frank

---

From: Douglas Otis <[email-masked]>
Date: Mon, 04 Sep 2006 21:47:51 -0700

> More like 230 octets if you treat US ASCII case insensitive.

This was in reference to scalar values of a character.  DNS case
insensitivity limits resolving an encoded local-part, especially when
the local-part is not ASCII, or perhaps includes subaddress symbols.

> to "forbid" RFC 2822 just makes no sense.

The current policy strategy is limited to a small segment of domains.
This segment is willing to endure delivery failures to ensure their
2822.From address is always signed by the same domain.  Some moderation
of delivery failures might be achieved by indicating adherence has not
been strict. 

> consensus of this WG to rename "policy" to "practises" ?

If I recall correctly, this took place before the chartering of the WG.

Due to potential replay issues, do not expect policy based criteria to
offer effective deterrents, except within an even smaller segment of
domains.  Working with large financial organizations, even the 2822.From
address being within the signing domain is not enough, there is also a
desire to further limit the resulting annotations.

With ether the perspective of an annotation or a policy based acceptance
standpoint, DKIM does not fully meet the needs of even a small segment
of domains.  Limiting annotations is not well accommodated by i=
semantics.  In addition, the i= parameter can not associate addresses
above or outside the signing domain.

Without policy associating signing domains with that of the SMTP client
or the 2821.MAIL_FROM, handling replay issues may prove problematic.
Ensuring DSNs, J.D. alluded to an expectation that the 2821.MAIL_FROM
would be the same as that of the signing domain.  This relationship is
not expressed within any DKIM related policy however.

By being able to associate the signing domain with that of other
domains, the DKIM signature offers greater value.  This association is
fully independent of the DKIM signature verification.

-Doug

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 05 Sep 2006 07:47:39 +0100

Frank Ellermann wrote:
>  What is the precise

There isn't one afaik. As Doug said that predates the WG.

But once reqs-01 is out, we're planning to move back into
using the issue tracker, so you can of course raise this
as an issue if you like, and it'll get resolved that way.

S.

---

From: Frank Ellermann <[email-masked]>
Date: Wed, 06 Sep 2006 05:35:37 +0200

Stephen Farrell wrote:
 
> As Doug said that predates the WG.

The WG charter says "policy" (incl. the quotes) and mentions
draft-allman-dkim-ssp 

> once reqs-01 is out. we're planning to move back into
> as an issue if you like

Yes.  I fear the SSP adventure is over, PRA is bad, anything
else is impossible.  On the SPF lists folks tried for years
to invent wild and wonderful new "identities" in addition to
the Return-Path, and they all failed miserably, incompatible
with 2822, only PRA makes remotely sense.

This "first address of the From" can't work.  Maybe you could
get the RFC 2822 author as external expert about this idea,
IIRC he was also invited to comment on some MARID proposals.

Frank

---

From: Damon <[email-masked]>
Date: Wed, 6 Sep 2006 10:08:42 -0400

> IIRC he was also invited to comment on some MARID proposals.

Only because people insist that it *must* work in every scheme they can make up.
I believe that we could implement what we have discussed and the fact
that it won't work for everybody should be an asterisk. It will work
for most systems and I am comfortable with that. Implementation is not
a requirement.

Regards,
Damon Sauer

---

From: Douglas Otis <[email-masked]>
Date: Wed, 06 Sep 2006 08:10:53 -0700

On Wed, 2006-09-06 at 10:08 -0400, Damon wrote:

> Only because people insist that it *must* work in every scheme they
> can make up. I believe that we could implement what we have discussed
> and the fact that it won't work for everybody should be an asterisk.
> It will work for most systems and I am comfortable with that.
> Implementation is not a requirement.

What percentage of domains want to experience delivery issues when the
2822.From address is not signed by the same domain?

An annotation scheme aimed at assuring an originating address should be
able to satisfy virtually all domains.  Introduce an optional
m=<email-address> parameter to both the signature field and the key.
This optional parameter could then work in conjunction with a designated
domain when assuring this email-address.  (Some might call this address
a PRA, but it would not depend upon any proprietary algorithm.)

An optional parameter added to the DKIM signature header not limited to
a specific domain, as well as policy records that can associate signing
domains with these other domains and offer far better coverage.  Making
this change would permit the largest percentages of the email-addresses
to be assured by DKIM, while also permitting simple autonomous
administration.  This would fully leverage the capabilities of a policy
record, where its administration also has a chance of scaling.

-Doug

---

From: Damon <[email-masked]>
Date: Wed, 6 Sep 2006 11:29:41 -0400

> record, where its administration also has a chance of scaling.

Why not both? I have no issues with using both.
I am not seeing this as a this proposal against that proposal. I think
they both have their place and we will be serving the community as a
whole much better by offering a choice between two schemes rather than
one or none.

Regards,
Damon Sauer

---

From: Douglas Otis <[email-masked]>
Date: Wed, 06 Sep 2006 09:05:57 -0700

> whole much better by offering a choice between two schemes rather than

Agreed.  Both can be done, while declaring exclusivity will likely
change into representing a list of domains.

-Doug

---

From: Frank Ellermann <[email-masked]>
Date: Wed, 06 Sep 2006 22:25:57 +0200

Damon wrote:

> It will work for most systems and I am comfortable with that

I'm not sure that it works for receivers implementing RFC 4406,
or senders using the Resent-* feature of STD 11.  We can't ask
non-participating resenders to upgrade their MUAs.  Maybe we
could ask SSP-verifiers to be smart wrt the PRA.  

As a requirement that could be:  "...must explain what happens
if a DKIM-ignorant user resends SSP-protected mail to SSP-aware
receivers".

Frank