Re: [ietf-dkim] [Technical Errata Reported] RFC6376 (4926)

[Stephen Farrell]

On 14/02/17 01:32, Barry Leiba wrote:
> Verified as Editorial is my preference.

Done.

Cheers,
S.



signature.asc
Description: OpenPGP digital signature
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html

Re: [ietf-dkim] [Technical Errata Reported] RFC6376 (4926)

[Stephen Farrell]

On 08/02/17 03:04, Barry Leiba wrote:
> When I was on the IESG, we had been talking with Heather and Sandy about
> what to do about fixing up the whole errata system.   Not sure where that
> is now.  It wasn't anyone's top priority at the time.

The RFC editor folks were too busy with the RFC format
fun. That's now much further along so I'd hope that it
becomes possible to address the errata system in the not
too distant future. If you care about that, it'd be no
harm to ping the IESG or an AD saying that you think it
is time to improve/fix the errata system.

Cheers,
S.


> 
> b
> 
> 
> On Tue, Feb 7, 2017 at 6:40 PM Dave Crocker  wrote:
> 
>> On 2/7/2017 5:52 PM, Roland Turner wrote:
>>> As a passing engineer who doesn't spend that much time spelunking IETF
>>> processes, a question that appears to be begged here is why the
>>> distinction matters. This is not immediately clear from any of the
>>> Status and Type of RFC Errata page
>>> , the How to Report
>>> Errata page , or the FAQ
>>> .
>>
>> 
>>
>> In recent years -- and by way of demonstrated some basic process
>> problems, I'll note that I have no idea when the current constraints on
>> the process were put in place -- the RFC errata process got moved into a
>> very specialized place, to the exclusion of a number of useful
>> functions.  It's not that what it does do isn't useful, it's that it has
>> become idiosyncractic.  And, yeah, it does not appear to me that most
>> folk know what it is and is not useful form.
>>
>> 
>>
>> d/
>>
>> --
>>
>>Dave Crocker
>>Brandenburg InternetWorking
>>bbiw.net
>>
> 
> 
> 
> ___
> NOTE WELL: This list operates according to
> http://mipassoc.org/dkim/ietf-list-rules.html
> 



smime.p7s
Description: S/MIME Cryptographic Signature
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html

Re: [ietf-dkim] Fwd: [Technical Errata Reported] RFC6376 (4926)

[Stephen Farrell]

On 07/02/17 15:33, Dave Crocker wrote:
> G'day.
> 
> Looking for a community determination, here:  The DKIM spec's examples
> in A.2 and A.3 do not explicitly claim to be related to each other.
> However they do contain the same message, so that assuming a
> relationship seems pretty reasonable.
> 
> As such, calling the point raised in this Errata report an actual error
> is certainly not silly.  But I'm not sure it's correct, either.
> 
> Thoughts?

Seems to me to maybe match the "hold for document update"
classification.

S.


> 
> d/
> 
> 
>  Forwarded Message 
> Subject: [Technical Errata Reported] RFC6376 (4926)
> Date: Tue,  7 Feb 2017 07:17:12 -0800 (PST)
> From: RFC Errata System 
> To: dcroc...@bbiw.net, tony+dki...@maillennium.att.com,
> m...@cloudmark.com, stephen.farr...@cs.tcd.ie,
> kathleen.moriarty.i...@gmail.com, barryle...@computer.org
> CC: simon@emersion.fr, ietf-dkim@mipassoc.org,
> text/pl...@rfc-editor.org, charset=ut...@rfc-editor.org
> 
> The following errata report has been submitted for RFC6376,
> "DomainKeys Identified Mail (DKIM) Signatures".
> 
> --
> You may review the report below and at:
> http://www.rfc-editor.org/errata_search.php?rfc=6376=4926
> 
> --
> Type: Technical
> Reported by: Simon Ser 
> 
> Section: A.2, A.3
> 
> Original Text
> -
> DKIM-Signature: v=1; a=rsa-sha256; s=brisbane; d=example.com;
>  c=simple/simple; q=dns/txt; i=j...@football.example.com;
>  h=Received : From : To : Subject : Date : Message-ID;
>  bh=2jUSOH9NhtVGCQWNr9BrIAPreKQjO6Sn7XIkfJVOzv8=;
>  b=AuUoFEfDxTDkHlLXSZEpZj79LICEps6eda7W3deTVFOk4yAUoqOB
>  4nujc7YopdG5dWLSdNg6xNAZpOPr+kHxt1IrE+NahM6L/LbvaHut
>  KVdkLLkpVaVVQPzeRDI009SO2Il5Lu7rDNH6mZckBdrIx0orEtZV
>  4bmp/YzhwvcubU4=;
> Received: from client1.football.example.com  [192.0.2.1]
>  by submitserver.example.com with SUBMISSION;
>  Fri, 11 Jul 2003 21:01:54 -0700 (PDT)
> From: Joe SixPack 
> To: Suzie Q 
> Subject: Is dinner ready?
> Date: Fri, 11 Jul 2003 21:00:37 -0700 (PDT)
> Message-ID: <20030712040037.46341.5...@football.example.com>
> 
> 
> Corrected Text
> --
> DKIM-Signature: v=1; a=rsa-sha256; s=brisbane; d=example.com;
>   c=simple/simple; q=dns/txt; i=j...@football.example.com;
>   h=Received : From : To : Subject : Date : Message-ID;
>   bh=2jUSOH9NhtVGCQWNr9BrIAPreKQjO6Sn7XIkfJVOzv8=;
>   b=AuUoFEfDxTDkHlLXSZEpZj79LICEps6eda7W3deTVFOk4yAUoqOB
>   4nujc7YopdG5dWLSdNg6xNAZpOPr+kHxt1IrE+NahM6L/LbvaHut
>   KVdkLLkpVaVVQPzeRDI009SO2Il5Lu7rDNH6mZckBdrIx0orEtZV
>   4bmp/YzhwvcubU4=;
> Received: from client1.football.example.com  [192.0.2.1]
>   by submitserver.example.com with SUBMISSION;
>   Fri, 11 Jul 2003 21:01:54 -0700 (PDT)
> From: Joe SixPack 
> To: Suzie Q 
> Subject: Is dinner ready?
> Date: Fri, 11 Jul 2003 21:00:37 -0700 (PDT)
> Message-ID: <20030712040037.46341.5...@football.example.com>
> 
> Notes
> -
> The "simple" header canonicalization doesn't change the header fields in
> any way.
> 
> Folded header fields are missing one space of indentation (they have 5
> spaces instead of 6), which makes the verification fail. Note that the
> plain text version of the RFC adds a prefix of three spaces before each
> line of text, which must be ignored.
> 
> In section A.3, the indentation is changed again (5 spaces instead of 6
> + the "b=" tag has 2 additional spaces of indentation).
> 
> Test cases:
> - opendkim:
> https://github.com/cyrusimap/opendkim/blob/ab2934e131cbe670b49f11db9daf8cd1223e3839/libopendkim/tests/t-testdata.h#L74
> 
> - go-dkim:
> https://github.com/emersion/go-dkim/blob/master/verify_test.go#L9
> 
> Instructions:
> -
> This erratum is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party  can log in to
> change the status and edit the report, if necessary.
> --
> RFC6376 (draft-ietf-dkim-rfc4871bis-15)
> --
> Title   : DomainKeys Identified Mail (DKIM) Signatures
> Publication Date: September 2011
> Author(s)   : D. Crocker, Ed., T. Hansen, Ed., M. Kucherawy, Ed.
> Category: DRAFT STANDARD
> Source  : Domain Keys Identified Mail
> Area: Security
> Stream  : IETF
> Verifying Party : IESG
> 
> ___
> NOTE WELL: This list operates according to
> http://mipassoc.org/dkim/ietf-list-rules.html



smime.p7s
Description: S/MIME Cryptographic Signature
___
NOTE WELL: This list operates according to

Re: [ietf-dkim] DKIM Key Sizes

[Stephen Farrell]

Hi Jon,

On 27/10/16 23:29, Jon Callas wrote:
> 
>> On Oct 27, 2016, at 1:29 AM, Peter Goldstein 
>> wrote:
> 
>> Those guidelines ... specify that receivers MUST validate
>> signatures of 512 to 2048 bits, but are not required to validate
>> signatures with longer keys - may be worth revisiting given
>> advances in computing power, the increasing importance of DKIM as
>> an element of email authentication, and the reuse of these
>> guidelines in other proposals (i.e. ARC).
> 
> 
> [...]
> 
>> I'd like to suggest that it may be a good idea to increase the
>> upper value to 4096 or even 8192, to ensure that the standard is
>> compatible with best practices going forward.
> 
> I don't object to increasing it in the standard, but operationally I
> don't think it's a good idea. Per-message processing cost is one
> reason, but the larger one is the semantic value of a DKIM signature,
> and what it is trying to do.
> 
> DKIM is a conversation between two administrative domains, and a
> signature only states that an administrative domain is taking
> responsibility for placing the message in the message stream. Nothing
> more.
> 
> That assurance comes at a cost of whatever integrity that assigns to
> a message that might have been unintended. That message integrity is
> a privacy loss by the users.
> 
> The real-world case in point is the leaked Podesta emails, where some
> people have asserted that authenticity can be checked via the DKIM
> signatures. I've raised an eyebrow on that, and the bottom line is
> that you're presuming that attackers were sophisticated enough to
> steal the email, yet unsophisticated enough that stealing the DKIM
> key from an MTA is out of the question.
> 
> The full discussion is pretty nuanced, and I think the relevant part
> here is that if an administrative domain wants to protect the privacy
> of its users, it should be using *smaller* DKIM keys, not larger
> ones. I think I could convincingly argue that a privacy-friendly
> email provider is better off using 512 bit keys (where there's a
> chance of spam forgery) than 4K keys (where there's a chance of
> ruining the privacy of the customers). Now actually, I think the
> sweet spot for key size is above 512, but it's lower than 768. For
> maximum balance, you want the key to take longer than a week to
> crack, but less than a year, and change it every month. Or something
> like that. You get the idea.

Ick.

I think the property you're aiming for is to not damage
deniability? If not, then can you explain.

I don't think a just-about-dodgy-rsa-length is a good
way to try get that because:

- it's extremely algorithm specific - other algs don't
have similar properties (and it'd be a horribly bad idea
to define 'em)

- it'd be vulnerable to an actual factorisation during
the operational lifetime of a key pair, which is not a
thing we can easily evaluate (more or less damage to
whom overall?)

- no matter that the semantics of a DKIM signature are
well defined to (try to) not damage deniability, we
can't stop people from associating other semantics with
signatures, of any length - IOW, so long as the factorisation
of a modulus isn't known, deniability is damaged

The only up-side of your suggestion I can see is that
it would keep some bad actors busy.

Instead, I'd point out that this can be handled, even now,
by simply rolling to a new key and then shortly publishing
the private key used to sign the messages. That way Podesta
could deny the content once more, at least at the crypto
level.

Whether or not publishing private keys would be something
that the community would do is a fine question, but it'd be
a better approach. (I forget, and didn't look back to see,
if someone suggested this before for DKIM, I think I recall
that someone may have though.)

Releasing the private key when you're done with it, is also
nicely algorithm independent so if we wanted to take that
route that would not prevent us moving DKIM to eddsa to get
the nice benefits that offers over RSA.

I could imagine us writing an RFC about why and how to do
DKIM signature key rollover and private key publication and
would be happy to help if there were a chance it'd get some
traction.

Cheers,
S.


> 
> In any event, I don't object to changing it, but I do think that if
> someone's going to implement long keys, they're going to get
> criticism about enabling surveillance of their users.
> 
> Jon
> 
> 
> 
> ___ NOTE WELL: This list
> operates according to http://mipassoc.org/dkim/ietf-list-rules.html
> 



signature.asc
Description: OpenPGP digital signature
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html

Re: [ietf-dkim] [Technical Errata Reported] RFC6376 (4810)

[Stephen Farrell]

If someone familiar with the dkim abnf could comment I'd be
happy to approve/reject this as appropriate.

S

On 26/09/16 20:15, RFC Errata System wrote:
> The following errata report has been submitted for RFC6376,
> "DomainKeys Identified Mail (DKIM) Signatures".
> 
> --
> You may review the report below and at:
> http://www.rfc-editor.org/errata_search.php?rfc=6376=4810
> 
> --
> Type: Technical
> Reported by: Juan Altmayer Pizzorno 
> 
> Section: 3.5
> 
> Original Text
> -
> x-sig-q-tag-args = qp-hdr-value
> 
> Corrected Text
> --
> x-sig-q-tag-args = dkim-quoted-printable  ; with ":" encoded
> 
> Notes
> -
> sig-q-tag-methods are ":"-separated in sig-q-tag, so ":" shouldn't be 
> permitted
> within x-sig-q-tag-args.  Note that qp-hdr-value (which I believe was 
> originally
> defined for sig-z-tag, which includes "|"-separated values) is defined as
> 
>qp-hdr-value=  dkim-quoted-printable; with "|" encoded
> 
> Instructions:
> -
> This erratum is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party (IESG)
> can log in to change the status and edit the report, if necessary. 
> 
> --
> RFC6376 (draft-ietf-dkim-rfc4871bis-15)
> --
> Title   : DomainKeys Identified Mail (DKIM) Signatures
> Publication Date: September 2011
> Author(s)   : D. Crocker, Ed., T. Hansen, Ed., M. Kucherawy, Ed.
> Category: DRAFT STANDARD
> Source  : Domain Keys Identified Mail
> Area: Security
> Stream  : IETF
> Verifying Party : IESG
> 
> 



smime.p7s
Description: S/MIME Cryptographic Signature
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html

[ietf-dkim] Fwd: [Lurk] Another outside the "box" use case: DKIM

[Stephen Farrell]

(Not sure if this list is still active, but FYI...)

LURK is an IETF mailing list that's discussing developing a
solution to the "offload TLS without giving the CDN my private
key" problem. Right now, people are trying to figure out if,
as seems likely, the above is the only use case that'll be
tackled, or if there are other relevant use-cases people are
also willing to work on.

If interested in this, please discuss it on l...@ietf.org

Ta,
S.

 Forwarded Message 
Subject: [Lurk] Another outside the "box" use case: DKIM
Date: Mon, 29 Feb 2016 21:09:58 +
From: Stephen Farrell <stephen.farr...@cs.tcd.ie>
To: Eric Burger <ebur...@standardstrack.com>, LURK BoF <l...@ietf.org>


(I like that we're playing this game now. If we get
a bunch of these off the table before B-A, that may
allow us better use the f2f time.)

Here's another one to consider and maybe say "no."

DKIM-signing domains sometimes use partner companies to
e.g. send out marketing crap or userful materials. That
can be done in various ways but using lurk for DKIM-signing
without giving the partner a DKIM private key for my domain
could be yet another use.

I suspect that it'd be considered OTT to use such an
interface for DKIM-signing, but who knows?

Cheers,
S.






___
Lurk mailing list
l...@ietf.org
https://www.ietf.org/mailman/listinfo/lurk



smime.p7s
Description: S/MIME Cryptographic Signature
___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

Re: [ietf-dkim] IPR Disclosure: ENTERKHAN CO., LTD's Statement about IPR related to RFC 6376, draft-allman-dkim-base-01, and Creative Commons

[Stephen Farrell]

That looks weird. Do we know its not spam?
S

On 08/15/2013 04:44 PM, IETF Secretariat wrote:
 
 Dear Murray Kucherawy, Dave Crocker, Tony Hansen:
 
  An IPR disclosure that pertains to your RFC entitled DomainKeys Identified
 Mail (DKIM) Signatures (RFC6376) was submitted to the IETF Secretariat on
 2013-08-08 and has been posted on the IETF Page of Intellectual Property 
 Rights
 Disclosures (https://datatracker.ietf.org/ipr/2169/). The title of the IPR
 disclosure is ENTERKHAN CO., LTD's Statement about IPR related to RFC 6376,
 draft-allman-dkim-base-01, and Creative Commons.);
 
 The IETF Secretariat
 
 
 
___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

Re: [ietf-dkim] WG Action: Conclusion of Domain Keys Identified Mail (dkim)

[Stephen Farrell]

On 09/26/2011 07:23 PM, Barry Leiba wrote:
 The Domain Key Identified Mail (dkim) working group in the Security Area
 has concluded.

 And with that, ends an era.  I want to thank everyone who worked hard
 on getting the DKIM documents decided, written, and published.  I've
 been pleased to chair this group for more than five and a half years.

Bit late 'cause I was away, but I second Barry's sentiment. I also
learned quite a bit (or think I did:-) along the way,

Thanks,
S.

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

Re: [ietf-dkim] ECC (was RE: DKIM using old RSA padding?)

[Stephen Farrell]

On 28/02/11 17:48, Murray S. Kucherawy wrote:
 But while we're on the topic...
 
 Elliptic curve cryptography has been getting more and more attention lately.  
 Does anyone have a good feel for adoption rates?  Should we (or maybe another 
 group, or an individual submission) look into registering a new signing 
 algorithm and key storage specification for that technology?

I think that'd be a fine thing for someone to do. However, I
don't think its really useful until we need it, so one idea
might be to wait for sha-3 and then do a bunch of 'em at the
same time?

I think we will eventually want ECC instead of veeery lng
RSA keys.

The time to switch for DKIM is likely to be when you no longer
want to sign with an RSA key that fits a DNS response nicely.
Not sure off the top of my head what exactly that would be in
terms of RSA modulus size.

But if there's demand now (e.g. for suite-B conformance or
something) maybe earlier than that would be better. I've not
heard that that's needed myself.

