4 ms·

Given the many historic openssl bugs related to certificate parsing (ie x509 and asn1) I’m not sure you should even trust expert crypto programmers to deal with

Given the many historic openssl bugs related to certificate parsing (ie x509 and asn1) I’m not sure you should even trust expert crypto programmers to deal with that

cormacrelf 5y ago
Some folks are trying to kill ASN.1. It is probably an awkward moment for that, when people are looking at binary encodings more because JSON is boring and doesn't stand out on a CV. It's got all the hallmarks of old tech that looks like it's survived on its merits, but it really isn't like that. > "ASN.1 is a serialization format which enables C programmers to turn binary data into remote code execution vulnerabilities" -- https://twitter.com/bascule/status/1086778481864658945 https://twitter.com/bascule/status/1086778481864658945 Also https://twitter.com/TwitchiH/status/1382649508371308547 https://twitter.com/TwitchiH/status/1382649508371308547, discussing it in context of the San Bernadino iPhone being broken with an ASN.1 vuln.
- lifthrasiir 5y ago
  The difference between ASN.1 (BER/DER) and modern binary encodings is that people have tried to parse the former by hand but not the latter (at least to my experience). BER/DER itself is a fine encoding---sure, it has a legacy including six string types but we can deal with them---and in principle a simple library with bound checks should have been more than enough. ASN.1 is however structured in a way that such a simple library looks like incomplete; it looks like that a correct way to parse BER/DER is an ASN.1 compiler, which tends to be bulky and annoying to integrate. As a result for a long time most ASN.1 implementations were either a "complete" ASN.1 compiler or a hand-crafted parser, with no middle ground of a library that is simple enough and prevents you from memory unsafety.
- memling 5y ago
  > Some folks are trying to kill ASN.1. It is probably an awkward moment for that, when people are looking at binary encodings more because JSON is boring and doesn't stand out on a CV. It's got all the hallmarks of old tech that looks like it's survived on its merits, but it really isn't like that. I think it's rather more than this. ASN.1 is deeply embedded in daily life: 3G/4G/LTE/5G, V2X, and many other protocols are specified in ASN.1. The inertia has as much to do with backwards compatibility as anything else. If you need to read call data records, you have to parse BER; if you want to deal with vehicle to vehicle communications you have to parse OER. 3G protocols are generally PER. Crypto is DER. Are there alternatives that are better in some respects? Sure. Are they likely to supplant existing telecommunications standards? No. Should move away from ASN.1 for crypto purposes? Probably, though I'm not experienced enough to have a strong opinion. I'd be interested to see whether we could install a new standard in a suitable time frame, and indeed what form that would take. (In the two links you cited, I didn't see anything, but I'm actually really interested!) I think ASN.1 is probably here to stay for a long time, and not merely as a resume polishing agent.
- woodruffw 5y ago
  > because JSON is boring and doesn't stand out on a CV. It's a little bit more than that: cryptographic container formats usually need to be stable on traversal/canonicalized so that things like hashes remain consistent. JSON alone doesn't have a canonicalized format (there are various suggested canonical forms), and leaves details about key iteration, duplication, etc. ambiguous in ways that are potential sources of vulnerability (what happens if a particular protocol allows users to introduce untrusted attributes to a JSON object and doesn't check for name clashes?). Edit: not to mention integer width/representation of large integers! That's a big one for cryptographic protocols.
  - memling 5y ago
    > It's a little bit more than that: cryptographic container formats usually need to be stable on traversal/canonicalized so that things like hashes remain consistent. Yeah, this, too: there's got to be a single way of representing the same message. (BER, in contrast to DER, has multiple means of writing the same message. BOOLEAN types, for example, indicate FALSE by 0x00, but TRUE is any non-zero value. I forget how DER resolves this. DER disallows the use of indefinite lengths, while BER admits both definite and indefinite lengths. Etc., etc.) I'm sympathetic to the challenges people face with ASN.1, having worked with it rather extensively in my career. I don't recommend it to people who have serialization challenges usually because something like protobuf or flatbuffers seems like a more reasonable choice in this day and age...but at the same time ASN.1 has a history of mistakes and innovations for solving some challenging problems in representation and encoding that should inform decision-making moving forward.
- jnwatson 5y ago
  ASN.1's primary problem is that it has been around a long time. Long before folks understood the security implications of a buffer overflow, we've been parsing ASN.1. Most of the vulnerabilities stem from the basic problem of trusting length fields. Any binary encoding is going to have similar issues.

