[cryptography] preventing protocol failings

Sampo Syreeni decoy at iki.fi
Wed Jul 6 15:35:43 EDT 2011

On 2011-07-06, Nico Williams wrote:

> To be fair, when I wrote that "you have to know the schema and message 
> type in order to do a good job of parsing the message", what I had in 
> mind was an actual application, not a forensic/debug tool like 
> dumpasn1 [...]

To my mind the difference seemed to be about shallow versus deep 
parsing. You can't really deep parse anything in BER with implicit 
tagging, while you can fully parse and also renormalize the intermediate 
levels of the parse tree. What is left behind is the stuff beyond 
implicit tags, where you can't discern the precise, atomic data types 
(which in effect become blobs of octets, then). Just as you said.

In this sense I would agree: to me parsing an input means parsing it 
right down to the last bit. If there's anything you have to skip, or 
munge, or skirt/skip over, that's not parsing proper, but shallow 

At the same time, I took Peter's comment to mean that he parses as deep 
as is possible, in a deterministic fashion, and then goes on to add some 
heuristic for even deeper debugging capability.

(Peter, correct me if I'm wrong.)

I don't see any real tension between these two approaches; one aims at 
formal correctness, and the second goes for maximum informativeness in 
decoding the stuff. But I'll have to say, I would personally want each 
and every protocol out there to be parsed deep. Shallow parsing is a 
highly useful debugging and development tool where polymorphism (and 
even just general complexity) comes into play. But in the end, if we 
talk about Parsing Inputs and Protocols, instead of a 
developmental/debugging crutch towards it, we should always be able to 
deep parse. Especially in the case of cryptographic protocols, we should 
then also fail deep/hard/safe/atomically/with-a-single-fail-code, if the 
input string fails to parse just right against an unambiguous grammar.

Against an efficient-to-parse, formal grammar, I might add...

> An actual application implementation just needs to know the ASN.1 
> types of the message being decoded, and this is equally true of PER as 
> of BER. [...]

The main reason I answered like this was that I'm seeing the first steps 
towards a vigorous agreement. :)
Sampo Syreeni, aka decoy - decoy at iki.fi, http://decoy.iki.fi/front
+358-50-5756111, 025E D175 ABE5 027C 9494 EEB0 E090 8BA9 0509 85C2

More information about the cryptography mailing list