S.

PS: No hats on for this of course:-)


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

Re: [ietf-dkim] ECC (was RE: DKIM using old RSA padding?)

[Stephen Farrell]

On 28 Feb 2011, at 19:47, Dave CROCKER d...@dcrocker.net wrote:

 
 
 On 2/28/2011 1:34 PM, Stephen Farrell wrote:
 The time to switch for DKIM is likely to be when ...
 
 
 Just to be entirely pedantic:
 
 1. This topic is out of scope for the wg at this time.

Asking is fine IMO, but yes, we're not chartered for that as I said earlier. 
(Though admittedly not directly when responding to Murray.)

 
 2. There is no industry view that we need to stop using the current DKIM 
 crypto algorithms anytime soon.  There's nothing wrong with adding to the 
 repertoire of algorithms if someone is motivated, but there is no industry 
 urgency.
 
 Yes?

Absolutely. Later is plenty soon enough.

S

 
 d/
 
 -- 
 
  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net

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

Re: [ietf-dkim] Do we need to meet in Prague?

[Stephen Farrell]

So I've just requested a 1.5 hour slot for Prague. If we figure
we don't need it we can cancel out later.

Stephen.

On 21/01/11 18:50, Eliot Lear wrote:
 Barry,
 
 I'd suggest that the group is in one of two states:
 
 * We are sufficiently agreed on 4871bis that it can advance, at
   which point I would ask that we circle back to the DOSETA split,
   and how it relates to other work, and what opportunities there
   are.  I think Dave really posed an interesting idea, and what it
   needs is a good test case.  If we can identify that, then I would
   say we should meet on that point, and consider this from a
   re-charter perspective.
 * If we are not concluded on 4871bis, then we should meet to close
   on open issues.
 
 
 Thanks,
 
 Eliot
 
 On 1/20/11 10:32 PM, Barry Leiba wrote:
 Does the DKIM working group think it needs a face-to-face meeting in
 Prague, at IETF 81?

 I think we do not, though that answer may depend upon whether 4871bis
 is ready or needs more discussion, and whether we think we need
 discussion about the mailing lists document (which Murray has
 patiently been holding off on, while we sort out 4871bis).

 Comments?

 Barry, as chair
 ___
 NOTE WELL: This list operates according to 
 http://mipassoc.org/dkim/ietf-list-rules.html

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

Re: [ietf-dkim] Re-thinking the organization of the DKIM spec

[Stephen Farrell]

On 11/01/11 12:12, Eliot Lear wrote:
 1.  I recognize that sometimes good ideas have their own schedules, but
 I consider it unfortunate that the WG had to spend time to go through
 WGLC, resolve open issues, and then for the authors and chairs to
 reorganize the work.  

Just one quick clarification. The editors brought this suggestion to
us and the chairs are bringing that to the WG to see if there's
consensus for a change or not, i.e., the chairs aren't advocating
one way or the other, (though we may have opinions), we're trying
to find out what the WG wants.

And as Barry said in his original posting: We'll need rough
consensus FOR making the change. Lacking that, 4871bis will stay
as it is, as one document.

Cheers,
S.
___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

Re: [ietf-dkim] one more round of the inane mailing list argument, was DKIM Japan has been set up

[Stephen Farrell]

Let's not do this on this list.

On 24/11/10 15:42, John R. Levine wrote:
 This really does need to be a FAQ.
 
 DKIM works just dandy, when lists sign their mail like this one does.
 
 Unless the intermediary co-operates by re-signing, mailing lists can break 
 DKIM signatures.
 
 Quite true.  But broken signatures are only a problem in a mutant version 
 of DKIM unlike the one specified in RFC 4871, so it's not a problem.
 
 but you do lose the ability to assign signer domain based reputation 
 to the message.
 
 Unless, of course, the list signs like this one does.  I don't see any 
 reason to think it's less likely that lists sign than that list 
 contributors sign.  Do you?  Concrete numbers would help here.
 
 Anecdotes: all the Yahoogroups lists sign.  All of my lists sign.
 
 Regards,
 John Levine, jo...@iecc.com, Primary Perpetrator of The Internet for 
 Dummies,
 Please consider the environment before reading this e-mail. http://jl.ly
 ___
 NOTE WELL: This list operates according to 
 http://mipassoc.org/dkim/ietf-list-rules.html
 
___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

Re: [ietf-dkim] ADSP and SPF

[Stephen Farrell]

On 24/11/10 16:02, Alessandro Vesely wrote:
 +1.  For different reasons, both ADSP and SPF seem to need a revision.
  Is there an opportunity to be taken here?

Not in this WG with this charter.

Let's get done with out work items.

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

Re: [ietf-dkim] Last call comment: Changing the g= definition

[Stephen Farrell]

On 15/10/10 18:32, Barry Leiba wrote:
 I'd like to ask a procedural question of the chairs: Dave killfile's
 many participants, therefore any consensus he sees will merely reflect
 the echo chamber of his own making.

 So I strongly object on procedural grounds for authors who kill file
 people in general, and for those asking for consensus in particular.
 
 Mike, you needn't object unless the chairs put people in our
 kill-files, and I can assure you that we don't.  There's nothing that
 requires any participant to read the posts by any other participant --
 although as a chair, I'd rather the editors did read all posts related
 to their documents -- but it's up to the chairs to evaluate consensus.

Right. (Though having so much mail is almost as effective as a
killfile;-)

In this case, I don't recollect an objection, so thus far, it seems
to me that Dave's correct on this one. I think its perfectly fine
for an editor to try to close off things that seem to have a clear
consensus like this.

 Therefore, the consensus that goes into the document will reflect what
 the chairs see.

Indeed,
S.

 
 Barry, as chair
 ___
 NOTE WELL: This list operates according to 
 http://mipassoc.org/dkim/ietf-list-rules.html
 
___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

Re: [ietf-dkim] Last call comment: Changing the g= definition

[Stephen Farrell]

On 15/10/10 19:48, Michael Thomas wrote:
 On 10/15/2010 10:45 AM, Stephen Farrell wrote:
 In this case, I don't recollect an objection, so thus far, it seems
 to me that Dave's correct on this one. I think its perfectly fine
 for an editor to try to close off things that seem to have a clear
 consensus like this.
 
 Stephen -- the issue here is the procedural one that Dave ignores
 *any* input *at all* from people he filters. It doesn't matter
 whether it's a typo -- ignored. This has been true of every document
 in this working group that he has edited. In the case of 4871-bis
 that means that I can have *no* input whatsoever, even though 

I guess all I can say is that amongst this group, there are
lots of people who argue a lot, and yes, there are patterns
to that, but nothing that in my opinion, based on list traffic
and DKIM meetings etc. amounts to the kind of problem you
mention above.

More generally, and not really addressed to you Mike, but since
this is that kind of message: I think it'd also be good if
people could bear in mind that we're not saving or endangering
the planet here - we're moving an RFC along the standards track
by making very very minor changes and clarifications in a
quite controlled fashion. (Most of which will be ignored by
many coders;-) Some of the recent discussion seems, to me,
quite overblown, (the volume of discussion absolutely
definitely is), given the issues that are actually at stake.

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

Re: [ietf-dkim] I-D Action:draft-ietf-dkim-implementation-report-03.txt

[Stephen Farrell]

On 11/10/10 22:35, Murray S. Kucherawy wrote:
   The same question on Working Group Last Call applies here as well.

 Abort, retry or ignore?  :-)
 
 I guess it's up to the chairs.  It hadn't occurred to me that this could 
 upset a WGLC.

At this point I'd say that the changes are (I hope) minor enough and
there are enough diff tools out there that folks commenting can take
their pick and I'd ask the editors to handle that if the versions
differ. So long as people are specific about the version they're
commenting on it should be ok.

If a problem arises, we'll deal with it, but let's try stick to the
current WGLC date.

If however, a bunch of folks find the above plan problematic, then
speak up and we'll add an extra week and base on the latest versions.

Probably best not to produce any other revisions just now as well:-)

Cheers,
Stephen.

PS: Let's do this for both updated I-Ds.
___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

Re: [ietf-dkim] THIS IS A MULTIPLE 5322.FROM MESSAGE

[Stephen Farrell]

On 05/10/10 23:54, Julian Mehnle wrote:
 Recommending that one more From be added to h= (and hashed) 
 than From headers are initially placed in the message should be enough.  
 There is no need to change the semantics of the spec.

Assuming that recommending above maps to a (putative)
MUST/SHOULD statement in 4871bis, I'd be interested in
opinions as to whether such a change might slow progress
to draft standard, or be detrimental to current deployments.

One could argue that this'd be a material change to the
protocol that is not a deletion, and hence that deployed
code would have to change to comply, which, to me, goes
against at least the spirit of the PS-DS transition.
(Which is the point of the current exercise.)

So in terms of meeting our chartered goals, this specific
addition might have undesirable side effects were it to
represent the WG's opinion. (Much as the chairs love you
all, starting right in on a 4871ter is not attractive:-)

Stephen.

PS: Note that I'm saying nothing about whether or not this
issue should be mentioned in 4871bis.
___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

Re: [ietf-dkim] Comments on draft-ietf-dkim-implementation-report-01

[Stephen Farrell]

On 01/10/10 18:28, Dave CROCKER wrote:
 
 
 On 10/1/2010 10:15 AM, Murray S. Kucherawy wrote:
 The spec simply states that DKIM doesn't require any binding at all.  
 (Section 1.1)
 
 
 It occurs to me that this language permits a misinterpretation and that 
 stronger 
 and more direct language would be appropriate.
 
 By saying is not required to match, the current spec leaves open the 
 possibility that the presence of a match might be taken to be meaningful by 
 DKIM.
 
 However the reality is that DKIM is literally blind to the relationship 
 between 
 a d= domain and a domain name in any other field.
 
 I think the text should therefore be revised from:
 
 1.1.  Signing Identity
 ...
   INFORMATIVE RATIONALE: The signing identity specified by a DKIM
   signature is not required to match an address in any particular
   header field because of the broad methods of interpretation by
   recipient mail systems, including MUAs.
 
 (hmm.  the use of the term 'address' is probably also inappropriate since it 
 means email address in the email world, rather than domain name address.)
 
 
 
 to be:
 
 1.1.  Signing Identity
 ...
   The signing identity specified by a DKIM signature is entirely 
 independent 
 of the identities present in any particular header field. The interpretation 
 of

s/identities/identifiers/ above?

S.

 a match that is possible between the signing identity and the identifier in 
 another field is outside the scope of DKIM.
 
 
 (I've removed the Informative Rationale label because the proposed text 
 really 
 moves into explanation of the protocol, rather than explanation of its 
 motivation or the like.)
 
 d/
 
 ps. just so no one is confused:  this does not change the protocol at all; it 
 merely clarifies a point that is often misunderstood.
___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

Re: [ietf-dkim] Comments on draft-ietf-dkim-implementation-report-01

[Stephen Farrell]

On 02/10/10 16:22, Dave CROCKER wrote:
 
 On 10/2/2010 5:58 AM, Stephen Farrell wrote:
 On 01/10/10 18:28, Dave CROCKER wrote:
 I think the text should therefore be revised from:

 1.1.  Signing Identity
 ...
INFORMATIVE RATIONALE: The signing identity specified by a DKIM
signature is not required to match an address in any particular
header field because of the broad methods of interpretation by
recipient mail systems, including MUAs.
 ...
 to be:

 1.1.  Signing Identity
 ...
The signing identity specified by a DKIM signature is entirely
 independent
 of the identities present in any particular header field. The
 interpretation of

 s/identities/identifiers/ above?
 
 
 Well, I did have a similar thought, when writing the proposed change,
 but that's a more substantial change, since it moves from saying
 entity to saying reference to the entity.
 
 The usage later in the sentence needs to match earlier in the sentence
 where it says signing identity, which is the term being defined in
 that subsection.
 
 How about:
 
 1.1.  Signing Identity
 ...
The signing identity specified by a DKIM signature is entirely
 independent of the identities referenced in any particular header field.
 The interpretation of...

Yeah, its a minor point and you're right that smaller changes
are better so that's fine by me.

I guess from a purist p-o-v, I think we could argue that only
identifiers appear directly in protocols, and never identities,
but since there's no need to go there, let's not:-)

Cheers,
S.

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

Re: [ietf-dkim] Authorizing List Domains

[Stephen Farrell]

On 28/09/10 23:02, Douglas Otis wrote:
   On 9/27/10 9:47 PM, Murray S. Kucherawy wrote:
 On Monday, September 27, 2010 4:19 PM, Douglas Otis wrote:
 
 TPA-Label involves ADSP being discussed on the dkim list.

I've no idea precisely what Doug means here, but to avoid
doubt: the DKIM WG has a charter that does not currently
include work on TPA nor other possible alternatives, nor
any other tweak or alternative to ADSP.

There does seem to be interest (though nothing like
consensus) in these however so we're not trying to stop
discussion for now, in the hope that one or other garners
sufficient consensus that we might re-charter. (And in
any case, its clear that asking people on this list to
stop typing is currently pointless;-)

So these are all unofficial activities in the sense
that there is no plan for the WG to produce any RFCs.

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

Re: [ietf-dkim] DKIM+ADSP = FAIL, and it's our fault

[Stephen Farrell]

I totally agree that this pointless repetition is...pointless.

Barry and I have asked folks to stop that kind of thing a number
of times with no real success. (As demonstrated by the last
few days messages.)

Perhaps this time people will be more responsible, we'll see.

I also think that the fewer people that take the bait, the
quicker these threads peter out. So each person who decides
not to hit send quite so readily is helping.

Stephen.

On 14/09/10 20:35, J.D. Falk wrote:
 ...but not for the reasons the anti-ADSP folks keep bringing up.
 
 DKIM is failing because every discussion about actually /using/ DKIM 
 inevitably gets stuck in the same old argument about ADSP.  Doesn't even 
 matter what the argument is about anymore; it stops all forward progress 
 every time.  And we keep letting it happen -- actively participating, even, 
 including me.
 
 Continuing to argue these same points over and over is disrespectful of our 
 colleagues both on and off this list, and of the IETF process.
 
 So I'm going to stop, and I beg you all to join me.
 
 Stop arguing, and start writing drafts.  Let us discuss the drafts instead of 
 attacking each others' intractable positions for the Nth time.  If you think 
 ADSP will bring about the end of all human communication, WRITE A DRAFT 
 EXPLAINING WHY.  If you think something else, write that instead.
 
 Yes, I know it requires more effort, but what we've been doing so far clearly 
 isn't working.
 
 
 ___
 NOTE WELL: This list operates according to 
 http://mipassoc.org/dkim/ietf-list-rules.html
 
___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

Re: [ietf-dkim] DKIM+ADSP = FAIL, and it's our fault

[Stephen Farrell]

On 15/09/10 15:43, McDowell, Brett wrote:
 On Sep 15, 2010, at 12:11 AM, Murray S. Kucherawy wrote:
 
 Based on that (rather precise) description, aren't ADSP's requirements a 
 proper subset of the DKIM requirements?  If so, I'm not sure I agree with 
 badly conflicting, but it does frame future discussion quite nicely.

 For example, if DKIM enables the identification of mail streams, isn't the 
 one ADSP covers just a specific instance of a mail stream?

 
 BTW, one thing I think we can agree on and find value from in these 
 pre-deployment email discussions is terminology.  I ran into a problem at the 
 last MAAWG during a panel discussion where my understanding of 3rd-party 
 signature is what someone else meant by 2nd-party signature.  What is the 
 real definitions of 1st-party, 2nd-party and 3rd-party signatures in 
 the context of DKIM and ADSP, i.e. in the context of i= and d= and from: 
 values?

How does that relate to the current WG work items?

If it does, please start a specific thread the editor
can make sense of.

If it doesn't, do you think its really a good idea to
ask folks to get involved in a discussion of definitions
now?

Also, how does it relate to the subject line?

Please don't respond to this on the list unless you have to.

S.


 
 
 
 From: ietf-dkim-boun...@mipassoc.org [ietf-dkim-boun...@mipassoc.org] On 
 Behalf Of Steve Atkins [st...@wordtothewise.com]
 Sent: Tuesday, September 14, 2010 3:01 PM
 To: DKIM List
 Subject: Re: [ietf-dkim] DKIM+ADSP = FAIL, and it's our fault

 The problem is that the two things have badly conflicting requirements. DKIM 
 is based on a domain-based identifier that's independent of the From: 
 domain, and that's where much of it's value comes from. ADSP is based on a 
 domain-based identifier that must remain identical to the From: field at all 
 times, and that's where it's sole value comes from. ADSP intrinsically 
 conflicts with the original design case for DKIM, despite being piggy-backed 
 on to it.

 So any document that puts forth even basic good practices for DKIM usage for 
 monitoring sender reputation (use d= to differentiate mail streams) is going 
 to be anathema to ADSP requirements (d= must be the same as the From: 
 domain).

 And any ADSP-driven set of requirements (mailing lists should not only 
 re-sign any mail they re-send, they should alter the From: address to match) 
 is going to be considered nonsensical by people who consider DKIM a way to 
 tie an identity cookie to a message.

 And, as we've seen, any compromise document is hated by pretty much 
 everyone, even assuming you can get there.

 Cheers,
  Steve

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

Re: [ietf-dkim] marketing dkim

[Stephen Farrell]

