Re: [ietf-dkim] Escaping things in key/ADSP records
It could put in a heading of "Unrecognized tag X=" for each such tag. Tony Hansen t...@att.com Steve Atkins wrote: > On Aug 3, 2009, at 9:13 AM, Murray S. Kucherawy wrote: > >>> -Original Message- >>> From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim- >>> boun...@mipassoc.org] On Behalf Of Steve Atkins >>> Sent: Sunday, August 02, 2009 6:34 PM >>> To: DKIM WG >>> Subject: Re: [ietf-dkim] Escaping things in key/ADSP records >>> >>> [...] >> Nice work! However: >> >>> If anyone has good (or known bad) records that it gets wrong I'm >>> interested to hear about it. >> It reports the contents of medusa3._domainkey.blackops.org as >> invalid which is not correct. That record contains an "r=" and an >> "rs=" tag, both of which are defined by active I-Ds. Those tags may >> be unknown to RFC4871, but that specification says such should >> merely be ignored; they don't render the record invalid. > > For typical DKIM users though, commenting on an invalid field as "This > is probably invalid, but there might be an experimental I-D that's > using it, so maybe it's OK and receivers may or may not ignore it" is > going to be far more confusing than "This is wrong, fix it." - as if > they're using "r=" it's probably a typo or a misunderstanding, rather > than intentional use of an experimental field. > > You're intentionally using non-standard or experimental fields - so > you know better than the mechanical validator, and that's OK. > > (If we were to add a form on dkim.org that points to the checker, that > might be the place to discuss what it considers valid and what it > doesn't.) > > It might be interesting to have an alternate checker that tracks the > additional fields being discussed in active I-Ds too, though. Is there > a registry of experimental fields or list of I-Ds anywhere? > > Cheers, >Steve > > ___ > NOTE WELL: This list operates according to > http://mipassoc.org/dkim/ietf-list-rules.html ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Escaping things in key/ADSP records
On 08/03/2009 09:13 AM, Murray S. Kucherawy wrote: >> -Original Message- >> From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim- >> boun...@mipassoc.org] On Behalf Of Steve Atkins >> Sent: Sunday, August 02, 2009 6:34 PM >> To: DKIM WG >> Subject: Re: [ietf-dkim] Escaping things in key/ADSP records >> >> [...] > > Nice work! However: > >> If anyone has good (or known bad) records that it gets wrong I'm >> interested to hear about it. > > It reports the contents of medusa3._domainkey.blackops.org as invalid which > is not correct. That record contains an "r=" and an "rs=" tag, both of which > are defined by active I-Ds. Those tags may be unknown to RFC4871, but that > specification says such should merely be ignored; they don't render the > record invalid. An active I-D does not a standard make ;-) But yeah, it should probably just tag them as unknown/ignored-by-4871 rather than an error. Mike ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Escaping things in key/ADSP records
On Aug 3, 2009, at 10:28 AM, Murray S. Kucherawy wrote: >> >> >> For typical DKIM users though, commenting on an invalid field as >> "This >> is probably invalid, but there might be an experimental I-D that's >> using it, so maybe it's OK and receivers may or may not ignore it" is >> going to be far more confusing than "This is wrong, fix it." - as if >> they're using "r=" it's probably a typo or a misunderstanding, rather >> than intentional use of an experimental field. > > How about: "The following tags are non-standard and will likely be > ignored by most verifiers"? > > Some of Tony's examples such as "h=rsa-sha1" can certainly be > reported as "invalid" as they are standardized tags with illegal > values (i.e., the legal values are enumerated). > >> It might be interesting to have an alternate checker that tracks the >> additional fields being discussed in active I-Ds too, though. Is >> there >> a registry of experimental fields or list of I-Ds anywhere? > > Alas, no. And it would be difficult, I think, to try to corral > people into using one in general (though the audience is currently > pretty small so for now it's a practical idea). Ah. If there's no registry of fields then there's nothing to say that a receiver isn't experimenting with an r= field that's completely different to the r= field that Tony is publishing. So it isn't safe to assume that a receiver that isn't using Tony's definition of r= will ignore his r= field, rather we're solidly into undefined behavior and something that is definitely an error in a production record (as opposed to a record used for pre-arranged testing with a specific receiver). Cheers, Steve ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Escaping things in key/ADSP records
> -Original Message- > From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim- > boun...@mipassoc.org] On Behalf Of Steve Atkins > Sent: Monday, August 03, 2009 9:59 AM > To: DKIM WG > Subject: Re: [ietf-dkim] Escaping things in key/ADSP records > > For typical DKIM users though, commenting on an invalid field as "This > is probably invalid, but there might be an experimental I-D that's > using it, so maybe it's OK and receivers may or may not ignore it" is > going to be far more confusing than "This is wrong, fix it." - as if > they're using "r=" it's probably a typo or a misunderstanding, rather > than intentional use of an experimental field. How about: "The following tags are non-standard and will likely be ignored by most verifiers"? Some of Tony's examples such as "h=rsa-sha1" can certainly be reported as "invalid" as they are standardized tags with illegal values (i.e., the legal values are enumerated). > It might be interesting to have an alternate checker that tracks the > additional fields being discussed in active I-Ds too, though. Is there > a registry of experimental fields or list of I-Ds anywhere? Alas, no. And it would be difficult, I think, to try to corral people into using one in general (though the audience is currently pretty small so for now it's a practical idea). -MSK ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Escaping things in key/ADSP records
On Aug 3, 2009, at 9:13 AM, Murray S. Kucherawy wrote: >> -Original Message- >> From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim- >> boun...@mipassoc.org] On Behalf Of Steve Atkins >> Sent: Sunday, August 02, 2009 6:34 PM >> To: DKIM WG >> Subject: Re: [ietf-dkim] Escaping things in key/ADSP records >> >> [...] > > Nice work! However: > >> If anyone has good (or known bad) records that it gets wrong I'm >> interested to hear about it. > > It reports the contents of medusa3._domainkey.blackops.org as > invalid which is not correct. That record contains an "r=" and an > "rs=" tag, both of which are defined by active I-Ds. Those tags may > be unknown to RFC4871, but that specification says such should > merely be ignored; they don't render the record invalid. For typical DKIM users though, commenting on an invalid field as "This is probably invalid, but there might be an experimental I-D that's using it, so maybe it's OK and receivers may or may not ignore it" is going to be far more confusing than "This is wrong, fix it." - as if they're using "r=" it's probably a typo or a misunderstanding, rather than intentional use of an experimental field. You're intentionally using non-standard or experimental fields - so you know better than the mechanical validator, and that's OK. (If we were to add a form on dkim.org that points to the checker, that might be the place to discuss what it considers valid and what it doesn't.) It might be interesting to have an alternate checker that tracks the additional fields being discussed in active I-Ds too, though. Is there a registry of experimental fields or list of I-Ds anywhere? Cheers, Steve ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Escaping things in key/ADSP records
> -Original Message- > From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim- > boun...@mipassoc.org] On Behalf Of Steve Atkins > Sent: Sunday, August 02, 2009 6:34 PM > To: DKIM WG > Subject: Re: [ietf-dkim] Escaping things in key/ADSP records > > [...] Nice work! However: > If anyone has good (or known bad) records that it gets wrong I'm > interested to hear about it. It reports the contents of medusa3._domainkey.blackops.org as invalid which is not correct. That record contains an "r=" and an "rs=" tag, both of which are defined by active I-Ds. Those tags may be unknown to RFC4871, but that specification says such should merely be ignored; they don't render the record invalid. -MSK ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Escaping things in key/ADSP records
Excellent job. Perhaps a pointer to this can go on the dkim.org site? Tony Hansen t...@att.com Steve Atkins wrote: > On Jul 31, 2009, at 2:02 PM, Steve Atkins wrote: > >> (This may be a duplicate, I have too many email addresses) >> >> On Jul 31, 2009, at 12:08 PM, Scott Kitterman wrote: >> >>> On Fri, 31 Jul 2009 10:19:43 -0400 Tony Hansen wrote: I'm wondering if there is a need for a web interface at dkim.org that would validate someone's _domainkey TXT record. >>> I'd say yes. It would provide a good way to isolate record >>> specific issues >>> from other potential problems people are having error sources when >>> troubleshooting. >> I have some perl code that does some validation for internal use; it'd >> be fairly easy to turn it into a webapp. > > http://dkimcore.org/tools/dkimrecordcheck.html > > Given a selector and a domain it'll slurp the record from DNS. > > Then it parses it, using the BNF from the spec (why, oh, > why do we support FWS in a DNS record?) and then > sanity checks the various fields and gives a good / bad message. > > If anyone has good (or known bad) records that it gets wrong I'm > interested to hear about it. > > Cheers, >Steve > > ___ > NOTE WELL: This list operates according to > http://mipassoc.org/dkim/ietf-list-rules.html ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Escaping things in key/ADSP records
On Jul 31, 2009, at 2:02 PM, Steve Atkins wrote: > (This may be a duplicate, I have too many email addresses) > > On Jul 31, 2009, at 12:08 PM, Scott Kitterman wrote: > >> On Fri, 31 Jul 2009 10:19:43 -0400 Tony Hansen wrote: >>> I'm wondering if there is a need for a web interface at dkim.org >>> that >>> would validate someone's _domainkey TXT record. >>> >> I'd say yes. It would provide a good way to isolate record >> specific issues >> from other potential problems people are having error sources when >> troubleshooting. > > I have some perl code that does some validation for internal use; it'd > be fairly easy to turn it into a webapp. http://dkimcore.org/tools/dkimrecordcheck.html Given a selector and a domain it'll slurp the record from DNS. Then it parses it, using the BNF from the spec (why, oh, why do we support FWS in a DNS record?) and then sanity checks the various fields and gives a good / bad message. If anyone has good (or known bad) records that it gets wrong I'm interested to hear about it. Cheers, Steve ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Escaping things in key/ADSP records
Jim Fenton wrote: > If you still have the records, can you count the number of records > with g=; ? That's used in an example in some of the DomainKey specs > and works for DK but means "match nothing" for DKIM. I was planning on doing an analysis of the key values anyway, so here goes. 65461 DNS _domainkey records were examined that did not contain syntax errors. Of these, 37309 were used by DKIM and 46623 were used by DomainKeys. (Some were used by both.) Of them, 2186 have v=DKIM1. mistakes As noted before, there were a number of mistakes found within the key records. I found occurrences of all of these DKIM=unknownO=- a=rsa-sha1 c=nofws c=relaxed/relaxed d=SOMEDOMAINdkim=alli=* kv=DKIM1o=- o=~ q=dns If I trim the list down to the v=DKIM1 records, there are STILL errors: c=relaxed/relaxed o=- There are a few records that have r=EMAIL values in them. legal keys == g= == The following valid g= values were used by DKIM: g= g=* g=noreply For v=DKIM1 records, it's just g=* g=noreply This confirms the suggestion a couple meetings ago that vendors should treat g= as equivalent to g=* if v=DKIM1 is not found. There were NO cases of g=; found for v=DKIM1 records. == h= == The following valid h= values were used by DKIM. All of these were in v=DKIM1 records: h=sha1 h=sha1:sha256 h=sha256 A notable mistake was an entry with this value: h=rsa-sha1 == k= == The following valid k= values were used by DKIM. k=rsa A notable mistake was an entry with this value: k=rsa-sha1 It was NOT the same record as the similar h= mistake. == n= == 1879 of the records used n=. == s= == The value s=email was used in 33 records, 31 along with v=DKIM1. == t= == The following valid t= values were used by DKIM. t=s t=s:y t=y t=y:s Of note are these two mistakes: t=n t=s|y Hope people found this of interest. Tony Hansen t...@att.com ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Escaping things in key/ADSP records
(This may be a duplicate, I have too many email addresses) On Jul 31, 2009, at 12:08 PM, Scott Kitterman wrote: > On Fri, 31 Jul 2009 10:19:43 -0400 Tony Hansen wrote: >> I'm wondering if there is a need for a web interface at dkim.org that >> would validate someone's _domainkey TXT record. >> > I'd say yes. It would provide a good way to isolate record specific > issues > from other potential problems people are having error sources when > troubleshooting. I have some perl code that does some validation for internal use; it'd be fairly easy to turn it into a webapp. Cheers, Steve ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Escaping things in key/ADSP records
> -Original Message- > From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim- > boun...@mipassoc.org] On Behalf Of Scott Kitterman > Sent: Friday, July 31, 2009 12:09 PM > To: ietf-dkim@mipassoc.org > Subject: Re: [ietf-dkim] Escaping things in key/ADSP records > > On Fri, 31 Jul 2009 10:19:43 -0400 Tony Hansen wrote: > >I'm wondering if there is a need for a web interface at dkim.org that > >would validate someone's _domainkey TXT record. > > I'd say yes. It would provide a good way to isolate record specific > issues > from other potential problems people are having error sources when > troubleshooting. A verifier equipped with additional code to email sites whose keys or policy records contain errors might be useful. Then again, it might also be obnoxious. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Escaping things in key/ADSP records
On Fri, 31 Jul 2009 10:19:43 -0400 Tony Hansen wrote: >I'm wondering if there is a need for a web interface at dkim.org that >would validate someone's _domainkey TXT record. > I'd say yes. It would provide a good way to isolate record specific issues from other potential problems people are having error sources when troubleshooting. Scott K ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Escaping things in key/ADSP records
Tony, If you still have the records, can you count the number of records with g=; ? That's used in an example in some of the DomainKey specs and works for DK but means "match nothing" for DKIM. -Jim Tony Hansen wrote: > Mark Martinec wrote: > > John Levine wrote: > >> 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. > > > > I'm collecting a set of common mistakes breaking DKIM signatures. > > Pulling up a message from a while ago. Mark, did you ever get further > with your set of common mistakes? > > I had occasion to look at a number of DNS key records, and find the > following common mistakes: > > Sample size: 65456 DNS _domainkey (DKIM+DK) records > > 16missing semi-colons between fields > 1 missing any separators (k=rsap=) > 14invalid quotation marks (") surrounding the entire record > 2 invalid \" surrounding the entire record > 5 invalid parens or paren+quotes surrounding the entire record > 47\-quoted characters, particularly \; > 9 TTL value or other random DNS data showing up in the record > 1 TTL value being in the record instead of the public key > 17random characters in the record, e.g. {, CRLF, backspace, SUB, > > 113 SPF records being returned > 13key only, no p= or any other options > 1 encoded ; as %3B > 1 missing tag before = > 8 other data in record (dkim=all, O=-, r=, &, ") > 1 v=DKIM1 not first field in record > 50other random errors > --- > 299 > > I was not able to verify if any of the keys that had spaces within them > were actually valid keys or not. > > The good news is that of the sample, the majority of the records were > just fine. > > I'm wondering if there is a need for a web interface at dkim.org that > would validate someone's _domainkey TXT record. > > Thoughts? > > Tony Hansen > t...@att.com > ___ > NOTE WELL: This list operates according to > http://mipassoc.org/dkim/ietf-list-rules.html > > ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Escaping things in key/ADSP records
Mark Martinec wrote: > John Levine wrote: >> 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. > > I'm collecting a set of common mistakes breaking DKIM signatures. Pulling up a message from a while ago. Mark, did you ever get further with your set of common mistakes? I had occasion to look at a number of DNS key records, and find the following common mistakes: Sample size: 65456 DNS _domainkey (DKIM+DK) records 16 missing semi-colons between fields 1 missing any separators (k=rsap=) 14 invalid quotation marks (") surrounding the entire record 2 invalid \" surrounding the entire record 5 invalid parens or paren+quotes surrounding the entire record 47 \-quoted characters, particularly \; 9 TTL value or other random DNS data showing up in the record 1 TTL value being in the record instead of the public key 17 random characters in the record, e.g. {, CRLF, backspace, SUB, > 113 SPF records being returned 13 key only, no p= or any other options 1 encoded ; as %3B 1 missing tag before = 8 other data in record (dkim=all, O=-, r=, &, ") 1 v=DKIM1 not first field in record 50 other random errors --- 299 I was not able to verify if any of the keys that had spaces within them were actually valid keys or not. The good news is that of the sample, the majority of the records were just fine. I'm wondering if there is a need for a web interface at dkim.org that would validate someone's _domainkey TXT record. Thoughts? Tony Hansen t...@att.com ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Escaping things in key/ADSP records
John Levine wrote: > 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. 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 ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Escaping things in key/ADSP records
Is there any chance that this is an OS inspired edit? Perhaps the web front end has a built in escape clause -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Olivier MJ Crepin-Leblond Sent: Thursday, October 30, 2008 4:22 AM To: John Levine; ietf-dkim@mipassoc.org Cc: [EMAIL PROTECTED] Subject: Re: [ietf-dkim] Escaping things in key/ADSP records +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 - Original Message - From: "John Levine" <[EMAIL PROTECTED]> To: Cc: <[EMAIL PROTECTED]> Sent: Thursday, October 30, 2008 12:52 AM Subject: Re: [ietf-dkim] Escaping things in key/ADSP records > >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. > > 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. > > R's, > John > ___ > NOTE WELL: This list operates according to > http://mipassoc.org/dkim/ietf-list-rules.html ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Escaping things in key/ADSP records
> 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 PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Olivier MJ > Crepin-Leblond > Sent: Thursday, October 30, 2008 4:22 AM > To: John Levine; ietf-dkim@mipassoc.org > Cc: [EMAIL PROTECTED] > Subject: Re: [ietf-dkim] Escaping things in key/ADSP records > > +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... ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Escaping things in key/ADSP records
duly noted Tony Hansen [EMAIL PROTECTED] Murray S. Kucherawy wrote: > On Thu, 30 Oct 2008, John L wrote: >> 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. > > 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
Re: [ietf-dkim] Escaping things in key/ADSP records
+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 - Original Message - From: "John Levine" <[EMAIL PROTECTED]> To: Cc: <[EMAIL PROTECTED]> Sent: Thursday, October 30, 2008 12:52 AM Subject: Re: [ietf-dkim] Escaping things in key/ADSP records > >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. > > 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. > > R's, > John > ___ > NOTE WELL: This list operates according to > http://mipassoc.org/dkim/ietf-list-rules.html ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Escaping things in key/ADSP records
On Thu, 30 Oct 2008, John L wrote: > 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. 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
Re: [ietf-dkim] Escaping things in key/ADSP records
>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. 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. R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Escaping things in key/ADSP records
>> 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. 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 ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Escaping things in key/ADSP records
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
[ietf-dkim] Escaping things in key/ADSP records
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= ...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