Re: [Atlas] Application Transport LAyer Security (ATLAS) Charter Text

[Carsten Bormann <[e-mail]>]

Hannes,

I have read the charter and I must admit that I have no idea what this WG would actually do.

TLS has been used in applications for a long time.  Let me take EAP-TTLS (and EAP-TLS) as an example for that to make my point more concrete.

With EAP-TTLS, one problem to be solved was the embedding of TLS in the specific application protocol (here, the application is network access control, but it is still an application).  Each such embedding will be specific to the application protocol; I have no idea what a generic embedding would look like.  This can be done only per embedding.  In any case, the charter does not discuss this, or which embeddings would be done.

The other aspect is that the application will need specific semantics from the security protocol.  For EAP-TTLS, the semantics was about secure (protected) access to a server.  The existing PKI worked reasonably well for this.  Ditto for EAP-TLS, with the addition of client certificates (which never were picked up very much in practice, something we maybe can learn from).

Other applications won't be about protected access to servers.  PKI won't do it.  I don't understand the optimism that believes that, since TLS is a fine security protocol, it will adapt to new security objectives without a hitch.  Actually, in practice, this is where security protocols fail quite often, and we will get a lot of insecure "application security" protocols on top of a "secure" TLS kernel.  The charter does not mention applications, and it does not say how an application would obtain the TLS extensions or other mechanisms to address its security objectives.  This can be done only per application.  The charter does not discuss this, or which applications would be done.  In any case, that work should include domain experts for the specific applications, so a TLS-minded WG may not be the best place to do it.

So, in summary, while TLS is a fine hammer, we won't be able to declare success by simply assuming the rest of the world to be nails.
Google's ALTS is a nice example of what you can achieve when you have a good set of building blocks to build specific signed claims that are actually reflecting the application security semantics.  Of course, the specific ALTS protocol is tailored to Google’s application environment; what we need to do first in the IETF is focus on how to offer these building blocks.  The reuse of TLS may or may not in the end help here, but pretty much is a diversion from solving the real problems.

Grüße, Carsten