On 19/08/10 18:06, Michael Thomas wrote:
 On 08/19/2010 09:20 AM, John Levine wrote:
 Be sure to tell them that ADSP is not useful, according to one of the
 authors of the ADSP RFC.
 
 Chairs --
 
 Can I ask for a revision of ADSP where John is stripped out of the document?

You can ask. The answer is that we don't currently have
a revision of ASDP on our charter and RFCs do not change.

 It's ridiculous that he presumes to speak for it, 

John was an editor of ADSP, which is a WG product. I think its a fine
thing to do editing work even if you don't agree with the content.
I personally wouldn't then deride the WG output, but the RFC is what
gets read, so I treat remarks like John's as the background noise that
they are, but I do understand why some WG participants find it annoying.

 and it was a huge mistake
 to give him this undue credibility. Especially when he has none.

That last is out of order on a list such as this. Please desist.

And everyone else: please don't take up this thread. Let's get the work
we have on our plate done and not get sidetracked again. Generic praise
or criticism of ADSP is currently out of scope.

Stephen. (As chair)
___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

Re: [ietf-dkim] marketing dkim

[Stephen Farrell]

Folks,

Please. Let's get back to the work at hand and not
spend time on this,

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

Re: [ietf-dkim] Straw poll results

[Stephen Farrell]

Hi John,

I think I generally agree with the overall conclusion that expecting
signatures to verify after list processing isn't worth the effort,
but I'm not sure your logic below is sound...

On 09/08/10 18:45, John Levine wrote:
 In article 548b10a3a5fcf3025a4b5...@lewes.staff.uscs.susx.ac.uk you write:
 However, if there's a need to trust the original sender, and you don't 
 quite trust the list to get that right for you, ...
 
 It appears that we can discard this concern as counterfactual.  I
 asked how people sort their list mail, and here's what I found:
 
   From: address   0.5  (Steve said he sorts on both from and list)
 
   List ID or similar: 8.5
 
   To: or Cc:. 3 (approximation to sorting by list name)
 
   rcpt-to address:1 (unique address per list, I gather)
 
 The overwhelming majority sort list mail by the identity of the list,
 not by anything else.  The one person who sometimes sorts by From:
 said that verifying the address wasn't an issue.
 
 Unless people can offer real life examples of situations where they
 remotely verify the identity of list contributors beyond using the
 name or address on the From: line, I hope we can put this meme of
 preserving incoming DKIM signatures to bed permanently.

You're assuming that how end-users sort list messages is the same
as how DKIM verifiers might operate on list messages. Is that a
good assumption? Or do you mean something else when you say
sort?

(Just asking, and not as chair or anything:-)

S.

 
 I realize there's all sorts of hypothetical situations one might
 imagine, but since we have over three decades of actual list practice,
 it seems unlikly that any important model of list usage isn't already
 in use somewhere now.
 
 R's,
 John
 
 ___
 NOTE WELL: This list operates according to 
 http://mipassoc.org/dkim/ietf-list-rules.html
 
___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

Re: [ietf-dkim] Straw poll results

[Stephen Farrell]

Folks. I suspect we're not longer involved
in a straw poll of any kind in this thread.

If there are points arising, please start
new threads.

Otherwise, it'd be great if folks could spend
their time commenting on Murray's draft, as
some have already done.

Thanks,
Stephen.
___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

[ietf-dkim] Chair affiliation

[Stephen Farrell]

Hi,

There was a discussion on the IETF wg chairs list last year
that concluded it'd be good for chairs to be transparent
about their affiliation.

So: Until recently (April) I was working 50:50 for Trinity
College Dublin (TCD) and NewBay Software. Since then I've got
some more research money and so I've quit NewBay and am
now working 80% of my time in TCD. I'll be spending the other
20% doing fun start-up type stuff with Tolerant Networks
Ltd. [1]

Stephen.

[1] http://www.tolerantnetworks.com/
___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

[ietf-dkim] Maastricht meeting

[Stephen Farrell]

Folks,

I guess we do have work to do in Maastricht so Barry and I
will request a meeting slot unless we hear that lots of
people we'd want there will be missing. (Last time I
asked I only got a very few folks who said they'd be there.
If you will be there, I'd be interested in knowing that
off list, just to get a sense for who'll be about.)

I'll send a mail asking for agenda slot requests later on.

Stephen.

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

Re: [ietf-dkim] Charter update

[Stephen Farrell]

On 05/21/2010 03:45 PM, Dave CROCKER wrote:
 
 
 On 5/20/2010 3:36 AM, Stephen Farrell wrote:
 Separately, some IESG folks have asked whether we really have
 the cycles available for some of our new charter items, in
 particular:
 
 I don't understand their concern.
 
 What do they mean and what is the basis for their concern?

I really can't think of more than one reason for asking, which
is the totally obvious one: is there enough interest to do the
work planned.

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

Re: [ietf-dkim] Charter update

[Stephen Farrell]

On 05/19/2010 11:25 PM, Murray S. Kucherawy wrote:
 Attending a Maastricht meeting is highly likely for me, but Beijing is less 
 certain.

You may not be alone there.

 Could we plan a regular meeting in Maastricht?  Seems appropriate given the 
 big interest in a DKIM And MLMs document.

Sure. Assuming there's sufficient interest. Please let Barry and I
know (or the list, whatever) what you think is better.

Separately, some IESG folks have asked whether we really have
the cycles available for some of our new charter items, in
particular:

- Dec  2010 - WG last call on an I-D detailing deployment and
effectiveness data for DKIM base
- Dec  2010 - WG last call on an I-D detailing deployment and
effectiveness data for ADSP
- Mar  2011 - Update overview and deployment informational RFCs as
appropriate, and/or produce one or more new informational RFCs from
information obtained above

So, if you're interested and have time to do good reviews or
help with editing please do let Barry and I know in the next day
or two and we'll summarise back to the list.

Thanks,
Stephen.
___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

Re: [ietf-dkim] Lists BCP draft available

[Stephen Farrell]

That doesn't seem to be about mailing lists.

I don't see that we're re-opening ADSP now and we're not
chartered for that, so I don't really see much point in
this discussion.

So perhaps take that discussion offlist?

Stephen.

On 05/19/2010 01:18 AM, Michael Deutschmann wrote:
 On Tue, 18 May 2010, Douglas Otis wrote:
 Why would you see rejectable as being different from all assertions?
 
 Just about everyone thinks EITHER that rejectable would be redundant
 with all, OR ...
___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

Re: [ietf-dkim] Lists BCP draft available

[Stephen Farrell]

On 05/11/2010 06:10 PM, Murray S. Kucherawy wrote:

 From what I see on the list, there is clear consensus that this
 document should be produced as a WG document (which I support as well).
 So can we consider that question closed?
 
 That's up to the chairs, but I suspect we have enough agreement to move 
 forward.  

Agreed.

 There is the incomplete matter of re-chartering though.

Right. Doing that now.

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

[ietf-dkim] Charter update

[Stephen Farrell]

Hi all,

The attached is the updated charter Barry and I
will send to Sean on Monday. The text is the same
as last time we sent this to the list, we just
modified the milestones a bit to reflect what
we think is doable starting from now.

This charter and milestones imply that we should
probably request a short session at the next IETF
in Maastricht, and that we'll want a longer session
in Beijing in November. If you've opinions or
issues with those face-to-face sessions, please
let us know.

Regards,
Stephen  Barry.




Draft charter update - 2010-05-12

--
Domain Keys Identified Mail (dkim)
--

Description of Working Group:

+++ Background +++
Internet mail protocols do not certify the validity of any
identification information associated with a message, including
the author's name and address.  This limits the ability to
determine legitimate accountability for a message.  It also limits
the ability to determine unauthorized uses of these identifiers.

The DKIM working group has produced two standards-track
specifications.  The first allows a domain to take responsibility,
using digital signatures, for having taken part in the
transmission of an email message.  The second allows a domain to
publish information about its practices in applying those
signatures. Taken together, these allow receiving domains to
ascertain responsibility for a message, and possibly to detect
some unauthorized assertions of authorship.

While the techniques specified by the DKIM working group will not
prevent fraud or spam, they can assist in efforts to establish a
basis for identifying actors that can be trusted. The
standards-track specifications do not mandate any particular
action by the receiving domain when a signature fails to validate.
That said, with the understanding that guidance is necessary for
implementers, the DKIM documents discuss a reasonable set of
possible actions and strategies, and analyze their likely effects
on attacks and on normal email delivery.

+++ Previous Work +++
The previously chartered deliverables for the DKIM working group
have been completed.  To provide background, we list them here:

* An informational RFC presenting a detailed threat analysis of,
and security requirements for, DKIM. (RFC 4686)

* A standards-track specification for DKIM signature and
verification. (RFC 4871, updated by RFC 5672)

* A standards-track specification for DKIM policy handling.
(RFC 5617)

* An informational RFC providing an overview of DKIM and how it
can fit into overall messaging systems, how it relates to other
IETF message signature technologies, implementation and
migration considerations, and outlining potential DKIM
applications and future extensions. (RFC 5585 and
draft-ietf-dkim-deployment, in its final stages)

(One previously chartered deliverable, a standards-track
specification for DKIM DNS Resource Record(s), was dropped by
agreement between the working group and the Area Directors.)

+++ New Work +++
The working group is now ready to switch its focus to refining and
advancing the DKIM protocols.  The current deliverables for the
DKIM working group are these:

1. Advance the base DKIM protocol (RFC 4871) to Draft Standard.
This is the first priority for the working group.

2. Collect data on the deployment, interoperability, and
effectiveness of the base DKIM protocol, with consideration
toward updating the working group's informational documents.

3. Collect data on the deployment, interoperability, and
effectiveness of the Author Domain Signing Practices protocol
(RFC 5617), and determine if/when it's ready to advance on the
standards track. Update it at Proposed Standard, advance it to
Draft Standard, deprecate it, or determine another disposition,
as appropriate.

4. Taking into account the data collected in (2) and (3), update
the overview and deployment/operations documents.  These are
considered living documents, and should be updated periodically,
as we have more real-world experience.

5. Consider issues related to mailing lists, beyond what is
already documented.  This includes considerations for mailing
list software that supports or intends to support DKIM, as well
as considerations for DKIM/ADSP deployment in the presence of
mailing lists that do not have such support.  Include
recommendations in the informational documents, or produce a
new informational document about mailing-list considerations.

+++ What's Out Of Scope +++
As before, several related topics remain out of scope for the DKIM
working group. These topics include:

* Reputation and accreditation systems. While we expect these to
add value to what is defined by the DKIM working group, their
development will be separate, and is out of scope for the DKIM
working group.

* Message content encryption.

* Additional key management protocols or infrastructure.

* Signatures that are intended to make long-term assertions beyond
the expected transit time of a 

[ietf-dkim] Recent discussions

[Stephen Farrell]

Just a question/comment about these recent discussions.

Is there anything here that's not already noted in our
draft charter update that might be actionable and could
garner WG consensus?

I didn't see anything myself, but then there's been a
lot of mail so I may have missed something. If I've got
that wrong then please reply to this with your proposed
delta to the charter text Barry circulated earlier. (BTW,
I'll send that back to the list for a quick check in a
day or so before I forward it to Sean.)

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

Re: [ietf-dkim] DKIM errata 1532 (v= and DomainKeys)

[Stephen Farrell]

On 03/11/2010 10:50 AM, pasi.ero...@nokia.com wrote:
 Just two unprocessed errata left! Tackling the easier one first:
 
 http://www.rfc-editor.org/errata_search.php?eid=1532
 
 Appendix A of draft-ietf-dkim-deployment has detailed text about 
 this topic (differences in DNS key records between DomainKeys and DKIM), 
 so I'm not sure if RFC 4871 really needs this information.
 
 How about rejecting this errata (with a pointer to Appendix A 
 of draft-ietf-dkim-deployment in the Notes field)?

Works for me. Absent objections in the next week, let's
go for that.

Stephen.

 
 Best regards,
 Pasi
 
 
 ___
 NOTE WELL: This list operates according to 
 http://mipassoc.org/dkim/ietf-list-rules.html
 
___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

Re: [ietf-dkim] An alternative way forward for dkim-deployment...

[Stephen Farrell]

Thanks Pasi,

FWIW, I think Pasi's suggestion moves us forward nicely so
I'd be happy to see us agree to do that.

Stephen.

On 03/11/2010 10:30 AM, pasi.ero...@nokia.com wrote:
 I'm getting the impression that this debate is starting to be about
 proving points rather than making progress. In the interest of getting 
 this document moving forward, I have entered the following RFC editor note:
 
Please add a new paragraph to Section 1, after the first paragraph:
 
The reader is encouraged to read the DKIM Service Overview document
[RFC5585] before this document. More detailed guidance about DKIM
and ADSP can also be found in the protocol specifications [RFC4871],
[RFC5617], and [RFC5672].
 
 Authors and Barry: if you think this is unacceptable, please yell ASAP
 and propose better text.
 
 Tim: unless you feel that the scope of this document is dangerously
 unclear even with this addition, please clear.
 
 Best regards,
 Pasi
 
 -Original Message-
 From: ext Dave CROCKER [mailto:d...@dcrocker.net]
 Sent: 11 March, 2010 01:59
 To: Polk, William T.
 Cc: DKIM IETF WG; Eronen Pasi (Nokia-NRC/Helsinki); IESG; draft-ietf-
 dkim-deploym...@tools.ietf.org; dkim-cha...@tools.ietf.org; Sean Turner
 Subject: Re: An alternative way forward for dkim-deployment...

 Tim,

 On 3/10/2010 3:18 PM, Polk, William T. wrote:
 Dave,

 First, I do think it is harmful when document content does not match
 the
 (explicit or implied) scope.

 And since I quoted text that made clear that the scope was constrained,
 what is
 the problem?

 Again the question:  just how much bullet-proofing against careless
 reading is
 required?


I certainly had different expectations
 based on the title and introductory material. In retrospect, I should
 have brought my discuss up another level of abstraction but I
 apparently
 got focused on the details (what was missing) instead of why it
 mattered.

 And yet even your original and later notes detail lacked detail, since
 there was
 no way of knowing exactly what problem you were trying to address /or/
 what
 would satisfy and you did not provide clarification.


 Personally, I would prefer to see this document expanded and either
 address the various topics that are covered elsewhere or explicitly
 reference the various bits of the DKIM overview and protocol specs
 where
 the rest of this information resides.

 Since the document is loaded with citations, including the other DKIM
 documents,
 once again I have no idea what you mean.


 Is there a chance that I am carrying my concern for the reader too
 far?

 Not only too far.  As two of my earlier responses suggested,
 implementing
 additional text in line in response to the concern you initially stated
 a likely
 downside, given the intended audience.  It would have been helpful for
 you to
 address that point, over the last 5 weeks.


 Perhaps... If you assume that the reader has already consumed the
 protocol specs, then I am way off base. It certainly is not
 surprising
 that the wg members weren't confused. I just don't make that
 assumption.

 Again, the text I quoted you earlier today is rather pointed in
 declaring the
 role of this document as being to augment, rather than replace, other
 documents.


 My concern for the reader is based on my perspective at NIST.
 Deployment
 guidance is actually something we do here, and sometimes we may even
 do
 it well.

 The IETF has some history here, too.  RFCs with the word deployment
 in them
 date back to 1992.  Interestingly, the first was about X.500 and X.400.

 In any event, your statement here suggests that you are relying on the
 NIST
 culture for your concern, rather than the IETF culture.


   However, they might use google to search on dkim and deployment
 and try to use this document.

 People might choose to do an infinite number of unreasonable things.
 Taking a
 document out of context is only one of them.  We cannot protect against
 every
 unreasonable action by a reader.

 And, again, the document states its nature and goals explicitly.


 I don't like holding this document up, especially when there are a
 variety of simple solutions.

 To say solution is to take as a given that there is a problem.  You
 have not
 responded to the responses that critique that assumption.


It
 is clear this document will not evolve into some sort of standalone,
 complete instructional missive so let's be clear about the document
 scope, and move on.

 The document /is/ already clear Tim, per the text that I quoted.  It
 merely
 needs the reader to be paying attention.

 d/
 --

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

[ietf-dkim] HOWTO discuss things on this list...

[Stephen Farrell]

DKIM colleagues,

You all know that the DKIM discussions have sometimes been
contentious, and some participants have gotten hot under the collar.
We note that that's been particularly true recently, and we'd like
everyone to take a step back and remind themselves of a few things:

1. The purpose of this forum is for people to get together and discuss
the development of standards, with the aim of forming consensus.  That
doesn't mean that everyone will agree on everything, and consensus may
be with you on some points, and against you on others.

2. It helps neither the formation of consensus nor our individual
reputations to be impolite, abrasive, sarcastic, derisive, belittling,
or otherwise snarky.  We all try to be somewhat tolerant of the
occasional bit of snark, but it should be rare -- the group should not
be expected to accept it as normal discourse.

3. We make progress when arguments give technical points for or
against an issue.  We don't make progress by exaggerating,
oversimplifying, or otherwise mischaracterizing others' positions, by
name-calling, by Is not!/Is so! bickering, and so on.  Messages
that are essentially content-free apart from saying, You're wrong,
are not useful.  Messages that say, You don't know what you're
talking about, or the like, cross the line of acceptability.

Please keep these points in mind when you participate in this -- and
in any other IETF -- working group.  Every time you post, ask yourself
what your post does to further the discussion.  And look at what
you're saying, and ask yourself whether you'd be annoyed if someone
said that about you.  Make sure your messages are polite, respectful,
and useful, even if you feel angry or upset.

