Subject: [ietf-dkim] editorials and nits

From: Stephen Farrell <[email-masked]>
Date: Sat, 01 Jul 2006 23:28:51 +0100

These definitely only need to be a single tracker entry.

S.

Editorial
---------

#1 saying "proof" and "non-repudiation" in the abstract is a mistake and
potentially misleading. Rephase to use less difficult terms, e.g.  talk about
signatures being evidence rather than proof.

#2 1.1, 1st set of bullets. The biggest difference between dkim and s/mime or
pgp signatures IMO is that with dkim we do not expect that signature failure
will lead to message (delivery) failure, whereas with s/mime or pgp we do. I'd
mention this in a bullet.

#3 1.1, 2nd set of bullets. dkim *does* require a ttp - the DNS. Better to say
that dkim requires no *new* ttp.

#4 1.1, last para. Seems a bit early to introduce selectors here - was there a
reason (that still applies)? If not, then maybe this can be deleted now.

#4 3.2, 1st sentence. "multiple key signing/verfication algorithms" is not
a good phrase, suggest changing to "multiple digital signature algorithms"
instead.

#5 3.3.1 and 3.3.1, phraseology is still a bit odd. Suggest changing from:
"That hash is then signed by the signer using the RSA algorithm (defined in
PKCS#1 version 1.5 [RFC3447]; in particular see section 5.2) with an exponent
of 65537 as the crypt-alg and the signer's private key.  The hash MUST NOT be
truncated or converted into any form other than the native binary form before
being signed." ...to... "The signature is calculated using the RSA algorithm
with a fixed public exponent of 65537 - if a different public exponent is
required, then a new DKIM signing algorithm must be defined."

#6 3.3.3 suggest s/"do not understand"/"cannot verify"/

#7 3.3.4 says "RSA keys of at least 1024 bits" and similar. The 1024
refers to the modulus length so that would be more correctly stated
as "RSA keys with modulus at leat 1024 bits long". Similar fixes could
be done with other parts of the same section.

#8 3.3.4 would be a little clearer if it said that "Verifier security
policies may use the length..."

#9 3.4 s/result in an authentication failure/result in signature
verification failure/ since dkim isn't authenticating, strictly
speaking.

#10 3.4.5, 1st sentence: s/and verified/and to be verified/
or just drop the last two words. 

#11 3.4.5, end of 1st informative note: s/ignore the tag/ignore
content after the indicated length/ Reason - if the ignore the tag
then they won't verify the signature.

#12 3.4.5, 3rd para: s/body length count is made after/body
length count is calculated after/ 

#13 3.4.5, 2nd informative note: I think this just repeats stuff in 
the 1st informative note and could be deleted.

#14 3.4.5, last informative note: again I think this could be 
deleted.

#15 3.5 "q=" the text says "dns/txt" but the ABNF contains "txt/dns"
and the text description isn't clear (enough) that "dns" is allowed
and means "dns/txt".

#16 3.5, example at end. This example doesn't contain a "bh=", it'd
be better if it did since that's REQUIRED.

#17 3.6.1 talks about "the response" which is dns specific, and I
thought we didn't want to be here, so s/response/record/ maybe?

#18 3.6.2.1 and elsewhere, I see ""_domainkey"" and other instances
of double-double quotes. Can't see why those are there.

#19, 3.7. This talks about two hashes all the time, which is correct, but a bit
misleading since any sensible API will include both hashing and private key
application inside a "sign()" function. The end result is that the dkim
programmer calls "hash()" once and either "sign()" or "verify()" once. Suggest
adding a sentence along these lines to clear that up. If someone ever
calculated "sign(hash())" then they'd be wrong and this text sort of
suggests that. Similar comment about the pseudo-code at the end where
I'd rather see something like:

       body-hash = hash( canon_body )
       signature = sign( canon_header || DKIM-SIG )

#20, 3.7, 4th last para. This sort-of threw me a bit since it seems like an MUA
instruction. Is it? If so, then maybe move to the appendix/overview? This is
the one starting "When calculating the hash on messages..."

#21, 3.7, last para. "sans" is nice, but would it confuse non-franglish
speakers?

#22, 5.2, last para. Change "when the selector containing the corresponding
public key is expected to be removed before the verifier...", to, "when
the public key in the relevant selector is expected to be revoked before
the verifier..." since we're not recommending removing the selector but
rather zeroing out the key.

#23, 5.5, last 2 paras about "l=". I think this has all already been said, so
it could be removed from here.

#24, Section 6, 1st sentence says "may expire a public key" s/expire/revoke/
since dkim, (properly), doesn't do expiry, only revocation.

#25, 6.1, 1st note, "other clues" is a bit opaque - include a reference
to somewhere where the reader can find those clues or maybe reword.

#26, 6.1 "; this is local policy..." that "this" is a maybe a tad
ambiguous, suggest replacing with "; such treatment is a matter
for local policy..."

#27, 6.1.3, list item #1 says "create a canonicalised copy" which isn't
necessary - all you need to is feed the right bits through the hashing,
so an entire copy need never be created. Suggest rewording to say
"re-create the canonicalized octets" or something. (Or, add an informative
note along the above lines.)

#28, 6.2. The reference to ID-AUTH-RES might be better off being removed
for process reasons.

#29, 8.1.1. Missing the example.

#30, 8.2. This section mainly applies to MUA signing, which is not the
main use-case, and so the threat is less serious. Suggest saying that 
at the start of the section along with a sentence like: "Protection of
private keys on servers can be easily achieved though the use of 
specialised crytographic hardware."

#31, A.2, the example has no "bh=". Needs recalculating. And would be
better if the example inlcuded real signatures and the corresponding
public key record too.

#32, A.3, the authentication results header should not, IMO be included
here.

#33, Appendix B. I expected to see a bit here about the type of setup
we have at IETF meetings, where the IETF's MTA signs and the verifier
has to handle the From being nothing like the signer identity. 

#34, Appendix C. I think that this can be deleted. Others may disagree.
In any case, the text says 768 and the command line 1024, no 
password handling is shown and the last part could confuse since
that signature is not usable for DKIM. So if this isn't deleted, then
a bunch of changes are needed.

Total Nits
----------

#1 When the [[]] text disappears there'll be nothing between "introduction" and
"overview" - suggest getting rid of 1.1 and just having the text be the
introduction.

#2 1.1, 2nd set of bullets. The last point here would be better in the 1st set
of bullets.

#3 2.3, last sentence. Does the single abnf definition here offer value? If so,
then why not one for FWS too? Suggest deleting this.

#4 3.5, 3rd para: is "the null string" well enough defined? Maybe "an
empty string" would be better?

#5 3.5, last para before tags says: "Defined tags are described below."
which is sort of obvious. Suggest deleting it.

#6 3.6.1 "k=" says that the public key is in the "p=" value, but its
actually the modulus.

#7 3.6, 3rd last para s/string of characters/string of octets/

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

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 1 Jul 2006 22:01:45 -0400

Agree with all, except...

>mention this in a bullet.

Fully disagree. There is no expectation of non-delivery for signature 
failures in S/MIME or OpenPGP.

>has to handle the From being nothing like the signer identity.

Disagree. Leave as-is.

>#34, Appendix C. I think that this can be deleted. Others may disagree.

Disagree. :-) It helps novice implementers.

>a bunch of changes are needed.

Agree.

---

From: Eric Allman <[email-masked]>
Date: Mon, 03 Jul 2006 17:58:18 -0700

> #1 saying "proof" and "non-repudiation" in the abstract is a
> mistake and potentially misleading. Rephase to use less difficult
> terms, e.g.  talk about signatures being evidence rather than proof.

Given the sensitivity over the exact wording of the abstract, I'm not 
willing to make this change without discussion of some proposed 
wording.

> #2 1.1, 1st set of bullets. The biggest difference between dkim and
> s/mime or pgp signatures IMO is that with dkim we do not expect
> that signature failure will lead to message (delivery) failure,
> whereas with s/mime or pgp we do. I'd mention this in a bullet.

There seems to be a difference of opinion on this, so I'll leave it 
for now.

> #3 1.1, 2nd set of bullets. dkim *does* require a ttp - the DNS.
> Better to say that dkim requires no *new* ttp.

I don't see DNS as a "third party" in the same sense as a CA for 
certs.  Yes, DNS has to work, but it isn't a third party (unless you 
want to count the root servers, I suppose).  By this logic, we should 
also include the multiple third parties that run the routers and all 
the rest of the infrastructure.

> #4 1.1, last para. Seems a bit early to introduce selectors here -
> was there a reason (that still applies)? If not, then maybe this
> can be deleted now.

I don't see it as necessary.  Deleted.

