Subject: [Atlas] Status Update

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 8 Jun 2018 11:44:07 +0000

Hi all,

Owen and I submitted another BoF proposal to the IESG based on the feedback from the last IETF meeting.

Here is the most recent charter text we came up with:
---
There are multiple scenarios where clients and servers need to negotiate shared encryption keys and establish secure, authenticated, integrity-protected, end-to-end encrypted sessions at the application layer over untrusted transport. There are a proliferation of transport protocols and mechanisms in use today across web and IoT use cases including, but not limited to, TCP, UDP, IP, Bluetooth and Zigbee. Additionally, network topologies often include middleboxes and proxies that terminate transport layer connections from clients and re-originate new transport layer connections towards the servers. From the clients and servers perspective, these transport layer proxy functions are untrusted and application data must be protected and encrypted, and not exposed to these proxies. There are multiple potential mechanisms that could be considered for negotiation of encryption keys, and establishment of end-to-end encrypted sessions at the application layer between clients and servers, and this working group proposes use of existing (D)TLS protocols and stacks.

This working group proposes reuse of (D)TLS at the application layer as a simple and straightforward means of achieving the security and implementation goals. The primary purpose of the working group is to develop specifications defining how (D)TLS can be leveraged at the application layer (i.e. Application Layer TLS or ATLS) to establish end-to-end encrypted sessions over a multitude of different transports.

Additionally, during development of ATLS specifications, the working group will consider and address concerns such as:

o complex, multi-hop and lossy transport topologies
o (D)TLS record fragmentation at the transport layer
o middlebox operators whose goals include interception of application layer data

The working group will engage with other relevant working groups across the Applications and Real-Time Area (art), Security Area (sec) and Transport Area (tsv), and one of the goals of this working group is to explicitly identity all related working groups that must be consulted during ATLS specifications development.
---

There do not seem to be minutes available from the IESG/IAB BoF discussions and how they reached their conclusions. So, we can only report what has been told to us by proxy.

In any case, the IESG rejected the BoF proposal.

The impression from the IESG was that the Bar BOF in London produced mixed feelings and that there was no activity on the list afterwards.
Another comment was that the required standardization effort is too small to justify the setup of an entire working group.

At first, this sounds a bit negative. On the other hand, we have two implementations right now. While they need to be polished I believe this is something we could go forward with.

Ciao
Hannes

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: Martin Thomson <[email-masked]>
Date: Fri, 8 Jun 2018 15:29:12 +0200

It seems to me that there are two things you might explore, almost
separately here:

1. The definition of new transports for the TLS handshake.  The cases
I've heard described cover a wide variety of cases with heterogeneous
hops even within the same example.

This is something we're (still) grappling with in QUIC, but we've
reached a point now where the working group believes that
we have a solid solution.  Talking to the people involved there might
be sensible.  It's ALSO something that the TAPS working group have
been pondering in a more abstract sense, which suggests that they
might have some valuable input.

>From this I've learned that DTLS and TLS are very different beasts.
TLS relies on ordered delivery of its handshake messages, but doesn't
really have any deep relationship with its record layer.  In contrast,
DTLS doesn't have that reliance, but it has a much closer relationship
with its record layer (at least in DTLS 1.3 - I'm assuming here that
new work would not entertain the use of anything less than TLS 1.3).

2. Then there is the extraction and use of the shared secret that TLS
negotiates.  For this, we have examples already in DTLS-SRTP, which
uses an exporter, and the current QUIC (though this will not be true
in future).  In using these secrets, we can be a lot more flexible,
and I suspect that anything the group does here will be much easier to
reason about than the far more complex handshakey piece.

My impression was that there were two aspects to the concerns from the
IESG and IAB.

The I* was looking to see more enthusiasm for the solutions proposed
here than was demonstrated (both on the list thus far and in the
presentation that was given).  In particular, the notion that this
might be used to circumvent blocking of TLS was problematic.  This was
inferred from the example given in the presentation and alluded to in
the charter: devices that can't be configured with trust anchors such
that they could connect through a MitM in the usual fashion, but want
to connect anyway.

They seem to also have wanted a more concrete definition of the
solutions that were being sought.  The charter Hannes describes is a
little open-ended and having some more clarity about that would be
good.

