Subject: [Cfrg] When TLS is an overkill...

From: "Dr. Pala" <[email-masked]>
Date: Mon, 25 Feb 2019 08:55:51 -0700

Hi CFRG,

I am working on some aspects about provisioning credentials and 
authenticating devices and I noticed that sometimes people use TLS to 
establish a secure channel with a server even when all they want to do 
(i.e., no extra features/checks/etc.) could potentially be achieved in 
just 2/3 messages. An example of this is EAP - whenever a secure channel 
needs to be established, EAP-TLS, EAP-TTLS, EAP-TEAP, etc. must be 
supported to tunnel the 2nd method that will be used for authentication.

My question for the group is: if we were to use a "simple" way to 
establish the secure channel, are there recommendations for what should 
be in those messages ? What would be the minimum set of required data 
that MUST be included in the exchange ?

A rough example of such messages could be (A = Client, B = Server):

  * [A] { Supported Encryption Algorithms List,
            Supported Key-Exchange Algorithms List,
            Encryption Initialization Data,
            MSG Authentication } -> [B]

  * [B] { Selected Encryption Algorithm and Params,
            Selected Key-Exchange Algorithm and Params,
            Key-Exchange Params (e.g., ECDHE),
            (Optional) Credentials (e.g., Certificate Chain),
            Encryption Initialization Data,
            MSG Authentication } -> [A]

  * [A] { Selected Encryption Algorithm and Params,
            Selected Key-Exchange Params (e.g., ECDHE),
            Key-Exchange Params (e.g., ECDHE),
            (Optional) My Credentials Encrypted (e.g., Certificate Chain),
            MSG Authentication } -> [B]

 From now on, the two parties end up with a shared secret key and 
agreed-upon encryption algorithm.

In environments where the number of exchanged messages matter - EAP is a 
great example of that - having a standardized method that provides the 
possibility of establishing a secure communication channel very easily 
would be great. After that, I think that either the TLS layer can kick 
in and manage the encryption or other options might be used for the 
encryption of the data itself (e.g., directly encrypting the data record 
by record).

Looking forward to hearing from you,

Cheers,
Max

-- 
Best Regards,
Massimiliano Pala, Ph.D.
OpenCA Labs Director
OpenCA Logo

---

From: Adam Langley <[email-masked]>
Date: Mon, 25 Feb 2019 08:00:12 -0800

On Mon, Feb 25, 2019 at 7:56 AM Dr. Pala <[email-masked]> wrote:

