Re: [cf-dev] Certificate Types, Cipher Suites, Compression Methods etc

[Bill Bennett <william.bennett@xxxxxxxxxxxxxxxxxxx>]

Hi Kai,

I think I missed part of the conversation here, but I just did the same thing for CompressionMethod.

I have to admit that I thought that returning a different enum than the requested one was a weird way to handle it. I think that it should throw an exception (preferred) or return a true null.

I don't think you need much code to handle that; it should be safe to just skip adding it to the list in listFromByteArray(). I only see a couple of scattered references elsewhere, most of which should have extra code to deal with that case anyway. E.g. ServerHello.fromByteArray() should be throwing HandshakeException.

Is there any need for a reference to something we can't support?

Thanks,
Bill

On 21/01/15 21:15, Hudalla Kai (INST/ESY) wrote:

Hi,

 

The scandium DTLS implementation currently uses enums for defining supported certificate types, cipher suites, compression methods and probably other stuff. During my work on the TLS handshake implementation I came across problems with this approach since the TLS spec allows for additional certificate types, cipher suites and compression methods being added over time. These are usually managed by the IANA TLS params registry.

However, using enums to represent these types, it is hard to implement a flexible and configurable handshake behavior that can deal with not yet supported types proposed by the peer during the handshake.

I would therefore like to change most of the enums to standard classes that contain the set of already known types embedded as an enum. This way we can always instantiate an object representation of the types instead of introducing null handling code throughout the handshaking process.

 

@Matthias: This will also address your question of whether returning the NULL cipher by default if an unknown cipher suite code is encountered is a good idea (I actually don’t think so).

 

This will involve quite an amount of refactoring. However, it should not affect Scandium’s external API at all so I think it is worth the effort because we will then be able to add more flexibility in configuring the supported types on a case by case basis, i.e. code using Scandium can better configure the DTLS layer’s behavior.

 

What do you think?

 

Regards,

Kai