DomainKeys Identified Mail (DKIM) Signatures
draft-ietf-dkim-base-10

[Ballot discuss]
Taking over one of Lisa's discuss items - Want to add some text to say that if you have some valid signatures, and some invalid signatures, you can't use the invalid signatures to figure out what changed in the message to break the broken signatures.

Agreed to add text "The list of unacceptable domains SHOULD be configurable."

[Ballot discuss]
The advice on which canonical form to use or to add a l= or not is still pretty hard for an implementor to know what to do. I'm working with Lisa on figuring out what to do here - it may end up being just leave it like it is.

I am worried the following text is not going to resolve the concern about compromising the whole .com space
  Verifiers MAY ignore the DKIM-Signature header field if the domain
  used by the signer in the d= tag is not associated with a valid
  signing entity.  For example, signatures with d= values such as "com"
  and "co.uk" may be ignored.
Would you be willing to add to this paragraph the sentence.
  Implementation SHOULD have a configurable list of such domains.
or some text along theses lines.

[Ballot comment]
When using the relaxed algorithm, is there an ascii art attack? Something like I send you an email with "a b c d", you reply saying it is messed up, then I use your signature on the reply and edit the space to say "Buy CSCO" and send it out. If this is an valid attack, it should be added to security section.

Section 3.3.1 says low value exponents are believed to be subject to attack - could you add an information reference here. Is 17 a low exponent?

[Ballot discuss]
I have not completed review of 08 version but I said I would get some comments out today so I am trying to update what I did get done. I see an incredible number of my concerns were dealt with. Some of the remaining ones I think are places where I have not been clear enough and we might need a bit of phone time.


I really like the new section 5.4.1 - Thank you. I would like it to recommend a canonical form. I also think that the phrase "nearly all of the body content" is too vague for implementers to know what you mean. Can you make this more specific. It also does not seem to specify if l= should be used or not.

I see the addition of 8.13 but it does not seem to address the concern here - I'd really like to talk about a proposed resolution to this on the phone. I'd like to talk about the options of requiring verifiers should be required to have a policy of not accepting signatures from unlikely domains such as ".com". Failing to do this creates a huge incentive to mange to get control of _domainkey.com and add unreasonable burdens on the people that would need to stop that from happening.


This uses _domainkey and the WG seem like it will be defining more of these. To make sure this does not conflict with other usages, it seems like we need an IANA register for the _domainkey.


I see some changes were made on this but the document still seem to contradict itself. Note, I'm fine with what you seem to be proposing as the solution, it just seems the document needs to updates on this.
Section 6.1 and other places, the text discussed SMTP rejections. This seems to conflict with the text that claims that "signature verification failure does not result in rejection of the message". I suspect you want to remove all this stuff about SMTP rejections but one way or another the document needs to not contradict itself.

[Ballot comment]
I think this specification is an important step in exploring how to
deal with unwanted email.  I'm not sure how that exploration will work
out; I'm not sure that this technology will ultimately be useful.
However I am sure that the exploration will be useful and this spec
meets the goals of  a proposed standard in that space.
So I'm voting yes.
Thanks for addressing my discuss comments.

[Ballot discuss]
I have not completed review of 08 version but I said I would get some comments out today so I am trying to update what I did get done. I see an incredible number of my concerns were dealt with. Some of the remaining ones I think are places where I have not been clear enough and we might need a bit of phone time.


I really like the new section 5.4.1 - Thank you. I would like it to recommend a canonical form. I also think that the phrase "nearly all of the body content" is too vague for implementers to know what you mean. Can you make this more specific. It also does not seem to specify if l= should be used or not.

I see the addition of 8.13 but it does not seem to address the concern here - I'd really like to talk about a proposed resolution to this on the phone. I'd like to talk about the options of requiring verifiers should be required to have a policy of not accepting signatures from unlikely domains such as ".com". Failing to do this creates a huge incentive to mange to get control of _domainkey.com and add unreasonable burdens on the people that would need to stop that from happening.


This uses _domainkey and the WG seem like it will be defining more of these. To make sure this does not conflict with other usages, it seems like we need an IANA register for the _domainkey.


I see some changes were made on this but the document still seem to contradict itself. Note, I'm fine with what you seem to be proposing as the solution, it just seems the document needs to updates on this.
Section 6.1 and other places, the text discussed SMTP rejections. This seems to conflict with the text that claims that "signature verification failure does not result in rejection of the message". I suspect you want to remove all this stuff about SMTP rejections but one way or another the document needs to not contradict itself.


I'm still waiting to hear back from some folks on security so I have not updated this paragraph but you can ignore it for now. The security section needs to analyze the threats that have been identified and explain if they are easy attacks or not and what mitigations can be made against them. In particular I am looking for things like how easy is to mount attacks identified in section 4.1.12 of RFC 4686. Do these DNS changing attacks work a small percentage of the time or a large percentage of the time. How relevant are the DNS name chaining attacks and can anything be done about them? More details on this in my comments. We need enough information here that it's possible to evaluate if this security protocol reasonably meets the goal of allowing a verifier to know that a certain domain is taking responsibility for an email.

[Ballot discuss]
I really like the new section 5.4.1 - Thank you. I would like it to recommend a canonical form. I also think that the phrase "nearly all of the body content" is too vague for implementers to know what you mean. Can you make this more specific. It also does not seem to specify if l= should be used or not.

I see the addition of 8.13 but it does not seem to address the concern here - I'd really like to talk about a proposed resolution to this on the phone. I'd like to talk about the options of requiring verifiers should be required to have a policy of not accepting signatures from unlikely domains such as ".com". Failing to do this creates a huge incentive to mange to get control of _domainkey.com and add unreasonable burdens on the people that would need to stop that from happening.


This uses _domainkey and the WG seem like it will be defining more of these. To make sure this does not conflict with other usages, it seems like we need an IANA register for the _domainkey.


I see some changes were made on this but the document still seem to contradict itself. Note, I'm fine with what you seem to be proposing as the solution, it just seems the document needs to updates on this.
Section 6.1 and other places, the text discussed SMTP rejections. This seems to conflict with the text that claims that "signature verification failure does not result in rejection of the message". I suspect you want to remove all this stuff about SMTP rejections but one way or another the document needs to not contradict itself.


I'm still waiting to hear back from some folks on security so I have not updated this paragraph but you can ignore it for now. The security section needs to analyze the threats that have been identified and explain if they are easy attacks or not and what mitigations can be made against them. In particular I am looking for things like how easy is to mount attacks identified in section 4.1.12 of RFC 4686. Do these DNS changing attacks work a small percentage of the time or a large percentage of the time. How relevant are the DNS name chaining attacks and can anything be done about them? More details on this in my comments. We need enough information here that it's possible to evaluate if this security protocol reasonably meets the goal of allowing a verifier to know that a certain domain is taking responsibility for an email.

[Ballot discuss]
I really like the new section 5.4.1 - Thank you. I would like it to recommend a canonical form. I also think that the phrase "nearly all of the body content" is too vague for implementers to know what you mean. Can you make this more specific. It also does not seem to specify if l= should be used or not.

I see the addition of 8.13 but it does not seem to address the concern here - I'd really like to talk about a proposed resolution to this on the phone. I'd like to talk about the options of requiring verifiers should be required to have a policy of not accepting signatures from unlikely domains such as ".com". Failing to do this creates a huge incentive to mange to get control of _domainkey.com and add unreasonable burdens on the people that would need to stop that from happening.


This uses _domainkey and the WG seem like it will be defining more of these. To make sure this does not conflict with other usages, it seems like we need an IANA register for the _domainkey.


I see some changes were made on this but the document still seem to contradict itself. Note, I'm fine with what you seem to be proposing as the solution, it just seems the document needs to updates on this.
Section 6.1 and other places, the text discussed SMTP rejections. This seems to conflict with the text that claims that "signature verification failure does not result in rejection of the message". I suspect you want to remove all this stuff about SMTP rejections but one way or another the document needs to not contradict itself.


