Subject: [ietf-dkim] Escaping things in key/ADSP records

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 28 Oct 2008 11:15:42 -0700 (PDT)

DNS TXT records can contain multiple strings which we just concatenate to 
form a complete key record.  That part's easily managed.  However some 
people have taken it upon themselves to escape semi-colons for some 
reason, presumably because some programs like "dig" do that in their 
output, which in turn is done perhaps to disambiguate a literal semi-colon 
with one that starts a comment in a zone file.

The problem is that RFC4871 (DKIM) doesn't say that "\" is a special 
character (at least nowhere that I can find) so something like this:

 	k=rsa\; t=y\; g=*\; p=<base64stuff>

...means the value of "k" for example is "rsa\" which doesn't match any of 
the key methods we know and thus the record will get discarded.  So if a 
user constructs a key record using the output of "dig" as a starting 
point, and then it doesn't work, the cause will not be at all obvious.

So, first: Is there anyplace, like in the ABNF specs, that codify "\" as a 
universal escape character and so I should be processing it as such if 
it's there even if the spec doesn't explicitly say so?

And, second: Should implementors treat it as such, even if the spec 
doesn't say so, just to handle that situation?

And, finally: Should we add text to the deployment document discussing 
this issue?
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 29 Oct 2008 17:00:30 -0700 (PDT)

On Wed, 29 Oct 2008, John Levine wrote:
> I find it hard to see this as anything other than a bug in whatever 
> scripts they're using to create their DNS records.  The DNS has counts 
> for all variable length fields, so there's never a need to escape 
> anything in the bits on the wire.

People who know the protocol would obviously agree, but I'm not certain 
everyone pasting these things into zone files has knowledge like that. 
They're more likely to follow scripts or examples they find online.

But in fact it's even less of a problem than I feared.  Some local testing 
shows the following two TXT records in a regular bind zone file are 
semantically equivalent in the current implementation:

 	IN	TXT	"foo;bar"
 	IN	TXT	"foo\;bar"

The RFCs about zone files are unfortunately ambiguous on the backslash. 
They only specify that backslash can be used to escape a quotation mark 
inside a quoted string.  They don't say what backslash means in any other 
context.

Why "dig" decided to start rendering semi-colons as escaped in their 
output, when they're not explicitly so in the zone file or on the wire, is 
currently a mystery to me.  I'm just concerned that it will confuse some 
people tasked with deployment somewhere down the line.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: John L <[email-masked]>
Date: Thu, 30 Oct 2008 01:24:29 +0100 (CET)

>> I find it hard to see this as anything other than a bug in whatever scripts 
>> they're using to create their DNS records.  The DNS has counts for all 
>> variable length fields, so there's never a need to escape anything in the 
>> bits on the wire.
>

Indeed.  That's why it's important to stamp out this kind of mistake 
earlier rather than later.

> Why "dig" decided to start rendering semi-colons as escaped in their output, 
> when they're not explicitly so in the zone file or on the wire, is currently 
> a mystery to me.  I'm just concerned that it will confuse some people tasked 
> with deployment somewhere down the line.

A reasonable concern, but it seems to me that the best response is to 
educate people about how to create valid DKIM setups.  Early in the life 
of SPF there used to be a lot of broken SPF records, but eventually people 
got the hang of setting them up.

R's,
John

---

From: John Levine <[email-masked]>
Date: 29 Oct 2008 23:52:50 -0000

R's,
John

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 29 Oct 2008 21:21:23 -0700 (PDT)

On Thu, 30 Oct 2008, John L wrote:
> of SPF there used to be a lot of broken SPF records, but eventually 
> people got the hang of setting them up.

So, is this an appropriate topic for the deployment document?  Seems like 
we're in agreement.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: "Olivier MJ Crepin-Leblond" <[email-masked]>
Date: Thu, 30 Oct 2008 09:21:34 +0100

+1

Many ISPs do not input records directly into the zone files. Their front end is often a
web-based interface and get pre-processed by a system checking validity before being
updated in the zone file automatically using script(s).
My ISP (as in, I am a client of theirs), one of the largest in the US, had to migrate my
domain to their new nameservers because the legacy ones could not cope with the ; and the
underscore (_). Thankfully I took this up with them early enough for the new nameservers
to have a front end allowing those characters, but it looks like they've used the
backslash...

Aside from the aesthetics of the record, does the escape affect functionality?

Olivier

---

From: Tony Hansen <[email-masked]>
Date: Thu, 30 Oct 2008 07:51:19 -0400

duly noted

	Tony Hansen
	[email-masked]

---

From: "John Levine" <[email-masked]>
Date: 30 Oct 2008 10:05:52 -0400

> Is there any chance that this is an OS inspired edit? Perhaps the web
> front end has a built in escape clause

It is certainly the kind of bug that occurs in PHP scripts when the 
programmer doesn't perfectly understand the quoting rules.  It\'s happened 
to me.

R's,
John

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Olivier MJ
> Crepin-Leblond
> Sent: Thursday, October 30, 2008 4:22 AM
> To: John Levine; [email-masked]
> Cc: [email-masked]

---

From: <[email-masked]>
Date: Thu, 30 Oct 2008 09:38:21 -0400

-----Original Message-----

+1

Many ISPs do not input records directly into the zone files. Their front
end is often a
web-based interface and get pre-processed by a system checking validity
before being
updated in the zone file automatically using script(s).
My ISP (as in, I am a client of theirs), one of the largest in the US,
had to migrate my
domain to their new nameservers because the legacy ones could not cope
with the ; and the
underscore (_). Thankfully I took this up with them early enough for the
new nameservers
to have a front end allowing those characters, but it looks like they've
used the
backslash...

Aside from the aesthetics of the record, does the escape affect
functionality?

Olivier

---

From: Mark Martinec <[email-masked]>
Date: Thu, 30 Oct 2008 18:42:50 +0100

> programmer doesn't perfectly understand the quoting rules.  It\'s happened

I'm collecting a set of common mistakes breaking DKIM signatures.

Mentioning a web interface to DNS and PHP brings the following to mind:

$ host -t txt default._domainkey.biofeedbackinternational.com
 "k=rsa\;
  p=MHwwDQYJKoZIhvcNAQEBBQADawAwaAJhAOr7pvAlT3y3qLf3zusWTjo5xI8yHSoj
  rS0nq bYpD1wEwroTAoqMOy2laMFEVC2Wr7G 0GAMN9XkH5dpBQQtnFj REbwc6sku
  6NJGPRB  IzNW iHrZ bcOtrHBgudeWwIDAQAB\;"

Note that each '+' in a published base64-encoded p tag has been
converted into a space, as per URI decoding rules. Naturally their
signatures fail, but nobody cares.

  Mark