> #4 3.2, 1st sentence. "multiple key signing/verfication algorithms"
> is not a good phrase, suggest changing to "multiple digital
> signature algorithms" instead.

I hope you mean 3.3, otherwise you may be reading a very out of date 
draft.  Changed.

> #5 3.3.1 and 3.3.1, phraseology is still a bit odd. Suggest
> changing from: "That hash is then signed by the signer using the
> RSA algorithm (defined in PKCS#1 version 1.5 [RFC3447]; in
> particular see section 5.2) with an exponent of 65537 as the
> crypt-alg and the signer's private key.  The hash MUST NOT be
> truncated or converted into any form other than the native binary
> form before being signed." ...to... "The signature is calculated
> using the RSA algorithm with a fixed public exponent of 65537 - if
> a different public exponent is required, then a new DKIM signing
> algorithm must be defined."

Adding the specific reference was specifically requested by another 
reviewer --- in fact, I think your proposal changes it back to almost 
exactly what was objected to before.  I think this requires some 
discussion.

> #6 3.3.3 suggest s/"do not understand"/"cannot verify"/

I changed this to "do not implement".  "Cannot verify" is too vague: 
there are lots of reasons a verifier might not be able to verify a 
signature.

> as "RSA keys with modulus at leat 1024 bits long". Similar fixes
> could be done with other parts of the same section.

I would like some discussion on this.  This might be more technically 
accurate for a cryto expert, but I know that if I as a non-crypto guy 
read this, I would immediately ask myself "now, is that the same as 
the key length or something else altogether?"

> #8 3.3.4 would be a little clearer if it said that "Verifier
> security policies may use the length..."

Agreed.

> verification failure/ since dkim isn't authenticating, strictly

It seems pretty pedantic, but OK, changed.

> or just drop the last two words.

I just dropped them.

> then they won't verify the signature.

Actually, in our early discussion over this we actually did mean that 
the verifier can simply ignore the tag, and yes, it won't verify. 
Some people deemed that to be a feature, not a bug.

> length count is calculated after/

Done.

> the 1st informative note and could be deleted.

The point of this note was to provide a clear rationale, which 
doesn't really seem to be fully done in the first (implementation) 
note.  I moved it up before the first note and deleted the first 
sentence of the implementation note, so it now reads:

        INFORMATIVE RATIONALE: This capability is provided because it
        is very common for mailing lists to add trailers to messages
        (e.g., instructions how to get off the list). Until those
        messages are also signed, the body length count is a useful
        tool for the verifier since it may as a matter of policy
        accept messages having valid signatures with extraneous data.

        INFORMATIVE IMPLEMENTATION NOTE:  Using body length limits
        enables an attack in which an attacker modifies a message to
        include content that solely benefits the attacker. It is
        possible for the appended content to completely replace the
        original content in the end recipient's eyes and to defeat
        duplicate message detection algorithms. To avoid this attack,
        signers should be wary of using this tag, and verifiers might
        wish to ignore the tag or remove text that appears after the
        specified content length, perhaps based on other criteria.

Does this address your comment adequately?

> #14 3.4.5, last informative note: again I think this could be

I deleted this and we'll see if anyone screams.  There are so many 
notes in that section because the "l= is evil" faction wanted to make 
it very clear that you can get yourself into a heap of trouble by 
using it inappropriately.

> and the text description isn't clear (enough) that "dns" is allowed

Whoops, the ABNF was wrong.  And actually "dns" by itself is /not/ 
allowed; note the sentence reading "The only option defined for the 
"dns" query type is "txt", which MUST be included."

> be better if it did since that's REQUIRED.

Right you are.  It was also missing a semicolon after the z= value.

> thought we didn't want to be here, so s/response/record/ maybe?

Works for me.

> of double-double quotes. Can't see why those are there.

Someone else reported the same thing and I couldn't find it --- but 
this time I did (use of spanx with style=verb causes quoting in plain 
text).  It should be fixed now.

> #19, 3.7. This talks about two hashes all the time, which is
> correct, but a bit misleading since any sensible API will include
> both hashing and private key application inside a "sign()"
> function. The end result is that the dkim programmer calls "hash()"
> once and either "sign()" or "verify()" once. Suggest adding a
> sentence along these lines to clear that up. If someone ever
> suggests that. Similar comment about the pseudo-code at the end
> where I'd rather see something like:
>

I disagree.  This section has nothing to do with what an API would 
look like, it's about what algorithms have to be applied and when. 
For example, I can easily see your change being interpreted to mean 
that you don't hash the header at all.

> #20, 3.7, 4th last para. This sort-of threw me a bit since it seems
> like an MUA instruction. Is it? If so, then maybe move to the
> appendix/overview? This is the one starting "When calculating the
> hash on messages..."

No, this is not an MUA function --- it is perfectly reasonable for a 
gateway to convert an 8-bit message to a 7-bit form long after the 
MUA is done with it, and dot-stuffing definitely has nothing 
whatsoever to do with the MUA.

> #21, 3.7, last para. "sans" is nice, but would it confuse
> non-franglish speakers?

Actually it's an English word, derived from Latin, as in "sans 
serif".  It is also a French word, and came into Middle English from 
Old French.  But if other English speakers want me to change it, Ita 
Sit (Latin for "so be it", although we more commonly use the word 
"amen", although that has another connotation).

> #22, 5.2, last para. Change "when the selector containing the
> corresponding public key is expected to be removed before the
> verifier...", to, "when the public key in the relevant selector is
> expected to be revoked before the verifier..." since we're not
> recommending removing the selector but rather zeroing out the key.

Is that what we are recommending?  I thought that omitting the key 
was a way of saying "we're sorry, but we had to pull that key 
unexpectedly."  In fact, the usual way of dropping a key would be to 
drop the record entirely.  Otherwise you would have ever-growing name 
spaces.

> #23, 5.5, last 2 paras about "l=". I think this has all already
> been said, so it could be removed from here.

I would consider removing the informative note, but I think it is 
completely reasonable to include all the steps in the section on 
"Compute the Message Hash and Signature", even if they do duplicate 
some other text.

> #24, Section 6, 1st sentence says "may expire a public key"
> s/expire/revoke/ since dkim, (properly), doesn't do expiry, only
> revocation.

See my comments on #22.

> #25, 6.1, 1st note, "other clues" is a bit opaque - include a
> reference to somewhere where the reader can find those clues or
> maybe reword.

I changed this to read "INFORMATIVE IMPLEMENTATION NOTE: Verifiers 
might use the order as a clue to signing order in the absence of any 
other information. However, other clues as to the semantics of 
multiple signatures (such as correlating the signing host with 
Received headers) may also be considered."

> ambiguous, suggest replacing with "; such treatment is a matter

Done.

> #27, 6.1.3, list item #1 says "create a canonicalised copy" which
> isn't necessary - all you need to is feed the right bits through
> the hashing, so an entire copy need never be created. Suggest
> rewording to say "re-create the canonicalized octets" or something.
> (Or, add an informative note along the above lines.)

This is a description of an algorithm, not an implementation.  I'll 
put in an implementation note, but frankly getting this wording 
sufficiently unambiguous has proven challenging, and I'm reluctant to 
wade in again without a really good reason.  I will change the intro 
to read "... consists of actions semantically equivalent to the 
following steps."  I can also add something in the Implementer's Note 
if you feel it needs more.

> #28, 6.2. The reference to ID-AUTH-RES might be better off being
> removed for process reasons.

Even as an example?  It's informational, not normative.

> #29, 8.1.1. Missing the example.

Right, thanks.  I added a paragraph reading:

        For example, if an attacker can append information to a
        text/html body part, they may be able to exploit a bug in
        some MUAs that continue to read after a </html> marker, and
        thus display HTML text on top of already displayed text.  If
        a message has a multipart/alternative body part, they might
        be able to add a new body part that is preferred by the
        displaying MTA.

> #30, 8.2. This section mainly applies to MUA signing, which is not
> the main use-case, and so the threat is less serious. Suggest
> saying that  at the start of the section along with a sentence
> like: "Protection of private keys on servers can be easily achieved
> though the use of  specialised crytographic hardware."

Added.

> #31, A.2, the example has no "bh=". Needs recalculating. And would
> be better if the example inlcuded real signatures and the
> corresponding public key record too.

I did get a (correct) bh= value included, but haven't recomputed the 
signature (it's getting late today; I'll try to get to that tomorrow).

> #32, A.3, the authentication results header should not, IMO be
> included here.

I think it is very important to make it clear how one might convey 
results to higher levels.  Otherwise all of A.3 doesn't have any 
reasonable example.  It doesn't have to be Authentication-Results, 
just something.

