[Cryptography] Is it time for a revolution to replace TLS?

Judson Lester nyarly at gmail.com
Wed Apr 16 16:19:09 EDT 2014


On Wed, Apr 16, 2014 at 11:52 AM, Tony Arcieri <bascule at gmail.com> wrote:
> On Wed, Apr 16, 2014 at 11:32 AM, Judson Lester <nyarly at gmail.com> wrote:
>>
>> So much poorly supported hate for ASN.1 in there.
> Have you actually read the LANGSEC paper and the attacks on ASN.1 they
> describe?
>
> http://langsec.org/papers/langsec-tr.pdf

To be honest, I just did. I'd read a couple of the other papers
referenced and was frustrated by not finding the proof of the parser
strength required. I did run across another paper that enumerated the
same attacks without getting to math.

I think the language formalism approach has a lot of merit.

A couple of points:

First, the attacks they enumerate don't make use of the fact that DER
is context-sensitive. The example they present against X.509
specifically has to do with the fact that DER allows for embedded
nulls - and that C-related implementations don't properly handle that
case. It'd be as possible to produce a regular language with the same
issue.

Second, my intuition is that CER would be context-free - as much as
s-expressions would be. And that DER is O(n) isomorphic to CER. So if
anything, there's an direction for how to implement an X.509 parser.

But it still wouldn't solve null embeddings - but that's solvable.
(And: I'm not familiar enough with Rust to answer this off the top of
my head: you'd have to implement a check for nulls there, anyway,
right?)


The other part of my issue with the original essay is this: TLS is the
result of decades of work. I'm not saying that that's inherently
valuable, but I'm concerned that an effort to replace it will resemble
e.g. Mongo's reimplementation of SQL in JSON. I'm not impressed with
"let's switch to CurveCP, which would work in some other world where
TCP wasn't prevalent."

Judson

On Wed, Apr 16, 2014 at 12:41 PM, Judson Lester <nyarly at gmail.com> wrote:
> To be honest, I just did. I'd read a couple of the other papers
> referenced and was frustrated by not finding the proof of the parser
> strength required. I did run across another paper that enumerated the
> same attacks without getting to math.
>
> I think the language formalism approach has a lot of merit.
>
> A couple of points:
>
> First, the attacks they enumerate don't make use of the fact that DER
> is context-sensitive. The example they present against X.509
> specifically has to do with the fact that DER allows for embedded
> nulls - and that C-related implementations don't properly handle that
> case. It'd be as possible to produce a regular language with the same
> issue.
>
> Second, my intuition is that CER would be context-free - as much as
> s-expressions would be. And that DER is O(n) isomorphic to CER. So if
> anything, there's an direction for how to implement an X.509 parser.
>
> But it still wouldn't solve null embeddings - but that's solvable.
> (And: I'm not familiar enough with Rust to answer this off the top of
> my head: you'd have to implement a check for nulls there, anyway,
> right?)
>
>
> The other part of my issue with the original essay is this: TLS is the
> result of decades of work. I'm not saying that that's inherently
> valuable, but I'm concerned that an effort to replace it will resemble
> e.g. Mongo's reimplementation of SQL in JSON. I'm not impressed with
> "let's switch to CurveCP, which would work in some other world where
> TCP wasn't prevalent."
>
> Judson
>
> On Wed, Apr 16, 2014 at 11:52 AM, Tony Arcieri <bascule at gmail.com> wrote:
>> On Wed, Apr 16, 2014 at 11:32 AM, Judson Lester <nyarly at gmail.com> wrote:
>>>
>>> So much poorly supported hate for ASN.1 in there. Especially
>>> surprising that they imply that JSON would be better (or two of the
>>> headline articles in the referenced at
>>> http://www.cs.dartmouth.edu/~sergey/langsec/).
>>
>>
>> Have you actually read the LANGSEC paper and the attacks on ASN.1 they
>> describe?
>>
>> http://langsec.org/papers/langsec-tr.pdf
>>
>> --
>> Tony Arcieri


More information about the cryptography mailing list