RE: [TLS] OTP-TLS I-D [Was: FW: I-D ACTION:draft-linn-otp-tls-00.txt]
<Pasi.Eronen@nokia.com> Wed, 28 June 2006 07:45 UTC
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvUjv-0003wQ-Ki; Wed, 28 Jun 2006 03:45:35 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvUju-0003qY-Di for tls@ietf.org; Wed, 28 Jun 2006 03:45:34 -0400
Received: from mgw-ext11.nokia.com ([131.228.20.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvUjt-0007HD-Ts for tls@ietf.org; Wed, 28 Jun 2006 03:45:34 -0400
Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext11.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k5S7jQxo019717; Wed, 28 Jun 2006 10:45:32 +0300
Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 28 Jun 2006 10:45:28 +0300
Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 28 Jun 2006 10:45:28 +0300
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [TLS] OTP-TLS I-D [Was: FW: I-D ACTION:draft-linn-otp-tls-00.txt]
Date: Wed, 28 Jun 2006 10:45:27 +0300
Message-ID: <B356D8F434D20B40A8CEDAEC305A1F2402D64003@esebe105.NOE.Nokia.com>
In-Reply-To: <CBF06F06E674C948AD89E671645B785F0103E807@rsana-ex-hq2.NA.RSA.NET>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [TLS] OTP-TLS I-D [Was: FW: I-D ACTION:draft-linn-otp-tls-00.txt]
Thread-Index: AcaKbfivbRGYQd5jT9u31k4wgZdHeQEoADYAAolPiLAAKn0foAAD6aDwAAEihOAAJRAsQA==
From: Pasi.Eronen@nokia.com
To: jlinn@rsasecurity.com, tls@ietf.org
X-OriginalArrivalTime: 28 Jun 2006 07:45:28.0457 (UTC) FILETIME=[D3191790:01C69A86]
X-Spam-Score: 0.2 (/)
X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976
Cc: mnystrom@rsasecurity.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>
Errors-To: tls-bounces@lists.ietf.org
John, I used "key exchange algorithm" in the TLS protocol sense: a key exchange algorithm defines what information is sent in the handshake messages, how they're processed, how the pre-master secret is computed, and how exceptional situations are handled. In other words, a TLS key exchange algorithm covers more than just the cryptographic calculations. Profiling RFC4279 (or building a layer on top of RFC4279) is an appropriate thing to do if it's really _above_ the TLS layer, but if there are changes to the handshake processing (e.g. in some situation RFC4279 would send alert X, while OTP-TLS sends alert Y), then IMHO defining a new key exchange algorithm would be a better idea. Of course, the new key exchange algorithm could copy most of the details from RFC4279, so it's not a question of whether RFC4279 should be re-used or not, but rather exactly how the re-use should be done and the additional behavior negotiated in TLS... Best regards, Pasi > -----Original Message----- > From: ext Linn, John [mailto:jlinn@rsasecurity.com] > Sent: 27 June, 2006 17:39 > To: Eronen Pasi (Nokia-NRC/Helsinki); tls@ietf.org > Cc: Nyström, Magnus > Subject: RE: [TLS] OTP-TLS I-D [Was: FW: I-D > ACTION:draft-linn-otp-tls-00.txt] > > Pasi, > > Thanks for the background and discussion. Leaving error > alerts and extension usage aside for the moment, there's an > interesting distinction here. Considering the phrase "key > exchange" in a crypto-focused sense, the approach proposed in > the draft wasn't intended to modify the underlying key > establishment as defined in RFC-4279. Rather, it describes a > method that starts with OTP data and associated attributes, > using these to construct the inputs to PSK, DHE_PSK, and/or > RSA_PSK ciphersuites. The same messages as in RFC-4279 are > applied, with profiling (part of "key exchange" processing in > a broader sense of the term) that is specific to the method > rather than to the consuming layer. Do you see an > appropriate means to reuse an existing ciphersuite in this > sort of layered fashion, rather than introducing a new and > parallel definition that would be based on the same > underlying crypto processing? The basic primitives in > RFC-4279 are general and flexible, and it seems attractive to > take advantage of them as a basis for related work. > > --jl > > -----Original Message----- > From: Pasi.Eronen@nokia.com [mailto:Pasi.Eronen@nokia.com] > Sent: Tuesday, June 27, 2006 9:29 AM > To: Linn, John; tls@ietf.org > Cc: Nyström, Magnus > Subject: RE: [TLS] OTP-TLS I-D [Was: FW: I-D > ACTION:draft-linn-otp-tls-00.txt] > > > Hi John, > > The "application profile specifications" mentioned in Sections 5.2 > and 5.4 were intended to specify how to *use* the RFC4279 > ciphersuites > to secure some particular application/service/higher-layer-protocol, > without modifying anything in TLS. (In other words, something > like RFC 2818 or 4261, which are for certificate-based ciphersuites) > > If you significantly modify how the TLS key exchange works (as > is done in this case), the architecturally right way to do so is to > define a new "TLS key exchange algorithm". This was discussed way > back also during the PSK work (where another proposal was to tweak > the session resumption mechanism instead of defining a key exchange > algorithm). > > Best regards, > Pasi _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls
- [TLS] OTP-TLS I-D [Was: FW: I-D ACTION:draft-linn… Linn, John
- RE: [TLS] OTP-TLS I-D [Was: FW: I-D ACTION:draft-… Pasi.Eronen
- RE: [TLS] OTP-TLS I-D [Was: FW: I-D ACTION:draft-… Linn, John
- RE: [TLS] OTP-TLS I-D [Was: FW: I-D ACTION:draft-… Linn, John
- RE: [TLS] OTP-TLS I-D [Was: FW: I-D ACTION:draft-… Pasi.Eronen
- RE: [TLS] OTP-TLS I-D [Was: FW: I-D ACTION:draft-… Pasi.Eronen