I'm still waiting to hear back from some folks on security so I have not updated this paragraph but you can ignore it for now. The security section needs to analyze the threats that have been identified and explain if they are easy attacks or not and what mitigations can be made against them. In particular I am looking for things like how easy is to mount attacks identified in section 4.1.12 of RFC 4686. Do these DNS changing attacks work a small percentage of the time or a large percentage of the time. How relevant are the DNS name chaining attacks and can anything be done about them? More details on this in my comments. We need enough information here that it's possible to evaluate if this security protocol reasonably meets the goal of allowing a verifier to know that a certain domain is taking responsibility for an email.

[Ballot comment]
When using the relaxed algorithm, is there an ascii art attack? Something like I send you an email with "a b c d", you reply saying it is messed up, then I use your signature on the reply and edit the space to say "Buy CSCO" and send it out. If this is an valid attack, it should be added to security section.

Section 3.3.1 says low value exponents are believed to be subject to attack - could you add an information reference here. Is 17 a low exponent?

I have not managed to review the new draft for all my comments after this point so please ignore them for now.


And now some comments from Rob  -----------


With respect to Rob's comments on header reordering, please have the draft explain when it is a good idea to sign other DKIM signatures and when it is not.

I can not see why you would not do the following:
- The discussion of the signature timestamp (t= tag) never states
  explicitly that signatures MAY be considered invalid if the
signature
  timestamp is a date in the future.

Could we clarify how and when this is used so that people like Rob and I are not confused
- The revocation mechanism (empty p= value) described in section 3.6.1
  is puzzling.  It's not revocation as I understand the term, and
  doesn't revoke a particular key in any case, as there is no way to
  identify the key in question.  Rather, it seems to revoke the -name-
  of a key, or perhaps the combination of the name of a key and a set
  of other attributes (e.g., algorithms).  I can't picture any case in
  which publishing a "revocation" of this kind would be useful, so if
  the WG thinks that this mechanism serves some useful purpose, the
  draft really needs to explain much more clearly what that purpose
is.

I suspect that verifying at the border MTA reduces some of the DNS attacks such as the hotel case but agree with Rob that  this needs to be part of the security analysis.
- Section 6 encourages border MTAs to verify DKIM signatures to
  minimize the chance of a key having expired.  This could be read as
  an invitation to stage a denial of service attack on the border MTA.
  Section 6.1 briefly mentions denial of service attacks, but for some
  reason most of the discussion of denial of service attacks in the
  draft seems to be worried about delays due to DNS lookups rather
  than CPU time expended on signature checks.  Denial of service
  issues based on cryptographic computations aren't even mentioned in
  the Security Considerations section.  They should be, particularly
  if the draft is going to encourage verification at choke points like
  border MTAs.

- Section 6.1.2 should state explicitly that the v= tag associated
with
  the public key must match a known version.



Uh, yah, I think this one has quite a few people that agree with Rob
- The security considerations are mostly OK, but I find the section on
  DNS attacks (section 8.4) unconvincing.  To be blunt, this section
  falls somewhere between "whistling in the dark" and "utter hogwash".

  The claim that "the types of DNS attacks relevant to DKIM are very
  costly and are far less rewarding than DNS attacks on other Internet
  applications" is at best unsubstantiated (in the draft, anyway); the
  same applies to "an attacker must conduct a very costly and very
  extensive attack on many parts of the DNS over an extended period".
  If there are data to support these assertions, cite them, otherwise
  this kind of hand waving is inappropriate.

  Consider, for example, a name chaining attack (see RFC 3833 2.3).
  This is trivially easy to trigger in the DKIM case, as the intended
  victim (a DKIM verifier) looks up DNS names handed to it by
  strangers for a living).  So send two messages: the first is just a
  trigger for a name chaining attack to poison the verifier's cache
  with a bogus NS RRset and associated glue; the second message is the
  one you want to sneak past DKIM, which you do by handing back a
  forged key when the verifier follows the bogus NS data cached during
  processing of the first message.

  The verifier's only hope here, absent DNSSEC, is that its DNS
  resolver is clever enough to detect the name chaining attack, which
  is non-trivial -- there are heuristics one can apply, but they
  require assumptions not supported by the base DNS specifications,
  and there is no reason to believe that every implementation include
  such heuristics (or that they work even if they are included).

  As an advocate of DNSSEC, I'm pleased to see a use case being put
  forward which, if adopted, would tend to drive DNSSEC deployment (if
  only because otherwise it is such an attractive attack target), but
  the Security Considerations of this draft need to be honest about
  the risks.  At the moment, in my opinion, they are not.

- More generally, there are two classes of DNS attacks on the DKIM
  verification algorithm (skipping over DoS attacks on the DNS itself,
  processing delays while attempting to retrieve keys, etcetera):

  1) Break a key so that signature of legitimate mail doesn't
validate;

  2) Fake a key so that signature of illegitimate mail does validate.

  The chaining attack discussed above is an example of (2).  I'm less
  concerned with (1), as it's only one of many things that could go
  wrong during verification.

  It's worth noting, however, that reliance on insecure DNS does open
  one more path by which an attacker can break signatures of
  legitimate messages, and that, since DNS traffic and SMTP traffic
  may go by wildly different paths and involve otherwise unrelated
  machines, there are likely to be cases where it's easier for an
  attacker to modify an (unsigned) DKIM key in flight than it would be
  for that same attacker to interfere with the email message,
  particularly as DNS service often comes from a recursive name server
  not chosen by the user (see RFC 3833 2.4).



From Olafur -----------------

Is there any reason not to do the following?
  Recommendation:  I would like to see an informational
    application statement that references RFC2671, RFC3397 and says having
    modern DNS software that supports these standards will aid in the use of
    DKIM, and possibly also say RFC403[345] support is a good thing.


#3 Section 3.6.1
  I fail to see what the s= field adds other than add hooks in there to
  expand the use of a key. IMHO this is a bad idea, DKIM is defined for
  MTA to MTA use ONLY, having hooks in there for other uses is out of
  scope and the justification is weak.
  As the only place where this field is discussed is in "Textual
  Representation" and "IANA considerations" (by creating a new sub registry),
  there is no guidance on future uses of this field.
  Please remove this field.

  IESG Discuss on this issue is strongly recommended!

I want to talk about the following one. If we can bias work towards the bad guys, that seem desirable.
- Section 8
  There are number of attacks that are not covered:
  For example for RSA, an attacker can elect to have a large
  signing key with a small exponent, thus making the verification
  key have a large one.
  This inverts the work required, forcing recipients of the message to use
  much more computing resources to verify the signatures than attacker
  used to generate them. (This same threat applies to DNSSEC)
  I'm not sure how comprehensive the security considerations section should
  be on cryptographic issues. But in this case the use of RSA seems to be
  motivated by the fact it is easy to tune which party does more work, and
  the intent is to make the signer do the heavy work.

Olafur

-------------------------------------------------------------------------
I share Rob's concerns when he says

My specific concern was with section 8.4, which contains unsupported
bombast about how hard DNS attacks are without addressing known
threats such as name chaining attacks (RFC 3833 2.3).  In particular,
text such as:

  Secondly, the types of DNS attacks relevant to DKIM are very costly
  and are far less rewarding than DNS attacks on other Internet
  protocols.  For example, attacking A records (to force users to a
  phishing site) is likely to be a more lucrative reason to poison
  DNS caches.

and

  To systematically thwart the intent of DKIM, an attacker must conduct
  a very costly and very extensive attack on many parts of the DNS over
  an extended period.  No one knows for sure how attackers will
  respond, however the cost/benefit of conducting prolonged DNS attacks
  of this nature is expected to be uneconomical.

is not appropriate for this document, because:

a) it makes unsupported (and possibly untrue, depending on the
  software in use) assertions about costs;

b) it drags in a red herring (the subject here is security of DKIM,
  not phishing attacks or other internet protocols); and