In any case, I think that it would be valuable to ask for some
side-meeting time in Montreal
On Fri, Jun 8, 2018 at 1:44 PM Hannes Tschofenig
<[email-masked]> wrote:
> _______________________________________________
> Atlas mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/atlas

---

From: Russ Housley <[email-masked]>
Date: Fri, 8 Jun 2018 12:11:16 -0400

In the SAAG session in London, we heard that TCP-AO is not being used.  Sadly, people are still using TCP-MD5.  One thing that TCP-AO offers is the ability to roll from one key to the next without tearing down the TCP connection.  To do that, a table of keys is needed.  I think that the TLS key extraction would be a very sound way to populate the key table automatically.  For example, once per week, TLS could be used to populate daily keys.

Russ

> On Jun 8, 2018, at 9:29 AM, Martin Thomson <[email-masked]> wrote:
> 
>> There are multiple scenarios where clients and servers need to negotiate shared encryption keys and establish secure, authenticated, integrity-protected, end-to-end encrypted sessions at the application layer over untrusted transport. There are a proliferation of transport protocols and mechanisms in use today across web and IoT use cases including, but not limited to, TCP, UDP, IP, Bluetooth and Zigbee. Additionally, network topologies often include middleboxes and proxies that terminate transport layer connections from clients and re-originate new transport layer connections towards the servers. From the clients and servers perspective, these transport layer proxy functions are untrusted and application data must be protected and encrypted, and not exposed to these proxies. There are multiple potential mechanisms that could be considered for negotiation of encryption keys, and establishment of end-to-end encrypted sessions at the application layer between clients and servers, and
>  this working group proposes use of existing (D)TLS protocols and stacks.
>> 
>> 
>>

---

From: Abhijan Bhattacharyya <[email-masked]>
Date: Tue, 19 Jun 2018 18:53:26 +0530

Hello Hannes,
Thanks for the update. The revise charter looks good. So what can we expect in Montral? Do we expect another attempt towards a BoF?
I have a view against the particular observation of low activities in the mailing list. I think what ATLAS is trying to do is to collect and coordinate between different relevant stray proposals (which may have already been worked out) under a single consolidated standardization effort. So, the activities are waiting at a threshold of a coordinated future progress. But, more activities in this list is definitely a proposition to establish the point of interest for the IETF community. 

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
____________________________________________

-----"Atlas" <[email-masked]> wrote: -----
To: "[email-masked]" <[email-masked]>
From: Hannes Tschofenig 
Sent by: "Atlas" 
Date: 06/08/2018 05:14PM
Subject: [Atlas] Status Update

Hi all,

 

 

 

Ciao
Hannes
 
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
=====-----=====-----=====
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: Mirja Kühlewind <[email-masked]>
Date: Tue, 19 Jun 2018 19:52:57 +0200

Hi all,

writing as an individual contributor, not an IESG member.

I just briefly looked at draft-friel-tls-atls-00 and when I saw Figure 
6, I have to say that I do wonder a bit what additional standardization 
is needed here. The new parts are the key export and the App Data Crypto 
box. However, the key export is mainly an interface question and to my 
understanding there are by now already libraries that provide the needed 
interface for quic. And the actual app data crypto should be rather 
straight forward and probably does not need that much standardization...?

In the context of taps, however, we've been thinking about how to even 
more generalize this approach (in figure 6). The two points I think 
could be generalized here even more are

1) The TLS handshake should be completely separated from the crypto and 
could be run directly by the TLS stack without "tunneling" it through 
the application. Effectively, in theory the handshake would not even 
need to use the same transport connection or transport protocol than the 
application (also it probably could).

This also something we discuss/propose in this draft as input for taps:
https://tools.ietf.org/html/draft-kuehlewind-taps-crypto-sep-02

2) The TLS handshake could negotiate within one handhshake multiple key 
shares that can be used on different layers for different protocols and 
algorithms. I guess that is more a question/request for the TLS working 
group but goes into the same direction of separating handshake/control 
and the actual crypto more.

Mirja

