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

[Hannes Tschofenig <[e-mail]>]

Hi Abhijan,

Thanks for your feedback!

Remarks below:

From: Abhijan Bhattacharyya [mailto:[e-mail]]
Sent: 31 January 2018 13:04
To: [e-mail]
Cc: Hannes Tschofenig
Subject: Re: [Atlas] Application Transport LAyer Security (ATLAS) Charter Text

Hi Hannes,

I went through the draft charter text. Some points that I would like to jot down (please pardon me in case I am raising something that has already been discussed. I was not there in Singapore, so unaware of the discussions on ground):

1) I would second this initiative. It is necessary for moving towards a more 'flat' stack structure to gain more application level control for IoT and low-latency use cases.
Do you think the current charter text (and/or the strawman solutions) capture your goal to a sufficient extend already?

2) When we say Application Layer TLS, we essentially infer "Application Layer" as a generic term. The OSI Session Layer concepts have to be incorporated into the Application Layer.

The term "Application Layer TLS" may be misleading since "ordinary" TLS already protects the application layer. I am open to suggestions for better terms.

So, are we talking about a generic set of requirements that every individual Application Layer need to follow in order to enable the underlying Record Layer in the Transport to function properly?

The standardization effort is very minimal here. I believe the biggest issue is to understand the difference in use. There are two things that could be standardized here:

1)      A place where we put the TLS/DTLS payloads (for the different protocols over which we "tunnel" the TLS / DTLS messages).

2)      A way to use the key extractor to derive keying material for use with another payloads, such as the JOSE or COSE.

The reason I am highlighting this point is because, the implementation of how the Session Layer feature is implemented will differ amongst different candidate Application Protocols because the semantics are not same. For example CoAP semantics and HTTP semantics are different. So, there will be architectural differences in different version of App Layer TLS. So, probably we need to put some text that clears the objective.
That's true. HTTP, CoAP and other protocols would require a different description and a different "place" where we put those TLS/DTLS payloads.


3) While we say that the group will re-use the existing TLS handshake protocol probably we need to be a little bit more elaborate in the line of point (2) above. I think, probably we would like to keep the existing implementation of TLS record-structure intact.

Yes, we would like to re-use existing implementations. Our early implementation efforts indicate that this is possible. Mark and I worked on mbed TLS; Owen, Richard, and Max worked on OpenSSL.

So, that defines the requirements / exact deliverables out of the session establishment exercise. Now, if we take the example of the draft that we submitted earlier (draft-bhattacharyya-dice-less-on-coap-00 ), we actually followed the similar philosophy. (i) We learned first what are the required inputs to run the record layer functions and what are the security and performance constraints. (ii) Then we tried to see how we achieve that in a resource efficient manner. (iii)This led to a generic handshake design without caring about the exact application protocol on which it is to be implemented. (iv) Then the concept is implemented using the confirmable semantics of CoAP.

Your work is obviously very helpful and the BOF and IMHO this mailing list are the appropriate place are the right place to share this experience. As such, I would recommend that you refresh your document and, if you have additional information, add it in version -01.


So, probably we can put some more clarity on the expected outcome which will bring out the expectations out of the "modern key exchange protocol" and why/how it should be designed with "re-use of the existing TLS handshake".

Let me think about how we could capture this in the charter text. I am trying to keep the balance between providing sufficient information to understand the high level goal of the group vs. precluding discussions.


Ciao
Hannes


Thank  you.

With Best Regards
Abhijan Bhattacharyya
Associate Consultant
Scientist, TCS Research
Tata Consultancy Services
Building 1B,Ecospace
Plot -  IIF/12 ,New Town, Rajarhat,
Kolkata - 700160,West Bengal
India
Ph:- 033 66884691
Cell:- [phone]
Mailto: [e-mail]<mailto:[e-mail]>
Website: http://www.tcs.com
____________________________________________
Experience certainty. IT Services
Business Solutions
Consulting
____________________________________________

=====-----=====-----=====
Notice: The information contained in this e-mail
message and/or attachments to it may contain
confidential or privileged information. If you are
not the intended recipient, any dissemination, use,
review, distribution, printing or copying of the
information contained in this e-mail message
and/or attachments to it are strictly prohibited. If
you have received this communication in error,
please notify us by reply e-mail or telephone and
immediately and permanently delete the message
and any attachments. Thank you

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.