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 

> -----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