A word on the mischaracterization:  If you attribute a point of view
to someone else, make sure what you say is an accurate rendering of
his position, erring on the side of caution.  It's always OK to ask,
I understand you to be advocating [X].  Is that correct?  We need to
understand each other's positions clearly.

As an example, it's fair to say, John says that we should not publish
signing policies at all.  I think he's wrong because [of these clear
arguments].  John has made his position on that clear, and it can be
addressed directly.  It's not fair to say, for example, John would
allow the phishers to rob us blind because he won't let us protect
ourselves.  That's the sort of thing we mean by mischaracterizing.

It's important, as we move the working group into its next phase,
whatever we decide that phase to be, that we all keep the discussion
reasonable.  We will not be as tolerant of impoliteness as we have
been.  Everyone should be aware that from this point on, unnecessarily
abrasive posts, things that violate respectful discourse, will be
subject to administrative action.  That may include suspension of the
right to post to this mailing list.

Everyone here has given useful input to this working group.  We would
like to see everyone continue to.  Thanks for your contributions, and
for your cooperation.

Stephen and Barry, as chairs
---
___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

Re: [ietf-dkim] Is anyone using ADSP? - bit more data from the receiving side

[Stephen Farrell]

Hi Hector,

We need to keep the tone here under control and in particular
the text below is inappropriate. Please desist from making
assertions like this on this list.

hector wrote:
 Well, maybe if the WG can get a true champion of POLICY and not one 
 that selfishly took over SSP with the sole clever confessing purpose 
 of creating a non-working protocol poison pill, then could change.
...
 Your input is extremely bias and a conflict of interest to the WG 
 participants who have interest in seeing a POLICY system work.

And just to be clear, your blaming us as you say below, is not
a problem for me.

 But you know, I don't blame you. I blame the CHAIRS for allowing this 
 to occur. It is surreal!

If you feel the need to discuss this further please do that
off-list with Barry  I.

Stephen.


 
 Is that crazy or what?
 
 This tells me that I'm not the only one who 
 thinks that there isn't a business case for ADSP.
 
 
 Thats crazy!
 
 --
 
 ___
 NOTE WELL: This list operates according to 
 http://mipassoc.org/dkim/ietf-list-rules.html
 
___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

Re: [ietf-dkim] DKIM charter update proposal

[Stephen Farrell]

Scott Kitterman wrote:
 If advancing DKIM/ADSP along the standards heirarchy is all that's on the 
 table, I think it should wait.  
 
 Effective rollout of DKIM in large hetrgenous organizations is complex and 
 takes time.  I think it's better to pause for a while and give broad 
 operational experience more of a chance to exercise what has just been 
 standardized.

When we last discussed this, and certainly at the Stockholm meeting,
there did seem to be consensus for moving 4871 along to DS. If other
folks want to wait they should speak up, but for now, I think we do
have WG consensus to do that.

Stephen.


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

[ietf-dkim] gathering data (was: Re: DKIM charter update proposal)

[Stephen Farrell]

Franck,

Franck Martin wrote:
 Seems to me something is missing: gather data to establish if DKIM 
 specifications have in any way alleviated any misuse of the email system, in 
 particular but not limited to spam, phishing attacks and fraud.
 

If you want to propose some specific work items for the WG
then please do so as proposed charter text.

However, I've not really seen much interest or energy for
such work so if you're suggesting something, would it be
safe to assume you're willing to work on it yourself? In
that case, submitting a draft-martin-dkim-foo I-D would
be a good place to start so's we'd have an idea of what
kind of gathering you envisage.

Stephen.


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

Re: [ietf-dkim] DKIM charter update proposal

[Stephen Farrell]

Thanks Dave,

Let's give it a day or two more to see if anyone else has
suggested changes then Barry  I will think about folding
in your suggestions.

Cheers,
S.

Dave CROCKER wrote:
 
 Barry Leiba wrote:
 Description of Working Group:

   The Internet mail protocols and infrastructure allow mail sent
   from one domain to purport to be from another. While there are
   sometimes legitimate reasons for doing this, it has become a
   source of general confusion, as well as a mechanism for fraud and
   for distribution of spam (when done illegitimately, it's called
   spoofing). The DKIM working group has produced standards-track
   specifications that allow a domain to take responsibility, using
   digital signatures, for having taken part in the transmission of
   an email message and to publish policy information about how it
   applies those signatures. Taken together, these will assist
   receiving domains in detecting (or ruling out) certain forms of
   spoofing as it pertains to the signing domain.
 
 I suggest replacing the last sentence with something more generic, to avoid 
 the 
 debate about how much any of this pertains to spoofing, per se.  Perhaps 
 instead 
 have a value proposition statement derived from the one in the Overview 
 abstract:
 
 These mechanisms permit email receivers to make additional assessments 
 about 
 messages.
 
 
   While the techniques specified by the DKIM working group will not
   prevent fraud or spam, they will provide a tool for defense
   against them by assisting receiving domains in detecting some
   spoofing of known domains. The standards-track specifications do
   not mandate any particular action by the receiving domain when a
   signature fails to validate. That said, with the understanding
   that guidance is necessary for implementers, the DKIM documents
   discuss a reasonable set of possible actions and strategies, and
   analyze their likely effects on attacks and on normal email
   delivery.
 
 Delete the first sentence, per my concern above.  At the least, the sentence 
 appears to be largely redundant with the preceding paragraph's last sentence.
 
 Isn't the second sentence incorrect?  Doesn't DKIM mandate treated a failed 
 validation the same as no signature present?
 
   The previously chartered deliverables for the DKIM working group
   have been completed:

   * An informational RFC presenting a detailed threat analysis of,
 and security requirements for, DKIM. (RFC 4686)

   * A standards-track specification for DKIM signature and
 verification. (RFC 4871, updated by RFC 5672)

   * A standards-track specification for DKIM policy handling.
 (RFC 5617)

   * An informational RFC providing an overview of DKIM and how it
 can fit into overall messaging systems, how it relates to other
 IETF message signature technologies, implementation and
 migration considerations, and outlining potential DKIM
 applications and future extensions. (RFC 5585 and
 draft-ietf-dkim-deployment, in its final stages)

   (One previously chartered deliverable, a standards-track
   specification for DKIM DNS Resource Record(s), was dropped by
   agreement between the working group and the Area Directors.)
 
 Do re-charters usually contain all this history?
 
 
   The working group is now ready to switch its focus to refining and
   advancing the DKIM protocols.  The current deliverables for the
   DKIM working group are these:

   * Advance the base DKIM protocol (RFC 4871) to Draft Standard.

   * Collect data on the deployment and interoperability of the
 Author Domain Signing Practices protocol (RFC 5617), and
 determine if/when it's ready to advance on the standards track.
 Update it at Proposed Standard or advance it to Draft Standard,
 as appropriate.

   As before, several related topics remain out of scope for the DKIM
   working group. These topics include:

   * Reputation and accreditation systems. While we expect these to
 add value to what is defined by the DKIM working group, their
 development will be separate, and is out of scope for the DKIM
 working group.

   * Message content encryption.

   * Additional key management protocols or infrastructure.

   * Signatures that are intended to make long-term assertions beyond
 the expected transit time of a message from originator to
 recipient, which is normally only a matter of a few days at
 most.

   * Signatures that attempt to make strong assertions about the
 identity of the message author, and details of user-level
 signing of messages (as distinguished from domain-level keys
 that are restricted to specific users).

   * Duplication of prior work in signed email, including S/MIME and
 OpenPGP.
 

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

Re: [ietf-dkim] DKIM charter update proposal

[Stephen Farrell]

Folks,

To make life a little easier for us all, (well, mainly Barry
and I:-), could you please keep this thread to discussion of
the proposed charter update.

And where you've thoughts on that, specific alternate
text would be appreciated.

Thanks,
Stephen.

PS: I see John L. has done the right thing and changed
the subject line, maybe reply to that if that's what you
want to chat about.


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

Re: [ietf-dkim] gathering data

[Stephen Farrell]

Franck Martin wrote:
 Huh?
 
 My point was to simply ask does dkim help (directly or indirectly) to solve 
 any problem related to SPAM? Where is the pudding and where is the proof?

A fine question, but the thread Barry started is discussing the proposed
WG charter modification, so for now, I'm just trying to understand if
you're proposing something for that, (and if so, if you're volunteering
to do work:-)

If your question is unrelated to the charter discussion, that's fine
too.

Cheers,
S.

 
 - Original Message -
 From: Stephen Farrell stephen.farr...@cs.tcd.ie
 To: Franck Martin fra...@genius.com
 Cc: barryle...@computer.org, IETF DKIM WG ietf-dkim@mipassoc.org
 Sent: Monday, 5 October, 2009 9:36:38 PM GMT +12:00 Fiji
 Subject: gathering data (was: Re: [ietf-dkim] DKIM charter update proposal)
 
 
 Franck,
 
 Franck Martin wrote:
 Seems to me something is missing: gather data to establish if DKIM 
 specifications have in any way alleviated any misuse of the email system, in 
 particular but not limited to spam, phishing attacks and fraud.

 
 If you want to propose some specific work items for the WG
 then please do so as proposed charter text.
 
 However, I've not really seen much interest or energy for
 such work so if you're suggesting something, would it be
 safe to assume you're willing to work on it yourself? In
 that case, submitting a draft-martin-dkim-foo I-D would
 be a good place to start so's we'd have an idea of what
 kind of gathering you envisage.
 
 Stephen.
 
 
 

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

Re: [ietf-dkim] RFC4871bis - whether to drop -- k: Key type

[Stephen Farrell]

Dave CROCKER wrote:
 
 Barry Leiba wrote:
 1. Crypto suite X had been seriously cracked, such that an attacker
 could, at least in some cases, create a valid suite-X signature on his
 
 Is there any experiential basis to motivate our having to worry about this 
 attack vector?  In other words, do we have good reason to believe that this 
 threat vector is significant?

I think this one's a yes - given the developments with hash collisions
in the last few years. While DKIM signatures are much more ephemeral
than other kinds (e.g. signatures on certificates) I think we should
still be concerned about this. There's also a non-security reason here,
the NIST recommendations and hash competition (that various folks will
follow) do mean that we are very likely to want to migrate from
rsa-sha256 to rsa-sha3 (or maybe something ECC based) within the next
few years. So we should try to make that transition easy (or at
least not make it hard).

 Is there a history of worrying about this attack vector, among other efforts 
 to 
 do standards work with similar technology?  In other words, are we the only 
 ones 
 worrying about it, or is this a common concern amongst experts?

Yes. TLS authenticates the ciphersuite negotiation via the final
handshake message. Less convincingly, there was a huge effort to
get negotiation right for GSSAPI with SPNEGO and S/MIME has
its capabilities stuff. Bidding down attacks are things that
folks do want to prevent or detect.

 Is the mechanism for protecting against this attack vector in DKIM anything 
 like the mechanisms used in those other, similar technologies?  In other 
 words, 
 if other experts have worked on this, have they solved in a similar way?

Sort-of. I think DKIM differs in this in that our default
key management is less secure, but were DNSSEC to happen, then I
think that inclusion of the k=  h= fields in key records wouldn't
be that conceptually different from how TLS handles ciphersuite
negotiation.

 If the above 3 questions do not have a clear yes answer, then we ought to 
 treat DKIM's effort on this topic as highly suspect.

I don't think 4871 is highly-suspect in this (or actually any)
respect.

 Anything other than 3 yes' means that we're attempted to solve a problem that 
 other experts do not see as a problem, or that they have not tried to solve 
 before or that they have solved in a different way.  In other words, to some 
 potentially high degree, we are hanging out entirely on our own.
 
 My own sense of security work by a crew of folk that have some security 
 expertise, but is not dominated by it, is that it should aggressively avoid 
 being creative...

Totally agree there.
S.


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

Re: [ietf-dkim] RFC4871bis - whether to drop -- k: Key type

[Stephen Farrell]

Murray S. Kucherawy wrote:
 Here's what I remember from the original discussion of h= and k= in
 the key record.

 First, part of the idea was to have them both there, to make things
 parallel: This key is used for this crypto suite.
 [...]
 
 I'm neutral on either keeping or removing this one.  It seems to me an RSA 
 key is invalid input to any other crypto mechanism, so those functions will 
 do the validation implicitly.

While that is probably true, I'd note that the rsa p= value is
a fairly simple construct (ASN.1 sequence of two integers) and
other algorithms have similar structures (e.g. Dss public key
in RFC 3279 is one integer and DSS-parms is an ASN.1 sequence
of three integers) so I guess I'd be a little concerned that
someone might define another key type (e.g. some ECC variant)
that was also two integers, or that someone's decoding code
might be suspect (e.g. accepting a DSS public key as an
RSA modulus and defaulting the exponent to 65537 or
something).

The putative attack would be to sign with foo-sha256 where
foo is some algorithm that a verifier supports and such
that the foo key encoding could accept an rsa p= value as
input and such that that combination allows the attacker
to forge signatures.

That's fairly theoretical, but there'd be a bit
of work to go check that there is in fact no realistic
situation where such confusion could arise. So on the
whole, for me, keeping the k= just makes it easier
to get things right now and in future.

S. (As participant, of course)

 
 Since h= doesn't have the same benefit, I'd rather keep it.
 
 
 ___
 NOTE WELL: This list operates according to 
 http://mipassoc.org/dkim/ietf-list-rules.html
 
___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

Re: [ietf-dkim] RFC4871bis - whether to drop -- k: Key type

[Stephen Farrell]

Dave CROCKER wrote:
 
 
 Stephen Farrell wrote:
 The putative attack would be to sign with foo-sha256 where foo is some
 algorithm that a verifier supports and such that the foo key encoding
 could
 accept an rsa p= value as input and such that that combination allows the
 attacker to forge signatures.

 That's fairly theoretical, but there'd be a bit of work to go check that
 there is in fact no realistic situation where such confusion could
 arise. So
 on the whole, for me, keeping the k= just makes it easier to get
 things right
 now and in future.
 
 
 If out-of-band algorithm/key-type registration like this is not a
 regular protection mechanism provided in existing, related
 crypto-based schemes:

I think it is common mechanism. Normally its in a certificate for
PKI based applications or as part of negotiation in e.g. TLS etc.
XMLDSIG also includes the same information in its data structures.

  1) Why should it be only in DKIM?

So I don't think that this is the case.

 
  2) Won't it need expert vetting by the security community to
 validate that the threat is real and the protection is sufficient?

Well, 4871 got last called, secdir review etc so it got as much
security review as most things. I don't think this is the kind of
thing where we'd need to get cfrg input.

 I have been repeatedly taught by the security community to be extremely
 cautious about casual assumptions of what will fix a theoretical
 exposure.  So, for example, there have been cases where encrypting twice
 using the same algorithm reduces protection rather than raising it. 
 That ain't intuitive.
 
 Same concern here.

Well I guess both concerns are theoretical really. Personally,
I think having these fields in the key record reduces the need
for security analysis which is a good enough reason for me.
Of course, others might disagree, but I've not heard any
security concern about including them.

 Having this information maintained in the DNS isn't free and isn't
 certain to be safe.

Fair enough. Though I don't understand the additional expense
of k= and h= in key records - I'd have thought it might even
help maintaining those records, but since I don't maintain any
DNS stuff I may be wrong.

I do agree that key records being unsigned in the DNS is a risk,
but its one we accepted at the start of the WG.

S.


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

Re: [ietf-dkim] chained signatures, was l= summary

[Stephen Farrell]

I think Murray's point is a fair one. This thread isn't
really progressing in terms of what to in/exclude from
4871bis as far as I can see so let's leave it there.

Stephen.

Doug Otis wrote:
 On Jun 8, 2009, at 3:37 PM, Murray S. Kucherawy wrote:
 
 The use of the DKIM l=,  z= and x= features provide a means for  
 recipients to separately evaluate DKIM signatures without reliance  
 on intermediary assessors.  In addition, the A-R header does not  
 capture the IP address when assessing path registration protocols,  
 which means that safe recipient reassessment might only be possible  
 in the case of DKIM or reverse DNS.
 [...]
 Could we please not re-re-re-rehash these A-R issues on ietf-dkim?
 
 
 This was in response Charles making the statement:
 
 For such forensic investigations, removing useful information (aka  
 dumbing down) is always a dumb thing.
 
 These headers represent an active and potentially hazardous component  
 used in email annotation.  Unless the border MTA is willing to assert  
 the A-R headers not removed are safe, the A-R headers should be  
 removed.  The point of rehashing information excluded from the A-R  
 header was to emphasize the point that these headers were not intended  
 to play a role in forensics.  Otherwise, the source of a message would  
 have been important.
 
 -Doug 
 ___
 NOTE WELL: This list operates according to 
 http://mipassoc.org/dkim/ietf-list-rules.html
 

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

[ietf-dkim] 4871bis/4871 interop

[Stephen Farrell]

It'd be useful for us, as chairs, to know if we have consensus
around requirements for interop between implementations of 4871
and 4871bis.

Some of the discussions about things to deprecate may affect that,
so if we have a clear understanding in advance it might short-cut
some discussions of specific topics. (When developing 4871 from
DomainKeys we did have a pretty clear set of principles we followed
for this, so if we can get to a similar level of understanding it
may help. For example, we required that DomainKeys key records
should be usable by 4871 so as not to require folks to re-key
when they moved to support 4871.)

