RE: [TLS] OTP-TLS I-D [Was: FW: I-D ACTION:draft-linn-otp-tls-00.txt]

<Pasi.Eronen@nokia.com> Tue, 27 June 2006 16:01 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvFzw-0006hi-Kd; Tue, 27 Jun 2006 12:01:08 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvFzv-0006hU-Cd for tls@ietf.org; Tue, 27 Jun 2006 12:01:07 -0400
Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvE0K-0008PB-Ei for tls@ietf.org; Tue, 27 Jun 2006 09:53:24 -0400
Received: from mgw-ext14.nokia.com ([131.228.20.173]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FvDdH-00069S-Pi for tls@ietf.org; Tue, 27 Jun 2006 09:29:36 -0400
Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext14.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k5RDTWIm006552; Tue, 27 Jun 2006 16:29:34 +0300
Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 Jun 2006 16:28:42 +0300
Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 Jun 2006 16:28:41 +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: Tue, 27 Jun 2006 16:28:46 +0300
Message-ID: <B356D8F434D20B40A8CEDAEC305A1F2402D63D40@esebe105.NOE.Nokia.com>
In-Reply-To: <CBF06F06E674C948AD89E671645B785F0103E7E1@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: AcaKbfivbRGYQd5jT9u31k4wgZdHeQEoADYAAolPiLAAKn0foAAD6aDw
From: <Pasi.Eronen@nokia.com>
To: <jlinn@rsasecurity.com>, <tls@ietf.org>
X-OriginalArrivalTime: 27 Jun 2006 13:28:41.0773 (UTC) FILETIME=[9B41FDD0:01C699ED]
X-Spam-Score: -2.6 (--)
X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6
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

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 

> -----Original Message-----
> From: ext Linn, John [mailto:jlinn@rsasecurity.com] 
> Sent: 27 June, 2006 16:14
> 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 review and comments, which we'll consider as 
> input to a subsequent draft revision; in particular, we can 
> include more quantitative discussion on OTP hardening. 
> 
> Rather than defining new ciphersuites that would parallel 
> those defined in RFC-4279, we'd thought that it was feasible 
> and appropriate to define how inputs to RFC-4279 could be 
> constructed to support OTP scenarios, thereby achieving a 
> modular approach that could layer on TLS-PSK rather than 
> duplicating it. As RFC-4279, Sec. 5, begins, "It is expected 
> that different types of identities are useful for different 
> applications running over TLS.  This document does not 
> therefore mandate the use of any particular type of 
> identity...".  Against this backdrop, and noting that 
> RFC-4279 (e.g., Secs. 5.2 and 5.4) explicitly contemplates 
> use in conjunction with application profiles, we set out to 
> profile the use of the identity field so as to represent 
> OTP-related attributes along with the identity itself.  As 
> noted, the draft also proposes error alerts (to be used only 
> when use of OTP-TLS is indicated) and (optional) use of TLS 
> extensions, so extends more than just TLS-PSK; this can be 
> clarified.  With regard to the proposed structure for OTP-TLS 
> PSK_Identity, however, we'd considered this as an example of 
> a TLS-PSK application profile which RFC-4279 did not appear 
> to preclude.  
> 
> --jl
> 
> -----Original Message-----
> From: Pasi.Eronen@nokia.com [mailto:Pasi.Eronen@nokia.com] 
> Sent: Monday, June 26, 2006 11:23 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]
> 
> Since the document quite significantly changes how the PSK
> ciphersuites work (identity field is re-used to carry a number of
> other attributes; new alert messages are added; key-exchange related
> information is carried in new TLS extensions; etc.), I think it would
> be better to treat OTP as a new TLS key exchange algorithm (and define
> new ciphersuites like TLS_OTP_WITH_AES_128_CBC_SA). As it's currently
> written, this document certainly is not a "profile" of RFC 4279
> in any usual sense of the word...
> 
> Couple of additional comments:
> 
> - See RFC 3979 section 11: "No IPR Disclosures in IETF Documents"
> 
> - Text about "hardening" should give concrete advice on how secure
> OTP-TLS actuallly is, given some realistic parameter values (just
> talking about "economically unattractive" is very vague).
> 
> Best regards,
> Pasi 

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