> establish the secure channel, are there recommendations for what should be
> in those messages ? What would be the minimum set of required data that
> MUST be included in the exchange ?
>
Noise Explorer (https://noiseexplorer.com/) is excellent work in this space.

Cheers

AGL

---

From: "Stanislav V. Smyshlyaev" <[email-masked]>
Date: Mon, 25 Feb 2019 19:03:54 +0300

Dear Max,

Just a quick comment: have you had a chance to have a look at the protocol
(also a SIGMA-based one) described in
https://tools.ietf.org/html/draft-selander-ace-cose-ecdhe-11? It may not be
the silver bullet but is definitely worth considering when thinking about
such questions.

Best regards,
Stanislav

пн, 25 февр. 2019 г. в 18:56, Dr. Pala <[email-masked]>:

> (i.e., no extra features/checks/etc.) could potentially be achieved in just
> 2/3 messages. An example of this is EAP - whenever a secure channel needs
> to be established, EAP-TLS, EAP-TTLS, EAP-TEAP, etc. must be supported to
> tunnel the 2nd method that will be used for authentication.
>
>    - [A] { Supported Encryption Algorithms List,
>    - [B] { Selected Encryption Algorithm and Params,
>    - [A] { Selected Encryption Algorithm and Params,
> would be great. After that, I think that either the TLS layer can kick in
> and manage the encryption or other options might be used for the encryption
> of the data itself (e.g., directly encrypting the data record by record).
>
> _______________________________________________
> Cfrg mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/cfrg
>

---

From: "Dr. Pala" <[email-masked]>
Date: Mon, 25 Feb 2019 09:37:15 -0700

Hi Stanislav,

I have not read it yet - from the abstract it seems it provides the 
solution for CBOR/COSE for ECDHE. It is definitely relevant - thanks for 
the pointer. From what I see, it seems that this is another example of 
the need for having such BCP (?) that can be implemented in different 
environments and can use different encodings (e.g., JSON, ASN.1, Binary, 
XML, etc.)

The specific I-D seems to be a bit too restrictive for a generic 
protocol - i.e., does not supports certificates, only intended for 
CBOR/COSE, and does only one algorithm for key exchange: I am thinking 
more in the direction of an "algorithm-independent" approach that would 
not require updating when new algorithms for key-exchange, for example, 
are standardized and deployed (e.g., hash-based signatures) and can 
support traditional, post-quantum, and future algorithms (as long as no 
"new paradigm" is introduced). However, besides all these 
"ecosystem-specific" limitations, the work goes in the same direction as 
what I am saying here: establish an encryption algorithm and a key by 
using 3 messages only.

Thanks for the pointer, I will look more closely into that document to 
see what they include in those messages and why.

Cheers,
Max

On 2/25/19 9:03 AM, Stanislav V. Smyshlyaev wrote:
> Dear Max,
>
> Just a quick comment: have you had a chance to have a look at the 
> protocol (also a SIGMA-based one) described in
> https://tools.ietf.org/html/draft-selander-ace-cose-ecdhe-11? It may 
> not be the silver bullet but is definitely worth considering when 
> thinking about such questions.
>
> Best regards,
> Stanislav
>
> пн, 25 февр. 2019 г. в 18:56, Dr. Pala <[email-masked] 
> <mailto:[email-masked]>>:
>
>     Hi CFRG,
>
>     authenticating devices and I noticed that sometimes people use TLS
>     to establish a secure channel with a server even when all they
>     want to do (i.e., no extra features/checks/etc.) could potentially
>     be achieved in just 2/3 messages. An example of this is EAP -
>     whenever a secure channel needs to be established, EAP-TLS,
>     EAP-TTLS, EAP-TEAP, etc. must be supported to tunnel the 2nd
>     method that will be used for authentication.
>
>     establish the secure channel, are there recommendations for what
>     should be in those messages ? What would be the minimum set of
>     required data that MUST be included in the exchange ?
>
>     In environments where the number of exchanged messages matter -
>     EAP is a great example of that - having a standardized method that
>     provides the possibility of establishing a secure communication
>     channel very easily would be great. After that, I think that
>     either the TLS layer can kick in and manage the encryption or
>     other options might be used for the encryption of the data itself
>     (e.g., directly encrypting the data record by record).
>
>     [email-masked] <mailto:[email-masked]>
-- 
Best Regards,
Massimiliano Pala, Ph.D.
OpenCA Labs Director
OpenCA Logo

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 25 Feb 2019 18:16:28 +0100

On Feb 25, 2019, at 17:37, Dr. Pala <[email-masked]> wrote:
> 
> The specific I-D seems to be a bit too restrictive for a generic protocol

Well, that’s the point.

Flexibility is overrated.

Grüße, Carsten

---

From: Peter Gutmann <[email-masked]>
Date: Tue, 26 Feb 2019 00:14:33 +0000

Dr. Pala <[email-masked]>​

>I noticed that sometimes people use TLS to establish a secure channel with a
>server even when all they want to do (i.e., no extra features/checks/etc.)
>could potentially be achieved in just 2/3 messages. An example of this is EAP
>- whenever a secure channel needs to be established, EAP-TLS, EAP-TTLS, EAP-
>TEAP, etc. must be supported to tunnel the 2nd method that will be used for
>authentication.

That's because it's required for EAP, which in the form of EAP / RADIUS is the
universal standard for device authentication.  There are (at least) tens of
billions of devices that use this somewhere.  It's not used because it's a
technically good solution (running EAP over DIAMETER over EAP-TLS over EAP
over RADIUS over UDP is probably close to insane), but because there's a vast
global infrastructure that supports it.

>My question for the group is: if we were to use a "simple" way to establish
>the secure channel, are there recommendations for what should be in those
>messages ? What would be the minimum set of required data that MUST be
>included in the exchange ?

Also, what colour should the various pieces be painted, and should it be
gloss, satin, or matt?

You're asking the wrong question(s).  What problem are you trying to solve?
Without that frame of reference, it's not possible to answer any of the
questions you're asking.

If you want an example of some designs that do a good job of solving a
particular problem, look at LoRaWAN security or WireGuard.  They solve a
specific, widely-encountered problem, and they do a pretty good job of it
without adding a ton of unnecessary bloat.

Peter.

---

From: "Dr. Pala" <[email-masked]>
Date: Mon, 25 Feb 2019 18:25:37 -0700

Hi Peter,

responses and comments inline...

> global infrastructure that supports it.

Yes, I always found the stacking of protocols for EAP insane... but it 
must not be too insane if we deployed such a large support for it. Just 
the right amount of insanity, I guess :D I tried to launch the idea that 
maybe we can re-visit EAP... but that was simply a no-go :D [ Updating 
standards seems like its becoming sooo difficult - there are always 
people that knock ideas down just because... thus keeping us in the dark 
ages for no good reason other than their companies might make more money 
with inefficient systems - look at the status of PKIs - we need to stop 
sayin "no" all the time and work for a better Internet ]

> without adding a ton of unnecessary bloat.

What I am trying to do is quite simple: /provide a building block that 
developers and engineers can use to secure the communication between two 
peers by using a low number of messages/.

In particular, I think that this building block could help many 
developers to do the right thing when not using TLS. Do not get me 
wrong, TLS is great.. however, it might be useful to have an 
alternative. My particular use case (but this is just one, there might 
be many others) is specifically EAP. In EAP, it seems, people always try 
to re-use deployment even when they do not make much sense (e.g., insane 
protocol stack) - i.e., always trying to fit a square peg in a round 
hole, so to speak.

Can we do better ?

Instead of using the square peg (TLS) with the round hole (to create a 
security association and optionally authenticate), can we provide a (BCP 
?) document that provides the reader with the minimum viable messages 
for securing the communication ? The main difference with TLS would be 
(a) no session resumption/tickets/etc., (b) not direct connection is 
required (transport independent - message based), (c) no support for TLS 
"extensions", (d) remove the dns validation from the equation (i.e., the 
network location of the server does not matter since it can not be 
verified - see (b)).

A building block like that could be used in many different environments 
and over many different transport protocols - from this point of view, 
if we do something, lets' make it useful for everybody and applicable in 
many different environments (i.e., encoding-independent with specific 
conversion rules, maybe ?) and settings (not just for my specific 
use-case EAP).

Does this answer your question ?

And my original question still stand - is there an RFC already out there 
that can be used for this ? Or that can be used as a starting point for 
this ?

Thanks again for the comments and questions :D

Cheers,
Max

-- 
Best Regards,
Massimiliano Pala, Ph.D.
OpenCA Labs Director
OpenCA Logo

---

From: Peter Gutmann <[email-masked]>
Date: Tue, 26 Feb 2019 03:54:32 +0000

Dr. Pala <[email-masked]> writes:

>provide a building block that developers and engineers can use to secure 
>the communication between two peers by using a low number of messages.

It still leaves way too much unstated... what's a low number?  Is there a
limit on bandwidth or message size?  Does one side need to be authenticated,
or both, or neither?  Is there a constraint on CPU use?  Is auth via a
third party (e.g. a CA) or mutual?  Do you need algorithm agility?  etc.

Coming up with something as a gedanken experiment is always fun, but
without a concrete goal or goals to act as success criteria you can never 
know whether you've achieved what you were aiming for.

Peter.

---

From: Ruslan Kiyanchuk <[email-masked]>
Date: Tue, 26 Feb 2019 00:45:45 -0800

> developers and engineers can use to secure the communication between
> two peers by using a low number of messages/.
>
> be many others) is specifically EAP. In EAP, it seems, people always
> try to re-use
>
I think you might be trying to reinvent Noise protocol framework
<http://www.noiseprotocol.org/> :)

It's a framework designed to be simple and straightforward for for
securing 2-party communication. By combining different elements of the
protocol you achieve various security properties. There is also a third
party website Noise Explorer <https://noiseexplorer.com/> where you can
explore various settings of the framework and corresponding security
properties.

By your description so far it sounded like a good fit.

Another mention that may be relevant is Google's ATLS
<https://cloud.google.com/security/encryption-in-transit/application-layer-transport-security/>
(it's their home-grown TLS alternative, I'm not aware how much scrutiny
and analysis it underwent).

Good luck!

---

From: [email-masked]
Date: Tue, 26 Feb 2019 09:06:35 +0000

Sounds like goal is quite similar to what noise protocol framework tries to achieve.

---

From: 赵运磊 <[email-masked]>
Date: Wed, 27 Feb 2019 00:37:17 +0800 (GMT+08:00)

Dear Dr. Pala and All:
I suggest my work on higncryption and identity-concealed non-malleable key-exchange (CNKE) might be useful for your seeking for.  This work was at CCS16, and the full version is available at: https://eprint.iacr.org/2018/1165

In htis work, we present a  identity-hiding higncryption (higncryption) and   family AKE protocols based on higncryption, having the following features:

(1) identity privacy;

(2) Support 0-RTT communicaions;

(3)  Using authenticated encryption, and secure channel can already be established from the second round message.

(4) simple, and relatively as efficient as HMQV

(4) flexible: various adaptions to TLS, QUIC, and ATLS,SACCE, etc.

Best regards
Yunlei
Fudan University, Shanghai, China

-----原始邮件-----
发件人:[email-masked]
发送时间:2019-02-26 17:06:35 (星期二)
收件人: [email-masked], "Ruslan Kiyanchuk" <[email-masked]>, "Dr. Pala" <[email-masked]>
抄送:
主题: Re: [Cfrg] When TLS is an overkill...

What I am trying to do is quite simple: provide a building block that developers and engineers can use to secure the communication between two peers by using a low number of messages.

In particular, I think that this building block could help many developers to do the right thing when not using TLS. Do not get me wrong, TLS is great.. however, it might be useful to have an alternative. My particular use case (but this is just one, there might be many others) is specifically EAP. In EAP, it seems, people always try to re-use

I think you might be trying to reinvent Noise protocol framework :)

It's a framework designed to be simple and straightforward for for securing 2-party communication. By combining different elements of the protocol you achieve various security properties. There is also a third party website Noise Explorer where you can explore various settings of the framework and corresponding security properties.

Another mention that may be relevant is Google's ATLS (it's their home-grown TLS alternative, I'm not aware how much scrutiny and analysis it underwent).

Good luck!