[Cryptography] Langsec & authentication

[Phillip Hallam-Baker]

On Mon, May 26, 2014 at 5:42 PM, James A. Donald <jamesd at echeque.com> wrote:
> On 2014-05-27 04:23, Judson Lester wrote:
>>
>> I've been fascinated to discover and read about the langsec movement
>> in the wake of heartbleed. The fundamental ideas seem sound, but
>> there's at least one question I'm have but haven't seen addressed
>> anywhere.
>>
>> As I understand it, the langsec position is that specifying your
>> protocol language to be as easy to parse as possible, in Chomsky
>> hierarchy terms, has direct security implications - if the uppermost
>> surface of your networked application doesn't have to include a Turing
>> machine, that severely limits an avenue of attack on that application.
>>
>> What confuses me is trying to align this with a principle of
>> cryptography that you should only authenticate what you mean, as
>> opposed to authenticating a particular series of bytes, especially in
>> the face of langsec sites that recommend the use of JSON after having
>> argued convincingly against ASN.1 DER.
>
>
>
> ASN.1 DER contains a turing machine in which the attacker can execute code
> that you never imagined.

Not in my code. But then again I only implement the parts of ASN.1
required to encode and decode X.509v3 certs. I don't implement the
macros and I don't use the ASN.1 schema language.





> With ASN.1 PER that turing machine is executed at compile time, and at run
> time is no longer around, so your attacker cannot use it.
>
> This is like the difference between using SQL (injection attacks) and
> compiled SQL.

The problem I have with 'compiled' SQL is that I am not at all sure
that the drivers would be using it like that.


> Just as SQL is extraordinarily vulnerable to attack, while compiled SQL and
> stored SQL procedures are normally invulnerable to attack, ASN.1 DER is
> extraordinarily vulnerable, while ASN.1 PER is normally invulnerable.

I think that has to be a consequence of the decoder design rather than
the format.