Subject: [dnsext] spaces in hex DS digest, NSEC3 salt and SSHFP

From: bert hubert <[email-masked]>
Date: Wed, 19 Jan 2011 20:03:46 +0100

Hi everybody,

PowerDNSSEC turns out to be confused by spaces in the database (or zone
file) in the DS digest. It terminates the digest at the first non-hex
character.

The venerable 'dig' tool emits DS digest type 2 with spaces:
powerdns.nl.		7200	IN	NS	powerdnssec2.ds9a.nl.
powerdns.nl.		7200	IN	NS	powerdnssec1.ds9a.nl.
powerdns.nl.		7200	IN	DS	7354 8 2
F238862D8DFCB5C837D33E28C0D318191DBA76FFC87C6F053D2AD67E 22BF1D7C

RFC 3658 says: 

 'The presentation format of the DS record consists of three numbers
  (key tag, algorithm, and digest type) followed by the digest itself
  presented in hex'

It says nothing about spaces in the hex. Of course we could be liberal in
what we accept, however, there is also the NSEC3 and NSEC3PARAM which store
the salt.. in hex.

RFC5155 says:

	The Salt field is represented as a sequence of case-insensitive
      	hexadecimal digits.  Whitespace is not allowed within the
      	sequence.

Finally, SSHFP is the third type that encodes hex blobs, and RFC 4255
states:

   'The RDATA of the presentation format of the SSHFP resource record
   consists of two numbers (algorithm and fingerprint type) followed by
   the fingerprint itself, presented in hex"

Sadly this breaks the nice symmetry where we had only one 'hexBlob', one
that terminates at the first space.

Because 'dig' is so widely distributed, I'm afraid we'll have no choice but
to butcher PowerDNS into dealing with the spaces, but what do people think?
Do spaces belong in hex blobs, and in the DS specifically?

	Bert
_______________________________________________
dnsext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsext

---

From: Alex Bligh <[email-masked]>
Date: Wed, 19 Jan 2011 19:11:40 +0000

--On 19 January 2011 20:03:46 +0100 bert hubert <[email-masked]> 
wrote:

> what do people think?

dig bug

-- 
Alex Bligh

---

From: Paul Wouters <[email-masked]>
Date: Wed, 19 Jan 2011 14:29:42 -0500 (EST)

> F238862D8DFCB5C837D33E28C0D318191DBA76FFC87C6F053D2AD67E 22BF1D7C

It really differs for which dig. Eg this older one shows:

openswan.nl.            7200 IN DS 42018 5 2 (
                                 8DB5704A28E9F583E0E6AB41EED3BCF2613E2AD4BDC3
                                 69C64A395F2F5EA16917 )

I'd say this is a dig specific issue.

Paul

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 19 Jan 2011 14:38:48 -0500

Didn't we move to a view that presentation format is not part of the DNS
specification and hence later drafts have 'suggested' presentation formats?

It gets a bit problematic because there is a presumption of interoperability
in the configuration file format even though that is never exchanged as bits
on the wire.

-- 
Website: http://hallambaker.com/
_______________________________________________
dnsext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsext

---

From: Tony Finch <[email-masked]>
Date: Wed, 19 Jan 2011 19:41:48 +0000

> Do spaces belong in hex blobs, and in the DS specifically?

The example in RFC 4034 section 5.4 has whitespace inside the hex blob.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
HUMBER THAMES DOVER WIGHT PORTLAND: NORTH BACKING WEST OR NORTHWEST, 5 TO 7,
DECREASING 4 OR 5, OCCASIONALLY 6 LATER IN HUMBER AND THAMES. MODERATE OR
ROUGH. RAIN THEN FAIR. GOOD.
_______________________________________________
dnsext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsext

---

From: "Jeremy C. Reed" <[email-masked]>
Date: Wed, 19 Jan 2011 13:43:22 -0600 (CST)

> what we accept, however, there is also the NSEC3 and NSEC3PARAM which store

3658 is obsoleted by 4033. RFC 4033 says "Whitespace is allowed within 
the hexadecimal text."

---

From: Roy Arends <[email-masked]>
Date: Wed, 19 Jan 2011 19:45:13 +0000

I don't recall that. RFC1035 defines Master Files Format in section 5.

Hope this helps.

Roy

Sent from my iPhone

On 19 Jan 2011, at 19:39, "Phillip Hallam-Baker" <[email-masked]<mailto:[email-masked]>> wrote:

Didn't we move to a view that presentation format is not part of the DNS specification and hence later drafts have 'suggested' presentation formats?

It gets a bit problematic because there is a presumption of interoperability in the configuration file format even though that is never exchanged as bits on the wire.

On Wed, Jan 19, 2011 at 2:03 PM, bert hubert <<mailto:[email-masked]>[email-masked]<mailto:[email-masked]>> wrote:
Hi everybody,

