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

Lakshminath Dondeti <ldondeti@qualcomm.com> Tue, 29 August 2006 03:23 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHuBq-0002Mk-Qj; Mon, 28 Aug 2006 23:23:02 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHuBo-0002Mf-Tp for tls@ietf.org; Mon, 28 Aug 2006 23:23:00 -0400
Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GHuBm-0007kY-IH for tls@ietf.org; Mon, 28 Aug 2006 23:23:00 -0400
Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k7T3Muai006919 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 28 Aug 2006 20:22:57 -0700
Received: from LDONDETI.qualcomm.com (qconnect-10-50-76-103.qualcomm.com [10.50.76.103]) by sabrina.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k7T3MsWU021220 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 28 Aug 2006 20:22:55 -0700 (PDT)
Message-Id: <7.0.1.0.2.20060828200239.06996c80@qualcomm.com>
X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0
Date: Mon, 28 Aug 2006 20:22:54 -0700
To: EKR <ekr@networkresonance.com>
From: Lakshminath Dondeti <ldondeti@qualcomm.com>
Subject: Re: [TLS] draft-tuexen-dtls-for-sctp-00.txt
In-Reply-To: <86psekcwkh.fsf@raman.networkresonance.com>
References: <AC1CFD94F59A264488DC2BEC3E890DE502580384@xmb-sjc-225.amer.cisco.com> <7.0.1.0.2.20060828153142.06aa3fd0@qualcomm.com> <86psekcwkh.fsf@raman.networkresonance.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 97adf591118a232206bdb5a27b217034
Cc: lars.eggert@netlab.nec.de, tls@ietf.org, hartmans-ietf@mit.edu
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

At 03:41 PM 8/28/2006, Eric Rescorla wrote:
>Lakshminath Dondeti <ldondeti@qualcomm.com> writes:
> > After a quick look at the documents in consideration, I am thinking
> > something like an IKEv2 PRF+ might also work.
> >
> > Each time an instance draws on the key material there would be a new
> > key.  Would that work?
>
>Well, the issue isn't really which PRF to use.
>
>Given that TLS has one and that it's got the ability generate disjoint
>keys from the same underlying entropy, that's kind of the obvious one
>to use.
>
>that's kind of a no-brainer. The issue is the layer violation
>and making sure that each side gets the same (unique) key
>even if multiple other protocols are trying to get keys out
>of TLS this way...

Hi Eric,

Thanks for the explanation.  Looks like I have some more reading to 
do to understand this fully :).
Let me ask you a follow-up question: would a PRF with protocol labels 
and protocol specific data as input would work better instead?  It is 
plausible then to maintain an IANA registry of such labels so there 
is a unique key per protocol.  That was the idea Joe was proposing earlier.

regards,
Lakshminath


>-Ekr


_______________________________________________
TLS mailing list
TLS@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/tls