On 19.06.2018 15:23, Abhijan Bhattacharyya wrote:
> Hello Hannes,
> Thanks for the update. The revise charter looks good. So what can we 
> expect in Montral? Do we expect another attempt towards a BoF?
> I have a view against the particular observation of low activities in 
> the mailing list. I think what ATLAS is trying to do is to collect and 
> coordinate between different relevant stray proposals (which may have 
> already been worked out) under a single consolidated standardization 
> effort. So, the activities are waiting at a threshold of a coordinated 
> future progress. But, more activities in this list is definitely a 
> proposition to establish the point of interest for the IETF community.
> 
> With Best Regards
> Abhijan Bhattacharyya
> Associate Consultant
> Scientist, TCS Research
> <mailto:abhijan.bhattacharyya@tcs..com>
> -----"Atlas" <[email-masked] <mailto:[email-masked]>> 
> wrote: -----
> To: "atlas@ietf..org <mailto:[email-masked]>" <[email-masked] 
> <mailto:[email-masked]>>
> From: Hannes Tschofenig
> Sent by: "Atlas"
> Date: 06/08/2018 05:14PM
> There are multiple scenarios where clients and servers need to negotiate 
> shared encryption keys and establish secure, authenticated, 
> integrity-protected, end-to-end encrypted sessions at the application 
> layer over untrusted transport. There are a proliferation of transport 
> protocols and mechanisms in use today across web and IoT use cases 
> including, but not limited to, TCP, UDP, IP, Bluetooth and Zigbee. 
> Additionally, network topologies often include middleboxes and proxies 
> that terminate transport layer connections from clients and re-originate 
> new transport layer connections towards the servers. From the clients 
> and servers perspective, these transport layer proxy functions are 
> untrusted and application data must be protected and encrypted, and not 
> exposed to these proxies. There are multiple potential mechanisms that 
> could be considered for negotiation of encryption keys, and 
> establishment of end-to-end encrypted sessions at the application layer 
> between clients and servers, and this working group proposes use of 
> existing (D)TLS protocols and stacks.
> 
> This working group proposes reuse of (D)TLS at the application layer as 
> a simple and straightforward means of achieving the security and 
> implementation goals. The primary purpose of the working group is to 
> develop specifications defining how (D)TLS can be leveraged at the 
> application layer (i.e. Application Layer TLS or ATLS) to establish 
> end-to-end encrypted sessions over a multitude of different transports.
> 
> Additionally, during development of ATLS specifications, the working 
> group will consider and address concerns such as:
> 
> The working group will engage with other relevant working groups across 
> the Applications and Real-Time Area (art), Security Area (sec) and 
> Transport Area (tsv), and one of the goals of this working group is to 
> explicitly identity all related working groups that must be consulted 
> during ATLS specifications development.
> 
> ---
> 
> There do not seem to be minutes available from the IESG/IAB BoF 
> discussions and how they reached their conclusions. So, we can only 
> report what has been told to us by proxy.
> 
> The impression from the IESG was that the Bar BOF in London produced 
> mixed feelings and that there was no activity on the list afterwards.
> 
> Another comment was that the required standardization effort is too 
> small to justify the setup of an entire working group.
> 
> At first, this sounds a bit negative. On the other hand, we have two 
> implementations right now. While they need to be polished I believe this 
> is something we could go forward with.
> 
> Ciao
> Hannes
> 
> 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.
> [email-masked] <mailto:[email-masked]>

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 21 Jun 2018 08:43:47 +0000

Hi Mirja,

You are correct that this work does not require a lot of standardization. I actually consider this a feature rather than a bug since after all the idea of this exercise is re-use. The alternative is to essentially re-design the DTLS/TLS protocol, which is being proposed by others.

Thanks for the pointer to your document. I haven't seen it before. Let me read through it and provide you feedback.

Ciao
Hannes

-----Original Message-----
From: Atlas [mailto:[email-masked]] On Behalf Of Mirja Kühlewind
Sent: 19 June 2018 18:53
To: [email-masked]; Tommy Pauly; Chris Wood
Subject: Re: [Atlas] Status Update

Hi all,