> #33, Appendix B. I expected to see a bit here about the type of
> setup we have at IETF meetings, where the IETF's MTA signs and the
> verifier has to handle the From being nothing like the signer
> identity.

Sorry, I don't see any signatures coming from the IETF MTA.  Can you 
be more specific?

> #34, Appendix C. I think that this can be deleted. Others may
> disagree. In any case, the text says 768 and the command line 1024,
> no  password handling is shown and the last part could confuse since
> that signature is not usable for DKIM. So if this isn't deleted,
> then a bunch of changes are needed.

I fixed the discrepancy, but I don't think it should be deleted. 
It's non-normative and will help people understand how to use the 
standard, which I think is A Good Thing.

I'm not sure what you mean about password handling.  I just ran 
through these instructions, and there are no passwords requested.

> Total Nits
> ----------
>
> #1 When the [[]] text disappears there'll be nothing between
> "introduction" and "overview" - suggest getting rid of 1.1 and just
> having the text be the introduction.

Works for me.

> #2 1.1, 2nd set of bullets. The last point here would be better in
> the 1st set of bullets.

Makes sense.  Done.

> #3 2.3, last sentence. Does the single abnf definition here offer
> value? If so, then why not one for FWS too? Suggest deleting this.

I think the ABNF does have value.  We don't include it for FWS 
because that's imported from another document (RFC2822); the ABNF is 
there.

> #4 3.5, 3rd para: is "the null string" well enough defined? Maybe
> "an empty string" would be better?

Done.

> #5 3.5, last para before tags says: "Defined tags are described
> below." which is sort of obvious. Suggest deleting it.

Done (but why do I have the creepy feeling someone is going to 
object?).

> #6 3.6.1 "k=" says that the public key is in the "p=" value, but its

I guess I'm confused.  If this isn't the public key, what is?

> #7 3.6, 3rd last para s/string of characters/string of octets/

3.7 perhaps?  I've made that change.

Thanks for your comments.

eric

---

From: Tony Hansen <[email-masked]>
Date: Mon, 03 Jul 2006 23:38:41 -0400

Eric Allman wrote:
> Actually it's an English word, derived from Latin, as in "sans serif". 
> It is also a French word, and came into Middle English from Old French. 
> But if other English speakers want me to change it, Ita Sit (Latin for
> "so be it", although we more commonly use the word "amen", although that
> has another connotation).

keep sans

	Tony Hansen
	[email-masked]

---

From: Jim Fenton <[email-masked]>
Date: Mon, 03 Jul 2006 23:25:05 -0700

>> has another connotation).
Amen.

-Jim

---

From: Eliot Lear <[email-masked]>
Date: Tue, 04 Jul 2006 08:42:38 +0200

Eric,

First of all, happy 4th of July.  For some unknown reason Switzerland
doesn't celebrate it.

>> 3 1.1, 2nd set of bullets. dkim *does* require a ttp - the DNS.
I believe one could distinguish different forms of attack, and in this
case whether untrustworthy messages are trusted.  This having been
said,  I think it's safe to say that DNS is already relied upon to
transmit mail, and hence no additional trusted third part is relied upon.
> the verifier can simply ignore the tag, and yes, it won't verify. Some
> people deemed that to be a feature, not a bug.

In the "Horses not Zebras" department what's the best wording?

Eliot

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 04 Jul 2006 10:40:38 +0100

Just ones where there's something to say,
Cheers,
Stephen.

Eric Allman wrote:
> willing to make this change without discussion of some proposed wording.

Ok, I'll back off on this. DKIM isn't the only document that includes
such phrases (but if you could even just not say "non-repudiation"
that'd be great).

> There seems to be a difference of opinion on this, so I'll leave it for 
> now.

Ok.

> I don't see DNS as a "third party" in the same sense as a CA for certs.  
> Yes, DNS has to work, but it isn't a third party (unless you want to 
> count the root servers, I suppose).  By this logic, we should also 
> include the multiple third parties that run the routers and all the rest 
> of the infrastructure.

In my little PKI-riddled mind, the DNS is a TTP since it supplies the
public keys and if/when DNSSEC were used, it starts to look quite like
a PKI. The routers etc. won't ever really be supplying signed key
records. But if no-one else thinks the same, leaving as-is if of course
right.

> exactly what was objected to before.  I think this requires some 

Sorry - you're right about the reference, I just forgot to include
it, you could change text suggestion to: "The signature is calculated
using the RSA signature algorithm as specified in PKCS#1 version 1.5
[RFC3447], and with a fixed public exponent of 65537 - if a different
public exponent is required, then a new DKIM signing algorithm tag
value must be defined."

> read this, I would immediately ask myself "now, is that the same as the 
> key length or something else altogether?"

Fair point. I was probably being a bit pernickity.

> The point of this note was to provide a clear rationale, which doesn't 
> really seem to be fully done in the first (implementation) note.  I 
> moved it up before the first note and deleted the first sentence of the 
> implementation note, so it now reads:
> 

Ok.

> I disagree.  This section has nothing to do with what an API would look 
> like, it's about what algorithms have to be applied and when. For 
> example, I can easily see your change being interpreted to mean that you 
> don't hash the header at all.

Fair enough. Its hard to get right either way. But can we add an
informative note somewhere like:

    INFORMATIVE NOTE: Many digital signature APIs provide both hashing
    and application of the RSA private key using a single "sign()"
    primitive. When using such an API the DKIM signature calculation
    pseudo-code might look more like:
          body-hash = hash( canon_body )
          signature = sign( canon_header || DKIM-SIG )
    Were an implementer to mistakenly include a second "hash()" call,
    i.e.,
          signature = sign( hash (canon_header || DKIM-SIG ) )
    they would sign and verify their own messages with no apparent
    problems, but could not interoperate with correct implementations.

> Is that what we are recommending?  I thought that omitting the key was a 
> way of saying "we're sorry, but we had to pull that key unexpectedly."  
> In fact, the usual way of dropping a key would be to drop the record 
> entirely.  Otherwise you would have ever-growing name spaces.

I guess I'm confused then. I thought that including a blank key
value was better since it could be cached. I would assume that
you then typically delete the selector record after a while, when
you no longer see many requests for it or whatever.

> Even as an example?  It's informational, not normative.

I appreciate that, but I bet it'd still slow down base's road
to rfc-dom.

> reasonable example.  It doesn't have to be Authentication-Results, just 
> something.

An abstract something here is better than a nearly-well-defined
something IMO. (I mean no criticism of ID-AUTH-RES here either, but
it may change in all sorts of ways, including the name of the header
field.)

> Sorry, I don't see any signatures coming from the IETF MTA.  Can you be 
> more specific?

If I go to a conference or IETF, then I generally use its smtp server.
If someone was used to mail from me being signed by tcd.ie and suddenly
see mail from me signed by ietf66.org they might react badly. I don't
want that to happen. (I know that the IETF meeting server doesn't sign
now, but I guess it may in future.)

So, my point was that I didn't see an example/use-case that mapped to
the one above.

> I fixed the discrepancy, but I don't think it should be deleted. It's 
> non-normative and will help people understand how to use the standard, 
> which I think is A Good Thing.
> 
> I'm not sure what you mean about password handling.  I just ran through 
> these instructions, and there are no passwords requested.

Sure, you don't have to use passwords with s/w private keys, but you
really should do at least that much.

If we're going to give this kind of help, we don't want it to encourage
people to take less secure options without being clear that that's what
they're doing.

> Done (but why do I have the creepy feeling someone is going to object?).

I object!

> I guess I'm confused.  If this isn't the public key, what is?

Me being pedantic again I guess. The public key is the modulus and
the public exponent (in our case hardcoded to be 65537).

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 04 Jul 2006 10:52:32 +0100

>>> has another connotation).

That's me properly told then:-)

S.

---

From: Michael Thomas <[email-masked]>
Date: Tue, 04 Jul 2006 07:36:40 -0700

> records. But if no-one else thinks the same, leaving as-is if of course

I think Eric captures the exact nature of the confusion. On purely technical
level, Stephen is right, but on the 'want-to-be-understood' level, 
mentioning
a ttp is good way to get un-understood in a big hurry. And even then people
try to shoe horn "certificates" into our certificateless design and proceed
misunderstanding based on that false premise.

> So, my point was that I didn't see an example/use-case that mapped to

Sure there is: the first obvious is that you can vpn into you home as
many of us do already and have your home mta's do the signing. However,
the "DKIM" answer is to delegate a key/selector to [email-masked]
(probably with g=stephen.farrell; ) and allow your own selector do the job.
I've been wanting for quite some time to hack up a thunderbird plugin that
can do exactly this.

> the public exponent (in our case hardcoded to be 65537).

