Re: [TLS] DTLS implementation questions
Rob Dugal <RDugal@certicom.com> Sat, 22 September 2007 01:45 UTC
Return-path: <tls-bounces@lists.ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYu3h-0002VG-TB; Fri, 21 Sep 2007 21:45:25 -0400
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYu3g-0002V9-F0 for tls@ietf.org; Fri, 21 Sep 2007 21:45:24 -0400
Received: from mail.ca.certicom.com ([38.113.160.197]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IYu3f-0002AA-Dj for tls@ietf.org; Fri, 21 Sep 2007 21:45:24 -0400
Received: from spamfilter.certicom.com (localhost.localdomain [127.0.0.1]) by mail.ca.certicom.com (Postfix) with ESMTP id 5DD7D10027FED; Fri, 21 Sep 2007 17:48:12 -0400 (EDT)
Received: from mail.ca.certicom.com ([127.0.0.1]) by spamfilter.certicom.com (storm.certicom.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P+8aIE4UN0fM; Fri, 21 Sep 2007 17:48:10 -0400 (EDT)
Received: from domino1.certicom.com (domino1.certicom.com [10.0.1.24]) by mail.ca.certicom.com (Postfix) with ESMTP; Fri, 21 Sep 2007 17:48:10 -0400 (EDT)
In-Reply-To: <AC1CFD94F59A264488DC2BEC3E890DE5048D3D49@xmb-sjc-225.amer.cisco.com>
To: "Joseph Salowey (jsalowey)" <jsalowey@cisco.com>
Subject: Re: [TLS] DTLS implementation questions
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 6.5.5 November 30, 2005
Message-ID: <OFF1AF8EDB.0A2EB52D-ON8525735E.0005D54B-8525735E.0009B16E@certicom.com>
From: Rob Dugal <RDugal@certicom.com>
Date: Fri, 21 Sep 2007 21:40:40 -0400
X-MIMETrack: Serialize by Router on Certicom1/Certicom(Release 7.0.2FP2 HF177|August 10, 2007) at 09/21/2007 09:40:42 PM, Serialize complete at 09/21/2007 09:40:42 PM
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 2a76bcd37b1c8a21336eb0a1ea6bbf48
Cc: tls@ietf.org, "Abhijit Choudhury (achoudhu)" <achoudhu@cisco.com>
X-BeenThere: tls@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/tls>
List-Post: <mailto:tls@lists.ietf.org>
List-Help: <mailto:tls-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@lists.ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1551092217=="
Errors-To: tls-bounces@lists.ietf.org
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@certicom.com PHONE: (905) 501-3848 FAX : (905) 507-4230 WEBSITE: www.certicom.com "Joseph Salowey \(jsalowey\)" <jsalowey@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@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/tls
_______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls
- [TLS] DTLS implementation questions Joseph Salowey (jsalowey)
- Re: [TLS] DTLS implementation questions Rob Dugal