Subject: [Isms] SNMP-TLS-TM-MIB errata

From: Robert Story <[email-masked]>
Date: Tue, 29 Jun 2010 20:23:38 -0400

Hi,

While testing our SNMP-TLS-TM-MIB implementation I discovered a problem
with the DISPLAY-HINT for SnmpTLSFingerprint. The current hint is
"1x:254x", which one might think meant one hex byte, a colon, and up to
254 more hex bytes. But according to section 3.1 of 2579, 254 is a
width specifier, so it is a one byte hex followed by a 254 byte wide hex
number. I believe the hint should be "1x:1x", which will be one hex
byte, a colon, and N hex bytes where N is the remaining length of the
octet string.

Hopefully this can be fixed before the rfc is finalized. It is a small
change that doesn't affect anything in the protocol or on the wire.

-- 
Robert Story
Senior Software Engineer
SPARTA (dba Cobham Analytic Soloutions)

---

From: Wes Hardaker <[email-masked]>
Date: Tue, 29 Jun 2010 18:52:48 -0700

Having just re-read the rules in RFC2579's 3.1, I agree with Robert's
analysis and will make this change during AUTH48 unless I hear
objections or other solution suggestions.
-- 
Wes Hardaker
Cobham Analytic Solutions

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 30 Jun 2010 05:17:00 +0200

> byte, a colon, and N hex bytes where N is the remaining length of the

Why do you believe 254 is a "width" specifier? RFC 2579 says:

(2)  the octet length: one or more decimal digits specifying the number
     of octets of the value to be used and formatted by this octet-
     specification.  Note that the octet length can be zero.  If less
     than this number of octets remain in the value, then the lesser
     number of octets are used.

My reading of this is "take 254 bytes of the value and display it as a
hexadecimal number". Your suggested hint says "take 1 byte of the
value and display it as a hexadecimal number" and since RFC 2579 says

   [...] If additional octets remain in the value after interpreting
   all the octet-format specifications, then the last octet-format
   specification is re-interpreted to process the additional octets,
   until no octets remain in the value.

you repeat taking a 1 byte value displaying it as a hexadecimal number
until the bytes are exhausted. So are not both hints producing the
same result? That said, I believe that "1x:1x" is a better choice given
the variable length nature of the SnmpTLSFingerprint.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Robert Story <[email-masked]>
Date: Wed, 30 Jun 2010 01:13:49 -0400

On Wed, 30 Jun 2010 05:17:00 +0200 Juergen wrote:
JS> Why do you believe 254 is a "width" specifier? RFC 2579 says:
JS> 
JS> (2)  the octet length: one or more decimal digits specifying the number
JS>      of octets of the value to be used and formatted by this octet-
JS>      specification.  Note that the octet length can be zero.  If less
JS>      than this number of octets remain in the value, then the lesser
JS>      number of octets are used.
JS> 
JS> My reading of this is "take 254 bytes of the value and display it as a
JS> hexadecimal number".

Hmmm... I have to admit, I'm biased by the Net-SNMP implementation of
display hint processing.  But using your reading and a hint of "2d",
given the value 0x0102, you could output a decimal number for each
octet and get the output "12", but the output should be the decimal
number represented by the two octets together: 258. It does seem to be a
bit ambiguous... but the next item, (3) says the octet length is used
in interpreting "the" value... i.e. a single value, which is how we
interpret "2d" in the example I gave earlier.

JS> So are not both hints producing the same result?

Definitely not in Net-SNMP. :-)  But I suppose I could be convinced
that it is a bug in our processing code.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 30 Jun 2010 07:48:09 +0200

> interpret "2d" in the example I gave earlier.

No, my reading matches yours. You take two bytes from the value and
render the value into a decimal number. So in case 254x, you take 254
bytes and render them into hexadecimal notation.

> that it is a bug in our processing code.

Can you show by example what the difference is between repeating 4
times "1x" and say once "4x"? Perhaps I am just missing the point...
 
/js

---

From: Robert Story <[email-masked]>
Date: Wed, 30 Jun 2010 11:44:51 -0400

On Wed, 30 Jun 2010 07:48:09 +0200 Juergen wrote:
JS> > JS> So are not both hints producing the same result?
JS> > 
JS> > Definitely not in Net-SNMP. :-)  But I suppose I could be convinced
JS> > that it is a bug in our processing code.
JS> 
JS> Can you show by example what the difference is between repeating 4
JS> times "1x" and say once "4x"? Perhaps I am just missing the point...

The only case that I can think of where it would make a difference
for hex would be leading zeros. Given the input "0x00000004", 1x would
output "00000004", while 4x would just output "4".

So the Net-SNMP library uses a long value to build the value before
printing it. This obviously doesn't work well for octet strings
larger than 4 bytes (on 32 bit systems, 8 bytes on 64 bit systems).

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 30 Jun 2010 22:52:13 +0200

> larger than 4 bytes (on 32 bit systems, 8 bytes on 64 bit systems).

Just looking at some old code I wrote. For OCTET STRINGs, I am always
rendering with leading zeros. It looks like my code has an issue with
a long conversion though. :-( I note that RFC 2579 is silent about
leading zeros in case of OCTET STRING values. (For 'x' it might make
sense to not suppress them, for 'd' and 'o' it likely makes sense to
suppress them. Isn't it fun that we still find questions like this?

I agree we should use the 1x format to avoid this pitfall.

/js