Wouldn't it actually be better to just say that it's the PEM formated
public key with reference and not give an explanation at all? For a
developer, what I'm looking for is a routine which reads it, and
looking for PEM_xxx is a lot easier than looking for "b64 modulus
with hardcoded public exponent of 65537".

       Mike

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 04 Jul 2006 07:54:56 -0700

Stephen Farrell <[email-masked]> writes:

>> Given the sensitivity over the exact wording of the abstract, I'm
>> not willing to make this change without discussion of some proposed
>> wording.
>

I totally agree.

>> want to count the root servers, I suppose).  By this logic, we
>> should also include the multiple third parties that run the routers
>> and all the rest of the infrastructure.
>

Well, I was probably the one who raised this issue originally, and
I don't agree with raising it as-is. The DNS has to be trusted to
give out the right info and, as Stephen observes, if/when DNSSEC
is deployed there will be an isomorphism between a classic PKI
and the DNS. 

>> reviewer --- in fact, I think your proposal changes it back to
>> almost exactly what was objected to before.  I think this requires
>> some discussion.
>

I don't understand the purpose of the fixed exponent of F4. It's
not needed for interoperability because a PKCS#1 RSAPublicKey
(which is what this document implies, though does not say
is stored in the DNS) structure contains the exponent.

> the public exponent (in our case hardcoded to be 65537).

This doesn't look right to me. Here's the relevant text:

   k=   Key type (plain-text; OPTIONAL, default is "rsa").  Signers and
       verifiers MUST support the "rsa" key type.  The "rsa" key type
       indicates that an RSA public key, as defined in [RFC3447],
       sections 3.1 and A.1.1, is being used in the p= tag.  (Note:  the
       p= tag further encodes the value using the base64 algorithm.)

And here's what's in A.1.1:

   An RSA public key should be represented with the ASN.1 type
   RSAPublicKey:

      RSAPublicKey ::= SEQUENCE {
          modulus           INTEGER,  -- n
          publicExponent    INTEGER   -- e
      }

   The fields of type RSAPublicKey have the following meanings:

    * modulus is the RSA modulus n.

    * publicExponent is the RSA public exponent e.

The only ASN.1 definition here is for the full public key.

-Ekr

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 04 Jul 2006 16:02:34 +0100

> is stored in the DNS) structure contains the exponent.

My fault I think. In an earlier thread we decided that playing with
the public exponent value could use too much space in the TXT record
and that we'd hardcode the dkim's "rsa" alg id to keys using 65537.
(I've no problem with us revisiting that if its appropriate.) I then
had the impression that key records contained "p=base64(modulus)" but
it looks like you're right and they don't.

But anyway, we do need to tighten up the spec. on the public key
format a bit it seems (along the lines of your mail which I also guess
is what's currently implemented).

S.

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 04 Jul 2006 16:08:28 +0100

> misunderstanding based on that false premise.

Fair point. I guess this is part of balancing the AD/IESG readership
with the more general programming readers too.

> many of us do already and have your home mta's do the signing. 

Not all setups support that, incl. ours in TCD at the mo. which reduces
you to webmail. I've no idea how common this still is, but I would
assume that vpn-ing in will be increasingly more the norm.

 > However, the "DKIM" answer is to delegate a key/selector to
> [email-masked]

Sure, but I didn't see a recommendation in the I-D that that be done for
that use-case. Maybe I missed it or maybe it doesn't need to be there,
but given that this is maybe one of the times that some current practice
and what we think will be dkim practice are a bit at odds, I'd have
thought it warranted a mention.

S.

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 04 Jul 2006 08:23:01 -0700

> and that we'd hardcode the dkim's "rsa" alg id to keys using 65537.

This striked me as fairly misguided optimization. Your average
1024-bit RSA public key is 141 octets long, like so.

 30    - sequence
 81 89 - length

     02 - integer tag [modulus]
     81 81 - length   [modulus]
       <129 bytes of modulus>

     02 - integer tag [exponent]
     03 - length      [exponent]
        01 00 01   - exponent value

If you remove the exponent, this lets you remove the outer sequence
wrapper (3 bytes) and the inner exponent field (5 bytes) for a 
total of 8 bytes (40 bits) or 6%. Consider that the next recommended
step for RSA keylength is generally 1536 bits, or 64 bytes longer. 
If you can't find 8 bytes here, how are you going to find those
64 later? (Or, if you think it's 1536 that pushes you over the line,
what about 2048...)

-Ekr

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 04 Jul 2006 16:37:50 +0100

Eric Rescorla wrote:
> This striked me as fairly misguided optimization. 

It wasn't really an optimization - I mistakenly thought that the current
implementations used "p=base64(modulus)" and asked "what if we want to
change e?". Apparently, at that time, none of us knew all of this in
sufficient detail to say: "you can do that now" ;-) Mea culpa.

But, the main thing for now is that the current implementations are ok
in this respect, and we'll fixup base to match properly.

S.

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 4 Jul 2006 11:52:04 -0400

At 10:40 AM +0100 7/4/06, Stephen Farrell wrote:
>>certs.  Yes, DNS has to work, but it isn't a third party (unless 
>>you want to count the root servers, I suppose).  By this logic, we 

My brain has the same affliction as Stephen's in this department. The 
keys have to be distributed somehow. The keys are not inherently 
trusted. DKIM users trust the keys they get from the DNS. The DNS is 
the trusted third party who hands out keys.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 4 Jul 2006 11:55:19 -0400

>I appreciate that, but I bet it'd still slow down base's road

It would. We should remove any references to Internet Drafts that are 
not necessary but would delay -base from becoming a published RFC.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 04 Jul 2006 17:23:01 +0100

Michael Thomas wrote:
> Simply not bringing it up may not solve all of the problems, 

Thing is though, the current I-D says "does not require the use
of a trusted third party" which is not the same as saying
nothing.

I'd be fine if it said: "does not require the use of any new
trusted third party".

I'd also be ok if, as you suggest, we make no mention of TTPs.

S.

---

From: Michael Thomas <[email-masked]>
Date: Tue, 04 Jul 2006 09:16:51 -0700

> the trusted third party who hands out keys.

You, me and Stephen aren't the problem though. We could read through the
entire document and it would be perfectly obviously a short way in that the
DNS was the ttp whether explicitly stated or not.  Somebody who's not
nearly as involved, however, might read "DNS is a trusted third party",
think "PKI! Certficates! Run away!" And I've already seen way to many people
who even write to this list make that mistake, so to the larger unwashed 
masses
the conflation of "trusted third party" === "PKI" is likely to be even 
stronger.
Simply not bringing it up may not solve all of the problems, but I do 
think that
the concept of the DNS as being a "trusted third party" is pretty 
inherent in its
design, so at some level all that does is restate the obvious -- in 
potentially
misleading ways to the under-informed.

       Mike

---

From: John Levine <[email-masked]>
Date: 4 Jul 2006 18:58:59 -0000

>First of all, happy 4th of July.  For some unknown reason Switzerland

As I understand it, they couldn't get the paperwork approved.

>In the "Horses not Zebras" department what's the best wording?

We still have some fairly basic disagreements about the utility, if
any, of the l= field.

If you want a consensus statement, I'd say that l= permits the sender
to indicate that there may be unsigned material after the end of the
signed body and leave it at that.  

I would not be eager to leave in the advice on ways to make it harder
for bad guys to do bad things by adding hostile MIME content after the
signed part.  We don't understand the attack routes very well and I
wouldn't want to create the impression that if senders follow our
advice, then l= is "safe".

R's,
John

---

From: Jim Fenton <[email-masked]>
Date: Tue, 04 Jul 2006 22:39:56 -0700

> willing to make this change without discussion of some proposed wording.
Given that the abstract is the only place in the document where the term
"repudiation" appears and virtually the only place where the term
"proof" appears, I think that the terms don't belong here.  Suggest
changing the wording of the last sentence of the abstract to the following:

Protection of email identity may assist in the global control of "spam"
and "phishing".

> the key length or something else altogether?"
I prefer the current "colloquial" usage.  The difference in security
involved depending on whether the modulus is included or not is
inconsequential.
> people deemed that to be a feature, not a bug.
If the verifier doesn't like the l= tag, they should just reject the
signature, rather than bother doing the math to verify it.

Perhaps we need to more globally describe what we mean by "ignore the
tag", since paragraph 9 of section 3.2 says, "Unrecognized tags MUST be
ignored."  In that case, what we want to say is that the verifier MUST
not take action on the tag, but MUST include it in the hash calculation
for this DKIM-Signature header field.  Do we need to spell this out?

-Jim

---

From: Jim Fenton <[email-masked]>
Date: Tue, 04 Jul 2006 22:22:25 -0700