c) it disregards a known form of attack that requires only that an
  attacker send two successive messages to the same MTA.

A qualification like "To systematically thwart the intent of DKIM"
includes terms of art and means whatever the author wants it to mean,
but I still think this section requires surgery.

As a practical matter, the most widely used iterative resolver
implementations do have non-DNSSEC defenses against name chaining
attacks, so the name chaining attack is not likely to be a huge
operational problem at the moment.  The danger, however, is that the
non-DNSSEC defenses against name chaining attacks are neither
documented in any RFC nor universally agreed upon, and there are
enough independent iterative resolver implementations out there these
days that there is no guarantee that all of them have this defense, or
that all of them will have it next year.  As I understand it, part of
the point of Security Considerations is to call out the known
weaknesses of a protocol so that implementors can avoid tripping over
them.  As long as DKIM relies on insecure DNS, this is a weakness, and
should be documented.

RFC 4686 4.1.12 mentions cache poisoning, but discusses it only as an
active attack on DNS; it completely misses cases like name chaining
attacks triggered by previous MTA activity, where the MTA's own normal
processing of a previous message causes the MTA to fetch the poisoned
data.  To me, this attack has sufficiently different properties from
an active DNS attack that it merits separate mention.

Section 8.4 also fails to mention the case of DNS service coming from
a recursive name server not chosen by the user (RFC 3833 2.4), e.g., a
DKIM verifier running in the MUA on a laptop at a hotel: in cases like
this the threat against the mail transfer path (IMAP or POP download
likely to be protected with TLS) is very different from the threat
against the DNS transfer path (completely at the hotel's mercy).

[Ballot comment]
I agree with most of Ted's comments.

In particular, I cannot ballot a NoObjection in a situation where
the protocol designers decided to use the TXT record while there was not a
convincing motivation to not use a new resource record.

Other comments that are not quite a DISCUSS:

In 'Abstract':

  ... either Mail Transfer Agents (MTAs) or Mail User Agents (MUAs). ...

MTA and MUA need a reference.

In section '3.3  Signing and Verification Algorithms':

      INFORMATIVE NOTE:  Although sha256 is strongly encouraged, some
      senders of low-security messages (such as routine newsletters) may
      prefer to use sha1 because of reduced CPU requirements to compute
      a sha1 hash.  In general, sha256 should always be used whenever
      possible.

Is the option of sha1 really needed? This argument doesn't sound very convincing as there is a lot of other processing for mail submission and delivery already. In addition, why would the receiving end be satisfied with this especially in the context of bulk mail.

In section '3.3.3  Key sizes':

      o  The practical constraint that large keys may not fit within a 512
        byte DNS UDP response packet

It seems a good idea to mention that this is in the context of ipv4.

[Ballot discuss]
The security section needs to analyze the threats that have been identified and explain if they are easy attacks or not and what mitigations can be made against them. In particular I am looking for things like how easy is to mount attacks identified in section 4.1.12 of RFC 4686. Do these DNS changing attacks work a small percentage of the time or a large percentage of the time. How relevant are the DNS name chaining attacks and can anything be done about them? More details on this in my comments. We need enough information here that it's possible to evaluate if this security protocol reasonably meets the goal of allowing a verifier to know that a certain domain is taking responsibility for an email.

To be able to implement a signer, we need advice on what to sign and how to do the canonical form along with recommendation for the rest of a choices a signer would need to make. The current draft explains the options but the WG needs to go a step further and actually make a choice about what would be at least one good signature that all signers are RECOMMENDED to include. I understand this is hard but I do not understand how anyone can implement useful verifiers without some minimal signing recommendations. I believe this working group is the best qualified group of people to pick a good tradeoff between having enough that the signatures are useful yet minimizing the amount of email that will end up with broken signatures due to issues around the currently deployed email system.

I'd like to talk about the options of requiring verifiers should be required to have a policy of not accepting signatures from unlikely domains such as ".com". Failing to do this creates a huge incentive to mange to get control of _domainkey.com and add unreasonable burdens on the people that would need to stop that from happening.

I think updates to the IANA registries should require a standards track document. Glad to talk about pros and cons of this.

This uses _domainkey and the WG seem like it will be defining more of these. o make sure this does not conflict with other usages, it seems like we need an IANA register for the _domainkey.

In the s= , I would rather not say this was appropriate for IM and VoIP without having something more concrete to discuss with that community.

Section 6.1 and other places, the text discussed SMTP rejections. This seems to conflict with the text that claims that "signature verification failure does not result in rejection of the message". I suspect you want to remove all this stuff about SMTP rejections but one way or another the document needs to not contradict itself.

In section 6.3 you say that if something verifies, it should be presented to user as simple binary result. I really wonder about this and suspect that this is not right. Something that did not sign the subject, or from and has l=0 seems like it deservers different presentation to the user. I do understand the users ability to interpret anything much more than a simple "lock" icon is pretty limited.

[Ballot comment]
I have worked through most of these comments with one of the authors so I hope folks can understand them but I could easily understand how some of them make no sense. I am glad to clarify, have phone calls, or do whatever is need to get these resolved. Cullen


Section 8.4
- I think lots of people believe there is a non trivial chance that DNS Sec will not end up security DNS

You say the attacks on DKIM are costly and prolonged. I think you need to explain these attacks and why they are costly and prolonged. The attacks of sending two email to a verifier and using the DNS fetch from the first as a timer to insert the spoofed DNS did not sound costly or prolonged to me.


I think of a certificate as a document that attests to the truth of something or the ownership of something. There are several places in the introduction saying this does not reply on any third parties or certificate authorities.  I don't think this is really true - DNS is acting as a CA here and DNS certainly relies on third parties. Can we adjust the text in these to bring it to a point we both agree is true and point out the current scheme does depend heavily on DNS for the security properties. Truth in advertising was one of the the key issues in formation of this WG.

When using the relaxed algorithm, is there an ascii art attack? Something like I send you an email with "a b c d", you reply saying it is messed up, then I use your signature on the reply and edit the space to say "Buy CSCO" and send it out. If this is an valid attack, it should be added to security section.

Add some information text discussing the expected sizes of the DNS records and if we expect TCP based DNS to be needed. I'm basically asking about what key sizes are likely to work with UDP based DNS.

Are any recommendation on DNS cache times needed?


Section 3.3.1 says low value exponents are believed to be subject to attack - could you add an information reference here. Is 17 a low exponent?

Section 3.4.5 - I get how the not including the --CRLF works for some MIME types but not others such as multipart/signed.


If you later want to have version numbers like 1.1, I think it would be better to move the version number of this to "1.0" instead of "1" - you will have less implementation bugs later. I don't understand the semantic difference of a version number changing by .1 instead of 1.0.

I think the ABNF for the sig-v-tag should allow the future values expected here not stick on 0.5.

Some of the other ABNF rules lack appropriate extensibility (for example, v tag) (most the rules look good)

Having l limited to 256 bits is a total hassle to implement and just seem too large. Could you limit it to 64 bits.

On the n= flag, do you need a lang tag for internationalization. If not, would be good to provide guidance this text is meant for administrators not end users. Any practical limits on size of this needed?

On the x tag, any advice for what a signer should put?

When should a z tag be used by a signer?


section 3.6.1

What type of regular expression are possible with the g= tag is not adequately specified. Can there be multiple *? do they match 1 or more or zero or more?

The open issue around using * even though that can be in dot-atom-text seem fairly significant. I can think of several ways of solving this which I imagined the WG discussed. I don't understand why this was not resolved.

End of section 3.7 mentions "dot stuffing" - can you add some more explanation to what this is.

In section 5.4 you mention signing Subject is highly advisable.  If so why not make it a SHOULD, if not then this might need to be changed.



Section 8.4 - I would have to question if it is true that the majority of people expect DNSSEC to solve DNS security problems.


I'm assuming that the example public and private keys, DNS records, and signatures in the back are all consistent with each-other and people can use them as test vectors - this really helps implementers. Is this assumption true?  Might be nice if A.2 mentioned it was signed with keys from C.




From Pekka ----------------

Concern here is that the following SHOULD are not implementable and are actually operational issues. I agree with Pekka that this is not clear if this is something an implementors needs to deal with or something the else. I think some small changes to the text could clarify this.

  Reusing a Selector with a new key (for example, changing the key
  associated with a user's name) makes it impossible to tell the
  difference between a message that didn't verify because the key is no
  longer valid versus a message that is actually forged.  Signers
  SHOULD NOT change the key associated with a Selector.  When creating
  a new key, signers SHOULD associate it with a new Selector.

==> it seems like 'Signer' here refers to a postmaster or whoever is in
charge of selecting Selectors.  Are these SHOULD conditions/enforcement
implementable, if so, how?  If this is purely operational guidance, I would
phrase it differently, without uppercase, such as 'Administrators should
not change the key associated with a Selector...'  On the other hand, if
this is meant as an implementation specification, maybe some rewording might
make it clearer how to implement it.



And now some comments from Rob  -----------


With respect to Rob's comments on header reordering, please have the draft explain when it is a good idea to sign other DKIM signatures and when it is not.

I can not see why you would not do the following:
- The discussion of the signature timestamp (t= tag) never states
  explicitly that signatures MAY be considered invalid if the
signature
  timestamp is a date in the future.

Could we clarify how and when this is used so that people like Rob and I are not confused
- The revocation mechanism (empty p= value) described in section 3.6.1
  is puzzling.  It's not revocation as I understand the term, and
  doesn't revoke a particular key in any case, as there is no way to
  identify the key in question.  Rather, it seems to revoke the -name-
  of a key, or perhaps the combination of the name of a key and a set
  of other attributes (e.g., algorithms).  I can't picture any case in
  which publishing a "revocation" of this kind would be useful, so if
  the WG thinks that this mechanism serves some useful purpose, the
  draft really needs to explain much more clearly what that purpose
is.

I suspect that verifying at the border MTA reduces some of the DNS attacks such as the hotel case but agree with Rob that  this needs to be part of the security analysis.
- Section 6 encourages border MTAs to verify DKIM signatures to
  minimize the chance of a key having expired.  This could be read as
  an invitation to stage a denial of service attack on the border MTA.
  Section 6.1 briefly mentions denial of service attacks, but for some
  reason most of the discussion of denial of service attacks in the
  draft seems to be worried about delays due to DNS lookups rather
  than CPU time expended on signature checks.  Denial of service
  issues based on cryptographic computations aren't even mentioned in
  the Security Considerations section.  They should be, particularly
  if the draft is going to encourage verification at choke points like
  border MTAs.

- Section 6.1.2 should state explicitly that the v= tag associated
with
  the public key must match a known version.



Uh, yah, I think this one has quite a few people that agree with Rob
- The security considerations are mostly OK, but I find the section on
  DNS attacks (section 8.4) unconvincing.  To be blunt, this section
  falls somewhere between "whistling in the dark" and "utter hogwash".

  The claim that "the types of DNS attacks relevant to DKIM are very
  costly and are far less rewarding than DNS attacks on other Internet
  applications" is at best unsubstantiated (in the draft, anyway); the
  same applies to "an attacker must conduct a very costly and very
  extensive attack on many parts of the DNS over an extended period".
  If there are data to support these assertions, cite them, otherwise
  this kind of hand waving is inappropriate.

  Consider, for example, a name chaining attack (see RFC 3833 2.3).
  This is trivially easy to trigger in the DKIM case, as the intended
  victim (a DKIM verifier) looks up DNS names handed to it by
  strangers for a living).  So send two messages: the first is just a
  trigger for a name chaining attack to poison the verifier's cache
  with a bogus NS RRset and associated glue; the second message is the
  one you want to sneak past DKIM, which you do by handing back a
  forged key when the verifier follows the bogus NS data cached during
  processing of the first message.

  The verifier's only hope here, absent DNSSEC, is that its DNS
  resolver is clever enough to detect the name chaining attack, which
  is non-trivial -- there are heuristics one can apply, but they
  require assumptions not supported by the base DNS specifications,
  and there is no reason to believe that every implementation include
  such heuristics (or that they work even if they are included).

  As an advocate of DNSSEC, I'm pleased to see a use case being put
  forward which, if adopted, would tend to drive DNSSEC deployment (if
  only because otherwise it is such an attractive attack target), but
  the Security Considerations of this draft need to be honest about
  the risks.  At the moment, in my opinion, they are not.

- More generally, there are two classes of DNS attacks on the DKIM
  verification algorithm (skipping over DoS attacks on the DNS itself,
  processing delays while attempting to retrieve keys, etcetera):

  1) Break a key so that signature of legitimate mail doesn't