We see these as the various ways in which implementations
could interop. If we had consensus on whether each of these
was a MUST, SHOULD or MAY that'd be good IMO.

Key Records:

1) 4871bis-compliant code [MUST|SHOULD|MAY] be able to use
   4871-compliant key records
2) 4871-compliant code [MUST|SHOULD|MAY] be able to use
   4871bis-compliant key records

Signatures:

3) 4871-compliant code generated signatures [MUST|SHOULD|MAY] be
   verifiable by 4871bis-compliant code
4) 4871bis-compliant code generated signatures [MUST|SHOULD|MAY] be
   verifiable by 4871-compliant code

If you could indicate your preferences that'd be good. Just reply
to this with your MUST|SHOULD|MAY preferences for 1-4.

In case it helps with interpreting this saying e.g. MUST for (3)
would mean a 4871bis verifier would never reject a 4871 signer's
signature just because it included some deprecated field. Saying
MAY for (2) would mean that some new key records would not be
usable with some 4871-compliant implementations.

If you say SHOULD anywhere, please specify what you mean, e.g.
by saying except in the case of foo

Thanks,
Stephen  Barry.





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

Re: [ietf-dkim] Whither 4871bis?

[Stephen Farrell]

So let me try summarise and ask a question.

I don't think I've seen anyone who wants to do more than
just roll up the existing errata into a bis document, possibly
with some editorial changes I guess. I've not seen anyone
suggest that we add features or remove a raft of features
or make other substantial changes.

Please correct me if I've missed or misinterpreted postings
that wanted more change than indicated above.

I've seen folks interested in draft standard and some not.
As to that, my imperfect understanding of DS is that an
RFC needs to be 6 months old before DS is possible. So isn't
it the case that on the day that rfc (being 4871bis) is
published that it may as well be PS? If so, then I can't see
why anyone would object to interested folks then generating
the implementation reports required for DS (and I expect
that that'd be easier than with most RFCs given the wide
deployment of DKIM).

If so, then it may be that we do have consensus to produce
a 4871bis that rolls up the errata and makes editorial
clarifications that garner consensus along the way but
no more.

Does that sound about right?

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

Re: [ietf-dkim] what is a standard, was errata revision: Assessor

[Stephen Farrell]

Murray S. Kucherawy wrote:
 Perhaps some other vendors would like to weigh in.

I'm not at all sure we really need to have that discussion on here.
The logic being that it doesn't affect what we do or don't say in
the errata I-D.

Stephen.

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

Re: [ietf-dkim] Moving to consensus on draft-ietf-dkim-rfc4871-errata

[Stephen Farrell]

Jim Fenton wrote:
 Dave CROCKER wrote:
 Are there other changes to draft-ietf-dkim-rfc4871-errata being proposed?
   
 
 I believe the Chairs requested that the other, non-controversial, errata
 be incorporated into this draft.  

I think we suggested it as an option rather than requested.

 Is that (editorial) work ongoing?

I think it'd be great if Dave were willing to do that, but I could
understand if he'd rather not.

S.

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

Re: [ietf-dkim] Moving on to ADSP - was RE: Handling the errata after the consensus call

[Stephen Farrell]

Siegel, Ellen wrote:
 
 -Original Message-
 On Behalf Of John Levine

 Seems like a reasonable way to avoid the i= fight. If there's interest,
 I can whip up a new ADSP draft with an r= tag.

 
 Sounds like a good approach to me. 

Just in case: Please don't prepare a new ADSP draft right now.

Stephen.

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

Re: [ietf-dkim] Handling the errata after the consensus call

[Stephen Farrell]

SM wrote:
 Hi Stephen,
 At 17:00 09-03-2009, Stephen Farrell wrote:
 Firstly, we're not authors in the sense of being personally
 responsible for each word - the ability and willingness to write
 something with which you disagree is laudable in many cases and in
 this case. Secondly, I don't think anyone would accuse John of a
 chronic tendency to understatement. So, no I don't believe his
 statement has any such implication,
 
 The authors do not have to agree to every word in their draft if the
 document is the work of a WG.  It is laudable that authors include
 material they may not fully agree with.  I appreciate John Levine's
 candidness.
 
 Quoting part of the message from the DKIM Chair:
 
  Then there's the question of where ADSP stands, and whether it can
 proceed as is,
   or needs to be changed in light of the errata.  Pasi may have some
 comments on
   this, and I know the working group will.  We've been holding ADSP up
 for a while,
   and we need to release it and move it forward.
 
 The WG will probably be asking the IETF community to review and comment
 on the ADSP draft.   If one of the authors has serious concerns about
 that draft, it is better to have them voiced out now so that the WG can
 decide where ADSP stands.

I consider that John's concerns have already been voiced, even if
most recently in a quite sloppy manner. To be fair though, John has
been consistent throughout the entire process. And the WG has
consistently kept on with ADSP on the standards track.

Stephen.




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

Re: [ietf-dkim] ADSP - Experimental

[Stephen Farrell]

Please stop all this ADSP good/ADSP bad repetition.

ADSP is finished WGLC and the only thing on our agenda
for it now is pushing it further along the process.

The might, or might not, require some minor change as a
result of the resolution one of the 16 errata for 4871,
however, forgetting ADSP, submitting it as experimental,
making wholesale changes etc. are just not on our agenda.

In this WG we've followed an explicit process of requiring
more support/evidence for late changes, when compared to
early changes. At this point, a substantive change in
the content or direction of ADSP would IMO require its
proponent to go away and produce a lot of evidence that
a very substantial number of WG participants have in
fact changed their opinions. I've seen nothing anywhere
approaching that.

So there is really no need to regurgitate all those old
opinions, it just serves to annoy people.

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

Re: [ietf-dkim] ADSP - Experimental

[Stephen Farrell]

You have suggested that many times. The WG and
the BoFs before it always disagreed. End of story
as far as I'm concerned unless *many* of those
that want it as standards-track now indicate
a change of mind.

Again, please stop. This is unproductive and
totally distracting the WG from progressing
with the 4871 errata,

Stephen.

John Levine wrote:
 Please stop all this ADSP good/ADSP bad repetition.
 
 I am specifically proposing that we withdraw it as
 standards track and resubmit it as experimental,
 because that's what it is.
 
 R's,
 John
 ___
 NOTE WELL: This list operates according to 
 http://mipassoc.org/dkim/ietf-list-rules.html
 
___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

Re: [ietf-dkim] Handling the errata after the consensus call

[Stephen Farrell]

MH Michael Hammer (5304) wrote:
 Please offer a better way of indicating that mail is always signed. 

Actually, please don't. We were chartered to do ADSP and we've
(almost) done that. Unless someone's looking to recharter I don't
see how this list is relevant for other ways to do what ADSP does
or for ways to do something else, or for yet more discussion as
to what ADSP does is wonderful/terrible.

Can we get back to the options mentioned in Barry's mail?

Thanks,
Stephen.
___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

Re: [ietf-dkim] Handling the errata after the consensus call

[Stephen Farrell]

On 9 Mar 2009, at 22:47, SM s...@resistor.net wrote:

 At 14:17 09-03-2009, John Levine wrote:
 I sign all my mail, but there's no way I can say that with ADSP.  In
 its current form, ADSP is broken and useless.

 Given that one of the authors of draft-ietf-dkim-ssp-09 states that
 ADSP is broken and useless, is it worth publishing it on the
 Standards Track or even asking for publication?
Firstly, we're not authors in the sense of being personally  
responsible for each word - the ability and willingness to write  
something with which you disagree is laudable in many cases and in  
this case. Secondly, I don't think anyone would accuse John of a  
chronic tendency to understatement. So, no I don't believe his  
statement has any such implication,
S.


 Regards,
 -sm

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

Re: [ietf-dkim] Nitpicking about ADSP

[Stephen Farrell]

Does the subject line and the endless rehashing of old arguments imply  
that there is, in fact, no recession and that we all have plenty of  
time to do all this for the n-th time?

*Please* re-read and opine on Barry's message, and not on this aged  
topic.
S.

On 9 Mar 2009, at 23:48, Douglas Otis do...@mail-abuse.org wrote:


 On Mar 9, 2009, at 2:55 PM, Murray S. Kucherawy wrote:

 On Mon, 9 Mar 2009, John R. Levine wrote:
 Even though I do in fact sign all my mail with valid DKIM
 signatures, I can't say that with ADSP.  Perhaps there are people
 who consider that makes ADSP highly functional, but it seems an odd
 interpretation.

 I also think it seems odd to label something which many people
 clearly consider to be potentially valuable as broken and useless
 in an environment which is supposed to be constructive and
 cooperative.

 ADSP constrains the use of the i= value in a manner the precludes its
 intended role.  This should be described as broken or at least
 incompatible with RFC4871.  When adhering to RFC4871, and there are
 cases where the i= value will not be found within the From header
 field.  Extra steps are needed to overcome ADSP incompatibilities and
 will be an impediment toward adoption.

 One approach encourages participation and improvement, the other
 discourages it.

 Agreed.  There should be greater sensitively for adoption
 impediments.  ADSP will not achieve sufficient adoption when only a
 small percentage of those deploying DKIM can safely make ADSP
 assertions beyond unknown.  Using terms like CLOSED and LOCKED
 instead of all and discardable were intended to avoid prejudicial
 handling that might discourage adoption, for example.

 -Doug




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

Re: [ietf-dkim] Errata

[Stephen Farrell]

So I think this thread seems to have descended into the
fairly pointless and unproductive category. Maybe let's
leave it there while Barry and I tot up the responses
to the concensus call and see what we (as chairs) make
of that.

In particular:

Michael Thomas wrote:
 Dave CROCKER wrote:
 A number of the latest set of posts indicate that some folks haven't read 
 RFCX 
 4871, and I don't mean carefully. It almost looks as if they haven't read 
 it 
 at all.  Worse, the point that is constantly being ignored was proffered 
 quite 
 clearly in the Errata draft.  So it appears they haven't read that document 
 either.

Dave - you know that a lot of the folks that disagree with you here
have read and contributed substantially to 4871. Saying otherwise
isn't helpful.


 ::snort::
...

 This is rich.


Mike - please take a deep breath before hitting send. Just
being annoyed on the list is also not at all helpful. There
are clearly a bunch of folks who have contributed to 4871
that do agree with the approach Dave is espousing here so
just labelling that revisionism only serves to aggravate and
won't get us closer to resolving the issue.

Thanks,
Stephen.

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

Re: [ietf-dkim] Errata

[Stephen Farrell]

Michael Thomas wrote:
 In any case, I'd like to understand the process by which a substantial
 change in semantics is allowed under the rubric of errata. 

I also believe substantial change is not allowed and wouldn't
get the ok from our AD to use the RFC editor's errata process.
However, at this point we're still trying to establish whether
we have rough consensus in the WG as to the change we want to
make.

Whether that can be processed as an erratum is another day's work
(regardless of the file name of the I-D). It is the case that a
few people have commented that this change might not fit the
errata process whereas others clearly think that its ok to proceed
with it as an erratum. We'll find out which opinion is correct in
the end, but for now, I at least don't claim to know.

Stephen.


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

[ietf-dkim] Consensus call on d=/i= clarification

[Stephen Farrell]

Hi All,

We've had some recent discussion about d=/i= on the list
and a couple of concrete proposals for clarifications to
make to RFC 4871.
   - The first is Dave's erratum I-D. [1]
   - The second is a proposal from Eliot.[2]

Barry and I would like to see if there's rough consensus
on one of these, and, if so, we'll then work with Pasi to
get that processed. (There is an open question as to whether
the erratum I-D fits the RFC editor's erratum model or not,
perhaps mostly due to its length, but we'll handle that if/when
we have WG rough consensus on the meat of the topic. For now,
ignore the process issues, and let's see what clarification
we'd like.)

So, can you please reply to the list with *one* of the
following opinions, before the end of next Monday, Feb
23rd.

(a) The erratum I-D [1] is ready to go. Process it.
(b) The erratum I-D [1] is the way to go, but needs work.
(Then specify your changes in NEW/OLD style.)
(c) Eliot's proposal [2] is ready to go. Process it.
(d) Eliot's proposal [2] is the way to go, but needs work.
(Then specify your changes in NEW/OLD style.)
(e) None of the above.

Thanks,
Stephen  Barry.

[1] http://tools.ietf.org/html/draft-ietf-dkim-rfc4871-errata
[2] http://mipassoc.org/pipermail/ietf-dkim/2009q1/011150.html

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

Re: [ietf-dkim] Requesting working group LastCall on: draft-ietf-dkim-rfc4871-errata-02

[Stephen Farrell]

Folks,

Please hold off on +1's etc until Barry  I respond to Dave's
request for a WGLC. If and when we do WGLC then you'll need
to resend anyway, so there's no need now.

S.

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

Re: [ietf-dkim] Requesting working group Last Call on: draft-ietf-dkim-rfc4871-errata-02

[Stephen Farrell]

Dave CROCKER wrote:
 Consequently, I'd like to ask that we go through a working group Last Call 
 for 
 rfc4871-errata-02.

Barry and I are just pinging about with Pasi on some process stuff but
will be back to get this started/sorted in a day or two.

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

Re: [ietf-dkim] draft Errata on RFC 4871

[Stephen Farrell]

Thanks Dave (and the other's acked) for taking this on
and making a firm proposal.

I guess we've a couple of questions related to this:

Firstly, do we have rough consensus on the substance of
the erratum?

Separately, is the best route from here to do a 4871bis
(assuming the 5378 mess gets sorted), that incorporates
all agreed errata to date? If not, then what?

I'd welcome opinions on the above in the next week or
so,

Thanks,
Stephen.

Dave CROCKER wrote:
 Folks,
 
 Howdy.
 
 I've just submitted an Internet Draft with text for the working group to 
 consider. A group of us have been working on it.
 
 It clarifies and resolves the roles and relationship of the d= and i= tag.
 
 An html version of the I-D is at:
 
 http://dkim.org/specs/draft-ietf-dkim-rfc4871-errata-00.html
 
 d/

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

Re: [ietf-dkim] draft Errata on RFC 4871

[Stephen Farrell]

John Levine wrote:
 Except that the UAID might or might not be an e-mail address.  The one
 on this messgage isn't.

So, for clarity, can you (or someone) call out what you think is
the impact, if any, for ADSP, caused by this proposed change to
4871.

Thanks,
Stephen.

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

[ietf-dkim] Copyright issues affecting current Internet-Drafts

[Stephen Farrell]

Folks,

There are some issues with the new IPR policies outlined in
RFC 5378 that I would like to bring to your attention. Please
read through the writeups that other folks have provided and
make your own judgement. Discussion of this should take place
on the IETF list and not here.

Stephen.

-Original Message-
From: owner-radius...@ops.ietf.org 
[mailto:owner-radius...@ops.ietf.org] On Behalf Of Dave Nelson
Sent: 14 January, 2009 21:53
To: radius...@ops.ietf.org
Subject: Copyright issues affecting current Internet-Drafts

The IETF Chair has requested that all Working Groups be 
notified of an intellectual property rights / copyright 
brou-ha-ha that is being currently discussed on the IETF 
General Discussion List.

As I understand it, there is a minor defect in RFC 5378, the 
document that currently governs rights in IETF submissions and 
publications.
Specifically, this has to do with rights for derivative works 
outside of the IETF standards process.

There is also ongoing discussion of a workaround for this 
problem.  If you are interested, please consult the IETF 
General Discussion mailing list archives.  Any discussion of 
the issue should occur on that list.

One potential impact to the Working Groups is that revised 
boilerplate text is likely to be required for submission of 
I-Ds.  That revised text is expected to be in place well 
before the I-D submission cut-off date prior to IETF-74.  
There may be some confusion during the transition, however.

A second potential impact is that any material that has been 
derived from a document published prior to the effective date 
RFC 5378 (November 11, 2008) may require special restrictions 
to be listed in the boilerplate, as to rights for derivative 
works outside the IETF standards process.

The fair use doctrine would seem to apply to small sections 
of properly quoted and cited text from older documents.  The 
issue arises with any modifications to such text.  We have 
seen such re-use of modified text proposed in recent WG list 
discussions on open RADEXT Issues.

All I-D authors need to be generally aware of this issue, and 
anyone wishing to include substantial sections of text or any 
sections of modified text from a pre-5378 document need to 
be particular aware.  It does not appear that this issue will 
impact our work, if we pay attention to the details.

Following is the details of the issue, as summarized in an 
announcement from the Trustees of the IETF Trust (the agency 
that holds IETF IPR).

---
---

The purpose of this message is twofold:

1) To summarize the issues that some members of our community 
   have experienced since the publication of RFC 5378 in 
November 2008, 
   and
2) To invite community review and discussion on a potential 
work-around 
   being considered by the IETF Trustees.

Some I-D authors are having difficulty implementing RFC 5378.  
An example of the difficulty is as follows:

  - an author wants to include pre-5378 content in a new submission
or contribution to the IETF, but
  - s/he is not certain that all of the author(s) of the earlier  
material have agreed to license it to the IETF Trust according
to RFC 5378.

If an I-D author includes pre-5378 material in a new document, 
then s/he must represent or warrant that all of the authors 
who created the
pre-5378 material have granted rights for that material to the 
IETF Trust.
If s/he cannot make this assertion, then s/he has a problem.