> the trusted third party who hands out keys.
I'm also with Stephen on this.  I think it helps our credibility to
acknowledge the dependency on DNS, although the threat document has
already spelled that out in some detail.

-Jim

---

From: Douglas Otis <[email-masked]>
Date: Wed, 5 Jul 2006 12:44:25 -0700

On Jul 4, 2006, at 10:22 PM, Jim Fenton wrote:

>>>> you

DKIM generally represents a domain wide entity.  A trusted third  
party (TTP) establishes trust between two parties when both trust the  
third party.  For DKIM, the TTP would be the signing domain verified  
by DNS.  To be a TTP, the signing domain would need to be known and  
trusted by verifier (the second party) for signing email-addresses of  
different domains (the first party) or this does not represent three  
parties.  DNSSEC, except making a stronger verification of the  
signing domain, does not alter this model.  Unless DKIM is expected  
to be commonly used with third-party signatures, it seems  
inappropriate to describe DNS as a TTP, nor does DNS represent a  
discrete entity or party.

-Doug

---

From: John Levine <[email-masked]>
Date: 5 Jul 2006 20:02:23 -0000

>signature, rather than bother doing the math to verify it.

Don't do that.  In the presumably common case where the message hasn't
had anything added to it in transit, you ignore l= and the signature
verifies just fine.  I suppose as a microoptimization you could
prescan the body and fail if the length is wrong.

>for this DKIM-Signature header field.  Do we need to spell this out?

I hope not.  Anyone who can't figure that out is unlikely to implement
a working verifier no matter what we tell them.

R's,
John

---

From: Jim Fenton <[email-masked]>
Date: Wed, 05 Jul 2006 13:53:23 -0700

> prescan the body and fail if the length is wrong.
Agreed.  That would be the effect of "ignoring" the l- tag -- in the
sense of actually removing it from the signature -- which is why that's
not a good thing to do.

-Jim

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 5 Jul 2006 17:36:01 -0400

At 12:44 PM -0700 7/5/06, Douglas Otis wrote:
>party (TTP) establishes trust between two parties when both trust 
>the third party.  For DKIM, the TTP would be the signing domain 
>verified by DNS.

This is completely wrong, and goes against nearly everything that 
this WG has been working on. The signing domain is *not* trusted.

Does anyone other than Doug think that it is?
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Jim Fenton <[email-masked]>
Date: Wed, 05 Jul 2006 14:57:21 -0700

Paul Hoffman wrote:
>> by DNS.
> This is completely wrong, and goes against nearly everything that this
> WG has been working on. The signing domain is *not* trusted.
>
We have talked about the concept of third-party signatures, although
this concept is really developed in the SSP draft, which hasn't come up
yet.  But DKIM does not in general depend on a trusted third party to
function, except possibly for DNS.

Doug does have a point though.  He says, "...nor does DNS represent a
discrete entity or party."  Describing DNS as a "party" to this protocol
is probably a stretch.

-Jim

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 5 Jul 2006 18:10:13 -0400

>discrete entity or party."  Describing DNS as a "party" to this protocol

It is not a party to this protocol, but it is a separate party 
nonetheless. And, in the case of DKIM, it is trusted.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Douglas Otis <[email-masked]>
Date: Wed, 5 Jul 2006 16:22:02 -0700

> Does anyone other than Doug think that it is?

You have misunderstood what was being said.  A signing domain can be  
a trusted first party, but unless DKIM becomes commonly used with  
third-party signing domains, a signing domain will not become a  
generally trusted third-party.  As an example, imagine an entity  
"trustworthy-email-accreditations.com" issues keys where a public  
half is published within their DNS domain, and the private half is  
sent to senders that comply with their provisos.  For EHLOs,  
"trustworthy-email-accreditations.com" could also offer A RRs in  
addition to DKIM key RRs.  When "trustworthy-email- 
accreditations.com" becomes trusted for their vetting of email  
senders, they will have established themselves as a trusted-third- 
party signing domain.  As I said, I don't think that is how most  
expect DKIM to be used.  Barring that model of use, DKIM does not  
offer TTP services.

A DNS domain delegation says little about email related behaviors.   
In addition to establishing a real identity and exposure to  
litigation, the behavior of an entity is generally a major component  
of the trust established by a TTP.  The information provided by DNS  
is that a signing domain (perhaps owned by an anonymous entity) was  
involved with the content of a message.  While DNS offers trustworthy  
domain delegations involving anywhere from a few to hundreds of  
separate entities, DNS domain delegation says vanishingly little  
about email related interactions and behaviors.  DKIM's use of DNS is  
little better than verifying the EHLO host name's IP address, except  
a DKIM signature survives beyond the first hop.

TTP services is simply not a normal component of either DKIM base or  
SSP.  SSP provides for a level of repudiation, but name-path  
registration offers even greater DoS protections with similar level  
of repudiation when desired.

-Doug

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 06 Jul 2006 00:41:34 +0100

Douglas Otis wrote:
> You have misunderstood what was being said.  

Clash of terms there. The DNS, as used by DKIM, is a TTP in
crypto-protocol terms according to the well-understood use of that
term [1]. I think I first heard such a definition 20 years ago.

Doug is inventing a new DKIM-specific way to interpret the term TTP, as
an application layer entity (or thereabouts).

I think the WG is much better off sticking with existing definitions
where they're as well understood as this one.

S.

[1] http://en.wikipedia.org/wiki/Trusted_third_party
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Douglas Otis <[email-masked]>
Date: Wed, 5 Jul 2006 18:11:30 -0700

On Jul 5, 2006, at 4:41 PM, Stephen Farrell wrote:
>>>> party (TTP) establishes trust between two parties when both  
>>>> trust the third party.  For DKIM, the TTP would be the signing  
>>>> domain verified by DNS.
>>>

 From your reference:
---
In cryptography, a trusted third party (TTP) is an entity which  
facilitates interactions between two parties who both trust the third  
party; they use this trust to secure their own interactions. TTPs are  
common in cryptographic protocols, for example, a certificate  
authority (CA).
---

While DNS associates a key with a domain name, there should be no  
expectation this domain name represents a tangible entity or offers  
meaningful recourse.  There are thousands of entities involved in  
these associations, where the basis is often limited to just the  
domain name itself.   It is difficult to consider an amalgam of often  
anonymous entities a "trusted third party" for "securing" email  
interactions.  Use of DNS by DKIM certainly falls short of the  
expectations of a TTP as set by Certificate Authorities or the  
example given of a notary public.  For DKIM to offer security, a  
separate assessment of the DKIM domain name should be made (likely by  
a TTP).  In that sense of trust or "securing" interactions, DNS fails  
this definition of TTP for email in my view.

-Doug

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 06 Jul 2006 02:35:44 +0100

Douglas Otis wrote:
> common in cryptographic protocols, for example, a certificate authority 
> (CA).
> ---
> 
> meaningful recourse.  

Irrelevant.

 > There are thousands of entities involved in these
> associations, where the basis is often limited to just the domain name 
> itself.   It is difficult to consider an amalgam of often anonymous 
> entities a "trusted third party" for "securing" email interactions.  Use 
> of DNS by DKIM certainly falls short of the expectations of a TTP as set 
> by Certificate Authorities or the example given of a notary public.  For
> DKIM to offer security, a separate assessment of the DKIM domain name 
> should be made (likely by a TTP).  In that sense of trust or "securing" 
> interactions, DNS fails this definition of TTP for email in my view.

Perhaps you haven't been involved in the fairly tedious exercise
of engineering one of these, e.g. when I worked for a large German
company we made an internal PKI where every building supervisor was
part of the TTP (mostly as RAs, as it happened). At the time there
were O(400,000) employees, and about O(1) private keys, so, like
everyone else, we kind of got used to the idea that a TTP needn't
be monolithic.

Main point is that there *is* an accepted way to use this term, and
yours is not it.

For DKIM, the DNS is a TTP.

Stephen.

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 5 Jul 2006 21:26:54 -0400

>where they're as well understood as this one.

+1. Doug's new definition is not useful to us.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Douglas Otis <[email-masked]>
Date: Thu, 6 Jul 2006 10:00:53 -0700

On Jul 5, 2006, at 6:35 PM, Stephen Farrell wrote:

>> facilitates interactions between two parties who both trust the  
>> third party; they use this trust to secure their own interactions.  
>> TTPs are common in cryptographic protocols, for example, a  
>> certificate authority (CA).
>> ---
>> expectation this domain name represents a tangible entity or  
>> offers meaningful recourse.
>
> Irrelevant.