validate;

  2) Fake a key so that signature of illegitimate mail does validate.

  The chaining attack discussed above is an example of (2).  I'm less
  concerned with (1), as it's only one of many things that could go
  wrong during verification.

  It's worth noting, however, that reliance on insecure DNS does open
  one more path by which an attacker can break signatures of
  legitimate messages, and that, since DNS traffic and SMTP traffic
  may go by wildly different paths and involve otherwise unrelated
  machines, there are likely to be cases where it's easier for an
  attacker to modify an (unsigned) DKIM key in flight than it would be
  for that same attacker to interfere with the email message,
  particularly as DNS service often comes from a recursive name server
  not chosen by the user (see RFC 3833 2.4).



From Olafur -----------------

Is there any reason not to do the following?
  Recommendation:  I would like to see an informational
    application statement that references RFC2671, RFC3397 and says having
    modern DNS software that supports these standards will aid in the use of
    DKIM, and possibly also say RFC403[345] support is a good thing.


#3 Section 3.6.1
  I fail to see what the s= field adds other than add hooks in there to
  expand the use of a key. IMHO this is a bad idea, DKIM is defined for
  MTA to MTA use ONLY, having hooks in there for other uses is out of
  scope and the justification is weak.
  As the only place where this field is discussed is in "Textual
  Representation" and "IANA considerations" (by creating a new sub registry),
  there is no guidance on future uses of this field.
  Please remove this field.

  IESG Discuss on this issue is strongly recommended!

I want to talk about the following one. If we can bias work towards the bad guys, that seem desirable.
- Section 8
  There are number of attacks that are not covered:
  For example for RSA, an attacker can elect to have a large
  signing key with a small exponent, thus making the verification
  key have a large one.
  This inverts the work required, forcing recipients of the message to use
  much more computing resources to verify the signatures than attacker
  used to generate them. (This same threat applies to DNSSEC)
  I'm not sure how comprehensive the security considerations section should
  be on cryptographic issues. But in this case the use of RSA seems to be
  motivated by the fact it is easy to tune which party does more work, and
  the intent is to make the signer do the heavy work.

Olafur

-------------------------------------------------------------------------
I share Rob's concerns when he says

My specific concern was with section 8.4, which contains unsupported
bombast about how hard DNS attacks are without addressing known
threats such as name chaining attacks (RFC 3833 2.3).  In particular,
text such as:

  Secondly, the types of DNS attacks relevant to DKIM are very costly
  and are far less rewarding than DNS attacks on other Internet
  protocols.  For example, attacking A records (to force users to a
  phishing site) is likely to be a more lucrative reason to poison
  DNS caches.

and

  To systematically thwart the intent of DKIM, an attacker must conduct
  a very costly and very extensive attack on many parts of the DNS over
  an extended period.  No one knows for sure how attackers will
  respond, however the cost/benefit of conducting prolonged DNS attacks
  of this nature is expected to be uneconomical.

is not appropriate for this document, because:

a) it makes unsupported (and possibly untrue, depending on the
  software in use) assertions about costs;

b) it drags in a red herring (the subject here is security of DKIM,
  not phishing attacks or other internet protocols); and

c) it disregards a known form of attack that requires only that an
  attacker send two successive messages to the same MTA.

