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