Subject: [Ace] Application Layer TLS

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 21 Nov 2017 09:42:58 +0000

Hi all,

based on the recent email discussion about the DTLS proxy I thought it might be useful that there was some thinking about how to run TLS/DTLS at the application layer.
There are essentially two drafts that have been submitted at the same time for IETF#100, namely

https://tools.ietf.org/html/draft-tschofenig-layered-tls-00
https://tools.ietf.org/html/draft-friel-tls-over-http-00

Both teams have worked on prototypes and getting it to work was remarkably simple.

Maybe something for this group to look at.

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: Ludwig Seitz <[email-masked]>
Date: Tue, 21 Nov 2017 11:06:53 +0100

On 2017-11-21 10:42, Hannes Tschofenig wrote:
> Hi all,
> 
> based on the recent email discussion about the DTLS proxy I thought it 
> might be useful that there was some thinking about how to run TLS/DTLS 
> at the application layer.
> 

I have a vague memory of a DICE draft for doing the DTLS handshake over 
CoAP a long time ago:

https://datatracker.ietf.org/doc/html/draft-schmertmann-dice-codtls-00

Can the original authors tell us why they didn't go further with that 
approach?

/Ludwig

-- 
Ludwig Seitz, PhD
Security Lab, RISE SICS
Phone +46(0)70-349 92 51

---

From: Abhijan Bhattacharyya <[email-masked]>
Date: Tue, 21 Nov 2017 15:53:39 +0530

Just to keep it on record:
We also had a draft which may find some relevance in the present context:
https://tools.ietf.org/html/draft-bhattacharyya-dice-less-on-coap-00
Related publication: http://ieeexplore.ieee.org/document/7096256/

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
____________________________________________

-----"Ace" <[email-masked]> wrote: -----
To: <[email-masked]>
From: Ludwig Seitz
Sent by: "Ace"
Date: 11/21/2017 03:37PM
Subject: Re: [Ace] Application Layer TLS

/Ludwig

--
Ludwig Seitz, PhD
Security Lab, RISE SICS
Phone +46(0)70-349 92 51

_______________________________________________
Ace mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ace

=====-----=====-----=====
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: Tue, 21 Nov 2017 10:49:12 +0000

Thanks for the pointer. I wasn't aware of that work.

-----Original Message-----
From: Ace [mailto:[email-masked]] On Behalf Of Abhijan Bhattacharyya
Sent: 21 November 2017 11:24
To: Ludwig Seitz
Cc: [email-masked]
Subject: Re: [Ace] Application Layer TLS

With Best Regards
Abhijan Bhattacharyya
Associate Consultant
Scientist, TCS Research
Experience certainty.IT Services

> Maybe something for this group to look at.

I have a vague memory of a DICE draft for doing the DTLS handshake over CoAP a long time ago:

Can the original authors tell us why they didn't go further with that approach?

/Ludwig

--
Ludwig Seitz, PhD
Security Lab, RISE SICS
Phone +46(0)70-349 92 51

=====-----=====-----=====
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: Tue, 21 Nov 2017 10:54:50 +0000

Hi Ludwig,

Carsten pointed me to that document. Mark and I will do a comparison between the different solutions. In any case, it is great to see the level of interest in this and if you attended the TLS WG session then you can certainly appreciate the heated discussion.

One question I was asked at the IETF meeting was why the HTTP Connect functionality hasn't been defined in CoAP since this would make certain use cases with proxy use simpler.
For me that's a useful addition but does not cover the entire solution space since I am also consider non-IP based scenarios.

Ciao
Hannes

-----Original Message-----
From: Ace [mailto:[email-masked]] On Behalf Of Ludwig Seitz
Sent: 21 November 2017 11:07
To: [email-masked]
Subject: Re: [Ace] Application Layer TLS

/Ludwig

--
Ludwig Seitz, PhD
Security Lab, RISE SICS
Phone +46(0)70-349 92 51

---

From: Rafa Marin-Lopez <[email-masked]>
Date: Tue, 21 Nov 2017 12:21:36 +0100

Dear all:

This I-D we wrote sometime ago might be also related:

https://tools.ietf.org/html/draft-garcia-core-app-layer-sec-with-dtls-record-00 <https://tools.ietf.org/html/draft-garcia-core-app-layer-sec-with-dtls-record-00>

Best Regards.

> El 21 nov 2017, a las 11:54, Hannes Tschofenig <[email-masked]> escribió:
> 
> Hi Ludwig,
> 

-------------------------------------------------------
Rafa Marin-Lopez, PhD
Dept. Information and Communications Engineering (DIIC)
Faculty of Computer Science-University of Murcia
30100 Murcia - Spain
Telf: +34868888501 Fax: +34868884151 e-mail: [email-masked]
-------------------------------------------------------

---

From: Olaf Bergmann <[email-masked]>
Date: Tue, 21 Nov 2017 12:42:52 +0100