A qualification like "To systematically thwart the intent of DKIM"
includes terms of art and means whatever the author wants it to mean,
but I still think this section requires surgery.

As a practical matter, the most widely used iterative resolver
implementations do have non-DNSSEC defenses against name chaining
attacks, so the name chaining attack is not likely to be a huge
operational problem at the moment.  The danger, however, is that the
non-DNSSEC defenses against name chaining attacks are neither
documented in any RFC nor universally agreed upon, and there are
enough independent iterative resolver implementations out there these
days that there is no guarantee that all of them have this defense, or
that all of them will have it next year.  As I understand it, part of
the point of Security Considerations is to call out the known
weaknesses of a protocol so that implementors can avoid tripping over
them.  As long as DKIM relies on insecure DNS, this is a weakness, and
should be documented.

RFC 4686 4.1.12 mentions cache poisoning, but discusses it only as an
active attack on DNS; it completely misses cases like name chaining
attacks triggered by previous MTA activity, where the MTA's own normal
processing of a previous message causes the MTA to fetch the poisoned
data.  To me, this attack has sufficiently different properties from
an active DNS attack that it merits separate mention.

Section 8.4 also fails to mention the case of DNS service coming from
a recursive name server not chosen by the user (RFC 3833 2.4), e.g., a
DKIM verifier running in the MUA on a laptop at a hotel: in cases like
this the threat against the mail transfer path (IMAP or POP download
likely to be protected with TLS) is very different from the threat
against the DNS transfer path (completely at the hotel's mercy).

[Ballot comment]
Very fundamentally, the number of combinations permitted by the specification is too high to expect a broadly interoperable email service using this mechanism to result.
The document notes, in its scalability section:


  DKIM is designed to support the extreme scalability requirements
  which characterize the email identification problem.  There are
  currently over 70 million domains and a much larger number of
  individual addresses.  DKIM seeks to preserve the positive aspects of
  the current email infrastructure, such as the ability for anyone to
  communicate with anyone else without introduction.

For this to work as an aid to the email service for the Internet, the
verifier must understand any of the supported algorithms, an
unbounded variety of potentially signed headers (including the
signing of headers not actually present), two very different tolerances
for modification in band, a new canonicalization, and the relationship
among different selectors, including, potentially, a parent domain.

I understand from discussions with members of the working group
that the intent is to create a BCP which documents which bits of
this will actually be used in specific scenarios or by specific actors (e.g.
mailing list MTAs).  As it stands this document is part way to
that BCP, but it is neither complete nor especially consistent.  I
understand that many of these elements were added after very
serious contention in the working group, as a compromise way
forward.  I think it would be far better as a prootcol document
if it were bare bones, and the advice given were thrown out. 
Statements like these:

      INFORMATIVE OPERATIONS NOTE:  The choice of which header fields to
      sign is non-obvious.  One strategy is to sign all existing, non-
      repeatable header fields.  An alternative strategy is to sign only
      header fields that are likely to be displayed to or otherwise be
      likely to affect the processing of the message at the receiver.  A
      third strategy is to sign only "well known" headers.  Note that
      verifiers may treat unsigned header fields with extreme
      skepticism, including refusing to display them to the end user or
      even ignore the signature if it does not cover certain header
      fields.  For this reason signing fields present in the message
      such as Date, Subject, Reply-To, Sender, and all MIME header
      fields is highly advised.

fundamentally do not help interoperability, and the last sentence's
attempt to aim to take away the variability in the first three
alternatives is particularly bad.  If it is going to name
"From, Date, Subject, Reply-to, Sender, and all MIME header fields", fine.
Saying that  there are lots of strategies and it is up to you to deal with the
unknowable skepticism of the verifiers is a bit much.

I will not block the document on this basis, given the working group
discussion, but I strongly urge the inclusion of a forward pointer
to the BCP along with language which indicates that the deployment
advice in the document must not be taken as normative.  I also
urge the working group chairs, in the development of the BCP,
to take the more usual IETF approach of throwing out elements
for which there is no consensus, rather than including all of them
to reach one.  If there are 70 million different policies for signers
and 70 million approaches to verification, DKIM will fail and it
will hurt the Internet email service as it does so.

Some specific points:

Either this document or the subsequent BCP should includes an
Internationalization section.  As it stands, the document notes specific
instances which are subject to IDNA and includes this note:

      INFORMATIVE IMPLEMENTATION NOTE:  Although the "plain text"
      defined below (as "tag-value") only includes 7-bit characters, an
      implementation that wished to anticipate future standards would be
      advised to not preclude the use of UTF8-encoded text in tag=value
      lists.

There is likely to be considerably more needed.  The general thrust
of the EAI work will mean that there are many cases in which there
are parallel headers, one in UTF8 and one downgraded (see
draft-ietf-eai-utf8headers-02.txt).  Any downgrade which occurs after
insertion will break the base mechanism for verification, but should
retain sufficient information to determine whether it would have passed
before downgrade.  Again, blocking this document to wait for the EAI
specs would not make sense (they are targeted initially at Experimental),
but a general description of the issues of how to work within the downgrade
approach would be useful.  That aspect of the EAI mechanism is not
likely to change, even if the bits on the wire do.  (Note that the transport
conversions text in 5.3 raises similar issues)

The document already contains some text on the issues around body length
limits.  I believe the whole mechanism is problematic, though, especially without
much better guidance.  To take an extreme example, using a body length of zero
would mean that only the asserted headers (with From: mandatory and potentially
no others) were actually signed.  Anyone receiving such a message would
be able to reintroduce to the mail stream whatever they liked with that signature. 
Yet a signer aware that the message was going to a mailing list might do so in
order to handle the case of mailing lists which enclose posted messages
with informative text.  I understand the mailing list motivation which caused
this feature to be included, but it does not seem to me like the bang is worth
the buck.  If the upshot of broken signatures is that they are treated as
unsigned (which this documents asserts), having this breakage occur
seems a smaller price to pay than this complexity. This text related to the
body length limit is also very odd:

    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.

Verifiers cannot ignore the tag and verify correctly.  Removing the
text that appears after the content length eliminates functionality; it
is also very different from the "treat as unsigned" default given elsewhere
in the text.

This MUST:

  Once the signature has been verified, that information MUST be
  conveyed to higher level systems (such as explicit allow/white lists
  and reputation systems) and/or to the end user.  If the message is
  signed on behalf of any address other than that in the From:  header
  field, the mail system SHOULD take pains to ensure that the actual
  signing identity is clear to the reader.

does not seem to be justified, or valid in many uses of DKIM at intermediate
MTAs.  Further, taking a single verified message to be evidence that
the signature/sender should be placed on a white list seems to be a policy
decision far beyond that appropriate for this document.  If I send you
a signed message that checks out, I may still be someone who deserves
to be on your blacklist for other reasons.  Even if my first message
checked out perfectly, there is no reason to short-circuit processing of
my later messages--which might not.

I also support the issues raised by Rob Austein and state that I would strongly
have preferred that a new RR be used for this.  The arguments for using
TXT are past their sell-by date by many years now, and not including it
even as an option is silly.

[Ballot discuss]
Fundamentally, this proposed standard has too much flexibility and not enough guidance for either signers or verifiers.  The basic algorithms for signing and validating are there, but:
- Many choices that signers might make could interoperate poorly with deployed systems such as mailing list software.  We need to give signers more guidance about this minefield.  I see the informative notes in some places, but I'm looking for something that involves *less* discretion on the part of senders -- a list of headers that are safe to sign and headers that are known to be unsafe, or a couple profiles that have certain known and tested characteristics.
- There are too many possible variations (in what is signed) for validators to be able to do a reasonable job -- particularly end-user agents.  A GUI that displays "Message was signed with DKIM" is not sufficiently useful.  We need to either reduce the variability (profiles again?) or explain to validators what it means if the Subject is signed or not, etc.
- We need more guidance for validators in judging the relationship between the signer and the sender.

I'm also concerned that the amount of flexibility allowed to signers will result in de facto standards for what headers are signed.  The choices made by early signer implementations may work for them but not for all signers, and may work badly with other Internet email infrastructure.  Yet early validation implementations will only be really prepared to handle those choices and not other profiles.  I predict finger-pointing when signatures fail to validate -- the signer will blame some other agent (e.g. a mailing list implementation or the validator) and the mailing list agent will blame the signer, leaving the validator with a broken, useless signature and no way to get the problem fixed.  The validator will have the most serious usability problem in this scenario and be the least able to fix it.  We need to establish responsibility -- whether it's the responsibility of the signer to provide signatures that work with deployed email systems, or whether it's the responsibility of those deployed systems to upgrade.

I did not understand the implications of multiple signatures well enough to be able to implement a verifier.  The text mostly boils down to "the interpretation of multiple valid signatures in combination is a local policy decision of the verifier."  Based on discussions so far I'm learning that there can be a lot of pitfalls.  Just because one signature covers the Subject and doesn't validate, and another signature doesn't cover the Subject but does validate, doesn't mean that the Subject was changed.  With the document this terse on the subject, one would have to read the mailing list archives (at least) in order to understand this kind of subtlety.

I understand the need for flexibility in a framework, but without more specific recommendations/requirements in what you might call a profile, interoperability will not be a real possibility and users will suffer along with the reputation of DKIM generally.

One way of addressing the need for more guidance and less arbitrary flexibility is to start working on profiles.  We could define a "high security" profile and a "high interop" profile and explain the level of protection provided by each, for example.  A profile would list what headers to sign, what headers *not* to sign  (and would presumably leave some headers unmentioned if they're unimportant but suggest some default for new headers); and also recommend specific canonicalization and body length behavior.  I see this as a huge interoperability win for signing-domain administrators who aren't DKIM experts -- a default profile or a couple of well-chosen profiles can serve that administrator well and save them from doing things which break frequently or leave their messages too open for attack.  I *also* see this as an important requirement for verifiers.  If a verifier sees a message that is validly signed according to a well-known profile, this seriously increases the chance that the verifier can make sensible decisions.

I understand the need to preserve the flexibility at the core of DKIM, both so that sites can do even better/smarter things than the default profiles require when they have more knowledge than we can generally assume, and so that we can update our profiles in response to changing network conditions (new phishing attacks or overhauled infrastructure software).  This is particularly why I mention profiles or named well-known policies as a possible solution -- to keep the base potential for flexibility but reduce the variability in practice.

[Ballot discuss]
[These may well be addressed in the diffs sitting in my mailbox]

Doug Otis raised a concern in last call that allowing the d= tag to be
a parent of the i= tag creates a new trust relationship between the
parent domain and the child domain.  IN addition to being responsible
for delegating naming of resources in the child domain, the parent is
now trusted to sign mail on the child's behalf.  The case where this
is most concerning is when this trust crosses large administrative
boundaries--for example if the .com registry chose to sign mail on
behalf of hotmail.com.  The working group has chosen not to address
this concern, but must still document the change in trust model and
document the vulnerability.
I think this needs an explicit mention in the security considerations section.

The security directorate review from Rob Austein raises the concern
that section 8.4 does not adequate describe attacks include the name
chaining attack and other attacks that could allow an attacker to
trick a verifier into accepting a domainkey record from the attacker
rather than the intended DNS target.  Rob also claims that the
difficulty of such attacks is over stated.  Please work with Rob until
you get a mutually agreeable section 8.4.

[Ballot comment]
The NON-NORMATIVE DISCUSSION POINT for g= actually seems like something that should be resolved, but perhaps it's OK since there probably aren't many real email addresses with stars.

Barry says my ABNF error has already been fixed in Eric's working copy, so I've cleared my DISCUSS.

[Ballot comment]
I was sort of surprised to see this still  on the ballot for this meeting given the discussion and lack of changes between 6 and 7 - I must apologize that I have not adequately sorted out my comments in to discuss level issues and comments. Many of these can simply be removed with a discussion or email and no change to the document. As the discussion evolves, I will clarify unclear comments and correctly split these into discuss, comments, and things that are just wrong and need to be deleted. I felt just getting these on the table in this draft form was better than deferring them.

The overall decision on if this protocol works or not is highly depended on how easy it is to get verifiers to get the wrong keys out of DNS. The document needs real analyses on how hard it is to mount an successful attack. Once this is available, I will be able to try and understand if the security is reasonable or not but right now this is missing from the security section making it impossible to evaluate the security.  I'm looking for information about how hard it is to spoof a DNS response. To be clear on what I am asking for here, I am looking for  the security section to describe how difficult it is (to the best of our knowledge) to mount the attacks identified in section 4.1.12 of 4686. Keep in mind time timing information that section 8.9 of the draft provides.

Reading this specification, I do not believe I could implement a good signer. Should I sign the subject line or not? What canonical form should I use? Should I use the l tag options. These are all hard topics and implementers will not know how to make the right choices.

For the same reason that I think this document should be standards track, I think updates to the IANA registries should require a standards track document.

In the Terminology section, could you add a definition of "responsible signer"


Section 8.4
- I think lots of people believe there is a non trivial chance that DNS Sec will not end up security DNS

You say the attacks on DKIM are costly and prolonged. I think you need to explain these attacks and why they are costly and prolonged. The attacks of sending two email to a verifier and using the DNS fetch from the first as a timer to insert the spoofed DNS did not sound costly or prolonged to me.

Overall I think the security section needs to outline what are the known attacks against DKIM and how are they mitigated against. I think more is needed on the DNS attacks.

I think of a certificate as a document that attests to the truth of something or the ownership of something. There are several places in the introduction saying this does not reply on any third parties or certificate authorities.  I don't think this is really true - DNS is acting as a CA here and DNS certainly relies on third parties. Can we adjust the text in these to bring it to a point we both agree is true and point out the current scheme does depend heavily on DNS for the security properties. Truth in advertising was one of the the key issues in formation of this WG.

When using the relaxed algorithm, is there an ascii art attack? Something like I send you an email with "a b c d", you reply saying it is messed up, then I use your signature on the reply and edit the space to say "Buy CSCO" and send it out. If this is an valid attack, it should be added to security section.

Add some information text discussing the expected sizes of the DNS records and if we expect TCP based DNS to be needed.

Are any recommendation on DNS cache times needed?

Section 3.2 - you say unrecognized tags are ignored. For future extensibility, it might be nice to have something like that an unrecognized tag that start with m- causes the whole signature to be ignored.


Section 3.3.1 says low value exponents are believed to be subject to attack - could you add an information reference here.

Section 3.4.5 - I get how the not including the --CRLF works for some MIME types but not others such as multipart/signed.

Section 3.8 - Is .com a valid parent domain of exmaple.com. Depending on how your DNS security analysis goes, you might not want this. I do understand the .uk  type issue.

If you later want to have version numbers like 1.1, I think it would be better to move the version number of this to "1.0" instead of "1" - you will have less implementation bugs later.

I think the ABNF for the sig-v-tag should allow the future values expected here not stick on 0.5.

Some of the other ABNF rules lack appropriate extensibility (for example, v tag) (most the rules look good)

Having l limited to 256 bits is a total hassle to implement and just seem too large. Could you limit it to 64 bits.

On the n= flag, do you need a lang tag for internationalization. If not, would be good to provide guidance this text is meant for administrators not end users. Any practical limits on size of this needed?

On the x tag, any advice for what a signer should put.

When should a z tag be used by a signer?

This uses _domainkey and the WG seem like it will be defining more of these but to make sure this does not conflict with other usages, it seems like it would be a good idea to IANA register the _domainkey. Perhaps the same way SRV is done today with IANA would work.

In the s= , I would rather not say this was appropriate for IM and VoIP without having something more concrete to discuss with that community.

section 3.6.1

What type of regular expression are possible with the g= tag is not adequately specified. Can there be multiple *? do they match 1 or more or zero or more? Can they match across a @ ?

The open issue around using * even though that can be in dot-atom-text seem fairly significant. I can think of several ways of solving this which I imagined the WG discussed. I don't understand why this was not resolved.

What are the h and k tags used for? When should they be used? Seem totally redundant given the a= tag.

End of section 3.7 mentions "dot stuffing" but I have no idea what you are talking about.

In section 5.4 you mention signing Subject is highly advisable. Is this true? If so why not make it a SHOULD, if not then this might need to be changed.

Section 6.1 and other places, the text discussed SMTP rejections. This seems to conflict with the text that claims that "signature verification failure does not result in rejection of the message"

In section 6.1.3 you mention "N-4" trick but I can't find the explanation of this.

Section 8.4 - I would have to question if it is true that the majority of people expect DNSSEC to solve DNS security problems.

In section 6.3 you say that if something verifies, it should be presented to user as simple binary result. I think I have a real problem with this. Something that did not sign the subject, or from and has l=0 seems like it deservers different presentation to the user.

Totally irrelevant comment but one character tag names make it significantly harder to understand this specification.

Section 7.7 and s tag definition - I think the * entry should be removed as it is not yet clear this should be used for services other than email (not to mention it being outside scope of WG)

I'm assuming that the example public and private keys, DNS records, and signatures in the back are all consistent with each-other and people can use them as test vectors - this really helps implementers. Is this assumption true?  Might be nice if A.2 mentioned it was signed with keys from C.

Section B.2.1 - So if some affinity group with a few hundred thousand users each with their own key did this, would it work with DNS? I'm not sure how many members ieee has but it seem like if "republican.org" offered this, I might get big. I'm assuming this all works fine but just want to check.

Section B.2.3 This uh, seems out of step with your charter which has "The specifications will also advise mailing lists on how to
take advantage of DKIM if they should choose to do so." . I think some more work is needed here. Does this work with existing malling lists? (the mailing lists I use don't seem to authenticate my messages) What should mailing lists do to work? What  should  signers do to work with mailing lists over the short term? If it just does not work, say that. What should signers to to work with mailing lists. Should they sign the Subject as the text currently says?

h = tag section needs to explain about how to deal with multiple headers

Would be nice to see some advice about suggested TTL for DNS records.

Would be nice to see some text about expected size of DNS responses for various key sizes.


From Pekka ----------------

Concern here is that the following SHOULD are not implementable and are actually operational issues. I agree with Pekka that this is not clear if this is something an implementors needs to deal with or something the else. I think some small changes to the text could clarify this.

  Reusing a Selector with a new key (for example, changing the key
  associated with a user's name) makes it impossible to tell the
  difference between a message that didn't verify because the key is no
  longer valid versus a message that is actually forged.  Signers
  SHOULD NOT change the key associated with a Selector.  When creating
  a new key, signers SHOULD associate it with a new Selector.

==> it seems like 'Signer' here refers to a postmaster or whoever is in
charge of selecting Selectors.  Are these SHOULD conditions/enforcement
implementable, if so, how?  If this is purely operational guidance, I would
phrase it differently, without uppercase, such as 'Administrators should
not change the key associated with a Selector...'  On the other hand, if
this is meant as an implementation specification, maybe some rewording might
make it clearer how to implement it.



And now some comments from Rob

With respect to Rob's comments on header reordering, please have the draft explain when it is a good idea to sign other DKIM signatures and when it is not.

I can not see why you would not do the following:
- The discussion of the signature timestamp (t= tag) never states
  explicitly that signatures MAY be considered invalid if the
signature
  timestamp is a date in the future.

Could we clarify how and when this is used so that people like Rob and I are not confused
- The revocation mechanism (empty p= value) described in section 3.6.1
  is puzzling.  It's not revocation as I understand the term, and
  doesn't revoke a particular key in any case, as there is no way to
  identify the key in question.  Rather, it seems to revoke the -name-
  of a key, or perhaps the combination of the name of a key and a set
  of other attributes (e.g., algorithms).  I can't picture any case in
  which publishing a "revocation" of this kind would be useful, so if
  the WG thinks that this mechanism serves some useful purpose, the
  draft really needs to explain much more clearly what that purpose
is.


- Section 6 encourages border MTAs to verify DKIM signatures to
  minimize the chance of a key having expired.  This could be read as
  an invitation to stage a denial of service attack on the border MTA.
  Section 6.1 briefly mentions denial of service attacks, but for some
  reason most of the discussion of denial of service attacks in the
  draft seems to be worried about delays due to DNS lookups rather
  than CPU time expended on signature checks.  Denial of service
  issues based on cryptographic computations aren't even mentioned in
  the Security Considerations section.  They should be, particularly
  if the draft is going to encourage verification at choke points like
  border MTAs.

- Section 6.1.2 should state explicitly that the v= tag associated
with
  the public key must match a known version.



Uh, yah, I think this one has quite a few people that agree with Rob
- The security considerations are mostly OK, but I find the section on
  DNS attacks (section 8.4) unconvincing.  To be blunt, this section
  falls somewhere between "whistling in the dark" and "utter hogwash".

  The claim that "the types of DNS attacks relevant to DKIM are very
  costly and are far less rewarding than DNS attacks on other Internet
  applications" is at best unsubstantiated (in the draft, anyway); the
  same applies to "an attacker must conduct a very costly and very
  extensive attack on many parts of the DNS over an extended period".
  If there are data to support these assertions, cite them, otherwise
  this kind of hand waving is inappropriate.

  Consider, for example, a name chaining attack (see RFC 3833 2.3).
  This is trivially easy to trigger in the DKIM case, as the intended
  victim (a DKIM verifier) looks up DNS names handed to it by
  strangers for a living).  So send two messages: the first is just a
  trigger for a name chaining attack to poison the verifier's cache
  with a bogus NS RRset and associated glue; the second message is the
  one you want to sneak past DKIM, which you do by handing back a
  forged key when the verifier follows the bogus NS data cached during
  processing of the first message.

  The verifier's only hope here, absent DNSSEC, is that its DNS
  resolver is clever enough to detect the name chaining attack, which
  is non-trivial -- there are heuristics one can apply, but they
  require assumptions not supported by the base DNS specifications,
  and there is no reason to believe that every implementation include
  such heuristics (or that they work even if they are included).

  As an advocate of DNSSEC, I'm pleased to see a use case being put
  forward which, if adopted, would tend to drive DNSSEC deployment (if
  only because otherwise it is such an attractive attack target), but
  the Security Considerations of this draft need to be honest about
  the risks.  At the moment, in my opinion, they are not.

- More generally, there are two classes of DNS attacks on the DKIM
  verification algorithm (skipping over DoS attacks on the DNS itself,
  processing delays while attempting to retrieve keys, etcetera):

  1) Break a key so that signature of legitimate mail doesn't
validate;

  2) Fake a key so that signature of illegitimate mail does validate.

  The chaining attack discussed above is an example of (2).  I'm less
  concerned with (1), as it's only one of many things that could go
  wrong during verification.

  It's worth noting, however, that reliance on insecure DNS does open
  one more path by which an attacker can break signatures of
  legitimate messages, and that, since DNS traffic and SMTP traffic
  may go by wildly different paths and involve otherwise unrelated
  machines, there are likely to be cases where it's easier for an
  attacker to modify an (unsigned) DKIM key in flight than it would be
  for that same attacker to interfere with the email message,
  particularly as DNS service often comes from a recursive name server
  not chosen by the user (see RFC 3833 2.4).



