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