This situation has halted the progression of some 
Internet-Drafts and interrupted the publication of some RFCs.  
The Trustees of the IETF Trust are investigating ways to 
implement a temporary work-around so that IETF work can 
continue to progress.  A permanent solution to this pre-5378 
problem may require an update to RFC 5378, for example new 
work by the community to create a 5378-bis document.

The remainder of this message provides an outline of the 
temporary work- around being considered by the Trustees.

RFC 5378 sections 1.j and 5.3.c provide the IETF Trust with 
the authority to develop legend text for authors to use in 
situations where they wish to limit the granting of rights to 
modify and prepare derivatives of the documents they submit.  
The Trustees used this authority in 2008 to develop and adopt 
the current Legal Provisions Relating to IETF Documents 
which are posted at:
http://trustee.ietf.org/license-info/.

The Trustees are now considering the creation of optional new 
legend text which could be used by authors experiencing the 
pre-5378 problem.

The new legend text, if implemented, would do the following:

  a. Provide Authors and Contributors with a way to identify (to the
 IETF Trust) that their contributions contain material 
from pre-5378  
 documents for which RFC 5378 rights to modify the material outside
 the IETF standards process may not have been granted, and

  b. Provide the IETF 

[ietf-dkim] Clarifying i=/d= in 4871 (was: Re: Next steps for draft-ietf-dkim-ssp)

[Stephen Farrell]

Hi Dave,

I think you're making a reasonable point below about 4871.

Dave CROCKER wrote:
 
 
 Stephen Farrell wrote:
 I don't believe this discussion is necessary in order to progress the
 ADSP draft, which, for better or worse, is where the WG's rough
 consensus ended up.
 
 
 Stephen,
 
 Happily, a community learns things about specifications as time progresses.
 Sometimes that learning uncovers problems and the problems get
 resolved.  For
 example, that's was RFC Errata are for.

Right. So if there's a significant concern (and I'm not sure how many
people share the concern) then I'd expect a thread on here aimed at
generating another erratum for 4871. My guess is that folks who are
ok with the status quo are likely to be silent, so I'd expect those
who are concerned to push that a bit.

 In the current case, this is a rather fundamental and persistent
 confusion in
 the community about DKIM's output.
 
 The Signing specification states:
 
 1. Introduction

 DomainKeys Identified Mail (DKIM) defines a mechanism ...
 permitting a signing domain to claim
 responsibility ...
 Message recipients can ...  confirm that the
 message was attested to by a party in possession of the private key
 for the
 signing domain.
 
 and
 
 1.1 Signing Identity

 DKIM separates the question of the identity of the signer of the
 message from
  the purported author of the message. In particular, a signature
 includes the
  identity of the signer. Verifiers can use the signing information to
 decide how they want to process the message. The signing identity is
 included as part of the signature header field
 
 
 This language declares that the result of a DKIM verification is an
 identifier that declares some responsibility.
 
 The question, now, is which string represents that identifier?
 
 The fact that there are serious, knowledgeable folk who declare it is
 the d= tag and other, equally serious and knowledgeable folk who declare
 that it is the i= tag, and that there are substantial numbers of each
 means that we have a real and basic problem:
 
   The community does not currently have consensus about
   where to find the one value that is DKIM's output!
 
 This is not something that can get resolved by fiat, Steve, such as
 saying that a prior decision by the working group resolves the matter. 

I don't think that noting that a spec (4871) that's been through
all our processes says foo is resolving anything by fiat, but
whatever.

 And it is not something that gets resolved by one or another person
 pointing to some other language in the Signing spec and declaring that
 it provides the one true answer.
 
 If the real world has competing interpretations of the spec, then the
 spec will not be used in a consistent matter.  And it's difficult to
 find a more serious problem with a specification, since it means that
 the core semantic has ambiguous interpretation.
 
 What we are seeing, now, is that work on ADSP is (again) surfacing this
 basic confusion.

 
 Approving ADSP, in the absence of resolving this basic confusion about
 what value to use, merely entrenches the confusion further.
 
 It doesn't actually resolve it.

Could be. However, I don't think we need to halt all progress on ADSP.
We can and should clarify ADSP (e.g. as requested by Pasi) and then if
it turns out that a new erratum on 4871 is agreed, we may or may not
need to revisit something in ADSP.

Given where we're at in the process for ADSP, I would have thought that
those who feel that i=/d= needs clarifying in 4871 would try resolve
that as a matter of (relative) urgency. Otherwise ADSP is likely to
be in Pasi's queue for a long time.

Stephen.


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

Re: [ietf-dkim] Next steps for draft-ietf-dkim-ssp

[Stephen Farrell]

John L wrote:
 That would be fine with me, but what it says now is that the i= MUST match 
 the From: address.  As I've said a few times, that's clearly wrong, but I 
 got shouted down in the past when I tried to change it.

Without getting into the merits of the argument (and I don't think we
should do all that again), the document does currently reflect the
WG's rough consensus so let's keep this to adding clarifications as
Pasi requested and not try re-open issues now after the end of IETF
LC.

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

[ietf-dkim] DKIM msp meeting minutes

[Stephen Farrell]

Hi,

I don't think we posted these to the list yet, so here
they are. [1]

Regards,
Stephen.

[1] http://www.ietf.org/proceedings/08nov/minutes/dkim.txt

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

Re: [ietf-dkim] AD evaluation comments for draft-ietf-dkim-ssp

[Stephen Farrell]

Hi Pasi,

The authors have pushed out a new version of ADSP. [1]

I've just had a look at the diffs [2] between that and
the previous one, and they seem to have covered your
AD comments fairly well, so hopefully you'll be ok with
starting IETF LC after you've had a chance to check
their changes.

Regards,
Stephen.

[1] http://tools.ietf.org/html/draft-ietf-dkim-ssp
[2]
http://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=http://tools.ietf.org/id/draft-ietf-dkim-ssp-06.txturl2=http://tools.ietf.org/id/draft-ietf-dkim-ssp-07.txt


[EMAIL PROTECTED] wrote:
 Hi,
 
 I've done my AD review for draft-ietf-dkim-ssp-06, and I was happy
 to see that the document is in good shape.
 
 I do have couple of suggestions, though. Basically all of these are of
 the WG members probably understand what this text means, but if you
 could add couple of more words, future readers would be thankful
 type; that is, suggestions for improving the clarity especially to
 folks who didn't read the WG discussions about the topic.
 
 Stephen, could you as the document shepherd take the lead in
 discussing these and getting agreement on appropriate edits? 
 (in some cases, I've suggested a possible wording, but that's 
 just one starting point)
 
 Best regards,
 Pasi
 
 --
 
 - Section 3.1: to some folks, domain means just a single DNS name
   example.com; to others, it might mean everything under
   example.com. I think it'd be useful to give a concrete example
   here, saying e.g. that an ADSP record for example.com (stored in
   _adsp._domainkey.example.com) does *not* apply to emails from
   e.g. [EMAIL PROTECTED] ; to cover that, you'd need 
   _adsp._domainkey.www.example.com etc. (IMHO this is quite important 
   detail that isn't currently isn't very obvious from the document.)
 
 - Section 3.3, 1st bullet would be clearer if it said
   ...no ADSP record is found
 
 - Section 3.3, 3rd bullet: this would be easier to understand if you
   copied the text from 4.2.1 definition of discardable here, too.
 
 - Section 3.3, 4th bullet: this would be easier to understand it
   said because it does not exist in DNS, this is the case if
   the domain does not exist in DNS, or something
 
 - Section 3.3, should mention the 5th possibility of the procedure in
   4.3: algorithm terminates without producing a result, indicating a
   temporary failure.
 
 - Section 4.1 says the Tag=Value List syntax from RFC 4871 is used,
   but it seems there's a difference: 4871 uses [FWS] around the =
   sign, while this document uses *WSP. This is probably an intentional
   difference (right?), but should be explicitly pointed out.
 
 - Section 4.2.1: Since the signing practice list is extensible, the
   text should say how an unknown value should be treated -- probably
   same as unknown?
 
 - Section 4.3, Check Domain Scope step: it'd be useful to explicitly
   say something NODATA (rcode=0 with ANCOUNT=0), as if I recall right,
   even some WG members were confused at some point...
 
 - Section 4.3, Fetch Named ADSP Record step: it'd be useful to say
   here that if the result is NXDOMAIN, or NOERROR with zero records, or
   NOERROR with records that aren't valid ADSP records, the result is
   unknown (is that right, BTW?)
 
 - Section 4.3, does not exist for mail would benefit from 
   rephrasing somehow (perhaps is not a valid email domain for
   [2821], or something?)
 
 - Section 4.3: would this be easier to read if you included a concrete
   example (e.g. email message with a From line, and all the DNS lookups
   done)? Or perhaps couple of examples?
 
 - Section 6.1, last paragraph: to me it seems the amount of DNS
   traffic would be less than amount of SMTP traffic, so this wouldn't
   be a very good traffic multiplication attack? (with multiplier  1)
   If that's the case, perhaps would be useful to mention?
 
 Nits:
 
 - Title: Expand acronym DKIM 
 - References: update RFC 2821 to 5321, and 2822 to 5322 
 - Section 4.1, the_adsp._domainkey - the _adsp._domainkey
 
 --
 
 ___
 NOTE WELL: This list operates according to 
 http://mipassoc.org/dkim/ietf-list-rules.html
 
___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

Re: [ietf-dkim] errata conclusions

[Stephen Farrell]

Thanks Tony,

If there are no objections, we'll forward these to Pasi to
take action (i.e. update the errata pages) in one week from
now,

Stephen.

Tony Hansen wrote:
 Here's a description of the errata conclusions that were made at today's
 meeting. If anyone disagrees, speak now.
 
   Tony Hansen
   [EMAIL PROTECTED]
 
 Errata 1383   show g= example with * in middle
 
   Add to the example list for g= the example of foo*bar:
 
   Section 3.6.1 should say:
 
   g= Granularity of the key (plain-text; OPTIONAL, default is
   *).  Wildcarding allows matching for addresses such as
   user+*, *-offer or foo*bar. An empty g= value never
   matches any addresses.
 
 Errata 1378   a= is required
 
   I was to check if the messages I captured at the interop last year if
 there were any that did not have a= in them. I still have 834 of the
 messages I received back then. *All of them have a= in them.* Given
 that, here is the conclusion:
 
   Section 3.3 should remove the sentence saying:
 
   The rsa-sha256 algorithm is the default if no algorithm is
   specified.
 
 Errata 1532   DomainKeys key record compatibility
 
   Add a section, probably after 6.1.3, with this text:
 
   6.1.4 Compatibility Note for DomainKeys
 
   The definition given here for the key record is upwardly
   compatible with what is used for DomainKeys, with the exception
   of the g= value. In DomainKeys, a key record empty g= value
   is equivalent to g=*, while DKIM treats that value as matching
   nothing. The value g=* means the same in both DomainKeys and
   DKIM.
 
   DomainKeys deployers are encouraged to at least switch their key
   records to using the equivalent g=* value, which works
   equivalently for both DomainKeys and DKIM.
 
   A DKIM implementation MAY choose to use the lack of a v= value
   at the beginning of the key record as an indicator that the key
   record is a DomainKeys key record, and interpret an empty g=
   value as if it were written g=*.
 
 Errata 1596   Ambiguity regarding whitespace and b= value
 
   Add text (including all surrounding whitespace) to the
   description of deleting the b= value.
 
   3.7. Computing the Message Hashes
 
   2. The DKIM-Signature header field that exists (verifying) or
   will be inserted (signing) in the message, with the value of the
   b= tag (including all surrounding whitespace) deleted (i.e.,
   treated as the empty string), canonicalized using the header
   canonicalization algorithm specified in the c= tag, and
   without a trailing CRLF.
 
   Fix the ambiguity in the base64string grammar to remove leading
   and trailing FWS. Replace the existing base64 production with:
 
   ALPHADIGITPS = (ALPHA / DIGIT / + / /)
   base64string = ALPHADIGITPS *([FWS] ALPHADIGITPS)
   [ [FWS] = [ [FWS] = ] ]
 ___
 NOTE WELL: This list operates according to 
 http://mipassoc.org/dkim/ietf-list-rules.html
 
___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

[ietf-dkim] Draft agenda for MSP

[Stephen Farrell]

Hi All,

A bit late (sorry;-) but I've now posted a draft
agenda. [1]

Let Barry  I know if there are any changes/additions
needed - we do have time if necessary.

Regards,
Stephen.

[1] http://www.ietf.org/proceedings/08nov/agenda/dkim.txt

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

Re: [ietf-dkim] [dkim-ops] Q: dkim=discardable

[Stephen Farrell]

Doug,

That was discussed at length in the WG and we ended up
where we ended up.

I'm sure you'll make the point again in IETF LC, (which is
entirely fine), but we don't need to revisit the topic on
this list, so please stop raising it here.

If you think you have some compelling reason that we
should discuss it on-list again, feel free to mail
Barry and I off-list. However, I'm pretty sure I'll
not be convinced from what I've seen to date.

Thanks,
Stephen.

Douglas Otis wrote:
 On Oct 30, 2008, at 9:26 AM, John R Levine wrote:
 
 I think most of the likely candidate domains for using  
 discardable would disagree with your assertion John.
 Then I have to say that they don't understand what discardable  
 means. Really, it says feel free to throw our mail away if you have  
 the least doubt about it.  This chronic misconception is the main  
 reason that I doubt that discardable will be useful in practice,  
 since only a small fraction of people who assert it will truly  
 understand what they've said.
 
 
 The term discard in RFC 5321 is used to mean the silent dropping of  
 information.
 
 In the prior note you said It's really only useful for banks and  
 places like Paypal sending out notices about accounts, not for any  
 domain with individual users.
 
 As Michael suggested, these domains will not want to have their  
 messages silently discarded.
 
 The term discardable suggests permission to violate RFC 5321 Section  
 2.1 MUST accept responsibility for either delivering the message or  
 properly reporting the failure.  This same MUST is echoed in Section  
 3.6.3 , 4.4 and 6.1.  Section 6.2 provides advice on making an  
 exception.
 
 ADSP will affect _all_ messages from the domain.  Few customers will  
 welcome messages from similar domains by the same institution.   
 Customers that have opted to go paperless will be negatively affected  
 by discardable since this affects all communications, even those  
 considered extremely important.  Unless DKIM signatures are so robust  
 that _any_ type of failure provides very high confidence that the  
 messages are seriously fraudulent, then the silent discard is not the  
 best choice.  If some institution ever had a problem with their DKIM  
 signatures, how will they become aware of the problem when _all_ their  
 messages are being silently discarded?
 
 At least two people on the DKIM list suggested that this term would be  
 problematic.  Instead of Discardable,  Dismissible would not imply  
 that not reporting a failure is now allowed.
 
 -Doug
 ___
 NOTE WELL: This list operates according to 
 http://mipassoc.org/dkim/ietf-list-rules.html
 
___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

Re: [ietf-dkim] Potential DKIM re-chartering...

[Stephen Farrell]

Jim Fenton wrote:
 It does seem like things are winding down.  A couple of things:
 
 1. I'm not sure where we are on the overview draft.  Have we completed
 WGLC on it?  The I-D tracker doesn't indicate anything happening.

Its done with WGLC (I sent out a note a while back.) Barry's just done
the PROTO write-up, so it's essentially with the AD. Datatracker should
catch up soon.

 
 2. The deployment draft has expired.  Is that still going to happen?

Yes.

 
 For new business, I understand that the domains that are actively
 using signatures for non-delivery decisions from specific domains (e.g.,
 PayPal - GMail) are doing so with a feedback path in place -- they know
 when mail is being dropped on their behalf.  I think we should consider
 taking on draft-kucherawy-dkim-reporting as a WG work item, as it
 provides approximately that capability in what would be a standardized
 way.  I realize there will be some disagreement whether this is a good
 idea, but that's what a chartering discussion is all about.

Ok. Looks like a good agenda item for MSP. But of course, folks should
discuss on-list if they have opinions/ideas.

S.

 
 -Jim
 
 Stephen Farrell wrote:
 Folks, we've had no response so far to this request for new
 work items. If that remains the case, Barry and I plan to
 let our AD know that its time to declare victory for DKIM and
 that we'll be heading into dormant mode after the next
 meeting (which should be very short).

 Stephen.

 Stephen Farrell wrote:
   
 Hi All,

 In Dublin [1] we had a few proposals for new work items and presentation
 of some related work (Murray's stuff). We agreed with the AD that we
 would not start a discussion about potentially re-chartering until after
 ADSP and the overview were out of the WG. Well, we're there now, ADSP is
 with the AD, the overview write-up is in Barry's queue, and Pasi is ok
 with us starting this discussion now.

 So, can folks who'd like to propose that we recharter to take on new
 work post an I-D describing what they'd like and then start a thread
 here so we can discuss the various ideas. Note that the I-D cutoff for
 -00's is October 27th. Of course, if you already have an I-D then just
 start a thread. Please don't make a proposal without an I-D (the new
 tools make posting a draft so easy, I think this is fair).

 Barry and I would like us to be able to discuss the various proposals
 in Minneapolis with a view to crafting new charter text to send to Pasi
 shortly thereafter if we see rough consensus for taking on some new
 work items. (BTW - I suspect that if we have no new work items, we
 won't need a DKIM slot at every IETF in future and so we'll be very
 close to declaring victory, which is always nice:-)

 And just in case some folks aren't clear - any new charter text
 would just be a proposal for a new charter, the IESG make the decision
 as to whether or not to ok that after requesting feedback from the
 broader IETF community.

 Regards,
 Stephen.

 [1] http://tools.ietf.org/wg/dkim/minutes?item=minutes72.html

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

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

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