From Olafur -----------------

Is there any reason not to do the following?
  Recommendation:  I would like to see an informational
    application statement that references RFC2671, RFC3397 and says having
    modern DNS software that supports these standards will aid in the use of
    DKIM, and possibly also say RFC403[345] support is a good thing.


#3 Section 3.6.1
  I fail to see what the s= field adds other than add hooks in there to
  expand the use of a key. IMHO this is a bad idea, DKIM is defined for
  MTA to MTA use ONLY, having hooks in there for other uses is out of
  scope and the justification is weak.
  As the only place where this field is discussed is in "Textual
  Representation" and "IANA considerations" (by creating a new sub registry),
  there is no guidance on future uses of this field.
  Please remove this field.

  IESG Discuss on this issue is strongly recommended!

I want to talk about the following one. If we can bias work towards the bad guys, that seem desirable.
- Section 8
  There are number of attacks that are not covered:
  For example for RSA, an attacker can elect to have a large
  signing key with a small exponent, thus making the verification
  key have a large one.
  This inverts the work required, forcing recipients of the message to use
  much more computing resources to verify the signatures than attacker
  used to generate them. (This same threat applies to DNSSEC)
  I'm not sure how comprehensive the security considerations section should
  be on cryptographic issues. But in this case the use of RSA seems to be
  motivated by the fact it is easy to tune which party does more work, and
  the intent is to make the signer do the heavy work.

