Re: draft-tschofenig-lwig-tls-minimal = TLS profile proposal

[Cc'd Megaco = H.248]

Hi Hannes,

with regards to:
> " such a simple protocol like Megaco "

Hm, looks like that you missed a main point: there are two aspects
a) Transport security for Diameter/Megaco/... protocol itself
	= RFC 3588 (clause 13.2. TLS Usage) for Diameter
	= H.248.67 for H.248

b) Transport security for Diamter/Megaco/... control IP transport connections ("called IP bearer connections in context of H.248")
	= ??? for Diameter
	= H.248.TLS (& H.248.TCP) for H.248

Any "TLS profile" concept would be valuable for both (a) and (b), but being aware that present "TLS protocol profiling" for (a) is fairly minimal (perhaps still too high level).
However, more challenging is "TLS protocol profiling" for (b), - for specific applications (not web/http, but IMS/SIP controlled).

Regards,
Albrecht

PS - MMUSIC related:
E.g., the negotiation of TLS client/server roles is presently not yet supported by SDP offer/answer. RFC 4145 does only define the semantics for TCP client/server roles, and RFC 4572 just provides the "fingerprint" capability.

PSS "simple protocol like Megaco":
Not sure whether you are up to date :-)
=> http://www.itu.int/rec/T-REC-H/e 
See list of H.248.x-series of Recommendations ...


-----Original Message-----
From: Hannes Tschofenig [mailto:[email protected]] 
Sent: Samstag, 23. Februar 2013 19:13
To: Schwarz, Albrecht (Albrecht)
Cc: [email protected]; [email protected]
Subject: Re: [TLS] draft-tschofenig-lwig-tls-minimal = TLS profile proposal

Hi Albrecht,

sorry that I missed your review comments.

The term "TLS profile" could be a bit misleading. In your context (based on the documents listed below) profile means (if I understood it
correctly) a description of how to use TLS to secure a selected protocol (Megaco in your case). Since TLS is a fairly widely used protocol there are many such descriptions available for TLS. For example, the Diameter base specification says how to use TLS to secure Diameter peer-to-peer exchanges.

When someone tries to use TLS (or DTLS) to secure protocols on a smart object or constraint node network then the initial reaction is that TLS is too heavy to do that. Based on several implementations we do, however, know that that's not true. The answer is of course more complex since TLS has many features and even more extensions and the security requirements (as well as non-security related requirements) may dictate which of these extensions are reasonable to use.

That's what draft-tschofenig-lwig-tls-minimal tries to explain. Of course, there is still work to provide better guidance (as you noticed).
Ideally, I would like to provide a rough estimate of main memory, code size, bandwidth requirements, and energy consumption for commonly used features for these types of devices.

In draft-tschofenig-lwig-tls-minimal we do not want to introduce new functionality that is in conflict with TLS/DTLS specifications.

Regarding the mentioned TLS documents in your mail below I think you went a bit too far in terms of describing TLS usage for such a simple protocol like Megaco. I had intentionally mentioned Diameter since it provides similar functionality and IMHO TLS with client and server certificates + a reference to RFC 6125 would have been enough already.

Ciao
Hannes


On 11/08/2012 11:47 AM, Schwarz, Albrecht (Albrecht) wrote:
> Dear All,
> like to raise a general comment to the group, driven by the "TLS 
> minimal" draft:
> Do agree to the message of this doc, guess that the subject as such is 
> out of question in the TLS community.
> Actually I've expected more concrete specification guidelines from the 
> conclusion section.
> Notions such as "TLS can be customized ...", "... required TLS 
> functionality" or "It can be tailored to fit the needs of a specific 
> deployment environment." point out that TLS related parameters and 
> procedures could and should be specified in detail for a particular 
> communication (and security) environment.
> The answer could be the explicit introduction of a profile concept, - 
> which is very well known already for some protocols.
> Profiles could be more high level (like the "RTP profiles" (e.g. RFC
> 3551 as a "minimum" ...) or fairly detailed (such as the 3GPP "SIP Gm 
> profile" or H.248 profiles).
> And there are already concepts for "TLS profiles" around, see e.g.
> - "3GPP TLS Protocol Profile" (Annex E/33.310)
> - "OMA TLS Profile" (OMA-TS-TLS-V1_...) or
> - "Operating system xyz TLS Profile" ('xyz' as a placeholder for some 
> well known OSs) However, all these TLS profile concepts are not really 
> identical, sharing some common capabilities, but also adding some 
> specifics.
> The rational behind is the fact that an explicit TLS profile concept 
> is not (yet?) introduced in the IETF TLS core RFCs in my understanding.
> We faced the same situation in ITU-T SG16 in work items for 
> H.248-controlled TLS services.
> Thus, we made a definition proposal as a working assumption.
> Interested parties may have a look in:
> a) *H.248.TLS "H.248 packages for control of transport security"* 
> _http://wftp3.itu.int/av-arch/avc-site/2009-2012/1209_Bri/TD-23.zip_
> *3.2.6   TLS-profile*: A selection of options from a set of TLS related
> parameters and procedures.
> and a concrete example may be found in:
> *8.7      Example for the TLS profile concept*
> b) *H.248.TLSPROF* "Guidelines on the use of H.248 capabilities for 
> transport security in TLS networks in H.248 Profiles"
> _http://wftp3.itu.int/av-arch/avc-site/2009-2012/1209_Bri/TD-2__4__.zi
> p_ 
> <http://wftp3.itu.int/av-arch/avc-site/2009-2012/1209_Bri/TD-24.zip>
> Would be interested whether the TLS WG experts
> a) thought already about the definition of a profile for TLS (and DTLS)?
> [Which would be a terminology definition and could be additionally a 
> template for protocol profiling]
> b) got any comments on our proposed TLS terms in above ITU-T work items?
> Thanks,
> Albrecht
>
>
> _______________________________________________
> TLS mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/tls
>