[TLS] DTLS implementation questions

"Joseph Salowey \(jsalowey\)" <jsalowey@cisco.com> Fri, 21 September 2007 23:02 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 1IYrVe-0007ub-4x; Fri, 21 Sep 2007 19:02:06 -0400
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYrVd-0007rk-CU for tls@ietf.org; Fri, 21 Sep 2007 19:02:05 -0400
Received: from sj-iport-6.cisco.com ([171.71.176.117]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IYrVc-0006UQ-Ps for tls@ietf.org; Fri, 21 Sep 2007 19:02:05 -0400
X-IronPort-AV: E=Sophos;i="4.20,285,1186383600"; d="scan'208";a="222894377"
Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 21 Sep 2007 16:02:04 -0700
Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l8LN24Ix015557 for <tls@ietf.org>; Fri, 21 Sep 2007 16:02:04 -0700
Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l8LN23ip019361 for <tls@ietf.org>; Fri, 21 Sep 2007 23:02:04 GMT
Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 21 Sep 2007 16:02:03 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Date: Fri, 21 Sep 2007 16:02:09 -0700
Message-ID: <AC1CFD94F59A264488DC2BEC3E890DE5048D3D49@xmb-sjc-225.amer.cisco.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: DTLS implementation questions
Thread-Index: Acf8o2/p8JOClxb0QfqQS/tgWiHDwg==
From: "Joseph Salowey (jsalowey)" <jsalowey@cisco.com>
To: tls@ietf.org
X-OriginalArrivalTime: 21 Sep 2007 23:02:03.0648 (UTC) FILETIME=[6CACC800:01C7FCA3]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1490; t=1190415724; x=1191279724; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jsalowey@cisco.com; z=From:=20=22Joseph=20Salowey=20\(jsalowey\)=22=20<jsalowey@cisco.com> |Subject:=20DTLS=20implementation=20questions |Sender:=20; bh=O09CrpFwo7faUIjwKvRqF5WxnTZ+0x6pROns4jRrsAc=; b=gO9yV8a4uLlkMvgqbHrN2PuUmgQPSf9qW1Vmx1g4ZyNNO3gUEE3BWeNH9zzTtdDHVVUAG7C9 NDctZlgaWT/3niDVsogBYF4678DvUEzrDqJNeXQXrTpbOs4AIY2ZWuX2;
Authentication-Results: sj-dkim-3; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; );
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464
Cc: "Abhijit Choudhury (achoudhu)" <achoudhu@cisco.com>
Subject: [TLS] DTLS implementation questions
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>
Errors-To: tls-bounces@lists.ietf.org

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