Olafur

-------------------------------------------------------------------------
I share Rob's concerns when he ways

My specific concern was with section 8.4, which contains unsupported
bombast about how hard DNS attacks are without addressing known
threats such as name chaining attacks (RFC 3833 2.3).  In particular,
text such as:

  Secondly, the types of DNS attacks relevant to DKIM are very costly
  and are far less rewarding than DNS attacks on other Internet
  protocols.  For example, attacking A records (to force users to a
  phishing site) is likely to be a more lucrative reason to poison
  DNS caches.

and

  To systematically thwart the intent of DKIM, an attacker must conduct
  a very costly and very extensive attack on many parts of the DNS over
  an extended period.  No one knows for sure how attackers will
  respond, however the cost/benefit of conducting prolonged DNS attacks
  of this nature is expected to be uneconomical.

is not appropriate for this document, because:

a) it makes unsupported (and possibly untrue, depending on the
  software in use) assertions about costs;

b) it drags in a red herring (the subject here is security of DKIM,
  not phishing attacks or other internet protocols); and

c) it disregards a known form of attack that requires only that an
  attacker send two successive messages to the same MTA.

A qualification like "To systematically thwart the intent of DKIM"
includes terms of art and means whatever the author wants it to mean,
but I still think this section requires surgery.

As a practical matter, the most widely used iterative resolver
implementations do have non-DNSSEC defenses against name chaining
attacks, so the name chaining attack is not likely to be a huge
operational problem at the moment.  The danger, however, is that the
non-DNSSEC defenses against name chaining attacks are neither
documented in any RFC nor universally agreed upon, and there are
enough independent iterative resolver implementations out there these
days that there is no guarantee that all of them have this defense, or
that all of them will have it next year.  As I understand it, part of
the point of Security Considerations is to call out the known
weaknesses of a protocol so that implementors can avoid tripping over
them.  As long as DKIM relies on insecure DNS, this is a weakness, and
should be documented.