Setting expectations within the base draft remains important, where  
the current language seems balanced.  General expectations related to  
typical trusted third-party services usually resolve an identifier to  
something tangible.  This is not a property of DNS.  Describing DNS  
as a trusted third-party and equivalent to the usual trusted  
certificate authorities produces inappropriately high expectations.

>> There are thousands of entities involved in these associations,  
>> where the basis is often limited to just the domain name itself.    
>> It is difficult to consider an amalgam of often anonymous entities  
>> a "trusted third party" for "securing" email interactions.  Use of  
>> DNS by DKIM certainly falls short of the expectations of a TTP as  
>> set by Certificate Authorities or the example given of a notary  
>> public.  For DKIM to offer security, a separate assessment of the  
>> DKIM domain name should be made (likely by a TTP).  In that sense  
>> of trust or "securing" interactions, DNS fails this definition of  
>> TTP for email in my view.
>
> Perhaps you haven't been involved in the fairly tedious exercise of  
> engineering one of these, e.g. when I worked for a large German  

While a service need not monolithic, the criteria established for the  
RA in your example likely was based upon tangible entities.  If there  
was a problem, there would also be meaningful recourse.  DNS domain  
delegations and email interactions are orthogonal from a trust  
standpoint.  While DNS could be called at TTP with respect to domain  
delegations (to and by often anonymous entities), with respect to  
email interactions, trust is missing.  When DKIM is based upon DNS  
keys, either pre-arranged acceptance (white-listing), or some other  
trusted third-party remains essential for secure email interactions.

> For DKIM, the DNS is a TTP.

The use of this TTP term with respect to DKIM and DNS creates false  
expectations in regard to what DKIM signature verification might  
imply.  While technically this term could be applied, it remains  
misleading.

-Doug

---

From: Eliot Lear <[email-masked]>
Date: Fri, 07 Jul 2006 04:20:12 +0200

Doug,
> trusted third-party remains essential for secure email interactions.
I don't see how you get here.  First of all, why is trust missing with
respect to email interactions?  There is already a reliance on DNS
because of MX records, and so there already needs to be an established
relationship between the domain administrator and the mail
administrator.  There are, typically, not countless interactions that
then occur, but the number of DNS delegations worth of interactions, and
for outside the organization that is typically two, and they're anything
but anonymous.  While the level of trust one invests in DNS is always a
matter of judgment, depending on how paranoid one wants to be about each
of the delegations one could use DNSSEC, if/when it becomes available
for a given zone.

All of this having been said, your use of the words "secure email
interactions" overstates the purpose of the method.

Eliot

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 07 Jul 2006 20:02:34 +0100

Folks,

Douglas Otis wrote:
>  Indeed DNS does not offer a reasonable method to exclude bad
> actors (secure), where a trusted third-party does.

Doug is again insisting on grappling gamely with the wrong end
of the stick.

The rest of the world however knows that a ttp in an Alice/Bob
crypto protocol is any entity they trust who can hurt them by
misbehaving. For dkim the dns is such a beast since it can
supply Bob with the wrong keys for the wrong domains. I think
a sufficient number of people have agreed with the above that
we no longer need debate the fact.

If anyone else wants to assert that the dns is not a ttp for dkim
then please do so, saying why, and we can have a fun, but basically
unprodutive discussion.

Otherwise we should get back to the point, which was put best by
Mike I think - should base mention the dns' role as a ttp at all,
and if so how?

Stephen.

---

From: Douglas Otis <[email-masked]>
Date: Fri, 7 Jul 2006 10:54:23 -0700

On Jul 6, 2006, at 7:20 PM, Eliot Lear wrote:

>> While a service need not monolithic, the criteria established for  
>> the RA in your example likely was based upon tangible entities.   
>> If there was a problem, there would also be meaningful recourse.   
>> DNS domain delegations and email interactions are orthogonal from  
>> a trust standpoint.  While DNS could be called at TTP with respect  
>> to domain delegations (to and by often anonymous entities), with  
>> respect to email interactions, trust is missing.  When DKIM is  
>> based upon DNS keys, either pre-arranged acceptance (white- 
>> listing), or some other trusted third-party remains essential for  
>> secure email interactions.
>
> I don't see how you get here.  First of all, why is trust missing  
> with respect to email interactions?

The CA identification process helps prevent anonymous behaviors.   
When dealing with a CA or a list of CAs, the CA selection is often  
based upon trust of their vetting process, hence the term trusted  
third-party.  As a result, the receiving party, CA, and a legal  
system are better able to mitigate bad behaviors. In other words,  
there is a moderate amount of recourse afforded when only trusted CAs  
are consulted to secure interactions.

In the case of an SSL server certificate for commerce, the CA can be  
trusted to:
- Confirm entity registration identification which includes location
- Confirm the domain is owned or controlled by the registering entity
- a 3rd party confirms the requester is an authorized agent of  
registering entity

> There is already a reliance on DNS because of MX records, and so  
> there already needs to be an established relationship between the  
> domain  administrator and the mail administrator.

DNS provides a delegation process starting at root resolving to a  
name server located by domain name.  There may not be any out-of-band  
information freely offered identifying the controlling entity's  
identity.  It is common for delegations of just one domain name to  
involve from dozens to hundreds of different entities, where again  
little is assured with respect to any of the delegating entity's  
identity either.

A delegation process is not the same as trusting a vetting process  
that specifically provides a tangible identity of the controlling  
entity.  In the case of DNS, there is _no_ selective trust involved.   
When this process involves hundreds of thousands of often anonymous  
entities, it seems rather misleading to describe that process as a  
"trusted third-party."  Expected to resolve a domain name is not the  
same as trusted to vet the identity of the controlling entity, an  
expectation invoked by the term "trusted third-party" and illustrated  
by the definition.

> There are, typically, not countless interactions that then occur,  
> but the number of DNS delegations worth of interactions, and for  
> outside the organization that is typically two, and they're  
> anything but anonymous.

This represents an underestimate of the problem.

See:
http://www.cs.cornell.edu/People/egs/beehive/dnssurvey.html

Limited access of whois:
http://www.pfir.org/statements/whois-access

Not anonymous?
http://www.fbi.gov/congress/congress03/farnan090403.htm
"As I’ve indicated, sometimes the Whois data is inaccurate,  
incomplete, outdated, or deliberately falsified."

The whois information can _not_ be trusted even when it is available!

> While the level of trust one invests in DNS is always a matter of  
> judgment, depending on how paranoid one wants to be about each of  
> the delegations one could use DNSSEC, if/when it becomes available  
> for a given zone.

DNSSEC improves the integrity of the delegation process and exchange  
of resource records.  It does not improve upon extremely poor  
identification vetting that might not even be available to the  
recipient.  The untrustworthy identification associated with DNS  
means it is very misleading to describe DNS as a trusted third-party  
analogous to a trusted CA.

> interactions" overstates the purpose of the method.

This comment used terminology offered by the definition provide by  
Stephen.  Indeed DNS does not offer a reasonable method to exclude  
bad actors (secure), where a trusted third-party does.

-Doug

---

From: Eric Allman <[email-masked]>
Date: Fri, 07 Jul 2006 13:25:46 -0700

--On July 4, 2006 6:58:59 PM +0000 John Levine <[email-masked]> wrote:
> ...
>
> If you want a consensus statement, I'd say that l= permits the
> sender to indicate that there may be unsigned material after the
> end of the signed body and leave it at that.
>
> I would not be eager to leave in the advice on ways to make it
> harder for bad guys to do bad things by adding hostile MIME content
> after the signed part.  We don't understand the attack routes very
> well and I wouldn't want to create the impression that if senders
> follow our advice, then l= is "safe".

Actually the intent of the wording is to make it clear to the reader 
that the l= option is /not/ safe in the general case.

eric

---

From: "Hector Santos" <[email-masked]>
Date: Fri, 7 Jul 2006 16:53:03 -0400

----- Original Message -----
From: "Stephen Farrell" <[email-masked]>
To: "ietf-dkim" <[email-masked]>

> Mike I think - should base mention the dns' role as a ttp at all,

Stephen,

I think TTP is a bad acronym. It is more like a trusted storage medium for
exposed domain resource information. The trust is that who ever put it there
directly reflects the domain it is associated with. We can not nor do we
operate under the presumption that the information was "fake" or put there
without the direct knowledge of the domain.

One of the fundamental issues I have the narrow DKIM base only focus is the
lack of protocol automation especially when it comes faults.

With DKIM, it is fundamentally incorrect to compare this, as another person
here did with MX operations.  With MX, we have concrete rules to help the
automation of SMTP.  e.g., the "NO MX RECORD(S), TRY A RECORD ATLEAST ONCE"
rule. This sort of protocol logic is lacking with DKIM.

