Re: [Lake] Call for adoption for draft-selander-lake-edhoc - respond by June 22

[Benjamin Kaduk <[e-mail]>]

Hi Martin,

Thanks for chasing this line of inquiry.  It does leave me with some more
questions, though...

On Tue, Jun 23, 2020 at 02:00:16PM +1000, Martin Thomson wrote:
> On Mon, Jun 8, 2020, at 23:54, Mališa Vučinić wrote:
> > we are now launching a call for adoption for 
> > https://tools.ietf.org/html/draft-selander-lake-edhoc-01.
> 
> I was reluctant to respond to this thread, because it generally isn't worth stopping other people from doing something they want to do.  And I'm aware that the contract implied by the formation of this working group - at least in the minds of many - was the development of a new AKE.

(Sure, though for me I was more interested in the "find out if we need to
develop a new AKE" question, first.)

> The time that others spend isn't the only factor we should use to decide.  As others have noted, adoption of an entirely new AKE means more than just the time that those other people spend.  I have no skin in the maintenance of IoT products, but the concerns raised about fracturing and maintenance overheads there are serious.  My concern is for the split this creates between endpoints that choose option A and endpoints that choose option B.
> 
> When CoAP was proposed, I didn't have the same presence of mind as others [1] to recognize the harm inherent in defining something like HTTP that wasn't HTTP.  It's easy to point to adoption of CoAP and use that to claim success, but that misses the true costs.  The true failure is the creation of a set of endpoints that don't talk to other endpoints.  The IETF made the choice to actively help create a division in the market.  Maybe these endpoints might never have been able to communicate (MQTT is, after all, largely outside our control), but the choice by the IETF to XKCD 927 didn't really help.

The main thread I'd like to tug on here is what exactly could be
interoperable, and how that might be affected by our decisions here in
LAKE.  In particular, it seems like we need to take the existence of CoAP
and OSCORE as a given, and cannot indulge in counterfactuals.  So, given
that there are devices using CoAP, and OSCORE is 8613, we can expect people
to be making devices that use OSCORE for their secure communications, and
need an AKE to key OSCORE for most/many use cases.  This already assumes
an "island" separate from HTTP, and an island separate from TLS for data
protection.  Is using cTLS as an AKE for OSCORE going to somehow (help)
join up an island of cTLS+OSCORE with the existing CoAP+DTLS island?
If we want a cTLS stack to talk to a non-'c' TLS stack, even just for the
AKE, where is the translation logic going to be (if it's even possible)?

My own first cut at an analysis is only finding that we'd "just" avoid
having separate EDHOC+OSCORE and cTLS+OSCORE islands, but that a
cTLS+OSCORE island would still be an island, isolated from the broader TLS
ecosystem.  Am I missing a way to join things together?

> For us, this failure manifests in a great deal of expenditure on parallel infrastructure and standards development.  For the market, who we leave to choose, the cost is in the creation of non-interoperable islands.  The market also pays through the dilution of resources that we dedicate to the improvement of the commons, of which protocols are some of the most valuable assets.

That is true, though it is unclear to me that there is any effort ("market"
or otherwise) currently going into a cTLS+OSCORE combination.  I'd love to
be illuminated if I've just been missing it!

Thanks,

Ben

> [1] https://tools.ietf.org/html/draft-montenegro-httpbis-h2ot-00