Subject: BER v DER: implementation comment

From: "D. R. Evans" <[email-masked]>
Date: Thu, 02 Sep 2004 08:41:11 -0600

Putting aside all issues related to whether it's wise to require 
BER-capable parsers, I did just go look at our PKINIT KDC code to see 
how much of an effort it would take to switch to BER decoding for the 
CMS stuff while continuing to use DER for the other layers.

It looks like a grand total of somewhere between 5 and 10 lines of code 
would need to be added :-)

If the PKINIT RFC were to require BER support for the CMS stuff, though, 
it should be very explicit about exactly which fields could be BER 
encoded. Don't just say something like "the CMS layer".

I repeat that this e-mail has nothing to do with whether requiring BER 
support is wise.

Also, one shouldn't generalize it to assume that all implementations 
would require similarly small amounts of change. I suspect that adding 
support for BER decoding of some fields while maintaining DER decoding 
for other fields would in fact be a major pain for some implementations, 
especially clients.

   Doc

-- 
--------------------------------------------------------------
Phone:  +1 303 494 0394
Mobile: +1 720 839 8462
Fax:    +1 781 240 0527
IM:     [email-masked]
--------------------------------------------------------------

---

From: Tom Yu <[email-masked]>
Date: Thu, 02 Sep 2004 19:07:01 -0400

>>>>> "N7DR" == D R Evans <[email-masked]> writes:

N7DR> Also, one shouldn't generalize it to assume that all implementations
N7DR> would require similarly small amounts of change. I suspect that adding
N7DR> support for BER decoding of some fields while maintaining DER decoding
N7DR> for other fields would in fact be a major pain for some
N7DR> implementations, especially clients.

Valid DER encodings are a subset of valid BER encodings.  As long as
you don't enforce strict DER on decode, a BER parser will handle both
DER and BER inputs.

---Tom

---

From: "D. R. Evans" <[email-masked]>
Date: Fri, 03 Sep 2004 08:23:43 -0600

Tom Yu said the following at 2004-09-02 17:07 :

> you don't enforce strict DER on decode, 

Um.... are you really suggesting that PKINIT-enabled KDCs not enforce 
DER when they parse incoming messages?

Danger, danger, Will Robinson....

"Why does your KDC not accept my BER-encoded Kerberos messages? This one 
over here is much better than yours, because it does...."

   Doc

---

From: Sam Hartman <[email-masked]>
Date: Fri, 03 Sep 2004 15:01:54 -0400

>>>>> "D" == D R Evans <[email-masked]> writes:

    D> Tom Yu said the following at 2004-09-02 17:07 :
    >> Valid DER encodings are a subset of valid BER encodings.  As
    >> long as you don't enforce strict DER on decode,

    D> Um.... are you really suggesting that PKINIT-enabled KDCs not
    D> enforce DER when they parse incoming messages?
Yes.  This is actually not uncommon design wizdom in the IETF 

Keep in mind that the IETF arises out of a practical tradition of
interoperability.  We judge success by how many independent
implementations we can get to talk to each other.  AT least in the
microcosmic view, liberally accepting input may increase
interoperability.

--Sam

---

From: Jan Nordqvist <[email-masked]>
Date: Mon, 06 Sep 2004 17:46:21 -0700

I am sorry to solicit on this discussion, but as an implementor of 
several ASN.1 based applications, among them a full Kerberos 5 KDC with 
PKINIT support for both the DH and the RSA leg including the 
parser/encoder code for both Kerberos and CMS, I could not resist 
speaking up.

1. Sam's opinion is 100% shared by me and I simply can't see any reason 
that a KDC would or should not accept BER encoded data in the Kerberos 
OR CMS parts of the message as long as signatures and checksums are 
correct over the encoded data. As far as I am concerned, one of the 
prime reasons for dictating the unambiguous DER subset of the encoding, 
is to allow devices to be able to decode and re-encode signed messages 
without alteration of data-content and still be relieved from 
recalculating hashes or signatures.
Unless someone more cryptographically educated than me can speak up and 
prove that using DER encoded data for signing/hashing/encryption is less 
vulnerable for breaking than sane BER encoded ditto, I think the golden 
rule of  "Be conservative in what you send, and liberal in what you 
accept" applies equally well to CMS/Kerberos as it does to many other 
protocols. I said "sane BER" because BER obviously leaves opportunities 
to encode a single byte integer into megabytes of zeroes.

