Re: Last Call: draft-kucherawy-dkim-atps-11.txt (DKIM Authorized Third-Party Signers) to Experimental RFC
I support adoption of dkim-atps as an experimental RFC. It would have been clearer to use the term Author-Domain rather than Author. Clearly, it is not the Author offering Authorization. -Doug ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Last Call: draft-kucherawy-dkim-atps-11.txt (DKIM Authorized Third-Party Signers) to Experimental RFC
-Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Douglas Otis Sent: Thursday, December 08, 2011 10:12 AM To: ietf@ietf.org Subject: Re: Last Call: draft-kucherawy-dkim-atps-11.txt (DKIM Authorized Third-Party Signers) to Experimental RFC I support adoption of dkim-atps as an experimental RFC. It would have been clearer to use the term Author-Domain rather than Author. Clearly, it is not the Author offering Authorization. This has already been fixed in the working copy, which I'll post after the IETF LC closes. -MSK ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Last Call: draft-kucherawy-dkim-atps-11.txt (DKIM Authorized Third-Party Signers) to Experimental RFC
-Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of John Levine Sent: Sunday, December 04, 2011 1:28 PM To: ietf@ietf.org Cc: dcroc...@bbiw.net Subject: Re: Last Call: draft-kucherawy-dkim-atps-11.txt (DKIM Authorized Third-Party Signers) to Experimental RFC ADSP already dictates use of the From: domain. ATPS is a modification to ADSP. It doesn't change anything that DKIM reports, only the rule for deciding whether ADSP finds an Author Domain Signature. ATPS can be applied without ADSP by a Verifier that cares about author domain signatures in its own way, so it's not a direct modification to ADSP. But there is a section that discusses how they work in tandem. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-kucherawy-dkim-atps-11.txt (DKIM Authorized Third-Party Signers) to Experimental RFC
On 12/4/2011 1:27 PM, John Levine wrote: ADSP already dictates use of the From: domain. The the nature ADSP's use of the From: domain is fundamentally different from ATPS' use. Broadly, we can distinguish: Name extraction:determining what name is being claimed Name verification: determining that the use of the name is authorized Name assessment:determining whether the name is associated with good or bad actor. ADSP adds a constraint on name verification; it mandates that at least one DKIM d= name match the domain in the From: field. ATPS essentially modifies name extraction, by making it a two-step process. The first step is the usual one, with d=, for use with validation, but the second one takes the domain in the From: field and makes it the output string to the assessment process. ATPS is a modification to ADSP. It doesn't change anything that DKIM reports, only the rule for deciding whether ADSP finds an Author Domain Signature. While yes it has text pertaining to ADSP, I will claim that with ADSP, too, the modification is in name extraction rather than validation or assessment. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-kucherawy-dkim-atps-11.txt (DKIM Authorized Third-Party Signers) to Experimental RFC
On 11/30/2011 1:03 PM, Barry Leiba wrote: In plain English, this reads as an update of ADSP but this draft does not update RFC 5617. It does not. There's no reason that anyone implementing ADSP need pay attention to this.*IF* you implement this, it might change your behaviour with respect to ADSP, but information about that is contained here. There's no reason for this to update 5617 in the IETF sense. I think Barry's characterization is correct. The word update can have some different uses in this realm. In IETF RFC formal lingo, I believe update means that the new spec is modifying the core document. It really is, therefore, to be taken as part of that core document's text. In a very different sense, some specification provide optional value-add to a core spec. Using that enhancement is optional; so it's no part of the core. However, if one chooses to use the enhancement, then yes the enhancements updates some aspect of the core. I believe that ATPS is the latter form of update to DKIM and ADSP. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-kucherawy-dkim-atps-11.txt (DKIM Authorized Third-Party Signers) to Experimental RFC
ATPS essentially modifies name extraction, by making it a two-step process. The first step is the usual one, with d=, for use with validation, but the second one takes the domain in the From: field and makes it the output string to the assessment process. If you're referring to the second paragraph in section 5, I agree that the second sentence should go, or at least be rewritten to clarify that the client is supposed to pretend that the message passed ADSP. If it's anything else in atps-11, you'll have to help me out with references to specific language. R's, John ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Last Call: draft-kucherawy-dkim-atps-11.txt (DKIM Authorized Third-Party Signers) to Experimental RFC
-Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of John R. Levine Sent: Monday, December 05, 2011 5:25 PM To: Dave Crocker Cc: ietf@ietf.org Subject: Re: Last Call: draft-kucherawy-dkim-atps-11.txt (DKIM Authorized Third-Party Signers) to Experimental RFC If you're referring to the second paragraph in section 5, I agree that the second sentence should go, or at least be rewritten to clarify that the client is supposed to pretend that the message passed ADSP. If it's anything else in atps-11, you'll have to help me out with references to specific language. But that's what Section 6 says. Section 5 is for those people that do DKIM without ADSP but care about giving author domain signatures preferential treatment. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-kucherawy-dkim-atps-11.txt (DKIM Authorized Third-Party Signers) to Experimental RFC
Section 5 is for those people that do DKIM without ADSP but care about giving author domain signatures preferential treatment. Since there's nothing in the DKIM spec that suggests that's a correct way to use DKIM, I'd be fairly unhappy about any language that purports to legitimize it. Here in standards-land, if you think that author domain signatures matter, you're supposed to use ADSP. R's, John ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Last Call: draft-kucherawy-dkim-atps-11.txt (DKIM Authorized Third-Party Signers) to Experimental RFC
-Original Message- From: Rolf E. Sonneveld [mailto:r.e.sonnev...@sonnection.nl] Sent: Saturday, December 03, 2011 4:49 AM To: Murray S. Kucherawy Cc: ietf@ietf.org Subject: Re: Last Call: draft-kucherawy-dkim-atps-11.txt (DKIM Authorized Third-Party Signers) to Experimental RFC Hi, Murray, having read the draft I support its publication as experimental RFC. One suggestion: under 'Security Considerations' add a reference to what is said about DNSSEC in RFC6376 par. 8.5. In my opinion, the same consideration applies for this ATPS document. Thanks; I've added that to the working copy. Cheers, -MSK ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Last Call: draft-kucherawy-dkim-atps-11.txt (DKIM Authorized Third-Party Signers) to Experimental RFC
-Original Message-
From: Dave CROCKER [mailto:d...@dcrocker.net]
Sent: Saturday, December 03, 2011 10:38 AM
To: Murray S. Kucherawy
Cc: ietf@ietf.org
Subject: Re: Last Call: draft-kucherawy-dkim-atps-11.txt (DKIM Authorized
Third-Party Signers) to Experimental RFC
So I suggest for the Abstract:
This specification modifies Domain Keys
Identified Mail (DKIM) by allowing advertisement of third-party
signature authorizations that are to be interpreted as equivalent to a
signature by the administrative domain of a message's author. The
supplement
initially has Experimental status.
(I think it's important for an Abstract to summarize the core
semantic.)
I'm a little worried about using this kind of language in something
Experimental when referencing a Draft Standard. My understanding is that the
former can't formally modify the latter. So instead of This specification
modifies, I'd be comfortable with This experimental specification proposes a
modification to, or suchlike. Should it earn its way up to the Standards
Track, your wording would be adopted.
I also suggest:
3. Discussion
...
o Signers, who send mail on behalf of Authors and apply [DKIM]
signatures using their own domains; and
-
o Signer, which applies a [DKIM] signature using its own domain,
but on behalf of the message's Author ADMD; and
OK.
{ Stylistically, I find that specification text is easier when things
are written in the singular. So I suggest author (ADMD), signer and
verifier, rather than their plural form. }
I would agree, but in fact when ATPS is in use there are at least two ADMDs and
there may be multiple signers involved for a single verifier, so the plural
seems more illustrative here.
A Verifier participates in this protocol if it wishes to ensure that
a message bears one or more signatures from sources approved to sign
mail on behalf of the Author, and identify for special treatment mail
that meets (or does not meet) that criterion.
-
A Verifier participating in this protocol treats the signer's
authorization on behalf of the author's ADMD as meaning that the signer's
signature is equivalent to a signature by the author's ADMD.
That ascribes semantics that are discussed later. This section is really
trying to describe the potential audience first, leaving an actual description
of the mechanism for later. So I'd prefer a merge of the two, something like:
t A Verifier participates in this protocol if it wishes
to ensure that a message bears one or more signatures
from sources authorized to sign mail on behalf of the
ADMD, and identify for special treatment mail
that meets (or does not meet) that criterion. It
will do so by treating the signer's authorization on
behalf of the author's ADMD as meant that the signer's
signature is equivalent to one affixed by the
author's ADMD. /t
On re-reading, I think this also warrants an enhanced statement in the
Introduction (roughly from the view that an Introduction expands on the
Abstract.)
So:
Absent is a protocol by which an ADMD can announce that DKIM
signatures on its mail added by other ADMDs should also be considered
trustworthy by verifiers. This memo presents an experimental
mechanism for doing so.
-
Absent is a protocol by which an Author ADMD can announce that specific
DKIM signatures on its mail, which are added by other ADMDs, are to
treated the same as a signature by the Author ADMD itself. This memo
presents an experimental mechanism for doing so.
OK.
{BTW, the document should be sanitized of normative vocabulary that is
not meant to be normative. That is, replace should, must and may with
synonyms. }
Done.
Thinking a bit more about this, actually, I think it is.
With a normal DKIM signature, the d= string is taken as the output to the
higher-level module that then makes whatever reputation (or the like)
assessment
that is to be performed.
With ATPS, the requirement is to replace the d= string with the domain name
from
the From: field. That replacement value is then passed to the
assessment module.
In other words, DKIM provides it's own identifier to be used for assessment,
whereas ATPS dictates use of the From: field domain name for
assessment.
That's a fundamental change in semantics.
If you are using ATPS, sure. So ATPS augments DKIM's semantics if you're using
it. But I don't think it's reasonable to say this is any kind of update to
DKIM itself, at least not in the way the IETF uses the term Updates as it
refers to RFCs.
At any rate, I think this draft already does make it clear that it's doing
something quite beyond what DKIM
Re: Last Call: draft-kucherawy-dkim-atps-11.txt (DKIM Authorized Third-Party Signers) to Experimental RFC
With ATPS, the requirement is to replace the d= string with the domain name from the From: field. That replacement value is then passed to the assessment module. In other words, DKIM provides it's own identifier to be used for assessment, whereas ATPS dictates use of the From: field domain name for assessment. At least one of us is confused here. ADSP already dictates use of the From: domain. ATPS is a modification to ADSP. It doesn't change anything that DKIM reports, only the rule for deciding whether ADSP finds an Author Domain Signature. With or without ADSP or ATPS, DKIM returns a possibly empty list of d= domains from valid signatures. ADSP returns the practices value (unknown/all/discardable) and a bit whether it found an Author Domain signature. Since there might be multiple DKIM signatures, even if ADSP says it found an Author Domain signature, you can't assume a d= domain had any relationship to the From: domain. It's true that ATPS adds a field to DKIM signatures that doesn't affect DKIM evaluation, but DKIM already knows how to skip over fields it doesn't understand. R's, John ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Last Call: draft-kucherawy-dkim-atps-11.txt (DKIM Authorized Third-Party Signers) to Experimental RFC
-Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Dave CROCKER Sent: Friday, December 02, 2011 3:59 PM To: SM Cc: ietf@ietf.org Subject: Re: Last Call: draft-kucherawy-dkim-atps-11.txt (DKIM Authorized Third-Party Signers) to Experimental RFC On 11/30/2011 12:34 PM, SM wrote: Readers should be familiar with the material and terminology discussed in [MAIL] and [EMAIL-ARCH]. The references to RFC 5598 and RFC 5322 should be normative. Arguably, they already are: the text says should and that's a normative term in the document... (but no, I doubt Murray, really intended it and for some odd reason, I agree both docs /should/ be normative...) Yes, I've already changed my working copy. In Section 3: An Author participates in this protocol if it wishes to announce that a message from it (in the RFC5322.From sense) should be considered authentic as long as it bears a signature from any in a set of specified domains. It's the domain and not the author which participates in this protocol. +1 [...] The working copy now uses ADMD. The Abstract section uses the term authorization whereas authentic is used in the above text. Shouldn't that be considered as authorized? +1 on the concern about using the correct term. The document needs to be much more clear and precise about this, since it is the essential semantic behind the spec and I think the current text is a bit confusing in that regard. SM and I agreed that changing it to authorized and also making reference to Section 1.5.2 of RFC5451 for a bit of further explanation should make it clearer, so that's done in the working copy. Does a signature by this on behalf of signer mean something different from a regular DKIM signature? It appears the current text means the answer to be yes. Correct, inasmuch as there are some people in the community who think author domain signatures might be more important or valuable than others. This memo doesn't make such an assertion, but merely acknowledges that perception. It should say this explicitly. If it is not redefining the existing, core DKIM semantic, it should say so. If it /is/ changing basic DKIM semantics, then this is more than an extension to DKIM. It is not. Section 1 of this draft reiterates that DKIM's core semantics don't extend to any kind of binding of the delivered, validated domain name to any part of the message. However, there are some people who believe that such a binding is valid and useful. This draft is meant for those people, without altering DKIM's base semantics. I suggest that the incremental semantic should merely be that the signature by an authorized signer should be interpreted as if the signature had been by the authorizing domain. It's a simple semantic and is, frankly, what I think is intended, based on the discussions surrounding this mechanism that I've heard. This is stated in Sections 5 and 6. In plain English, this reads as an update of ADSP but this draft does not update RFC 5617. +1 The definition used for Updates, as I understand it, is that we say X updates Y if someone implementing X really needs also to read Y in order to implement X completely. I don't think that's true here. In this case, RFC5617 stands on its own just fine without this addition. If I should be using some other criteria for doing the Updates, please let me know. The IANA Considerations section is unusual. If no action is required at this time, the sub-sections are not needed. I suggest updating the DKIM- Signature Tag Specification Registry for the tags as they will appear on the Internet. +1 The working copy already has this change; specifically, Section 8.1 is still the template for a future registry creation, but the remaining subsections are now actionable by IANA. -MSK ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-kucherawy-dkim-atps-11.txt (DKIM Authorized Third-Party Signers) to Experimental RFC
Hi, Murray, having read the draft I support its publication as experimental RFC. One suggestion: under 'Security Considerations' add a reference to what is said about DNSSEC in RFC6376 par. 8.5. In my opinion, the same consideration applies for this ATPS document. /rolf On 12/3/11 9:32 AM, Murray S. Kucherawy wrote: -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Dave CROCKER Sent: Friday, December 02, 2011 3:59 PM To: SM Cc: ietf@ietf.org Subject: Re: Last Call:draft-kucherawy-dkim-atps-11.txt (DKIM Authorized Third-Party Signers) to Experimental RFC On 11/30/2011 12:34 PM, SM wrote: Readers should be familiar with the material and terminology discussed in [MAIL] and [EMAIL-ARCH]. The references to RFC 5598 and RFC 5322 should be normative. Arguably, they already are: the text says should and that's a normative term in the document... (but no, I doubt Murray, really intended it and for some odd reason, I agree both docs /should/ be normative...) Yes, I've already changed my working copy. In Section 3: An Author participates in this protocol if it wishes to announce that a message from it (in the RFC5322.From sense) should be considered authentic as long as it bears a signature from any in a set of specified domains. It's the domain and not the author which participates in this protocol. +1 [...] The working copy now uses ADMD. The Abstract section uses the term authorization whereas authentic is used in the above text. Shouldn't that be considered as authorized? +1 on the concern about using the correct term. The document needs to be much more clear and precise about this, since it is the essential semantic behind the spec and I think the current text is a bit confusing in that regard. SM and I agreed that changing it to authorized and also making reference to Section 1.5.2 of RFC5451 for a bit of further explanation should make it clearer, so that's done in the working copy. Does a signature by this on behalf of signer mean something different from a regular DKIM signature? It appears the current text means the answer to be yes. Correct, inasmuch as there are some people in the community who think author domain signatures might be more important or valuable than others. This memo doesn't make such an assertion, but merely acknowledges that perception. It should say this explicitly. If it is not redefining the existing, core DKIM semantic, it should say so. If it /is/ changing basic DKIM semantics, then this is more than an extension to DKIM. It is not. Section 1 of this draft reiterates that DKIM's core semantics don't extend to any kind of binding of the delivered, validated domain name to any part of the message. However, there are some people who believe that such a binding is valid and useful. This draft is meant for those people, without altering DKIM's base semantics. I suggest that the incremental semantic should merely be that the signature by an authorized signer should be interpreted as if the signature had been by the authorizing domain. It's a simple semantic and is, frankly, what I think is intended, based on the discussions surrounding this mechanism that I've heard. This is stated in Sections 5 and 6. In plain English, this reads as an update of ADSP but this draft does not update RFC 5617. +1 The definition used for Updates, as I understand it, is that we say X updates Y if someone implementing X really needs also to read Y in order to implement X completely. I don't think that's true here. In this case, RFC5617 stands on its own just fine without this addition. If I should be using some other criteria for doing the Updates, please let me know. The IANA Considerations section is unusual. If no action is required at this time, the sub-sections are not needed. I suggest updating the DKIM- Signature Tag Specification Registry for the tags as they will appear on the Internet. +1 The working copy already has this change; specifically, Section 8.1 is still the template for a future registry creation, but the remaining subsections are now actionable by IANA. -MSK ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-kucherawy-dkim-atps-11.txt (DKIM Authorized Third-Party Signers) to Experimental RFC
On 12/3/2011 12:32 AM, Murray S. Kucherawy wrote:
Does a signature by this on behalf of signer mean something different
from a regular DKIM signature? It appears the current text means the
answer to be yes.
Correct, inasmuch as there are some people in the community who think author
domain signatures might be more important or valuable than others. This memo
doesn't make such an assertion, but merely acknowledges that perception.
Understood. I meant the this as a writing question; the meaning wasn't clear to
me and I think it needs to be easily clear to the reader.
So I suggest for the Abstract:
This specification modifies Domain Keys
Identified Mail (DKIM) by allowing advertisement of third-party
signature authorizations that are to be interpreted as equivalent to a
signature by the administrative domain of a message's author. The supplement
initially has Experimental status.
(I think it's important for an Abstract to summarize the core semantic.)
Also, the original text said 'originator' and I think you don't mean that, since
that equates to the Sender: field and not the From: field, per RFC 5598.
I also suggest:
3. Discussion
...
o Signers, who send mail on behalf of Authors and apply [DKIM]
signatures using their own domains; and
-
o Signer, which applies a [DKIM] signature using its own domain,
but on behalf of the message's Author ADMD; and
{ Stylistically, I find that specification text is easier when things are
written in the singular. So I suggest author (ADMD), signer and verifier,
rather than their plural form. }
and
A Verifier participates in this protocol if it wishes to ensure that
a message bears one or more signatures from sources approved to sign
mail on behalf of the Author, and identify for special treatment mail
that meets (or does not meet) that criterion.
-
A Verifier participating in this protocol treats the signer's
authorization on behalf of the author's ADMD as meaning that the signer's
signature is equivalent to a signature by the author's ADMD.
That is, I'm pressing for having this semantic made clear more than once in the
document, even though it needs formal, normative assertion only once (of course).
On re-reading, I think this also warrants an enhanced statement in the
Introduction (roughly from the view that an Introduction expands on the Abstract.)
So:
Absent is a protocol by which an ADMD can announce that DKIM
signatures on its mail added by other ADMDs should also be considered
trustworthy by verifiers. This memo presents an experimental
mechanism for doing so.
-
Absent is a protocol by which an Author ADMD can announce that specific
DKIM signatures on its mail, which are added by other ADMDs, are to
treated the same as a signature by the Author ADMD itself. This memo
presents an experimental mechanism for doing so.
{BTW, the document should be sanitized of normative vocabulary that is not meant
to be normative. That is, replace should, must and may with synonyms. }
It should say this explicitly. If it is not redefining the existing,
core DKIM semantic, it should say so. If it /is/ changing basic DKIM
semantics, then this is more than an extension to DKIM.
It is not.
Thinking a bit more about this, actually, I think it is.
With a normal DKIM signature, the d= string is taken as the output to the
higher-level module that then makes whatever reputation (or the like) assessment
that is to be performed.
With ATPS, the requirement is to replace the d= string with the domain name from
the From: field. That replacement value is then passed to the assessment module.
In other words, DKIM provides it's own identifier to be used for assessment,
whereas ATPS dictates use of the From: field domain name for assessment.
That's a fundamental change in semantics.
Section 1 of this draft reiterates that DKIM's core semantics don't extend
toany kind of binding of the delivered, validated domain name to any part of the
message. However, there are some people who believe that such a binding is valid
and useful. This draft is meant for those people, without altering DKIM's base
semantics.
ack.
I suggest that the incremental semantic should merely be that the
signature by an authorized signer should be interpreted as if the
signature had been by the authorizing domain.
It's a simple semantic and is, frankly, what I think is intended, based
on the discussions surrounding this mechanism that I've heard.
This is stated in Sections 5 and 6.
Indeed, they do.
And while we're in Section 5 (DKIM): the SHOULD needs to be a MUST.
With respect to DKIM itself, this new mechanism has one simple semantic: Use
the domain name in the From: field as the output. That's not optional and
that's not modifiable. If the verifier is playing in the ATPS sandbox, that's
the single immutable requirement.
With respect to
Re: Last Call: draft-kucherawy-dkim-atps-11.txt (DKIM Authorized Third-Party Signers) to Experimental RFC
Dave CROCKER wrote: On 11/30/2011 8:09 PM, Murray S. Kucherawy wrote: As the draft says, the point is to make the idea available and see if it sticks to anyone or anything. If the bulk senders (or receivers) do decide they collectively want this, there's something for them to try and report back. if one thinks the mechanism is a bad idea, it's still worth having a good document to describe it.l The usual people with DKIM continue to utterly surprise me. #1 The Author Domain verification was always in DKIM since its conception, especially as a selling and marketing point, in its presentations, and its description to news rags publishers. It was sold DKIM to me as a proof of concept. #2 It was burned into the APIs available. #3 It was burned into your DKIM Architectural Framework RFC5585 and it even included nice pretty ASCII-ART pictures that I am sure you are proud of: | |- RFC5322 Message V ++ | Message Signed? | +-++-+ |yes |no | | |SDID/AUID|AUID | | V | +-+ SDID/AUID | | Verify +-+ | | Signature | | | +--+--+ | | pass|fail| | V| | +-+ | | |SDID | | | | Assessments | | | | | V V +-+--++ +---+ || / Check \ |+--SDID--/ Signing \ | / Practices \ |+---+---+ || VV The issue was always how to implement it for 3rd party Signers once the DKIM mindset in its eventual RFC changed to a 3rd party signer TRUST vendor and vainly tried unsuccessfully to remove the Author Domain from the DKIM picture. The methods for 3rd party Authorization were long conceived and the only problem was how to scale it in DNS. This I-D simply took and existing idea of having an Authorized Signer List (ASL) and offers a way to scale it. We are probably the only vendor in the market to actively supports both the ASL idea and the ATPS idea. This is a web-based wizard we provided to customers before an internal version was provided: http://www.winserver.com/public/wcadsp/default.wct It allows for DKIM author domains to create DNS records with ASL tags for ADSP records and also add ATPS sub-domain records with the BASE32 hash of the ASL domains. The bottom line, the proof of concept works, just like it always did since it Author Domain validation was originally conceived in DKIM v1.0.The ASL and ATPS ideas simply offers a way to address the long time issues of the 3rd party signer. The idea is good for the smaller scale. For the larger scale, it still remains a problem. Implementation wise, it is very complex and unless the DKIM system offers the automation tools, its harder to get the layman operator to begin doing it on its own. After all, with ATPS, you have to get a utility to do the BASE32 hashing. Finally, the public Wizard focused on Windows based records, a real one has to cover both and its needs to be BATCH so that any updates are automatically and/or delayed updated in the DNS server databases. i.e. individual updating was not good enough. Thanks -- Hector Santos, CTO http://www.santronics.com ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-kucherawy-dkim-atps-11.txt (DKIM Authorized Third-Party Signers) to Experimental RFC
On 11/30/2011 12:34 PM, SM wrote: Readers should be familiar with the material and terminology discussed in [MAIL] and [EMAIL-ARCH]. The references to RFC 5598 and RFC 5322 should be normative. Arguably, they already are: the text says should and that's a normative term in the document... (but no, I doubt Murray, really intended it and for some odd reason, I agree both docs /should/ be normative...) In Section 3: An Author participates in this protocol if it wishes to announce that a message from it (in the RFC5322.From sense) should be considered authentic as long as it bears a signature from any in a set of specified domains. It's the domain and not the author which participates in this protocol. +1 Domain-based identification roughly equates to organizational, not personal, actors. Although the document appears to define the term Author precisely and use it consistently within the document, the particular label that's been chosen is likely to encourage confusion with the reader who will think that author means the /person/ that wrote the message. Alternative terms to consider: Author Domain Organization Administrative Domain (ADMD) The Abstract section uses the term authorization whereas authentic is used in the above text. Shouldn't that be considered as authorized? +1 on the concern about using the correct term. The document needs to be much more clear and precise about this, since it is the essential semantic behind the spec and I think the current text is a bit confusing in that regard. Does a signature by this on behalf of signer mean something different from a regular DKIM signature? It appears the current text means the answer to be yes. It should say this explicitly. If it is not redefining the existing, core DKIM semantic, it should say so. If it /is/ changing basic DKIM semantics, then this is more than an extension to DKIM. I suggest that the incremental semantic should merely be that the signature by an authorized signer should be interpreted as if the signature had been by the authorizing domain. It's a simple semantic and is, frankly, what I think is intended, based on the discussions surrounding this mechanism that I've heard. In Section 6: A Verifier implementing both ADSP and ATPS SHOULD treat a message for which the ATPS test described above passes as if it were signed by the author domain. That is, a pass of ATPS means a pass for ADSP. In plain English, this reads as an update of ADSP but this draft does not update RFC 5617. +1 In Section 8: No actions are required by IANA at this time. The following need only be applied if and when this specification reaches the Standards Track. The IANA Considerations section is unusual. If no action is required at this time, the sub-sections are not needed. I suggest updating the DKIM-Signature Tag Specification Registry for the tags as they will appear on the Internet. +1 d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-kucherawy-dkim-atps-11.txt (DKIM Authorized Third-Party Signers) to Experimental RFC
On 1 December 2011 05:09, Murray S. Kucherawy m...@cloudmark.com wrote: so long as experimental-status drafts are allowed to make IANA registrations. (I thought they weren't, which is why it is the way it is right now.) Depends on the registry, some registrations need standards track, others want published RFC, some need IETF consensus, and so on, down to first come first served. The author of RFC 5451 wants published RFC with IETF review. that's below standards track, or in other words, IETF experimental with IETF Last Call is okay. -Frank ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-kucherawy-dkim-atps-11.txt (DKIM Authorized Third-Party Signers) to Experimental RFC
At 11:38 30-11-2011, The IESG wrote: The IESG has received a request from an individual submitter to consider the following document: - 'DKIM Authorized Third-Party Signers' draft-kucherawy-dkim-atps-11.txt as an Experimental RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2011-12-28. Exceptionally, comments may be In Section 2: Readers should be familiar with the material and terminology discussed in [MAIL] and [EMAIL-ARCH]. The references to RFC 5598 and RFC 5322 should be normative. In Section 3: An Author participates in this protocol if it wishes to announce that a message from it (in the RFC5322.From sense) should be considered authentic as long as it bears a signature from any in a set of specified domains. It's the domain and not the author which participates in this protocol. As a nit, the RFC 5598 term looks more like Originator instead of Author. The Abstract section uses the term authorization whereas authentic is used in the above text. Shouldn't that be considered as authorized? In Section 4.1: When the Signer generates a DKIM signature on behalf of an Author, it MUST include an atps tag in the signature and include as its value the Author's domain name. See above comment about originator. In Section 6: A Verifier implementing both ADSP and ATPS SHOULD treat a message for which the ATPS test described above passes as if it were signed by the author domain. That is, a pass of ATPS means a pass for ADSP. In plain English, this reads as an update of ADSP but this draft does not update RFC 5617. In Section 8: No actions are required by IANA at this time. The following need only be applied if and when this specification reaches the Standards Track. The IANA Considerations section is unusual. If no action is required at this time, the sub-sections are not needed. I suggest updating the DKIM-Signature Tag Specification Registry for the tags as they will appear on the Internet. Regards, -sm ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-kucherawy-dkim-atps-11.txt (DKIM Authorized Third-Party Signers) to Experimental RFC
Readers should be familiar with the material and terminology discussed in [MAIL] and [EMAIL-ARCH]. The references to RFC 5598 and RFC 5322 should be normative. I agree; I missed that in my shepherd review. So sorry. A Verifier implementing both ADSP and ATPS SHOULD treat a message for which the ATPS test described above passes as if it were signed by the author domain. That is, a pass of ATPS means a pass for ADSP. In plain English, this reads as an update of ADSP but this draft does not update RFC 5617. It does not. There's no reason that anyone implementing ADSP need pay attention to this. *IF* you implement this, it might change your behaviour with respect to ADSP, but information about that is contained here. There's no reason for this to update 5617 in the IETF sense. The IANA Considerations section is unusual. If no action is required at this time, the sub-sections are not needed. I did call this out in my shepherd review (see the PROTO writeup: https://datatracker.ietf.org/doc/draft-kucherawy-dkim-atps/history/ and click show all on the PROTO writeup entry; side point: it should probably be easier to get to the PROTO writeup for a document). I actually think it's clever to put the information here in this manner, but, as I say in the writeup, it is unusual. I prefer that we leave it here, and just make sure that the intelligent folks at IANA do the intelligent thing. This can then serve as a template for the IANA Considerations section for a possible revision that moves ATPS to Standards Track, should that happen. Barry, document shepherd ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-kucherawy-dkim-atps-11.txt (DKIM Authorized Third-Party Signers) to Experimental RFC
Hi Barry, At 13:03 30-11-2011, Barry Leiba wrote: It does not. There's no reason that anyone implementing ADSP need pay attention to this. *IF* you implement this, it might change your behaviour with respect to ADSP, but information about that is contained here. There's no reason for this to update 5617 in the IETF sense. Ok. I did call this out in my shepherd review (see the PROTO writeup: https://datatracker.ietf.org/doc/draft-kucherawy-dkim-atps/history/ and click show all on the PROTO writeup entry; side point: it should probably be easier to get to the PROTO writeup for a document). I missed that. I actually think it's clever to put the information here in this manner, but, as I say in the writeup, it is unusual. I prefer that we leave it here, and just make sure that the intelligent folks at IANA do the intelligent thing. This can then serve as a template for the IANA Considerations section for a possible revision that moves ATPS to Standards Track, should that happen. Agreed. I support publication of the draft as Experimental. Regards, -sm ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Last Call: draft-kucherawy-dkim-atps-11.txt (DKIM Authorized Third-Party Signers) to Experimental RFC
Hi, SM. Thanks for your comments. In reply to the stuff Barry hasn't already covered: -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of SM Sent: Wednesday, November 30, 2011 12:35 PM To: ietf@ietf.org Subject: Re: Last Call: draft-kucherawy-dkim-atps-11.txt (DKIM Authorized Third-Party Signers) to Experimental RFC In Section 3: An Author participates in this protocol if it wishes to announce that a message from it (in the RFC5322.From sense) should be considered authentic as long as it bears a signature from any in a set of specified domains. It's the domain and not the author which participates in this protocol. As a nit, the RFC 5598 term looks more like Originator instead of Author. The term is more based on how DKIM and ADSP use it. But you're right in that Author Domain is the more correct term rather than Author. I'll change that for -12. The Abstract section uses the term authorization whereas authentic is used in the above text. Shouldn't that be considered as authorized? Yes, I think that's more correct as well. -MSK ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Last Call: draft-kucherawy-dkim-atps-11.txt (DKIM Authorized Third-Party Signers) to Experimental RFC
-Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Murray S. Kucherawy Sent: Wednesday, November 30, 2011 2:21 PM To: ietf@ietf.org Subject: RE: Last Call: draft-kucherawy-dkim-atps-11.txt (DKIM Authorized Third-Party Signers) to Experimental RFC It's the domain and not the author which participates in this protocol. As a nit, the RFC 5598 term looks more like Originator instead of Author. The term is more based on how DKIM and ADSP use it. But you're right in that Author Domain is the more correct term rather than Author. I'll change that for -12. Actually ADMD from RFC5598 seems to be a good fit, so I'll use that. Thanks again! -MSK ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-kucherawy-dkim-atps-11.txt (DKIM Authorized Third-Party Signers) to Experimental RFC
I'm one of the authors of RFC 5617, which this document would update if it moved into the standards track. It doesn't seem very useful to me, but it also seems mostly harmless so there's no reason not to publish it as experimental. This strikes me a hack that appeals primarily to bulk mail senders who grossly overestimate how interested receivers are in helping them do their mail management. So I would be surprised if there were many receiver-side implementations, but it's an experiment so what the heck. No actions are required by IANA at this time. The following need only be applied if and when this specification reaches the Standards Track. I would strongly suggest changing the IANA section so that the DKIM-Signature tags in section 8.4 are registered when this is published. Tags are text strings, and I'd rather the tags it uses be noted and reserved so that nobody uses them for something else in the future and risks collisions. For the same reason, it'd probably be a good idea to register the authentication-results tags described in sections 8.2 and 8.3. 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 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Last Call: draft-kucherawy-dkim-atps-11.txt (DKIM Authorized Third-Party Signers) to Experimental RFC
-Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of John Levine Sent: Wednesday, November 30, 2011 6:04 PM To: ietf@ietf.org Subject: Re: Last Call: draft-kucherawy-dkim-atps-11.txt (DKIM Authorized Third-Party Signers) to Experimental RFC I'm one of the authors of RFC 5617, which this document would update if it moved into the standards track. It doesn't seem very useful to me, but it also seems mostly harmless so there's no reason not to publish it as experimental. This strikes me a hack that appeals primarily to bulk mail senders who grossly overestimate how interested receivers are in helping them do their mail management. So I would be surprised if there were many receiver-side implementations, but it's an experiment so what the heck. As the draft says, the point is to make the idea available and see if it sticks to anyone or anything. If the bulk senders (or receivers) do decide they collectively want this, there's something for them to try and report back. No actions are required by IANA at this time. The following need only be applied if and when this specification reaches the Standards Track. I would strongly suggest changing the IANA section so that the DKIM- Signature tags in section 8.4 are registered when this is published. Tags are text strings, and I'd rather the tags it uses be noted and reserved so that nobody uses them for something else in the future and risks collisions. For the same reason, it'd probably be a good idea to register the authentication-results tags described in sections 8.2 and 8.3. I'd be fine with that, so long as experimental-status drafts are allowed to make IANA registrations. (I thought they weren't, which is why it is the way it is right now.) Thanks, -MSK ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-kucherawy-dkim-atps-11.txt (DKIM Authorized Third-Party Signers) to Experimental RFC
On 11/30/2011 8:09 PM, Murray S. Kucherawy wrote: As the draft says, the point is to make the idea available and see if it sticks to anyone or anything. If the bulk senders (or receivers) do decide they collectively want this, there's something for them to try and report back. if one thinks the mechanism is a bad idea, it's still worth having a good document to describe it.l I'd be fine with that, so long as experimental-status drafts are allowed to make IANA registrations. (I thought they weren't, which is why it is the way it is right now.) depends on the criteria for the registry. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Last Call: draft-kucherawy-dkim-atps-11.txt (DKIM Authorized Third-Party Signers) to Experimental RFC
-Original Message- From: Dave CROCKER [mailto:d...@dcrocker.net] Sent: Wednesday, November 30, 2011 11:16 PM To: Murray S. Kucherawy Cc: ietf@ietf.org Subject: Re: Last Call: draft-kucherawy-dkim-atps-11.txt (DKIM Authorized Third-Party Signers) to Experimental RFC I'd be fine with that, so long as experimental-status drafts are allowed to make IANA registrations. (I thought they weren't, which is why it is the way it is right now.) depends on the criteria for the registry. So it does, and the registry for DKIM signature tags is IETF Consensus, which doesn't require standards track documents to update. So I guess the registrations could indeed be made here. Neat. It's a short walk from the current wording to actually requesting the IANA action. I'll check with my shepherd and sponsoring AD for advice prior to the end of LC. Thanks, -MSK ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
