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