2. An implementation that decodes BER will always implicitly decode DER 
as well since DER is an indistinguishable subset of BER as Tom Yu 
pointed out. If it does not, it has nothing to do with ASN.1 decoding.

3. A strict DER encoder is in reality a BER encoder with policy 
restriction added to enforce the definite encoding rules of DER. With 
this in mind, an implementor could easily add dynamics to the policy 
enforcement (e.g. strict DER / BER with "reason", i.e. no indefinite 
length and/or other limitations such as not allowing 100 bytes for a 
length field of "1" / no enforcements).

One could argue that CMS by allowing "open ended" BER opens up a 
potential security hole for an attacker, but it seems to me that the 
purpose of this discussion is not to suggest redefinition of CMS but 
rather accept it as a base building block to implement extensions to 
Kerberos.
My implementation decodes BER and encodes DER and shares the ASN.1 layer 
between CMS and Kerberos and works impeccable with a number of different 
clients that it has been tested against, including MIT's own. It has 
been a while since I worked on the low-level parts of it, but I know for 
a fact that some of the clients I used emitted non-DER encoding of the 
Kerberos parts.

So the bottom line would be that one should be able to utilize any CMS 
library using BER or DER encoding if it says "CMS" in the PKINIT spec, 
and if available to the KDC implementor, he/she could with a minimal 
effort add policy code so to let the end user/installer determine the 
decoding strictness of Kerberos 5.

Jan Nordqvist

---

From: Love <[email-masked]>
Date: Tue, 07 Sep 2004 11:11:50 +0200

> to encode a single byte integer into megabytes of zeroes.

Just look at X.509, it assumes that the Certificate is encoded with DER (so
that TBSCertificate is DER encoded). If you where to allow BER,
TBSCertificate _could_ be encoded diffrently, and thus the checksum in
Certificate no longer match.

There are simular examples in Kerberos (SAM).

So far I've only seem one usage of BER that is sane, and that is in CMS and
for "streaming" objects, ie when you don't know the size of the input and
don't can save the whole content.

Love

---

From: Matt Crawford <[email-masked]>
Date: Tue, 07 Sep 2004 07:30:09 -0500

In the context of recent news and discussions on cheap collisions in 
hash functions, it seems to me that accepting full BER gives an 
attacker more opportunities to manufacture a collision.  The space in 
which useful colliding messages can be found is still rather 
restricted, so I cannot estimate the importance of this point. Still, 
accepting non-DER encoding in the minimum required contexts seems 
prudent.

     Matt Crawford

---

From: Martin Rex <[email-masked]>
Date: Tue, 7 Sep 2004 15:17:09 +0200 (MET DST)

> accepting non-DER encoding in the minimum required contexts seems 
 
X.509v3 certificates are a so much more interesting targets for
Hash function collisions.  It's easy to add an non-critical
X.509v3 certificate extension with an unusual OID, deliberate
length and deliberate contents which every correct PKI-implementation
is supposed to ignore.

-Martin

---

From: Martin Rex <[email-masked]>
Date: Tue, 7 Sep 2004 15:21:53 +0200 (MET DST)

> Certificate no longer match.

Unfortunately there is PKI-Software out there that fails to produce
correct DER encoding for X.509 certs, and it is used by commercial
CAs for their RootCA cert which is being shipped with browsers for
a couple of years already.

The GlobalSign CA uses a non-DER RootCA certificate; the KeyUsage
BitString has an incorrect "validBits" count.

-Martin

---

From: Jan Nordqvist <[email-masked]>
Date: Tue, 07 Sep 2004 10:19:05 -0700

That would only happen if the certificate is decoded and re-encoded into 
a different form by some entity without recalculating the signature. I 
don't know of any software that writes certificates except certificate 
generators, and in all other instances the certificate in its 
distributed encoding should be treated as a read only object.

- Jan.