Subject: [ietf-dkim] Ticket #17

From: Dave CROCKER <[email-masked]>
Date: Tue, 26 Apr 2011 14:03:06 -0700

> Detecting Fake A-Label use is essential for the safe introduction of UTF-8 throughout email

DKIM does not have the task of validating input.  In addition, the nature of 
DKIM's crypto algorithms provides quite a bit of validity checking inherently.

This ticket is invalid.

d/
-- 

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

---

From: Douglas Otis <[email-masked]>
Date: Tue, 26 Apr 2011 18:43:06 -0700

> DKIM's crypto algorithms provides quite a bit of validity checking inherently.
Dave,

When DKIM allows garbage input, DKIM's output is also garbage and 
untrustworthy.  The saying Garbage-IN Garbage-OUT is still valid.  Fake 
A-Labels can still resolve resources satisfying DKIM's signing 
algorithms.  Cryptography only indicates some odd domain published a 
public key matching the key used to sign a message.  The A-Label concern 
will become more apparent when UTF-8 encoding is generally permitted 
within email.

Applications that simply use RFC3492 to display A-Labels could offer 
highly deceptive information when Fake A-Labels have not been excluded 
by the DKIM verification process.  Rules imposed by RFC5890 improved 
UTF-8 security significantly and should truly play a role in the DKIM 
verification process.

The DKIM protocol is logically where Fake A-Labels and malformed 
messages should be detected.  Why give malefactors an ability to 
generate deceptive and misleading information?  Doing so would be evil.

Not validating input creates a bigger mess when used in conjunction with 
RFC5336bis.  As such, it seems unfair for the DKIM WG operating within 
the Security area to close and then hand a mess over to the Applications 
area EAI WG.

-Doug

---

From: Hector Santos <[email-masked]>
Date: Tue, 26 Apr 2011 22:43:45 -0400

> will become more apparent when UTF-8 encoding is generally permitted 

As an developer, I am mostly concern with the process functional 
"blackbox" implementation modeling aspects and that comes with the 
engineering faith the functional specification and the I/O were well 
considered.

For RFC4871:

    dkim.sig.dvalue = EncodeRFC3492(dkim.signer.domain)

For RFC4871bis:

    dkim.sig.dvalue = EncodeRFC5890(dkim.signer.domain)

I don't see any software engineering issue other than to considered 
backward compatibility:

   dkim.signer.domain = DecodeRFC5890(DecodeRFC3492(dkim.sig.dvalue))

So all that is the easy part.  But I would love to see an example of 
what we are dealing with both RFC3492 and RFC5890 and see what these 
labels will look like.

Can you provide a few example maybe showing how an IDN address and 
domain will look like under each RFC and also UTF8 for?

    From:
    DKIM-Signature: d=
    DNS zone record

or anything else you deem important to show the issue and/or conflicts?

-- 
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com

---

From: Douglas Otis <[email-masked]>
Date: Wed, 27 Apr 2011 11:17:24 -0700

On 4/27/11 2:21 AM, SM wrote:
>  Hi Doug, At 18:43 26-04-2011, Douglas Otis wrote:
> > Not validating input creates a bigger mess when used in conjunction
> > with RFC5336bis. As such, it seems unfair for the DKIM WG
> > operating within the Security area to close and then hand a mess
> > over to the Applications area EAI WG.
>
>  I thought that the advancement of the specifications from Proposed to
>  Draft would not be too much of an effort as there are existing
>  implementations of RFC 4871. But then, this is the DKIM WG.

DKIM represents a security measure intended to have minimal impact on 
existing email infrastructure.  When moving to draft collides with 
repairing deficiencies found, whether due to DKIM errors, unanticipated 
encoding changes, or unexpected deficiencies with dependent protocols, 
then this move is clearly premature.  The substantially greater 
resources expended to support DKIM overwhelmingly justify minor 
adjustments necessary to better restore security.  Whether this might 
mean incrementing singleton header counts, or detecting Fake A-Labels by 
checking symmetry with existing libraries.  IMHO, it would also improve 
security by indicating these additional checks are in place.  When doing 
what is best is hindered by being associated with a "standard", then 
something has gone wrong.

>  I don't see any issue between the Security Area and the Applications
>  Area. I don't recall DKIM being discussed in the EAI WG. I read
>  draft-ietf-dkim-rfc4871bis during the last WGLC in October 2010 and
>  commented on the draft (
>  http://mipassoc.org/pipermail/ietf-dkim/2010q4/014696.html ).

DKIM is briefly discussed in the Framework document where it indicates 
DKIM is an open issue for both groups where changes ARE needed.

>  IDNA and EAI are not the same. You are going to break stuff if you
>  want to DKIM support for RFC5336bis. It's up to the DKIM WG to see
>  whether it wants to do that or not.

DKIM would be deficient blaming deceptive output on name or transport 
services.  DKIM binds elements of the message with a recognizable domain 
contained within the DKIM-Signature "d=" parameter.  When recipients are 
expected to compare the output of a Punycode algorithm against the UTF-8 
IDNs, then clearly DKIM will have failed.  When DKIM does not ensure 
resources are only obtained from DNS using NR-LDH or Valid A-Labels, 
then clearly DKIM will have failed.  When the only header field required 
to be signed is not guarded against deceptive pre-pended header fields 
(by incrementing the signed header count), then clearly DKIM has failed.

-Doug