Given the many historic openssl bugs related to certificate parsing (ie x509 and asn1) I’m not sure you should even trust expert crypto programmers to deal with that

cormacrelf 5y ago

Some folks are trying to kill ASN.1. It is probably an awkward moment for that, when people are looking at binary encodings more because JSON is boring and doesn't stand out on a CV. It's got all the hallmarks of old tech that looks like it's survived on its merits, but it really isn't like that. > "ASN.1 is a serialization format which enables C programmers to turn binary data into remote code execution vulnerabilities" -- https://twitter.com/bascule/status/1086778481864658945 https://twitter.com/bascule/status/1086778481864658945 Also https://twitter.com/TwitchiH/status/1382649508371308547 https://twitter.com/TwitchiH/status/1382649508371308547, discussing it in context of the San Bernadino iPhone being broken with an ASN.1 vuln.

lifthrasiir 5y ago
The difference between ASN.1 (BER/DER) and modern binary encodings is that people have tried to parse the former by hand but not the latter (at least to my experience). BER/DER itself is a fine encoding---sure, it has a legacy including six string types but we can deal with them---and in principle a simple library with bound checks should have been more than enough. ASN.1 is however structured in a way that such a simple library looks like incomplete; it looks like that a correct way to parse BER/DER is an ASN.1 compiler, which tends to be bulky and annoying to integrate. As a result for a long time most ASN.1 implementations were either a "complete" ASN.1 compiler or a hand-crafted parser, with no middle ground of a library that is simple enough and prevents you from memory unsafety.
memling 5y ago
> Some folks are trying to kill ASN.1. It is probably an awkward moment for that, when people are looking at binary encodings more because JSON is boring and doesn't stand out on a CV. It's got all the hallmarks of old tech that looks like it's survived on its merits, but it really isn't like that. I think it's rather more than this. ASN.1 is deeply embedded in daily life: 3G/4G/LTE/5G, V2X, and many other protocols are specified in ASN.1. The inertia has as much to do with backwards compatibility as anything else. If you need to read call data records, you have to parse BER; if you want to deal with vehicle to vehicle communications you have to parse OER. 3G protocols are generally PER. Crypto is DER. Are there alternatives that are better in some respects? Sure. Are they likely to supplant existing telecommunications standards? No. Should move away from ASN.1 for crypto purposes? Probably, though I'm not experienced enough to have a strong opinion. I'd be interested to see whether we could install a new standard in a suitable time frame, and indeed what form that would take. (In the two links you cited, I didn't see anything, but I'm actually really interested!) I think ASN.1 is probably here to stay for a long time, and not merely as a resume polishing agent.
woodruffw 5y ago
> because JSON is boring and doesn't stand out on a CV. It's a little bit more than that: cryptographic container formats usually need to be stable on traversal/canonicalized so that things like hashes remain consistent. JSON alone doesn't have a canonicalized format (there are various suggested canonical forms), and leaves details about key iteration, duplication, etc. ambiguous in ways that are potential sources of vulnerability (what happens if a particular protocol allows users to introduce untrusted attributes to a JSON object and doesn't check for name clashes?). Edit: not to mention integer width/representation of large integers! That's a big one for cryptographic protocols.
- memling 5y ago
  > It's a little bit more than that: cryptographic container formats usually need to be stable on traversal/canonicalized so that things like hashes remain consistent. Yeah, this, too: there's got to be a single way of representing the same message. (BER, in contrast to DER, has multiple means of writing the same message. BOOLEAN types, for example, indicate FALSE by 0x00, but TRUE is any non-zero value. I forget how DER resolves this. DER disallows the use of indefinite lengths, while BER admits both definite and indefinite lengths. Etc., etc.) I'm sympathetic to the challenges people face with ASN.1, having worked with it rather extensively in my career. I don't recommend it to people who have serialization challenges usually because something like protobuf or flatbuffers seems like a more reasonable choice in this day and age...but at the same time ASN.1 has a history of mistakes and innovations for solving some challenging problems in representation and encoding that should inform decision-making moving forward.
jnwatson 5y ago
ASN.1's primary problem is that it has been around a long time. Long before folks understood the security implications of a buffer overflow, we've been parsing ASN.1. Most of the vulnerabilities stem from the basic problem of trusting length fields. Any binary encoding is going to have similar issues.