RFC 4686 4.1.12 mentions cache poisoning, but discusses it only as an
active attack on DNS; it completely misses cases like name chaining
attacks triggered by previous MTA activity, where the MTA's own normal
processing of a previous message causes the MTA to fetch the poisoned
data.  To me, this attack has sufficiently different properties from
an active DNS attack that it merits separate mention.

Section 8.4 also fails to mention the case of DNS service coming from
a recursive name server not chosen by the user (RFC 3833 2.4), e.g., a
DKIM verifier running in the MUA on a laptop at a hotel: in cases like
this the threat against the mail transfer path (IMAP or POP download
likely to be protected with TLS) is very different from the threat
against the DNS transfer path (completely at the hotel's mercy).

[Ballot comment]
The NON-NORMATIVE DISCUSSION POINT for g= actually seems like something that should be resolved, but perhaps it's OK since there probably aren't many real email addresses with stars.

[Ballot discuss]
The following ABNF:

  key-s-tag        = %x73 [FWS] "=" [FWS] key-s-tag-type
                      0*( [FWS] ":" [FWS] key-s-tag-type

is syntactically incorrect (missing trailing parenthesis?)

[Ballot discuss]
Fundamentally, this proposed standard has too much flexibility and not enough guidance for either signers or verifiers.  The basic algorithms for signing and validating are there, but:
- Many choices that signers might make could interoperate poorly with deployed systems such as mailing list software.  We need to give signers more guidance about this minefield.  I see the informative notes in some places, but I'm looking for something that involves *less* discretion on the part of senders -- a list of headers that are safe to sign and headers that are known to be unsafe, or a couple profiles that have certain known and tested characteristics.
- There are too many possible variations (in what is signed) for validators to be able to do a reasonable job -- particularly end-user agents.  A GUI that displays "Message was signed with DKIM" is not sufficiently useful.  We need to either reduce the variability (profiles again?) or explain to validators what it means if the Subject is signed or not, etc.
- We need more guidance for validators in judging the relationship between the signer and the sender.

I'm also concerned that the amount of flexibility allowed to signers will result in de facto standards for what headers are signed.  The choices made by early signer implementations may work for them but not for all signers, and may work badly with other Internet email infrastructure.  Yet early validation implementations will only be really prepared to handle those choices and not other profiles.  I predict finger-pointing when signatures fail to validate -- the signer will blame some other agent (e.g. a mailing list implementation or the validator) and the mailing list agent will blame the signer, leaving the validator with a broken, useless signature and no way to get the problem fixed.  The validator will have the most serious usability problem in this scenario and be the least able to fix it.  We need to establish responsibility -- whether it's the responsibility of the signer to provide signatures that work with deployed email systems, or whether it's the responsibility of those deployed systems to upgrade.

The guidance to treat signatures independently (and ignore the ones that fail? ) leaves out important use cases.  For example, a sender could wish to provide both a signature that covers the Subject field and a signature that doesn't.  Then when the Subject field is changed by  mailing list software (usually the name of the DL is prepended), the verifier can see that otherwise the message does validate (and may even be able to confirm whether the Subject header in its original form would have caused both signatures to validate).

I understand the need for flexibility in a framework, but without more specific recommendations/requirements in what you might call a profile, interoperability will not be a real possibility and users will suffer along with the reputation of DKIM generally.

One way of addressing the need for more guidance and less arbitrary flexibility is to start working on profiles.  We could define a "high security" profile and a "high interop" profile and explain the level of protection provided by each, for example.  A profile would list what headers to sign, what headers *not* to sign  (and would presumably leave some headers unmentioned if they're unimportant but suggest some default for new headers); and also recommend specific canonicalization and body length behavior.

[Ballot comment]
Appendix A., paragraph 9:
>    Received: from dsl-10.2.3.4.football.example.com  [10.2.3.4]

  Should use 192.0.2.0/24 - the block assigned as "TEST-NET" for use in
  documentation and example code. (Also elsewhere in these examples.)


Section 1.3, paragraph 2:
>    The DNS is proposed as the initial mechanism for the public keys.
>    Thus, DKIM currently depends on DNS adminstration and the security of

  Nit: s/adminstration/administration/


Appendix C., paragraph 14:
>    This results in signature data similar to this when represented in
>    Base64 [MIME] format:

  Nit: Not in the references - should probably cite RFC 2045/2047.

[Ballot comment]
6.2  Communicate Verification Results

  Verifiers wishing to communicate the results of verification to other
  parts of the mail system may do so in whatever manner they see fit.
  For example, implementations might choose to add an email header
  field to the message before passing it on.

What, not even a RECOMMENDED minimal header to communicate this,
like DKIM-verified: OK or DKIM-verified: Fail?

A de facto standard for this seems highly desirable. There is
no particular 1:1 relationship between MTA and MUA, and a user
who switches routinely between MTAs will be put in difficulty if
each MTA handles this differently.

Also, how about a note that this mechanism assumes that the MUA
trusts the verifier, and that DKIM does nothing to secure
that relationship?