I just briefly looked at draft-friel-tls-atls-00 and when I saw Figure 6, I have to say that I do wonder a bit what additional standardization is needed here. The new parts are the key export and the App Data Crypto box. However, the key export is mainly an interface question and to my understanding there are by now already libraries that provide the needed interface for quic. And the actual app data crypto should be rather straight forward and probably does not need that much standardization...?

In the context of taps, however, we've been thinking about how to even more generalize this approach (in figure 6). The two points I think could be generalized here even more are

1) The TLS handshake should be completely separated from the crypto and could be run directly by the TLS stack without "tunneling" it through the application. Effectively, in theory the handshake would not even need to use the same transport connection or transport protocol than the application (also it probably could).

2) The TLS handshake could negotiate within one handhshake multiple key shares that can be used on different layers for different protocols and algorithms. I guess that is more a question/request for the TLS working group but goes into the same direction of separating handshake/control and the actual crypto more.

Mirja

On 19.06.2018 15:23, Abhijan Bhattacharyya wrote:
> There are multiple scenarios where clients and servers need to
> negotiate shared encryption keys and establish secure, authenticated,
> that terminate transport layer connections from clients and
> re-originate new transport layer connections towards the servers. From
> the clients and servers perspective, these transport layer proxy
> functions are untrusted and application data must be protected and
> encrypted, and not exposed to these proxies. There are multiple
> potential mechanisms that could be considered for negotiation of
> encryption keys, and establishment of end-to-end encrypted sessions at
> the application layer between clients and servers, and this working
> group proposes use of existing (D)TLS protocols and stacks.
>
> This working group proposes reuse of (D)TLS at the application layer
> as a simple and straightforward means of achieving the security and
> The working group will engage with other relevant working groups
> across the Applications and Real-Time Area (art), Security Area (sec)
> and Transport Area (tsv), and one of the goals of this working group
> is to explicitly identity all related working groups that must be
> consulted during ATLS specifications development.
>
> ---
>
> implementations right now. While they need to be polished I believe
> this is something we could go forward with.
>
> Ciao
> Hannes
>
> 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.
> 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: Thu, 21 Jun 2018 09:00:36 +0000

I did a quick read of draft-kuehlewind-taps-crypto-sep-02

I agree that providing flexibility by separating the transport protocol, record  protocol and control protocol makes sense.
If you look at the TLS / DTLS protocol you can see that there is much of this already realized today. For example,
  * Transport: support for various underlying protocols, even non-IP.
  * Record: DTLS has been used to establish keying material for SRTP and, if you look at network access authentication, also for use with WiFi security. The same is true for some other radio technologies, such as IEEE 802.15.4 in Thread.

Where the nice separation falls apart a bit (which is not appropriately reflected in the figures) is the unfortunate fact that the handshake protocol itself may need to use some security protection for its own use. In TLS the design just happens in such a way that the record layer is re-used for protecting handshake messages itself (once keys become available). In other protocols, like IKEv2/IPsec there are two separate mechanisms used.

I believe the core message in your document and the message in our document is the same. I have to check how close our Mbed TLS API is to the requirements you outline in your document.

An area where more work is needed IMHO is in the policy context since the developer has to determine which layer has to be protected with what mechanism. This is particularly important when the same protocol can in a flexible way be used at different layers. When you use totally different protocols, as it is often done today then this policy is hardwired.

Ciao
Hannes

-----Original Message-----
From: Atlas [mailto:[email-masked]] On Behalf Of Mirja Kühlewind
Sent: 19 June 2018 18:53
To: [email-masked]; Tommy Pauly; Chris Wood
Subject: Re: [Atlas] Status Update

Hi all,

Mirja

---

From: DAN GARCIA CARRILLO <[email-masked]>
Date: Fri, 22 Jun 2018 19:42:21 +0200

Dear Mirja,

Regarding the "draft-kuehlewind-taps-crypto-sep". I think it may be  
related to what we where also proposing in Section 4 of the   
"draft-garcia-core-app-layer-sec-with-dtls-record". A separation of  
the DTLS record from the DTLS handshake, which could be done with  
several protocols, though an API to be standardized.

It think, this idea is worth pursuing and maybe we could try to push  
it forward in a joint effort.

Best Regards,
Dan.

Hannes Tschofenig <[email-masked]> escribió:

> I agree that providing flexibility by separating the transport  
> protocol, record  protocol and control protocol makes sense.
> If you look at the TLS / DTLS protocol you can see that there is  
> much of this already realized today. For example,
>   * Record: DTLS has been used to establish keying material for SRTP  
> and, if you look at network access authentication, also for use with  
> WiFi security. The same is true for some other radio technologies,  
> such as IEEE 802.15.4 in Thread.
>
> Where the nice separation falls apart a bit (which is not  
> appropriately reflected in the figures) is the unfortunate fact that  
> the handshake protocol itself may need to use some security  
> protection for its own use. In TLS the design just happens in such a  
> way that the record layer is re-used for protecting handshake  
> messages itself (once keys become available). In other protocols,  
> like IKEv2/IPsec there are two separate mechanisms used.
>
> I believe the core message in your document and the message in our  
> document is the same. I have to check how close our Mbed TLS API is  
> to the requirements you outline in your document.
>
> An area where more work is needed IMHO is in the policy context  
> since the developer has to determine which layer has to be protected  
> with what mechanism. This is particularly important when the same  
> protocol can in a flexible way be used at different layers. When you  
> use totally different protocols, as it is often done today then this  
> policy is hardwired.
>
> Ciao
> Hannes
>
> I just briefly looked at draft-friel-tls-atls-00 and when I saw  
> Figure 6, I have to say that I do wonder a bit what additional  
> standardization is needed here. The new parts are the key export and  
> the App Data Crypto box. However, the key export is mainly an  
> interface question and to my understanding there are by now already  
> libraries that provide the needed interface for quic. And the actual  
> app data crypto should be rather straight forward and probably does  
> not need that much standardization...?
>
> In the context of taps, however, we've been thinking about how to  
> even more generalize this approach (in figure 6). The two points I  
> think could be generalized here even more are
>
> 1) The TLS handshake should be completely separated from the crypto  
> and could be run directly by the TLS stack without "tunneling" it  
> through the application. Effectively, in theory the handshake would  
> not even need to use the same transport connection or transport  
> protocol than the application (also it probably could).
>
> 2) The TLS handshake could negotiate within one handhshake multiple  
> key shares that can be used on different layers for different  
> protocols and algorithms. I guess that is more a question/request  
> for the TLS working group but goes into the same direction of  
> separating handshake/control and the actual crypto more.
>
> Mirja
>
>
>
> 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: Sat, 23 Jun 2018 01:19:16 +0530

+1 Dan.
The draft https://tools.ietf.org/html/draft-bhattacharyya-dice-less-on-coap-01 also proposes how the session initiation part of DTLS can be switched to CoAP to optimise the resource usage during session establishment by leveraging the lightweight semantics of CoAP. Also, to accomplish the stated objective of establishing end-to-end security association in a secure manner and managed at the application itself. The draft also tries to be less disruptive to existing DTLS implementations by defining an adaptation layer that ensures channel security by allowing the reuse of the existing DTLS record-layer encryption through the session key tuple from the CoAP layer. Of course there can be several other ways to accomplish this than what has been described in the draft.

So, it seems there are several corners with similar interests and with implementations in silos. A coordination effort will essentially lead to standardisation of the different interfaces and handshakes to reconcile these propositions.  

With Best Regards
Abhijan Bhattacharyya
Associate Consultant
Scientist, TCS Research

-----"Atlas" <[email-masked]> wrote: -----
To: [email-masked]
From: DAN GARCIA CARRILLO 
Sent by: "Atlas" 
Date: 06/22/2018 11:17PM
Cc: SARA NIEVES MATHEU GARCIA <[email-masked]>, RAFAEL MARIN <[email-masked]>
Subject: Re: [Atlas] Status Update

Dear Mirja,

Best Regards,
Dan.

---

From: Mirja Kühlewind <[email-masked]>
Date: Sun, 24 Jun 2018 19:15:03 +0200

Hi Hannes,

see below.

> Am 21.06.2018 um 11:00 schrieb Hannes Tschofenig <[email-masked]>:
> 