The venerable 'dig' tool emits DS digest type 2 with spaces:
<http://powerdns.nl>powerdns.nl<http://powerdns.nl>.            7200    IN      NS      <http://powerdnssec2.ds9a.nl> powerdnssec2.ds9a.nl<http://powerdnssec2.ds9a.nl>.
<http://powerdns.nl>powerdns.nl<http://powerdns.nl>.            7200    IN      NS      <http://powerdnssec1.ds9a.nl> powerdnssec1.ds9a.nl<http://powerdnssec1.ds9a.nl>.
<http://powerdns.nl>powerdns.nl<http://powerdns.nl>.            7200    IN      DS      7354 8 2
F238862D8DFCB5C837D33E28C0D318191DBA76FFC87C6F053D2AD67E 22BF1D7C

RFC 3658 says:

RFC5155 says:

       Bert
_______________________________________________
dnsext mailing list
<mailto:[email-masked]>[email-masked]<mailto:[email-masked]>
<https://www.ietf.org/mailman/listinfo/dnsext>https://www.ietf.org/mailman/listinfo/dnsext

--
Website: <http://hallambaker.com/> http://hallambaker.com/

_______________________________________________
dnsext mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/dnsext
_______________________________________________
dnsext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsext

---

From: David Blacka <[email-masked]>
Date: Wed, 19 Jan 2011 14:45:35 -0500

>      	hexadecimal digits.  Whitespace is not allowed within the

The reason why whitespace wasn't allowed for the salt was to prevent ambiguity in parsing the zone file format.  The other records with blobs can have whitespace without ambiguity because those records have a fixed number of fields and the hex/base64 encoded field is last.  Therefore a parser can be reasonably expected to know that it is parsed the prior two (e.g.) fields (which couldn't have whitespaces) and then conclude that the rest of the record is the final field, whitespace and all.

> Do spaces belong in hex blobs, and in the DS specifically?

"belong" isn't the correct term,  "allowed" is.  And spaces aren't disallowed, thus are implicitly allowed.  Thus, you have to deal with it somehow.  Sorry.

--
David Blacka                          <[email-masked]> 
Principal Engineer    Verisign Platform Product Development

---

From: Chris Thompson <[email-masked]>
Date: 19 Jan 2011 19:54:01 +0000

>3658 is obsoleted by 4033. RFC 4033 says "Whitespace is allowed within 

I think you mean 4034 (section 5.3, just before to the example in section
5.4 quoted by Tony Finch), but the same remark applies.

-- 
Chris Thompson               University of Cambridge Computing Service,
Email: [email-masked]    New Museums Site, Cambridge CB2 3QH,
Phone: +44 1223 334715       United Kingdom.
_______________________________________________
dnsext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsext

---

From: bert hubert <[email-masked]>
Date: Wed, 19 Jan 2011 21:01:37 +0100

On Wed, Jan 19, 2011 at 02:45:35PM -0500, David Blacka wrote:
> disallowed, thus are implicitly allowed.  Thus, you have to deal with it
> somehow.  Sorry.

Well, we got it - http://wiki.powerdns.com/trac/changeset/1900

However, I'd like to say that I find remarks that RFCs do not specify the
representation format to be somewhat worrying. It smells of a cop out.

If RFCs don't specify a canonical textual representation format, they are
not as useful as they could be.

Other posters remarked that DNS representations never hit the wire, but in
reality this is very untrue. DNS in most large settings is not provisioned
via 'vi' but via an API that fills out a backend.

Such an API needs a representation too.

I can understand that an RFC should not *mandate* a storage format, but it
would be useful to specificy a 'canonical textual representation'. If only
because people like to copy/paste dig output.

	Bert

---

From: David Blacka <[email-masked]>
Date: Wed, 19 Jan 2011 15:10:09 -0500

> representation format to be somewhat worrying. It smells of a cop out.

My real point wasn't really about how the RFCs were written.  It was more on the order of "this behavior exists in the wild, so you have to handle it."  The idea that it wasn't disallowed by the RFC just means you don't have a standards-based justification to not handle it.

But, I was wrong.  It isn't that whitespace was implicitly allowed.  As others who bother to look at the RFCs pointed out, it is explictly allowed.

---

From: Brian Dickson <[email-masked]>
Date: Wed, 19 Jan 2011 16:18:32 -0400

Hi, Bert,

I'd say that whatever you do, if you are breaking up a "blob", you
should stick by RFC 1035, and put it inside parentheses "()".

The parentheses indicate that line breaks in the parentheses should be
ignored; this could/should extend to whitespace as appropriate.

Brian

---

From: Mark Andrews <[email-masked]>
Date: Thu, 20 Jan 2011 08:40:55 +1100

In message <AANLkTi=[email-masked]>, Bria
> ignored; this could/should extend to whitespace as appropriate.

No.  We should not change the meaning of parentheses.

As for masterfile format.  It is standardised interchange format
and all nameserver packages SHOULD be able to read it.  There is
no requirement to use it internally.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]
_______________________________________________
dnsext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsext

---

From: Francis Dupont <[email-masked]>
Date: Fri, 21 Jan 2011 20:31:44 +0100

IMHO it is a problem of length, i.e., if the hex digest can be
long then one should be allowed to cut it to make it more readable.
Of course this includes spaces.
Note this argument applies only to DS, not to NSEC3 salt which
is BTW not the last field, i.e., a space makes the RR ambiguous.
About SSHFP I think it should be handled in same way than DS.

Regards

[email-masked]
_______________________________________________
dnsext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsext