Re: [TLS] DTLS implementation questions

[Rob Dugal <RDugal at certicom.com>]

I discovered several bugs in the openssl
implementation back in dec 2005 that prevented it interoperating with our
implementation.
- ChangeCipherSpec including 2 byte
MSN
- Incorrect DTLS version number
- mtu argument causing crashes

As late as sept 2006 nagendra modadugu
had still not managed to get patches commited to openssl.
I gave up trying to interoperate with
openssl's implementation.

I agree with both your interpretations,
which is identical to the interpretations we made in our DTLS implementation.

1. If HelloVerifyRequest is sent/received
then it and the first ClientHello are not included in the message hashes.

In our implementation we just reset
the hashes if HelloVerifyRequest is sent/received.

2.We include the complete handshake
message in the finished message hashes and certificate verify message hashes,

This includes the message_seq, fragment_offset,
and fragment_length fields that were added for DTLS.
If a handshake message was fragmented
across multiple datagrams it is assembled into a single message as if the
message had been sent in a single fragment, then added to message hashes.
 rfc4347 discusses this in section 4.2.6 for finished message calculation.
We assumed the same thing applies for
certificate verify message hashes.

-----------------------------------------------
Robert Dugal
Member of Development Group
Certicom Corp.
EMAIL: rdugal at certicom.com
PHONE: (905) 501-3848
FAX  : (905) 507-4230
WEBSITE: www.certicom.com

"Joseph Salowey \(jsalowey\)" <jsalowey at cisco.com>
wrote on 09/21/2007 07:02:09 PM:

> We have noticed some inconsistencies between RFC 4347 and DTLS
> implementations (in particular implementations based on OpenSSL).
 There
> may be some areas where the specification is not clear so we wanted
to
> make sure we understood the intention of the spec in these areas.
> 
> 1. We notice that some implementations include the initial ClientHello
> and the HelloVerifyRequest in the Finished message hash and
> CertificateVerify message hash. Section 4.2.1 of RFC 4347 indicates
that
> the initial ClientHello and the HelloVerifyRequest should be excluded
> from the Finished message hash, however it does not mention excluding
> these messages from the CertificateVerify message hash.  We believe
that
> these messages should be excluded from both hashes in order to achieve
> the intended DOS protection.  
> 
> 2. We notice that the handshake "headers" are omitted in
the hash
> computation for the CertificateVerify and the Finished message in
some
> implementations.  Although the spec does not explicitly specify
how the
> hashes are constructed we believe it should be consistent with RFC
4346
> and use the complete handshake message.  
> 
> Do these interpretations make sense? 
> 
> We have found other implementation issues that do not appear to derive
> from specification interpretation.  They detailed here
> http://groups.google.com/group/mailing.openssl.dev/browse_thread/thread/
> 84c7c55752393dd/fcbb1734be44c72b?lnk=gst&q=dtls&rnum=1#fcbb1734be44c72b.
> 
> 
> Thanks,
> 
> Joe
> 
> _______________________________________________
> TLS mailing list
> TLS at lists.ietf.org
> https://www1.ietf.org/mailman/listinfo/tls
_______________________________________________
TLS mailing list
TLS at lists.ietf.org
https://www1.ietf.org/mailman/listinfo/tls