Hannes Tschofenig <[email protected]> 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). -- Michael Richardson <[email protected]>, Sandelman Software Works -= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
_______________________________________________ Ace mailing list [email protected] https://www.ietf.org/mailman/listinfo/ace
