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

From: Abhijan Bhattacharyya <[email-masked]>
Date: Wed, 31 Jan 2018 17:33:32 +0530

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:- +919830468972
 Mailto: [email-masked]
 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

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 31 Jan 2018 17:01:03 +0000

Hi Abhijan,

Thanks for your feedback!

Remarks below:

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

Hi Hannes,

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.

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
Mailto: [email-masked]<mailto:[email-masked]>

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.

---

From: Abhijan Bhattacharyya <[email-masked]>
Date: Thu, 1 Feb 2018 11:41:17 +0530

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

-----"Atlas" <[email-masked]> wrote: -----

>To: Abhijan Bhattacharyya <[email-masked]>,
>"[email-masked]" <[email-masked]>
>From: Hannes Tschofenig 
>Sent by: "Atlas" 
>Date: 01/31/2018 10:33PM
> 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
>  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
>[email-masked]
>https://www.ietf.org/mailman/listinfo/atlas
>