HI David,
Many thanks for your excellent questions !
On a) Security:
One design goal of TCF is componentization : Create small building blocks that can be assembled in flexible ways to create target access, monitoring, debugging and tracing.
Securing the communication channel is not a core competency of TCF – SSH works great for that part.
The communication channel is a replaceable entity, users can make it as secure as they want with external building blocks like SSH.
On b) SSL/TLS and X.509 Certificates:
The TCF support for SSL is minimal, and from what I know nobody actively uses it. One big limitation of SSL is the use of a single key (==Certificate). If that
key gets ever known to an intruder, all devices would be at risk. Therefore, our official stance and recommendation is using an SSH tunnel if you need secure communication via TCP/IP.
Also note that while TCP/IP is the default exemplary implementation for TCF, the channel abstraction supports implementing it over Serial, USB, Shared Memory
(on Multicore Chips) etc. where security is not so much of an issue since the channel is physically separated from the outside world.
Let me know if you have any more questions, I can try weaving these answers into the Release Review material for further clarification (or would that be discouraged
now that the PMC has officially signed off ?).
Thanks,
Martin
--
Martin Oberhuber, SMTS / Product Owner – Development Tools,
Wind River
direct +43.662.457915.85 fax +43.662.457915.6
From: tools-pmc-bounces@xxxxxxxxxxx [mailto:tools-pmc-bounces@xxxxxxxxxxx]
On Behalf Of David M Williams
Sent: Thursday, June 04, 2015 8:05 PM
To: Tools PMC mailing list
Subject: Re: [tools-pmc] PMC Approval Request for TCF 1.3
+1
I approve of this for release, (without qualification) but have some questions, which are actually "over my head", so might not be asking quite right, or perhaps obvious to others.
a. You say "TCF connections use a plaintext protocol based on JSON by default"
Isn't the trend to use "secure connections" by default, and force the user to be less secure, if that's what they want?
(Not sure how that would be done, for TCF ... just asking.)
b. In standards section, you say "The SSL support uses X.509 certificates."
Could that be stated as "TLS/SSL support? (That is, is that implied?)
I'm just asking, in light of "POODLE" and "Heartbleed" it seemed the advice was "to disable SSL support, and use TLS instead".
I'm guessing you've accounted for all that ... but, am just curious (mostly due to timing of some other notes I recently got about an
old, old server I marginally support. :)
Thanks,
From: "Oberhuber, Martin" <Martin.Oberhuber@xxxxxxxxxxxxx>
To: Tools PMC mailing list <tools-pmc@xxxxxxxxxxx>,
Date: 06/04/2015 12:40 AM
Subject: [tools-pmc] PMC Approval Request for TCF 1.3
Sent by: tools-pmc-bounces@xxxxxxxxxxx
Dear Tools PMC,
I'd like to ask for PMC approval for TCF 1.3 which is planned to be part of Mars.
Release Review Document:
https://projects.eclipse.org/projects/tools.cdt.tcf/releases/1.3.0/review
The IP Log has already been approved and is attached on the review.
Thanks,
Martin
--
Martin Oberhuber, SMTS / Product Owner – Development Tools,
Wind River
direct +43.662.457915.85 fax +43.662.457915.6
_______________________________________________
tools-pmc mailing list
tools-pmc@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/tools-pmc