It’s not only the protection but also other transport features, such as reliability. DTLS has its own little transport in that sense. The other option can you use one transport for the handshake and another to actually uses the encryption… from my understanding there are still two problems where things are not as separable as it would nice to have: a) the handshake itself uses the TLS record layer (which is not necessarily a problem but also is not necessary), and b) it’s not only the handshake but also later control messages that would need to be separated (eventually).

> I believe the core message in your document and the message in our document is the same. I have to check how close our Mbed TLS API is to the requirements you outline in your document.

Cool!

> An area where more work is needed IMHO is in the policy context since the developer has to determine which layer has to be protected with what mechanism. This is particularly important when the sam…

Another aspect is also when to do what. Because if things are nicely separated and you have session-resumption, you can basically already „pre-load“ crypto context for servers that you know you want to use later.

Mirja

---

From: Mirja Kühlewind <[email-masked]>
Date: Sun, 24 Jun 2018 19:22:36 +0200

Yes, indeed, this is the same idea. Maybe we can organize a side meeting in Montreal!

Mirja

> Am 22.06.2018 um 19:42 schrieb DAN GARCIA CARRILLO <[email-masked]>:
> 
> Dear Mirja,
> 
> Regarding the "draft-kuehlewind-taps-crypto-sep". I think it may be related to what we where also proposing in Section 4 of the  "draft-garcia-core-app-layer-sec-with-dtls-record". A separation of the DTLS record from the DTLS handshake, which could be done with several protocols, though an API to be standardized.
> 
> It think, this idea is worth pursuing and maybe we could try to push it forward in a joint effort.
> 
> Best Regards,
> Dan.
> 
> 
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 25 Jun 2018 10:46:36 +0000

Hi Mirja,

~snip~

[Hannes] In DTLS the handshake contains reliability and fragmentation support. Is this necessary? Per definition of where DTLS is supposed to be used, it is necessary. If you don't need it then you also better use TLS instead.

So, in essence with the work in ATLAS we have been thinking about running TLS/DTLS on higher layers and also about separating the handshake from the application data protection. Going back to your initial question: Is there so much standardization that needs to be done? Based on our implementation experience with Mbed TLS and OpenSSL (by Owen, Mark and myself) the answer is clearly "no, there is not that much". Is there nothing to be done? I still think that there is a small amount of standardization work in addition to the description of the actual idea.

Ciao
Hannes

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 25 Jun 2018 22:46:23 -0500

> The draft https://tools.ietf.org/html/draft-bhattacharyya-dice-less-on-coap-01 also proposes how the session initiation part of DTLS can be switched to CoAP to optimise the resource usage during se…

There seems to be some "novel crypto" in here; it would be good to build on
standard blocks like Needham-Schroeder (e.g., as realized in Kerberos), to
make sure all the needed key confirmation and freshness properties are
realized.  The best freshness properties tend to occur when one endpoint
proposes a subsession key that must be confirmed by the other, which then
produces its own sub-subsession key that is likewise confirmed by the
original party.  It's best if there is contributory behavior for the keys
as opposed to just encrypting sub-keys in the previous key, though that
does tend to involve more hashing which induces cost.

-Ben

---

From: Dan García Carrillo <[email-masked]>
Date: Thu, 28 Jun 2018 22:56:19 +0200

Dear Mirja,

Sadly I will not be able to attend to the next IETF. My participation will be remotely.  But we can start discussing the subject. 

Best Regards,
Dan. 

> El 24 jun 2018, a las 19:22, Mirja Kühlewind <[email-masked]> escribió:
>

---

From: Abhijan Bhattacharyya <[email-masked]>
Date: Fri, 29 Jun 2018 13:13:30 +0530

Same for me. Looking forward to more list discussions.

With Best Regards
Abhijan Bhattacharyya
Associate Consultant
Scientist, TCS Research

-----"Atlas" <[email-masked]> wrote: -----
To: Mirja Kühlewind <[email-masked]>, [email-masked]
From: Dan García Carrillo 
Sent by: "Atlas" 
Date: 06/29/2018 02:27AM
Cc: SARA NIEVES MATHEU GARCIA <[email-masked]>, "U. Rafael Marín López" <[email-masked]>
Subject: Re: [Atlas] Status Update

Dear Mirja,

Best Regards,
Dan.