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

["Dr. Pala" <[e-mail]>]

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 <[e-mail] 
> <mailto:[e-mail]>>:
>
>     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
>     _______________________________________________
>     Cfrg mailing list
>     [e-mail] <mailto:[e-mail]>
>     https://www.irtf.org/mailman/listinfo/cfrg
>
-- 
Best Regards,
Massimiliano Pala, Ph.D.
OpenCA Labs Director
OpenCA Logo