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

[Abhijan Bhattacharyya <[e-mail]>]

Hi Hannes,
Thanks for your response.
I do agree to your views in general. It is also good to know that you find our work as a useful precursor. Now, coming to the following specific point from your response:

> Do you think the current charter text (and/or the strawman
>solutions) capture your goal to a sufficient extend already?
> 

Charter: You have already mentioned about modifying the charter in your response.
Strawman solutions: I think the available strawman proposals do show that there is quite a bit of interest behind the basic design idea (of segregation of security responsibilities between application and transport layers). We need more reconciliation amongst efforts as they all have emerged in silos. This should be the objective of this list. The idea is reflected. We may also gain knowledge about possible implementation specific constrains and concerns from these works as well.

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
 ____________________________________________
 

-----"Atlas" <[e-mail]> wrote: -----

>To: Abhijan Bhattacharyya <[e-mail]>,
>"[e-mail]" <[e-mail]>
>From: Hannes Tschofenig 
>Sent by: "Atlas" 
>Date: 01/31/2018 10:33PM
>Subject: Re: [Atlas] Application Transport LAyer Security (ATLAS)
>Charter Text
>
>       
> 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 &#8220;Application Layer TLS&#8221; may be misleading since &#8220;ordinary&#8221;
>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 &#8220;tunnel&#8221; 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&#8217;s true. HTTP, CoAP and other protocols would require a
>different description and a different &#8220;place&#8221; 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]
> 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.
>_______________________________________________
>Atlas mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/atlas
>