In my view, it is more about what the verifier expects from the DKIM related
DNS information. There is no reason to believe the data in DNS is not who it
said it came from.  It is more what do you do with the information that is
there or more importantly, and highly neglected, not there or does not match
the expectations of the verifier.

How does the DKIM markings relate with the DNS information?

What if there is no DNS information?

What if there was suppose to be no DKIM consideration?

What if the DNS information does not validate the MESSAGE?

And so on.

In conclusion, maybe the following or something like it may be considered:

 "DNS has a historical implied trust as a trusted distributed
  storage medium to access or obtain domain resource information.
  There is no practical reason to presume the information is
  maliciously faulty unless the domain's security and DNS
  administrative network has been directly violated."

and/or combined or separate:

 "The DKIM related DNS information is EXPECTED to correlate with
  the DKIM signatures in the messages in order to correctly validate
  the message.  When the DNS information does not correlate with the
  validation of the DKIM signed message, this aspect of the BASE
  PROTOCOL is indeterminate (out of scope)."

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

---

From: Eliot Lear <[email-masked]>
Date: Fri, 07 Jul 2006 22:59:18 +0200

Douglas Otis wrote:
>>> the RA in your example likely was based upon tangible entities.  If
>>> there was a problem, there would also be meaningful recourse.  DNS
>>> domain delegations and email interactions are orthogonal from a
>>> trust standpoint.  While DNS could be called at TTP with respect to
>>> domain delegations (to and by often anonymous entities), with
>>> respect to email interactions, trust is missing.  When DKIM is based
>>> upon DNS keys, either pre-arranged acceptance (white-listing), or
>>> some other trusted third-party remains essential for secure email
>>> interactions.
>>
> The CA identification process helps prevent anonymous behaviors.  When
> dealing with a CA or a list of CAs, the CA selection is often based
> upon trust of their vetting process, hence the term trusted
> third-party.  As a result, the receiving party, CA, and a legal system
> are better able to mitigate bad behaviors. In other words, there is a
> moderate amount of recourse afforded when only trusted CAs are
> consulted to secure interactions.
>
> DNS provides a delegation process starting at root resolving to a name
> server located by domain name.  There may not be any out-of-band

All this is true, but this is what reputation services are for.  One
could even imagine a reputation service that took registrar practices
into account.  And now we really are covering old ground.

>
>> There are, typically, not countless interactions that then occur, but
>> the number of DNS delegations worth of interactions, and for outside
>> the organization that is typically two, and they're anything but
>> anonymous.
>

These statements are registrar specific and cannot be generalized.
>> judgment, depending on how paranoid one wants to be about each of the
>> delegations one could use DNSSEC, if/when it becomes available for a
>> given zone.
>
> recipient.  The untrustworthy identification associated with DNS means
> it is very misleading to describe DNS as a trusted third-party

Every problem you've mentioned with DNS can occur with CAs.  Heck I run
my own.  What makes you think you can trust me?!

> Stephen.  Indeed DNS does not offer a reasonable method to exclude bad

Reiterating, every problem you state really has nothing to do with DNS
but with registration.  That problem is universal, regardless of
mechanism.  To be fair CAs have a few more gizmos to play with, but the
notion of delegation and registration remains the same.

Eliot

---

From: Eric Allman <[email-masked]>
Date: Fri, 07 Jul 2006 14:11:47 -0700

--On July 4, 2006 10:40:38 AM +0100 Stephen Farrell >>> #1 saying 
"proof" and "non-repudiation" in the abstract is a
>> not  willing to make this change without discussion of some
>> proposed wording.
>

Personally I have no problem with making a modification, but given 
the sensitivity of this wording I don't feel I can just come up with 
it myself.  Perhaps we should have this as a (hopefully short) agenda 
item in Montreal.

>> you want to  count the root servers, I suppose).  By this logic,
>> we should also  include the multiple third parties that run the
>> routers and all the rest  of the infrastructure.
>
> In my little PKI-riddled mind, the DNS is a TTP since it supplies
> the public keys and if/when DNSSEC were used, it starts to look
> quite like a PKI. The routers etc. won't ever really be supplying
> signed key records. But if no-one else thinks the same, leaving
> as-is if of course right.

I think of TTP as an administrative entity, not as a piece of 
software.  If I have a key service controlled by the owner of that 
key, then I don't have a third party at all, even if there is another 
piece of software involved.

As soon as the key data is in the hands of a third party then the 
situation changes.  I guess that implies that if I outsource my DNS 
then there in fact is a TTP.  But I can outsource my mail system 
today and people don't seem to deem that to be a TTP situation even 
if it really is once you peek under the hood.  But outsourcing isn't 
a requirement for DKIM, even if someone might choose to implement it 
that way.

Hmm...  given the amount of heat this has generated, the best thing 
is probably to say "does not require any additional TTPs" and leave 
it at that.

>> Adding the specific reference was specifically requested by
>> another  reviewer --- in fact, I think your proposal changes it
>> back to almost  exactly what was objected to before.  I think this
>> requires some  discussion.
>
> it, you could change text suggestion to: "The signature is
> calculated using the RSA signature algorithm as specified in PKCS#1
> version 1.5 [RFC3447], and with a fixed public exponent of 65537 -
> if a different public exponent is required, then a new DKIM signing
> algorithm tag value must be defined."

I made the change as you suggest --- but this left me wondering: when 
you use openssl "genrsa", does that produce something that contains 
the exponent or not?  If it does, then we shouldn't be mentioning 
65537 at all.  If that is implied, then we should.  [IIRC I got this 
wording from Jon --- perhaps he can add something.]

>>> function. The end result is that the dkim programmer calls
>>> "hash()" once and either "sign()" or "verify()" once. Suggest
>>> adding a sentence along these lines to clear that up. If someone
>>> ever calculated "sign(hash())" then they'd be wrong and this text
>>> sort of suggests that. Similar comment about the pseudo-code at
>>> the end where I'd rather see something like:
>>>
>> look  like, it's about what algorithms have to be applied and
>> when. For  example, I can easily see your change being interpreted
>> to mean that you  don't hash the header at all.
>

I added:

        INFORMATIVE NOTE:  Many digital signature APIs provide both
        hashing and application of the RSA private key using a single
        "sign()" primitive.  When using such an API the last two
        steps in the algorithm would probably be combined into a
        single call that would perform both the hash-alg and the
        sign-alg.

>> unexpectedly."   In fact, the usual way of dropping a key would be
>> to drop the record  entirely.  Otherwise you would have
>> ever-growing name spaces.
>

I guess we're not completely clear on that either way.  I changed it 
to "revoked or removed" to cover all the bases.

> I appreciate that, but I bet it'd still slow down base's road

OK, I pulled it.

> it may change in all sorts of ways, including the name of the header

OK, I used an abstract model.  It happens to be the same as the 
Auth-Res draft using X-Authentication-Results instead of 
Authentication-Results, but honest, it's just something I pulled out 
of thin air.

Seriously, I think it is good to show the kind of information you 
should plan on conveying.  I could reorder or shuffle the syntax a 
bit, but that adds nothing and might imply to someone who implements 
from examples that there is some other formal form they should be 
using.

>> Sorry, I don't see any signatures coming from the IETF MTA.  Can
>> you be  more specific?
>
> If I go to a conference or IETF, then I generally use its smtp
> server. If someone was used to mail from me being signed by tcd.ie
> and suddenly see mail from me signed by ietf66.org they might react
> badly. I don't want that to happen. (I know that the IETF meeting
> server doesn't sign now, but I guess it may in future.)
>
> So, my point was that I didn't see an example/use-case that mapped
> to the one above.

Well, depending on how you look at it, B.6 (Third-party Message 
Transmission) might cover it.  Alternatively, we could add a B.7 that 
explicitly discusses the "hotel room" problem.  The two are very 
close but not quite identical.

Any thoughts?

>>> disagree. In any case, the text says 768 and the command line
>>> 1024, no  password handling is shown and the last part could
>>> confuse since that signature is not usable for DKIM. So if this
>>> isn't deleted, then a bunch of changes are needed.
>>
> If we're going to give this kind of help, we don't want it to
> encourage people to take less secure options without being clear
> that that's what they're doing.

So are you saying that the genrsa step should be using -passin?  I 
can see that as an optional step that we could discuss, but it's not 
strictly required for the algorithm to work.

> ...
>
>>> #6 3.6.1 "k=" says that the public key is in the "p=" value, but
>>> its actually the modulus.
>>

See my question above about the exponent.

eric

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 07 Jul 2006 22:38:12 +0100

Hi Eric,

Eric Allman wrote:
> Personally I have no problem with making a modification, but given the 
> sensitivity of this wording I don't feel I can just come up with it 
> myself.  Perhaps we should have this as a (hopefully short) agenda item 
> in Montreal.