Re: [ietf-dkim] Re-send: Considerations for rechartering

[Stephen Farrell]

Oops - probably just by me, sorry. (Found it in a wrong folder.)

S.

Murray S. Kucherawy wrote:
 Apparently this got missed.  Re-sending...
 
 -- Forwarded message --
 Date: Fri, 17 Oct 2008 11:31:39 -0700 (PDT)
 From: Murray S. Kucherawy [EMAIL PROTECTED]
 To: ietf-dkim@mipassoc.org
 Subject: Considerations for rechartering
 
 I'd suggest we consider rechartering to cover this draft:
 
 https://datatracker.ietf.org/drafts/draft-kucherawy-dkim-reporting
 
 The draft depends on two other drafts which are more broadly-based 
 (draft-shafranovich-feedback-report and 
 draft-kucherawy-sender-auth-header) and thus may not be able to come under 
 the working group's purview. draft-kucherawy-sender-auth-header is 
 currently in AD Followup status as an individual submission.
 
 -MSK
 ___
 NOTE WELL: This list operates according to 
 http://mipassoc.org/dkim/ietf-list-rules.html
 
___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

Re: [ietf-dkim] Potential DKIM re-chartering...

[Stephen Farrell]

Folks, we've had no response so far to this request for new
work items. If that remains the case, Barry and I plan to
let our AD know that its time to declare victory for DKIM and
that we'll be heading into dormant mode after the next
meeting (which should be very short).

Stephen.

Stephen Farrell wrote:
 Hi All,
 
 In Dublin [1] we had a few proposals for new work items and presentation
 of some related work (Murray's stuff). We agreed with the AD that we
 would not start a discussion about potentially re-chartering until after
 ADSP and the overview were out of the WG. Well, we're there now, ADSP is
 with the AD, the overview write-up is in Barry's queue, and Pasi is ok
 with us starting this discussion now.
 
 So, can folks who'd like to propose that we recharter to take on new
 work post an I-D describing what they'd like and then start a thread
 here so we can discuss the various ideas. Note that the I-D cutoff for
 -00's is October 27th. Of course, if you already have an I-D then just
 start a thread. Please don't make a proposal without an I-D (the new
 tools make posting a draft so easy, I think this is fair).
 
 Barry and I would like us to be able to discuss the various proposals
 in Minneapolis with a view to crafting new charter text to send to Pasi
 shortly thereafter if we see rough consensus for taking on some new
 work items. (BTW - I suspect that if we have no new work items, we
 won't need a DKIM slot at every IETF in future and so we'll be very
 close to declaring victory, which is always nice:-)
 
 And just in case some folks aren't clear - any new charter text
 would just be a proposal for a new charter, the IESG make the decision
 as to whether or not to ok that after requesting feedback from the
 broader IETF community.
 
 Regards,
 Stephen.
 
 [1] http://tools.ietf.org/wg/dkim/minutes?item=minutes72.html
 
 ___
 NOTE WELL: This list operates according to 
 http://mipassoc.org/dkim/ietf-list-rules.html
 
___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

Re: [ietf-dkim] AD evaluation comments for draft-ietf-dkim-ssp

[Stephen Farrell]

Thanks Pasi,

I'll work with the authors to get their reactions back to the list
and we can go from there,

Cheers,
S.

[EMAIL PROTECTED] wrote:
 Hi,
 
 I've done my AD review for draft-ietf-dkim-ssp-06, and I was happy
 to see that the document is in good shape.
 
 I do have couple of suggestions, though. Basically all of these are of
 the WG members probably understand what this text means, but if you
 could add couple of more words, future readers would be thankful
 type; that is, suggestions for improving the clarity especially to
 folks who didn't read the WG discussions about the topic.
 
 Stephen, could you as the document shepherd take the lead in
 discussing these and getting agreement on appropriate edits? 
 (in some cases, I've suggested a possible wording, but that's 
 just one starting point)
 
 Best regards,
 Pasi
 
 --
 
 - Section 3.1: to some folks, domain means just a single DNS name
   example.com; to others, it might mean everything under
   example.com. I think it'd be useful to give a concrete example
   here, saying e.g. that an ADSP record for example.com (stored in
   _adsp._domainkey.example.com) does *not* apply to emails from
   e.g. [EMAIL PROTECTED] ; to cover that, you'd need 
   _adsp._domainkey.www.example.com etc. (IMHO this is quite important 
   detail that isn't currently isn't very obvious from the document.)
 
 - Section 3.3, 1st bullet would be clearer if it said
   ...no ADSP record is found
 
 - Section 3.3, 3rd bullet: this would be easier to understand if you
   copied the text from 4.2.1 definition of discardable here, too.
 
 - Section 3.3, 4th bullet: this would be easier to understand it
   said because it does not exist in DNS, this is the case if
   the domain does not exist in DNS, or something
 
 - Section 3.3, should mention the 5th possibility of the procedure in
   4.3: algorithm terminates without producing a result, indicating a
   temporary failure.
 
 - Section 4.1 says the Tag=Value List syntax from RFC 4871 is used,
   but it seems there's a difference: 4871 uses [FWS] around the =
   sign, while this document uses *WSP. This is probably an intentional
   difference (right?), but should be explicitly pointed out.
 
 - Section 4.2.1: Since the signing practice list is extensible, the
   text should say how an unknown value should be treated -- probably
   same as unknown?
 
 - Section 4.3, Check Domain Scope step: it'd be useful to explicitly
   say something NODATA (rcode=0 with ANCOUNT=0), as if I recall right,
   even some WG members were confused at some point...
 
 - Section 4.3, Fetch Named ADSP Record step: it'd be useful to say
   here that if the result is NXDOMAIN, or NOERROR with zero records, or
   NOERROR with records that aren't valid ADSP records, the result is
   unknown (is that right, BTW?)
 
 - Section 4.3, does not exist for mail would benefit from 
   rephrasing somehow (perhaps is not a valid email domain for
   [2821], or something?)
 
 - Section 4.3: would this be easier to read if you included a concrete
   example (e.g. email message with a From line, and all the DNS lookups
   done)? Or perhaps couple of examples?
 
 - Section 6.1, last paragraph: to me it seems the amount of DNS
   traffic would be less than amount of SMTP traffic, so this wouldn't
   be a very good traffic multiplication attack? (with multiplier  1)
   If that's the case, perhaps would be useful to mention?
 
 Nits:
 
 - Title: Expand acronym DKIM 
 - References: update RFC 2821 to 5321, and 2822 to 5322 
 - Section 4.1, the_adsp._domainkey - the _adsp._domainkey
 
 --
 
 ___
 NOTE WELL: This list operates according to 
 http://mipassoc.org/dkim/ietf-list-rules.html
 
___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

[ietf-dkim] Potential DKIM re-chartering...

[Stephen Farrell]

Hi All,

In Dublin [1] we had a few proposals for new work items and presentation
of some related work (Murray's stuff). We agreed with the AD that we
would not start a discussion about potentially re-chartering until after
ADSP and the overview were out of the WG. Well, we're there now, ADSP is
with the AD, the overview write-up is in Barry's queue, and Pasi is ok
with us starting this discussion now.

So, can folks who'd like to propose that we recharter to take on new
work post an I-D describing what they'd like and then start a thread
here so we can discuss the various ideas. Note that the I-D cutoff for
-00's is October 27th. Of course, if you already have an I-D then just
start a thread. Please don't make a proposal without an I-D (the new
tools make posting a draft so easy, I think this is fair).

Barry and I would like us to be able to discuss the various proposals
in Minneapolis with a view to crafting new charter text to send to Pasi
shortly thereafter if we see rough consensus for taking on some new
work items. (BTW - I suspect that if we have no new work items, we
won't need a DKIM slot at every IETF in future and so we'll be very
close to declaring victory, which is always nice:-)

And just in case some folks aren't clear - any new charter text
would just be a proposal for a new charter, the IESG make the decision
as to whether or not to ok that after requesting feedback from the
broader IETF community.

Regards,
Stephen.

[1] http://tools.ietf.org/wg/dkim/minutes?item=minutes72.html

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

Re: [ietf-dkim] RFC 4871 errata

[Stephen Farrell]

Thanks Pasi,

Tony - you generated both of those from the interop, so
could you take a peek and let us know what you recall
and/or think? (e.g. for 1378 do you prefer optional or
REQUIRED?, for 1383 I guess if the interop showed that
folks implement more generic wildcarding then the erratum
is ok as-is).

Ta,
S.

[EMAIL PROTECTED] wrote:
 In particular, my earlier email (two months ago) identified 
 two errata (1383 and 1378) that deserve a closer look:
 
 http://mipassoc.org/pipermail/ietf-dkim/2008q3/010664.html
 
 (For these two, I'd be hesitant to assume that silence 
 means everyone's OK with them.)
 
 Best regards,
 Pasi
 
 -Original Message-
 From: [EMAIL PROTECTED] 
 [mailto:[EMAIL PROTECTED] On Behalf Of ext 
 Stephen Farrell
 Sent: 29 September, 2008 12:44
 To: ietf-dkim
 Subject: [ietf-dkim] RFC 4871 errata


 Hi all,

 We need to give Pasi guidance on the WG's opinion of the
 various errata [1] that've been posted for RFC 4871.

 Most of these were generated as a result of the good interop
 work done earlier, so this should hopefully be easy.

 We need to tell Pasi if we think the errata as posted
 should be accepted and if so, whether the proposed
 change and accompanying notes are ok or not. If the
 text needs changing then we need to generate the new
 text required. (Since this could take some time, please
 don't try to e.g. polish the notes text so that its
 totally nice and shiny:-)

 If there are ones we need to discuss, please start
 a new thread for each. Once that's settled down, I'll
 send out a mail looking for some +1's on the entire set.
 (If no-one comments on any of them in two weeks, i.e.
 by 2008-10-13, then I'll send out that message
 anyway.)

 After that's all done, we'll want to think about whether
 to do a 4871bis with the changes or a delta or whatever,
 but that's for later.

 Thanks,
 Stephen.

 [1] http://www.rfc-editor.org/errata_search.php?rfc=4871eid=
 ___
 NOTE WELL: This list operates according to 
 http://mipassoc.org/dkim/ietf-list-rules.html

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

[ietf-dkim] ADSP publication requested

[Stephen Farrell]

Hi Pasi,

The DKIM WG has finished WGLC on the ADSP draft [1] so this is
a formal note requesting publication. The proto write up details
are attached,

Thanks,
Stephen.

[1] http://tools.ietf.org/html/draft-ietf-dkim-ssp-06





Technical Summary

   DomainKeys Identified Mail (DKIM) defines a domain-level authentication
   framework for email to permit verification of the source and contents of
   messages.  This document specifies an adjunct mechanism to aid in assessing
   messages that do not contain a DKIM signature for the domain used in the
   author's address.  It defines a record that can advertise whether a domain
   signs its outgoing mail, and how other hosts can access that record.

Working Group Summary

   draft-ietf-dkim-ssp-06 is the 7th official WG draft, following on from
   3 iterations of an individual submission (draft-allman-dkim-ssp)
   with the -00 version dating back to January 2006. The current draft
   has passed WGLC with solid support in the DKIM WG. Some minor editorial
   changes were make post-WGLC based on (a few) comments received on
   the -05 draft.

   The DKIM WG used the rt.psg.com tracker for its work (queue=dkim)
   and processed O(50) issues for this document over the period.

Document Quality

   The document has undergone thorough review in the WG resulting in
   various revisions, typically removing features or renaming elements
   of the protocol, however, the basic core feature of ADSP has remained
   stable all through the process.

Personnel

   Stephen Farrell ([EMAIL PROTECTED]) is the shepherd for this
   document.

PROTO write-up:

(1.a)  Who is the Document Shepherd for this document?  Has the Document
Shepherd personally reviewed this version of the document and, in particular,
does he or she believe this version is ready for forwarding to the IESG for
publication?

   I have reviewed this vesion and believe it is ready for publication.
  

(1.b)  Has the document had adequate review both from key WG members and from
key non-WG members?  Does the Document Shepherd have any concerns about the
depth or breadth of the reviews that have been performed?

   The document has undergone very thorough review in the WG. Some
   members of the DNS directorate have also been involved in 
   discussions at various stages of its development.

(1.c) Does the Document Shepherd have concerns that the document needs more
review from a particular or broader perspective, e.g., security, operational
complexity, someone familiar with AAA, internationalization, or XML?

   No concerns.

(1.d) Does the Document Shepherd have any specific concerns or issues with this
document that the Responsible Area Director and/or the IESG should be aware of?
For example, perhaps he or she is uncomfortable with certain parts of the
document, or has concerns whether there really is a need for it.  In any event,
if the WG has discussed those issues and has indicated that it still wishes to
advance the document, detail those concerns here.  Has an IPR disclosure
related to this document been filed?  If so, please include a reference to the
disclosure and summarize the WG discussion and conclusion on this issue.

   No concerns.

   I know of no IPR issues with this document. 

(1.e)  How solid is the WG consensus behind this document?  Does it represent
the strong concurrence of a few individuals, with others being silent, or does
the WG as a whole understand and agree with it?

   The WG has a strong concensus that this document should proceed. 


(1.g)  Has the Document Shepherd personally verified that the document
satisfies all ID nits?  (See http://www.ietf.org/ID-Checklist.html and
http://tools.ietf.org/tools/idnits/.)  Boilerplate checks are not enough; this
check needs to be thorough.  Has the document met all formal review criteria it
needs to, such as the MIB Doctor, media type, and URI type reviews?  If the
document does not already indicate its intended status at the top of the first
page, please indicate the intended status here.

   The nits tool generates one warning only (Authors' Adresses section
   title).

(1.h)  Has the document split its references into normative and informative?
Are there normative references to documents that are not ready for advancement
or are otherwise in an unclear state?  If such normative references exist, what
is the strategy for their completion?  Are there normative references that are
downward references, as described in [RFC3967]?  If so, list these downward
references to support the Area Director in the Last Call procedure for them
[RFC3967].

References are split, there are no downrefs.

(1.i) Has the Document Shepherd verified that the document's IANA
Considerations section exists and is consistent with the body of the document?
If the document specifies protocol extensions, are reservations requested in
appropriate IANA registries?  Are the IANA registries clearly identified?  If
the document creates a new registry, does it define

[ietf-dkim] RFC 4871 errata

[Stephen Farrell]

Hi all,

We need to give Pasi guidance on the WG's opinion of the
various errata [1] that've been posted for RFC 4871.

Most of these were generated as a result of the good interop
work done earlier, so this should hopefully be easy.

We need to tell Pasi if we think the errata as posted
should be accepted and if so, whether the proposed
change and accompanying notes are ok or not. If the
text needs changing then we need to generate the new
text required. (Since this could take some time, please
don't try to e.g. polish the notes text so that its
totally nice and shiny:-)

If there are ones we need to discuss, please start
a new thread for each. Once that's settled down, I'll
send out a mail looking for some +1's on the entire set.
(If no-one comments on any of them in two weeks, i.e.
by 2008-10-13, then I'll send out that message
anyway.)

After that's all done, we'll want to think about whether
to do a 4871bis with the changes or a delta or whatever,
but that's for later.

Thanks,
Stephen.

[1] http://www.rfc-editor.org/errata_search.php?rfc=4871eid=
___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

[ietf-dkim] Progressing ADSP (Was: Re: New Version Notification for draft-ietf-dkim-ssp-06 (fwd))

[Stephen Farrell]

Thanks John,

So this means that we're not taking on board the various
suggestions in Doug's draft since they didn't garner
any real support. I think that's correct, but just in
case - if there's a whole bunch of folks out there who
agree with Doug's draft so much that they think we
should not progress ADSP - now's your last chance
(in the WG) to say so.

It might be no harm if folks who do think ADSP should
go ahead would respond to this saying so. I'm sure that
Doug will (quite reasonably) bring up his concerns again
at IETF LC, so being crystal clear here might be no
harm.

I'll give folks the weekend to check that and for any
new typos then send the publication request to Pasi.

Thanks all,
Stephen.

John L wrote:
 This addresses the various last call comments.  The changes are all minor 
 editorial ones, nothing large.
 
 Regards,
 John Levine, [EMAIL PROTECTED], Primary Perpetrator of The Internet for 
 Dummies,
 Information Superhighwayman wanna-be, http://www.johnlevine.com, ex-Mayor
 More Wiener schnitzel, please, said Tom, revealingly.
 
 -- Forwarded message --
 Date: Fri, 19 Sep 2008 14:17:07 -0700 (PDT)
 From: IETF I-D Submission Tool [EMAIL PROTECTED]
 To: [EMAIL PROTECTED]
 
 A new version of I-D, draft-ietf-dkim-ssp-06.txt has been successfuly 
 submitted by John Levine and posted to the IETF repository.
 
 Filename:  draft-ietf-dkim-ssp
 Revision:  06
 Title: DKIM Author Domain Signing Practices (ADSP)
 Creation_date: 2008-09-19
 WG ID: dkim
 Number_of_pages: 21
 
 Abstract:
 DomainKeys Identified Mail (DKIM) defines a domain-level
 authentication framework for email to permit verification of the
 source and contents of messages.  This document specifies an adjunct
 mechanism to aid in assessing messages that do not contain a DKIM
 signature for the domain used in the author's address.  It defines a
 record that can advertise whether a domain signs its outgoing mail,
 and how other hosts can access that record.
 
 
 
 The IETF Secretariat.
 
 
 ___
 NOTE WELL: This list operates according to 
 http://mipassoc.org/dkim/ietf-list-rules.html
 
___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

Re: [ietf-dkim] Progressing ADSP (Was: Re: New Version Notification for draft-ietf-dkim-ssp-06 (fwd))

[Stephen Farrell]

Sorry, let me clarify. WGLC is done. I was only interested
in getting +1 to publish or I agree with Doug responses.
We're done with this document.
Thanks,
Stephen.

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

Re: [ietf-dkim] Overview WGLC

[Stephen Farrell]

Stephen Farrell wrote:
 This note is to start WGLC for the overview document. [1]
 
 Given its vacation time, WGLC will run for 4 weeks from
 now, ending on September 3rd.

And this note closes WGLC.

I believe we got the following comment:-

http://mipassoc.org/pipermail/ietf-dkim/2008q3/010672.html

Can the authors respond, to the list if discussion is
needed or with a new I-D for typos etc.

Thanks,
Stephen.
___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

Re: [ietf-dkim] ADSP WGLC

[Stephen Farrell]

Stephen Farrell wrote:
 This note is to start WGLC for the ADSP document. [1]
 
 Given its vacation time, WGLC will run for 4 weeks from
 now, ending on September 3rd.

And this closes WGLC for ADSP.

I think we got the following comments:-

http://mipassoc.org/pipermail/ietf-dkim/2008q3/010671.html
http://mipassoc.org/pipermail/ietf-dkim/2008q3/010673.html
http://mipassoc.org/pipermail/ietf-dkim/2008q3/010675.html

Can the authors respond to those, either to the list or
with a revised I-D for typos etc.

Thanks,
Stephen.
___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

Re: [ietf-dkim] Overview WGLC

[Stephen Farrell]

Douglas Otis wrote:
 
 On Sep 18, 2008, at 8:53 AM, Stephen Farrell wrote:
 


 Stephen Farrell wrote:
 This note is to start WGLC for the overview document. [1]

 Given its vacation time, WGLC will run for 4 weeks from
 now, ending on September 3rd.

 And this note closes WGLC.

 I believe we got the following comment:-

 http://mipassoc.org/pipermail/ietf-dkim/2008q3/010672.html
 
 Stephen,
 
 Is there a reason you have ignored the supporting comment also published
 as a ID.

Yes:-)

 See:
 http://tools.ietf.org/id/draft-otis-dkim-adsp-sec-issues-02.txt

Wrong thread Doug!

Your adsp comment was noted in the other message I sent out
on adsp.

S.


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

[ietf-dkim] Meeting next time

[Stephen Farrell]

Folks,

FYI - I've submitted a meeting request for a 1 hour session and
asked that it not be Monday or Friday.

We can start agendising later, but feel free to let Barry
and I know if you'd like a slot now (and for what and for how
long). If we're looking like 1 hour is too short I can modify
the request on Monday.

Stephen.

PS: I'll start the wrap-up of the WGLC'd docs next week, haven't
had a chance yet. And we also need to start working on the errata,
I'll also kick that next week.


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

[ietf-dkim] ADSP WGLC

[Stephen Farrell]

This note is to start WGLC for the ADSP document. [1]

Given its vacation time, WGLC will run for 4 weeks from
now, ending on September 3rd.

Thanks,
Stephen.

[1] http://tools.ietf.org/wg/dkim/draft-ietf-dkim-ssp/

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

[ietf-dkim] Overview WGLC

[Stephen Farrell]

This note is to start WGLC for the overview document. [1]

Given its vacation time, WGLC will run for 4 weeks from
now, ending on September 3rd.

Thanks,
Stephen.

[1] http://tools.ietf.org/wg/dkim/draft-ietf-dkim-overview/

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

[ietf-dkim] Fuller minutes for last week's meeting.

[Stephen Farrell]

I've expanded on the summary posted earlier at [1]. Please
send any comments by the end of this week (I'll be on
vacation thereafter).

Stephen.

[1] http://www.ietf.org/proceedings/08jul/minutes/dkim.txt

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

[ietf-dkim] Closing issues

[Stephen Farrell]

Eliot,

I believe we can now close all of the issues mentioned in the minutes
just sent out. (Almost all of those were previously flagged for
closure a few weeks ago.)

Can you do that on Friday, just to give people a last chance to check
if I messed up?

Thanks,
Stephen.

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

Re: [ietf-dkim] Issues summary - 20080704

[Stephen Farrell]

Hi Eliot,

Its now past July 11 so since none of these issues has generated
discussion on the list, I think you can close:

1519
1535
1547
1578

These ones did get discussed on the list so let's keep
those open and try resolve them in Dublin.

1543
1575
1571
1576
1579

Stephen.


Stephen Farrell wrote:
 
 The tracker [1] currently lists 31 new/open dkim tickets.
 
 I've spammed you with a mail about each (sorry, but I couldn't
 figure a better way). A summary of the dispositions is attached.
 
 If you care about any of these to-be-closed issues, you
 should check before the relevant date, either July 11
 or else a week after overview-10 issues, otherwise they'll
 be closed.
 
 As of now, that'd leave us with 4 open issues; 2 on the
 overview, and 1 each on ADSP and the deployment guide.
 
 Please do bear in mind that we want to get done with the
 overview and ADSP so I'd ask that you restrict your comments
 on these to things that really do need fixing.
 
 Barry and I will look at the more recent list traffic on
 ssp-04 during the next week or so and will ask Eliot to
 create new issues as appropriate (or not, depending), so
 if there's something that's not been discussed before that
 you think should get through that filter, please post to
 the list, or if its been on the list, but isn't in the
 tracker just send a mail to the chairs.
 
 Regards,
 Stephen.
 
 [1] https://rt.psg.com/ login is ietf/ietf queue is dkim
 
 
 
 
 ___
 NOTE WELL: This list operates according to 
 http://mipassoc.org/dkim/ietf-list-rules.html
