[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
- [TLS] DTLS implementation questions Joseph Salowey (jsalowey)
- Re: [TLS] DTLS implementation questions Rob Dugal