[TLS] draft-tuexen-dtls-for-sctp-00.txt

Michael Tuexen <Michael.Tuexen@lurchi.franken.de> Mon, 28 August 2006 10:26 UTC

Received: from [] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHeKC-0004nm-Se; Mon, 28 Aug 2006 06:26:36 -0400
Received: from [] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHeKB-0004nh-Pu for tls@ietf.org; Mon, 28 Aug 2006 06:26:35 -0400
Received: from mail-n.franken.de ([] helo=ilsa.franken.de) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GHeK9-0003aR-Fn for tls@ietf.org; Mon, 28 Aug 2006 06:26:35 -0400
Received: from [] (p5481FEBB.dip.t-dialin.net []) by ilsa.franken.de (Postfix) with ESMTP id 19B93245C4; Mon, 28 Aug 2006 12:26:25 +0200 (CEST) (KNF account authenticated via SMTP-AUTH)
Mime-Version: 1.0 (Apple Message framework v752.2)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <C06CE11B-6CFD-46C7-A3DE-3D56EA7CF077@lurchi.franken.de>
Content-Transfer-Encoding: 7bit
From: Michael Tuexen <Michael.Tuexen@lurchi.franken.de>
Date: Mon, 28 Aug 2006 12:26:22 +0200
To: tls@ietf.org
X-Mailer: Apple Mail (2.752.2)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081
Cc: lars.eggert@netlab.nec.de, hartmans-ietf@mit.edu
Subject: [TLS] draft-tuexen-dtls-for-sctp-00.txt
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

Dear all,

I would like to get some comments on draft-tuexen-dtls-for- 
sctp-00.txt. This includes

- technical comments
   We would like to use the TLS master secret to generate an  
additional shared secret which
   we would use at the transport layer (SCTP) for SCTP-AUTH. It was  
already brought up,
   that this is a layer violation (but a nice one) and the risk would  
be that multiple
   instances would do this, then these multiple instances would use  
the same key material
   which is definitely bad.
   How should we progress here? From an implementation point of view  
I see only a limited
   risk here, because we will modify the TLS implementation to  
generate the additional
   material and would provide to to SCTP via a socket option. So  
there is NOT API to the
   TLS user involved.
   Another point was to have something like a registry for the  
material generated. This
   would avoid two instances to use the same material. What about  
this? Is this a good or
   bad idea? How can we achieve this, if it is a good idea?

- procedural advises (Sam, Lars this is why you are CCed)
   Currently this document is an individual submission. How can it be  
progressed? Should
   it be taken to a WG? Which one? SCTP (including SCTP-AUTH) is  
handled in TSVWG and
   TLS is handled in the TLS WG. I'm not sure where DTLS was handled,  
if it was handled in
   any WG.

I think having DTLS for SCTP is important because it is needed by  
anyone using SCTP
with PR-SCTP or unordered delivery and wanting to have a TLS like  
security solution.
IPFIX is one example.

Best regards

TLS mailing list