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 10:39:02 -0400
Message-ID: <CBF06F06E674C948AD89E671645B785F0103E807@rsana-ex-hq2.NA.RSA.NET>
In-Reply-To: <B356D8F434D20B40A8CEDAEC305A1F2402D63D40@esebe105.NOE.Nokia.com>
Thread-Topic: [TLS] OTP-TLS I-D [Was: FW: I-D ACTION:draft-linn-otp-tls-00.txt]
Thread-Index: AcaKbfivbRGYQd5jT9u31k4wgZdHeQEoADYAAolPiLAAKn0foAAD6aDwAAEihOA=
From: "Linn, John" <jlinn@rsasecurity.com>
To: <Pasi.Eronen@nokia.com>, <tls@ietf.org>
Cc: =?iso-8859-1?Q?Nystr=F6m=2C_Magnus?= <mnystrom@rsasecurity.com>
Precedence: list
Errors-To: tls-bounces@lists.ietf.org

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. =20

--jl

-----Original Message-----
From: Pasi.Eronen@nokia.com [mailto:Pasi.Eronen@nokia.com]=20
Sent: Tuesday, June 27, 2006 9:29 AM
To: Linn, John; tls@ietf.org
Cc: Nystr=F6m, 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=20
and 5.4 were intended to specify how to *use* the RFC4279 ciphersuites=20
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=20
define a new "TLS key exchange algorithm". This was discussed way
back also during the PSK work (where another proposal was to tweak=20
the session resumption mechanism instead of defining a key exchange
algorithm).

Best regards,
Pasi=20

> -----Original Message-----
> From: ext Linn, John [mailto:jlinn@rsasecurity.com]=20
> Sent: 27 June, 2006 16:14
> To: Eronen Pasi (Nokia-NRC/Helsinki); tls@ietf.org
> Cc: Nystr=F6m, Magnus
> Subject: RE: [TLS] OTP-TLS I-D [Was: FW: I-D=20
> ACTION:draft-linn-otp-tls-00.txt]
>=20
> Pasi,
>=20
> Thanks for the review and comments, which we'll consider as=20
> input to a subsequent draft revision; in particular, we can=20
> include more quantitative discussion on OTP hardening.=20
>=20
> Rather than defining new ciphersuites that would parallel=20
> those defined in RFC-4279, we'd thought that it was feasible=20
> and appropriate to define how inputs to RFC-4279 could be=20
> constructed to support OTP scenarios, thereby achieving a=20
> modular approach that could layer on TLS-PSK rather than=20
> duplicating it. As RFC-4279, Sec. 5, begins, "It is expected=20
> that different types of identities are useful for different=20
> applications running over TLS.  This document does not=20
> therefore mandate the use of any particular type of=20
> identity...".  Against this backdrop, and noting that=20
> RFC-4279 (e.g., Secs. 5.2 and 5.4) explicitly contemplates=20
> use in conjunction with application profiles, we set out to=20
> profile the use of the identity field so as to represent=20
> OTP-related attributes along with the identity itself.  As=20
> noted, the draft also proposes error alerts (to be used only=20
> when use of OTP-TLS is indicated) and (optional) use of TLS=20
> extensions, so extends more than just TLS-PSK; this can be=20
> clarified.  With regard to the proposed structure for OTP-TLS=20
> PSK_Identity, however, we'd considered this as an example of=20
> a TLS-PSK application profile which RFC-4279 did not appear=20
> to preclude. =20
>=20
> --jl
>=20
> -----Original Message-----
> From: Pasi.Eronen@nokia.com [mailto:Pasi.Eronen@nokia.com]=20
> Sent: Monday, June 26, 2006 11:23 AM
> To: Linn, John; tls@ietf.org
> Cc: Nystr=F6m, Magnus
> Subject: RE: [TLS] OTP-TLS I-D [Was: FW: I-D=20
> ACTION:draft-linn-otp-tls-00.txt]
>=20
> 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...
>=20
> Couple of additional comments:
>=20
> - See RFC 3979 section 11: "No IPR Disclosures in IETF Documents"
>=20
> - 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).
>=20
> Best regards,
> Pasi=20

_______________________________________________
TLS mailing list
TLS@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/tls