Sure.

> I think of TTP as an administrative entity, not as a piece of software.  
> If I have a key service controlled by the owner of that key, then I 
> don't have a third party at all, even if there is another piece of 
> software involved.
> 
> situation changes.  I guess that implies that if I outsource my DNS then 
> there in fact is a TTP.  But I can outsource my mail system today and 
> people don't seem to deem that to be a TTP situation even if it really 
> is once you peek under the hood.  But outsourcing isn't a requirement 
> for DKIM, even if someone might choose to implement it that way.
> 
> Hmm...  given the amount of heat this has generated, the best thing is 
> probably to say "does not require any additional TTPs" and leave it at 
> that.

Works for me.

> you use openssl "genrsa", does that produce something that contains the 
> exponent or not?  If it does, then we shouldn't be mentioning 65537 at 
> all.  If that is implied, then we should.  [IIRC I got this wording from 
> Jon --- perhaps he can add something.]

Yes it does. The AQAB at the end is the b64 of a binary 65537, so
ignore pretty much most of what I said about exponents for now and
I'll try work some text with you next week. (Or if Jon gets in
first that's good too.)

>        single call that would perform both the hash-alg and the

Great.

> I guess we're not completely clear on that either way.  I changed it to 
> "revoked or removed" to cover all the bases.

Ok.

Ok.

> OK, I used an abstract model.  It happens to be the same as the Auth-Res 
> draft using X-Authentication-Results instead of Authentication-Results, 
> but honest, it's just something I pulled out of thin air.
> 
> Seriously, I think it is good to show the kind of information you should 
> plan on conveying.  I could reorder or shuffle the syntax a bit, but 
> that adds nothing and might imply to someone who implements from 
> examples that there is some other formal form they should be using.

I guess we'll have to see.

> explicitly discusses the "hotel room" problem.  The two are very close 
> but not quite identical.
> 
> Any thoughts?

Yep. No text yet though;-) Maybe next week if no-one else gets to
it first.

> So are you saying that the genrsa step should be using -passin?  I can 
> see that as an optional step that we could discuss, but it's not 

Right. But if we show an example that doesn't use passphrases we
should say in the text that this can be problematic.

Cheers,
S.

---

From: Douglas Otis <[email-masked]>
Date: Fri, 7 Jul 2006 14:53:33 -0700

On Jul 7, 2006, at 12:02 PM, Stephen Farrell wrote:

> Doug is again insisting on grappling gamely with the wrong end of  
> the stick.
>
> misbehaving.

Agreed.  However trust established with a third-party is typically  
based upon their vetting of an identity against something tangible.   
When there is bad behavior, confirmed tangible identifiers provide a  
means for accountability.  As a result, bad actors are more readily  
excluded to better secure interactions.  There is also accreditation  
by an trusted third party that holds the entity accountable by de- 
listing.  There is also reputation that holds the entity accountable  
by listing.  Accreditation or reputation could also be considered  
trusted third-parties but doe not impose a need to offer tangible  
identifiers related to the domain name.  Vetting the identity against  
something tangible provides more pro-active protections, assuming the  
recipient or the CA makes the effort to correlate these identifiers.

> For dkim the dns is such a beast since it can supply Bob with the  
> wrong keys for the wrong domains. I think a sufficient number of  
> people have agreed with the above that we no longer need debate the  
> fact.

The concern is the vetting of identities against something tangible.   
This issue of trusted vetting by a third-party is completely separate  
from the integrity of DNS itself.  When Bob can easily reappear as  
another domain name without any confirmed tangible identifiers,  
securing email interactions away from bad actors remains futile.   
Without some trusted third-party, DNS will not offer a reasonable  
means to exclude bad actors.  Perhaps whois could someday perform  
this role as a trusted third-party, or some other third-party service  
could be used, such as a trusted CA, or accreditation et al perhaps.   
DNS simply does not ensure tangible identifiers are associated with  
the controlling entity of the domain name.  DKIM provides a verified  
domain domain that can be checked against a trusted third-party  
service.  Do not confuse DNS as being analogous to a TTP service  
however.

> Mike I think - should base mention the dns' role as a ttp at all,  

No. Not at all. It would be misleading.

-Doug

---

From: Douglas Otis <[email-masked]>
Date: Fri, 7 Jul 2006 15:19:05 -0700

On Jul 7, 2006, at 1:59 PM, Eliot Lear wrote:

>> DNSSEC improves the integrity of the delegation process and  
>> exchange of resource records.  It does not improve upon extremely  
>> poor identification vetting that might not even be available to  
>> the recipient.  The untrustworthy identification associated with  
>> DNS means it is very misleading to describe DNS as a trusted third- 
>> party analogous to a trusted CA.
>
> Every problem you've mentioned with DNS can occur with CAs.  Heck I  
> run my own.  What makes you think you can trust me?!

The key term here is trusted.  You may offer CA services, but  
competence and general acceptance will determine whether the service  
becomes and remains trusted.

> Reiterating, every problem you state really has nothing to do with  
> DNS but with registration.

Exactly.  How is the registration of domain names separate from the  
delegation of domain names?  Can a bad actor by any other domain name  
still be held accountable?  Unfortunately, no.

> That problem is universal, regardless of mechanism.  To be fair CAs  
> have a few more gizmos to play with, but the notion of delegation  
> and registration remains the same.

Those that are competent at vetting identities against tangible  
elements will become and remain trusted.  With DNS, there is a  
notable lack of choice in the matter of trust, and currently every  
reason to consider the DNS registration process itself is not held  
accountable.  Perhaps the lack of accountability with domain name  
registration is due to the lack of choice.  It would be very  
misleading to declare DNS replaces a trusted CA, for example.  DKIM  
verifies a domain name that can be readily checked against various  
lists and trusted third party services.  DNS and its associated  
registration process should not be trusted at this time to have  
vetted identities against tangible elements when securing  
interactions and establishing accountability.

-Doug

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 07 Jul 2006 16:09:01 -0700

> wording from Jon --- perhaps he can add something.]

I don't agree that this is the appropriate test. The correct
test is what the right engineering choice is, and that's
clearly to use a PKCS#1 PublicKey struct. What would happen
if OpenSSL emitted some totally nonstandard thing?
That said, what openssl emits *is* a PKCS#1 public key
struct.

> strictly required for the algorithm to work.

Frankly, I don't think the password advice makes much sense.
You in general want your server to restart unattended
This means that the key needs to be available without
some clown at the console typing the password. So, either
you don't use a password or you wire it into some config
file or script, at which point the question becomes why
you didn't just protect the key with whatever file permissions
protect the password.

-Ekr

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 08 Jul 2006 11:44:44 +0100

> you didn't just protect the key with whatever file permissions

Sure - what I was asking was only that it be stated that the
example is showing a s/w key store with no passphrase and
maybe also say that using h/w crypto for servers is better.

S.

---

From: Dave Crocker <[email-masked]>
Date: Sun, 30 Jul 2006 09:13:28 -0700

> For DKIM, the DNS is a TTP.

Unless keys are queried through a different mechanism?

(Given the desire to allow extensibility in the choice of query mechanisms, it
is worth being very clear about this.)

The DNS name *registration* mechanism is inherently essential to DKIM.

The DNS name *query* mechanism is certainly going to be essential to initial
operation, but is it an inherent requirement long-term?

d/
-- 

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

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 30 Jul 2006 17:15:39 +0100

> Unless keys are queried through a different mechanism?

Yep, agreed.

S.

---

From: <[email-masked]>
Date: Sun, 30 Jul 2006 12:25:45 -0400

The query mechanism could certainly point to an alternate retrieval
mechanism such as http for long policy statements. 
Thanks,

Bill Oxley 
Messaging Engineer 
Cox Communications, Inc. 
Alpharetta GA 
404-847-6397 
[email-masked] 

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Dave Crocker
Sent: Sunday, July 30, 2006 12:13 PM
To: Stephen Farrell
Cc: ietf-dkim
Subject: Re: DKIM TTPs (was Re: [ietf-dkim] editorials and nits)

(Given the desire to allow extensibility in the choice of query
mechanisms, it
is worth being very clear about this.)

The DNS name *query* mechanism is certainly going to be essential to
initial
operation, but is it an inherent requirement long-term?

d/
-- 

  Dave Crocker

---

From: Dave Crocker <[email-masked]>
Date: Sun, 30 Jul 2006 09:31:37 -0700

> mechanism such as http for long policy statements. 

What I was referring to was having q= point to something other than DNS, at
which point, DKIM would have no dependence on DNS query, though the dependence
on DNS registration would of course remain.

d/
-- 

  Dave Crocker