> Can the original authors tell us why they didn't go further with that

The main reason was that it did not fit into the official DICE work
program. Meanwhile, the student who did most of the work (including a
working prototype[1] which is also available as rubby gem) has graduated
and left the university.

But there is no technical reason for not taking this up again.

[1] https://github.com/SmallLars/codtls

Grüße
Olaf

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 21 Nov 2017 12:22:30 +0000

To me it sounds like we have multiple groups who have seen a problem and have been willing to spend the time to work on the solutions.

I believe we should put a BOF proposal for the London IETF meeting together. How does that sound?

Ciao
Hannes

-----Original Message-----
From: Ace [mailto:[email-masked]] On Behalf Of Olaf Bergmann
Sent: 21 November 2017 12:43
To: Ludwig Seitz
Cc: [email-masked]
Subject: Re: [Ace] Application Layer TLS

> Can the original authors tell us why they didn't go further with that

The main reason was that it did not fit into the official DICE work program. Meanwhile, the student who did most of the work (including a working prototype[1] which is also available as rubby gem) has graduated and left the university.

Grüße
Olaf

---

From: Olaf Bergmann <[email-masked]>
Date: Tue, 21 Nov 2017 13:27:47 +0100

Hannes Tschofenig <[email-masked]> writes:

> To me it sounds like we have multiple groups who have seen a problem
> and have been willing to spend the time to work on the solutions.
>

+1

Grüße
Olaf

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 21 Nov 2017 14:07:23 +0100

> [1] https://github.com/SmallLars/codtls

This work was a successful early proof of concept and has thus fully achieved its objective.

One more reason that we haven’t picked this up again is that the original work was for an older chip, the MC1322x, and contained code to keep connection state in the Flash of that chip that probably would need some porting.

At the time, the TLS WG also didn’t seem particularly receptive to new work: codtls is not just a compressed DTLS, as it performed the MAC operations for the Finished messages on the actual messages exchanged, not on the original uncompressed messages that never are reified.  Essentially, a large part of the complexity of the solution is in trying to maintain the entire set of TLS exchanges, and then the MAC doesn’t quite.  (This is a fundamental problem any TLS emulation will have, and it would be good to get the envelope of what works and what doesn’t for this specified.)

With much more tailored solutions around the corner (e.g., EDHOC), we didn’t see a strong technical motivation to take this up again either.  But we sure can if there is a political reason instead.

Grüße, Carsten

---

From: Michael Richardson <[email-masked]>
Date: Tue, 21 Nov 2017 10:16:07 -0500

> at the application layer.

yes, and I'm enthusiastic to permit EST to run over whatever comes out, as I
suspect it will be bytes-on-the-wire cheaper than COAPS.

Yet, there are people who want EST over CoAPS to work as is...

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Michael Richardson <[email-masked]>
Date: Tue, 21 Nov 2017 10:21:23 -0500

Hannes Tschofenig <[email-masked]> wrote:
    > One question I was asked at the IETF meeting was why the HTTP Connect
    > functionality hasn't been defined in CoAP since this would make certain
    > use cases with proxy use simpler.

HTTPS CONNECT invokes a multistage TLS connection: client->proxy and proxy->server.
That obscures the server certificate from the client and VV, and we have a
well established serious security issues in the "enterprise" world with the
ability of the proxy to usefully validate the server certificate.

An COAP (not COAPS) CONNECT mechanism which put the security inside CoAP
(as EDHOC/OSCORE and presumably draft-tschofenig-layered-tls-00 and
draft-friel-tls-over-http-00 do) solves the problem of certificate validation
nicely because it offers end to end security.

However, it's unclear to me how it would be better than NAT66 (with all of
it's expensive state), which is why I want a mechanism where the relay state
is stored in the network (echoed, source routed back to the proxy).

---

From: Derek Atkins <[email-masked]>
Date: Tue, 21 Nov 2017 12:33:56 -0500

Hannes,

Hannes Tschofenig <[email-masked]> writes:

> Hi all,
>
> based on the recent email discussion about the DTLS proxy I thought it might
> be useful that there was some thinking about how to run TLS/DTLS at the
> application layer.

I don't understand this statement.  The whole point of TLS/DTLS is that
it runs at the Application Layer (as opposed to at the network layer,
like IPsec).  Indeed, the fact that it could run at the application
layer (e.g. in a web brower / web server) is exactly why SSL/TLS was
created in the first place.  It meant you didn't require waiting for the
kernel/OS to add network security.

> https://tools.ietf.org/html/draft-friel-tls-over-http-00

So you are moving the application layer up even higher than the historic
view of an application layer?

Perhaps we need a better naming scheme here.

> Both teams have worked on prototypes and getting it to work was remarkably

-derek
-- 
       Derek Atkins                 617-623-3745
       [email-masked]             www.ihtfp.com
       Computer and Internet Security Consultant