___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

[ietf-dkim] [Fwd: Upcoming Jabber Server Load Test]

[Stephen Farrell]

If you're about tomorrow, you might want to fire up your jabber
client and see if we break something or not:-)

If it works, I might see you in the dkim room then,
S.

---BeginMessage---
We recently deployed a new IETF Jabber server (ejabbered) and we would like
to load test it before the Dublin meeting. This coming Tuesday, July 15 at
10am PT (1PM ET and 5pm GMT) you are officially invited to log into the IETF
Jabber Hallway or various WG Chatrooms and chat with your fellow community
members. We will be monitoring the performance of the server from 10-11am
PT, so the more people online and using the Jabber Chatrooms the better.

For more information about the IETF Jabber services, please see here:
http://jabber.ietf.org/

Thank you,
Alexa

---
Alexa Morris / Executive Director / IETF
48377 Fremont Blvd., Suite 117, Fremont, CA  94538
Phone: +1.510.492.4089 / Fax: +1.510.492.4001
Email: [EMAIL PROTECTED]

Managed by Association Management Solutions (AMS)
Forum Management, Meeting and Event Planning
www.amsl.com http://www.amsl.com/



___
Ietf mailing list
[EMAIL PROTECTED]
https://www.ietf.org/mailman/listinfo/ietf
---End Message---
___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

Re: [ietf-dkim] New version -- draft-ietf-dkim-overview-10

[Stephen Farrell]

Thanks Dave,

So this starts the clock on all those overview  + 1 week issues
I posted before. I'll ask Eliot to close those that see no discussion
by July 21.

Stephen.

Dave Crocker wrote:
 Folks,
 
 New version of the Service Overview has been posted to Internet Drafts.
 
 Various formats and diffs are at:
 
http://dkim.org/ietf-dkim.htm#overview
 
 This draft is intended to close all open 'issues' concerning the Overview.  
 (All 
 issues that have the word 'overview' in the subject.)
 
 Every issue was reviewed and considered carefully.  If you see a change that 
 was 
 not made or not made to your satisfaction, and you wish to pursue the matter 
 further, please do raise it with the working group.
 
 /d
___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

Re: [ietf-dkim] identity vs domain, battles of years past, and bot-nets.

[Stephen Farrell]

Douglas Otis wrote:
 This is a tragedy.

This is not the time for any kind of drama for ADSP, whether
in 3 acts or not;-)

If you have a concrete proposal please send exact text that
can be edited into the document.

I'd ask people to not debate this (again) in the absence of
both a) such a concrete proposal *and* b) declared support
for that proposal from at least a few other participants.

Thanks,
Stephen.

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

Re: [ietf-dkim] Issue 1576: Revise wildcard discussion

[Stephen Farrell]

So, trying to get to closure on this, rather than go
'round and 'round. There seem to be 3 things being
discussed here, as listed below.

Even if you disagree and think there's a 4th thing - please
hold your fire until we bottom out on these three.

We'd like to close out on these things by Friday (11th) so
if you do care, you need to suggest text asap. If some
suggested text seems to be getting a bunch of +1's then we
won't be v. strict about that deadline, but if nothing is
getting support then I think we'll declare victory on this
one then.

Thing 1:

Charles Lindsey (and others) wrote (things like):
 Having all genuine ADSP records  
 start with some string such as dkim= will make such checks easier  
 (though not foolproof because even a randomly created TXT record could  
 start with dkim-, though with low probability :-) ).

I think the counter John is making is that parsing the entire
ADSP record is equally easy, so his argument as I read it is that
the above is an optimization that isn't worthwhile.

Is it really significantly better/easier to check starts-with(dkim=)
rather than matches(the-ABNF-from-4.2.1)? The ABNF from 4.2.1. is:
 adsp-dkim-tag = %x64.6b.69.6d *FWS = *FWS
 (unknown / all / discardable)

(If responding, please ignore the [FWS] vs. *FWS issue.)

If you think the optimization is worthwhile, please post
text (and not discussion) and we'll see if that gets +1's
or -1's or gets ignored (at this stage I think the latter
two are the same). If you do post text for that please put
dkim= in the subject as well as 1576.

Thing 2:

Currently ssp-04 says that ADSP records use the tag=value
syntax... and also says that only one ADSP record is to be
published.

So if that means that records returned because of wildcards that
don't match eactly one instance of the ABNF are ignored then we seem
to be ok. If however, the current text isn't explicit enough about
how to handle records that don't parse correctly, or multiple records
then maybe there's more to say.

If you think there is, then please post text (and not discussion)
and we'll see if that gets +1's or -1's or gets ignored (at this
stage I think the latter two are the same).  If you do post text
for that please put handling in the subject as well as 1576.

Thing 3:

The last thing that seems to be involved in this thread is a
concern that the current description of the dangers of wildcards
is not sufficiently well explained. If you think that that is
the case then please post text (and not discussion)
and we'll see if that gets +1's or -1's or gets ignored (at this
stage I think the latter two are the same). If you do post text
for that please put caveats in the subject as well as 1576.

Thanks,
S.


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

Re: [ietf-dkim] Issue 1576: dkim= no optimisation required

[Stephen Farrell]

Sorry, Bill, I meant to ask those who wanted change to
propose new text. In each case if the new text proposed
gets a sufficient bunch of +1's then we go from there,
but if not, we stay as-is.

Stephen.

[EMAIL PROTECTED] wrote:
 
 -Original Message-
 From: [EMAIL PROTECTED]
 [mailto:[EMAIL PROTECTED] On Behalf Of Stephen Farrell
 Sent: Tuesday, July 08, 2008 6:52 AM
 To: DKIM
 Subject: Re: [ietf-dkim] Issue 1576: Revise wildcard discussion
 
 
 So, trying to get to closure on this, rather than go
 'round and 'round. There seem to be 3 things being
 discussed here, as listed below.
 
 Even if you disagree and think there's a 4th thing - please
 hold your fire until we bottom out on these three.
 
 We'd like to close out on these things by Friday (11th) so
 if you do care, you need to suggest text asap. If some
 suggested text seems to be getting a bunch of +1's then we
 won't be v. strict about that deadline, but if nothing is
 getting support then I think we'll declare victory on this
 one then.
 
 Thing 1:
 
 Charles Lindsey (and others) wrote (things like):
 Having all genuine ADSP records  
 start with some string such as dkim= will make such checks easier  
 (though not foolproof because even a randomly created TXT record could
 
 start with dkim-, though with low probability :-) ).
 
 I think the counter John is making is that parsing the entire
 ADSP record is equally easy, so his argument as I read it is that
 the above is an optimization that isn't worthwhile.
 
 Is it really significantly better/easier to check starts-with(dkim=)
 rather than matches(the-ABNF-from-4.2.1)? The ABNF from 4.2.1. is:
  adsp-dkim-tag = %x64.6b.69.6d *FWS = *FWS
  (unknown / all / discardable)
 
 (If responding, please ignore the [FWS] vs. *FWS issue.)
 
 If you think the optimization is worthwhile, please post
 text (and not discussion) and we'll see if that gets +1's
 or -1's or gets ignored (at this stage I think the latter
 two are the same). If you do post text for that please put
 dkim= in the subject as well as 1576.
 
 Thing 2:
 
 Currently ssp-04 says that ADSP records use the tag=value
 syntax... and also says that only one ADSP record is to be
 published.
 
 So if that means that records returned because of wildcards that
 don't match eactly one instance of the ABNF are ignored then we seem
 to be ok. If however, the current text isn't explicit enough about
 how to handle records that don't parse correctly, or multiple records
 then maybe there's more to say.
 
 If you think there is, then please post text (and not discussion)
 and we'll see if that gets +1's or -1's or gets ignored (at this
 stage I think the latter two are the same).  If you do post text
 for that please put handling in the subject as well as 1576.
 
 Thing 3:
 
 The last thing that seems to be involved in this thread is a
 concern that the current description of the dangers of wildcards
 is not sufficiently well explained. If you think that that is
 the case then please post text (and not discussion)
 and we'll see if that gets +1's or -1's or gets ignored (at this
 stage I think the latter two are the same). If you do post text
 for that please put caveats in the subject as well as 1576.
 
 Thanks,
 S.
 
 
 ___
 NOTE WELL: This list operates according to 
 http://mipassoc.org/dkim/ietf-list-rules.html
 
___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

Re: [ietf-dkim] Issue 1579: ADSP result set, New issue: ADSP status codes

[Stephen Farrell]

Frank,

I'm not clear if you're saying that this remains an open
issue or not or whether you're raising new issues or what.
Can you clarify?

Thanks,
Stephen.

Frank Ellermann wrote:
 Stephen Farrell wrote:
  
 The suggestion (I think) is to define three possible
 ADSP results (open/closed/locked).
 
 Yeah, my part in that was mostly focussed on there is
 no worse name than 'discradable', therefore 'locked' 
 might be better.
 
 ssp-04 doesn't do that - it lists 4 possible results,
 but doesn't give those specific names.
 
  [3.3]
 | All messages from this domain are signed and discardable.
 
 Even if you stick to discardable that is certainly not
 what you want.  Maybe [...] are either signed or [...}
 
  [4.2.1]
 |  adsp-dkim-tag = %x64.6b.69.6d *FWS = *FWS
 | (unknown / all / discardable)
 
 digression
  Never, under no circumstances, allow more than one FWS,
  a single optional [FWS] is bad enough in DNS.  More than
  one introduces the miracles of apparently empty lines
  consisting entirely of semantically significant white
  space.  
 
  Submitted as 4871 erratum - normally I'd say editorial,
  but the other reported DKIM ABNF nits say technical.
 /digression
 
 ssp-04 still says discardable, and maybe it passes IETF
 review for status experimental.  But spp-04 clearly says
 standards track, and does not mention Resent-* anywhere.
 
 For receivers rejecting suspicious mails the draft should
 note the relevant SMTP reply and extended error code with
 a reference to RFC 5248.  
 
  Frank
 
 ___
 NOTE WELL: This list operates according to 
 http://mipassoc.org/dkim/ietf-list-rules.html
 
___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

Re: [ietf-dkim] Issue 1576: Revise wildcard discussion

[Stephen Farrell]

Can I ask those who think that the current text is not sufficient
to please suggest alternative text?

Thanks,
S.

PS: Eliot - since this one has attracted discussion, it should not
be closed by default on July 11.


John Levine wrote:
  A simple MUST start with 'dkim=' (or similar) could fix it.
 But to what end?  In what circumstance would a wildcard that stops at an 
 existing label be at all useful?  This is where I have been bashing my head.
 
 Let's pretend that we want to try to tell the world that we don't send
 mail from all the subdomains we don't send mail from:
 
 *.foo.com. mx 0 . ; MX says no mail
 *.foo.com. txt v=spf1 -all; SPF says no mail
 *.foo.com. txt spf2.0/mfrom,pra -all  ; Sender ID says no mail
 *.foo.com. txt dkim=discardable   ; ADSP says no mail
 
 So you can look up the MX or TXT for plugh.foo.com and get answers,
 and you can also look up _adsp._domainkey.plugh.foo.com, only you get
 the same answers.
 
 Plan A: forget that silly prefixed name stuff and add yet another
 magic string to tell our records apart from the other umpteen strings
 that will soon overflow our 512 byte buffer.
 
 Plan B: note that DNS wildcards, once again, don't do what you want
 particularly when prefixed names are involved.  This issue is not
 unique to ADSP and affects DKIM keys as well.
 
 I believe we chose Plan B.
 
 R's,
 John
 
 ___
 NOTE WELL: This list operates according to 
 http://mipassoc.org/dkim/ietf-list-rules.html
 
___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html