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

[Abhijan Bhattacharyya <[e-mail]>]

 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.

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. 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 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.

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. 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. 

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".


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]
 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