---

From: Michael Richardson <[email-masked]>
Date: Tue, 21 Nov 2017 13:48:05 -0500

> it runs at the Application Layer (as opposed to at the network layer,

DTLS has to provide many of the services of the Transport and Network layer
(various amounts of reliability, fragmentation/segmentation) and there is
overhead in that.  When running over things like CoAP, which *ALSO* provides
those services, and in a more constrained network happy way, DTLS is way less
appealing.

    > Perhaps we need a better naming scheme here.

In my opinion, the ISO layer naming system has always been better as
documentation, rather than architecture :-)

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 21 Nov 2017 20:25:13 +0100

> documentation, rather than architecture :-)

And we can celebrate its 40th birthday in a couple of months.

Grüße, Carsten

(The OSI Reference Model, standardized in ISO 7498/ITU-T X.200 was *intended* to be prescriptive, structuring the standardization work lying ahead in 1978.
It lost that function with the factual end of the OSI project a dozen years later, and most people have forgotten what the OSI layers were about:  Layer 2, 3, 4, 7 took on a new, slightly different meaning as layer numbers for the layers named in RFC 1122/1123, while 1 is convenient as a layer number for the part of the RFC 1122 link layer that is concerned with bits, symbols, clocks, and physical interoperability.
The old seven-layer OSI model is still being taught, usually mostly with the current meaning of the layer numbers that still exist, and a lot of misconceptions of what L5/L6 were supposed to be, in computer networking classes by teachers that don’t know better.  Foo.)

---

From: Abhijan Bhattacharyya <[email-masked]>
Date: Wed, 22 Nov 2017 01:41:34 +0530

+1

With Best Regards
 Abhijan Bhattacharyya
 Associate Consultant
 Scientist, TCS Research

-----"Ace" <[email-masked]> wrote: -----
To: Olaf Bergmann <[email-masked]>, Ludwig Seitz <[email-masked]>
From: Hannes Tschofenig 
Sent by: "Ace" 
Date: 11/21/2017 05:56PM
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [Ace] Application Layer TLS

Ciao
Hannes

-----Original Message-----
From: Ace [mailto:[email-masked]] On Behalf Of Olaf Bergmann
Sent: 21 November 2017 12:43
To: Ludwig Seitz
Cc: [email-masked]
Subject: Re: [Ace] Application Layer TLS

Grüße
Olaf

---

From: "Panos Kampanakis (pkampana)" <[email-masked]>
Date: Tue, 21 Nov 2017 22:04:05 +0000

Someone had pointed it out on the mic in ACE @ IETF99, I think. Redefining well established protocol functionality like (D)TLS' to secure communications of other unencrypted application protocols comes with the risks of lack of vetting and scrutiny, test of time and mistakes though. 

I am not against this work, but I have seen many new secure protection channel establishment protocols and I am not sure there are no issues  which we don't see now that will manifest themselves later. 

-----Original Message-----
From: Ace [mailto:[email-masked]] On Behalf Of Michael Richardson
Sent: Tuesday, November 21, 2017 1:48 PM
To: [email-masked]
Cc: Derek Atkins <[email-masked]>
Subject: Re: [Ace] Application Layer TLS

    > it runs at the Application Layer (as opposed to at the network layer,

DTLS has to provide many of the services of the Transport and Network layer (various amounts of reliability, fragmentation/segmentation) and there is overhead in that.  When running over things like CoAP, which *ALSO* provides those services, and in a more constrained network happy way, DTLS is way less appealing.

    > Perhaps we need a better naming scheme here.

In my opinion, the ISO layer naming system has always been better as documentation, rather than architecture :-)

--
Michael Richardson <[email-masked]>, Sandelman Software Works  -= IPv6 IoT consulting =-

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 22 Nov 2017 12:10:02 +0000

Hi Derek

There might indeed be room for improvement on the terminology front. I was using the "application layer TLS terminology" because it was used in discussions in the TLS working group and at the TLS WG session @ IETF#100.

I suspect that the use cases in various documents, which differ slightly, might give a better idea what we try to accomplish.

Ciao
Hannes

-----Original Message-----
From: Derek Atkins [mailto:[email-masked]]
Sent: 21 November 2017 18:34
To: Hannes Tschofenig
Cc: [email-masked]
Subject: Re: [Ace] Application Layer TLS

Hannes,

> at the application layer.

I don't understand this statement.  The whole point of TLS/DTLS is that it runs at the Application Layer (as opposed to at the network layer, like IPsec).  Indeed, the fact that it could run at the application layer (e.g. in a web brower / web server) is exactly why SSL/TLS was created in the first place.  It meant you didn't require waiting for the kernel/OS to add network security.

> https://tools.ietf.org/html/draft-friel-tls-over-http-00

So you are moving the application layer up even higher than the historic view of an application layer?

-derek