[Cryptography] TLS2

[ianG]

On 2/10/13 00:43 AM, James A. Donald wrote:
> On 2013-10-01 14:36, Bill Stewart wrote:
>> It's the data representations that map them into binary strings that
>> are a
>> wretched hive of scum and villainy, particularly because you can't
>> depend on a
>> bit string being able to map back into any well-defined ASN.1 object
>> or even any limited size of ASN.1 object that won't smash your stack
>> or heap.
>> The industry's been bitten before by a widely available open source
>> library
>> that turned out to be vulnerable to maliciously crafted binary strings
>> that could be passed around as SNMP traps or other ASN.1-using messages.
>>
>> Similarly, PGP's most serious security bugs were related to
>> variable-length binary representations that were trying to steal bits
>> to maximize data compression at the risk of ambiguity.
>> Scrounging a few bits here and there just isn't worth it.
>
>
> This is an inherent problem, not with ASN.1, but with any data
> representation that can represent arbitrary data.


Right.  I see the encoding choice as both integral to any proposal, and 
a very strong design decision.

I would fail any proposal that used some form of external library like 
ASN.1, XML, JSON, YAML, pb, Thrift, etc, that was clearly not suited for 
purpose of security.  I would give a thumbs-up to any proposal that 
created its own tight custom definition.


> The decoder should only be able to decode the data structure it expects,
> that its caller knows how to interpret, and intends to interpret.
> Anything else should fail immediately.  Thus our decoder should have
> been compiled from, a data description, rather than being a general
> purpose decoder.


This is why I like not using a decoder.  My requirement is that I read 
exactly what I expect, check it for both syntax & semantics, and move 
on.  There should be no intervening "lazy compilation" steps to stop the 
coder seeing the entire picture.

Another problem with decoders is that you need a language.  So that 
makes two languages - the primary one and the layout.  Oops.  Have you 
noticed how these languages start off simple and get more and more 
complicated, as they try and do what the primary could already do?

The end result is no savings in coding, split sanity & semantics 
checking, added complexity and less security.  For every element you 
need to read, you need a line of code either way you do it, so it may as 
well be in the primary language, and then you get the security and the 
full checking capability, for free.


> Thus sender and receiver should have to agree on the data structure for
> any communication to take place, which almost automatically gives us a
> highly compressed format.
>
> Conversely, any highly compressed format will tend to require and assume
> a known data structure.
>
> The problem is that we do not want, and should not have, the capacity to
> send a program an arbitrary data structure, for no one can write a
> program that can respond appropriately to an arbitrary data structure.


Right.  To solve this, we would generally know what is to come, and we 
would signal that the exact expected thing is coming.

Following-data-identification is the one problem I've not seen an 
elegant solution to.  Tagging is something that lends itself to some 
form of hierarchical or centralised solution.  I use a centralised file 
with numbers and classes, but there are many possibilities.

If I was to do it, for TLS2, I'd have a single table containing the 
mapping of all things.  It would be like (off the top of my head):


1  compactInt
2  byteArray
3  bigInt
4  booleans

20 secret key packet
21 hash
22 private key packet
23 public key packet
24 hmac

40 Hello
41 Hiya
42 Go4It
43 DataPacket
44 Teardown


I don't like it, but I've never come across a better solution.




iang