Re: [cf-dev] DTLS handshake message encryption

["Hudalla Kai (INST/ESY)" <Kai.Hudalla@xxxxxxxxxxxx>]

Hi Matthias,

the messages are encrypted as part of the Handshaker.wrapMessage(Record) method where Record instances are created for the outgoing DTLSMessages. As part of Record's constructor the Record.setFragment(DTLSMessage) method is invoked where the encryption takes place invariably for all types of messages. It seems that the original idea in the code was to control the need for encryption by means of the existence of a DTLSSession within the Record instance. However, this obviously does not work for a rehandshake or session resumption where the server still has a cached session.

Regarding understanding of the spec: What's the meaning of "special case for the FINISHED message"? Do you think that it should be encrypted according to the current session state? I think that only the incuded hash is generated using the (newly) negotiated crypto params but the fragment itself is still plaintext.

The spec explicitly states that Change Cipher Spec messages must be encrypted according to the current session state, i.e. in an initial handshake the message is not encrypted, whereas in a rehandshake it would be encrpyted using the session's current state, right?

Kai
________________________________________
Von: cf-dev-bounces@xxxxxxxxxxx [cf-dev-bounces@xxxxxxxxxxx]" im Auftrag von "Kovatsch  Matthias [kovatsch@xxxxxxxxxxx]
Gesendet: Dienstag, 31. März 2015 20:59
An: Californium (Cf) developer discussions
Betreff: Re: [cf-dev] DTLS handshake message encryption

Dear Kai

I understand it the same way: Handshake messages in plaintext (with a special case for Finished), ChangeCipherSpec and appdata depending on the current state. In a resumption, ChangeCipherSpec is still "plaintext."

During development, we could not test the abbreviated handshake with other implementations because the feature was not available. So it is possible that there are still issues.

Looking through the code, I could not find the place where encryption would be applied (doProcessMessage() is overridden in ResumingServerHandshaker). Did you see an encrypted flight from the server on the wire?

Ciao
Matthias

> -----Original Message-----
> From: cf-dev-bounces@xxxxxxxxxxx [mailto:cf-dev-bounces@xxxxxxxxxxx] On
> Behalf Of Hudalla Kai (INST/ESY)
> Sent: Tuesday, 31 March 2015 09:21
> To: cf-dev@xxxxxxxxxxx
> Subject: [cf-dev] DTLS handshake message encryption
>
> Hi,
>
> I am currently working on some issues with the DTLS handshake in Scandium.
> While going through the ResumingServerHandshaker I noticed that it encrypts all
> messages sent to the client according to the current session state. While going
> through section 7.4 of the TLS 1.2 [1] spec I found this passage:
> "Handshake messages are supplied to the TLS record layer, where they are
> encapsulated within one or more TLSPlaintext structures, which are processed
> and transmitted as specified by the current active session state."
> My understanding of this is that handshake messages are never encrypted but
> are always transmitted in plaintext (except for the Change Cipher Spec message
> which actually is not a handshake message).
> Does anybody have any deeper insight into this? Matthias, have you given this
> more thought yet?
>
> [1] http://tools.ietf.org/html/rfc5246#section-7.4
>
> Regards,
> Kai
>
> _______________________________________________
> cf-dev mailing list
> cf-dev@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe from
> this list, visit https://dev.eclipse.org/mailman/listinfo/cf-dev
_______________________________________________
cf-dev mailing list
cf-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cf-dev