Re: [Secdispatch] I-D: Deploying Publicly Trusted TLS Servers on IoT Devices Using SNI-based End-to-End TLS Forwarding (SNIF)

[Eric Rescorla <[e-mail]>]

Document: draft-zubov-snif-04.txt


OVERALL
As I understand it the problem statement here is that you
have a back-end IoT server which is not publicly addressable
and you want to have a front-end proxy server which:

1. Assigns the back-end-server a hostname

2. Acquires publicly available WebPKI certificates on its
   behalf

3. Serves as a reverse proxy for the server at the TCP
   layer (and presumably eventually at the UDP layer).

The problem of acquiring WebPKI certificates for non-publicly
addressable devices is a pretty common one and applies to
a number of enterprise use cases, not just WebPKI.

However, it seems to me that your situation is different because you
want the device to be accessible, it just isn't publicly
addressable. This suggests to me that there is a simpler approach:

- When a device first connects to the proxy, assign it a
  hostname and establish a credential (e.g., a random
  key) bound to the hostname (effectively #1 above)

- Allow the device to connect to the proxy and authenticate with the
  credential and then route any TLS or HTTP connections to the
  hostname to that device (a generalization of #3).

If you just do this, then you shouldn't need any other mechanism
because the device will be able to fulfill the ordinary ACME HTTP
Challenge (RFC 8555; S 8.3) and the ALPN challenge (RFC 8737) without
any additional effort by the proxy. In particular, the proxy will
not need to engage with ACME because the back-end server can
do that.

Second, I don't think you need to define a new proxy protocol. While
MASQUE isn't currently specified for this kind of server application,
it seems like a natural extension and MASQUE would handle all the
transport mechanics for you, thus making life a lot simpler.


DETAILED COMMENTS
A number of the design choices here seem suboptimal. These would
mostly go away if you adopted the strategy I propose above. However,
I note them in case you do not do so.

* If I am reading this protocol correctly, there is no way to
  change the private key of a server in a given name. If that's
  correct, it seems suboptimal.

* It seems like you are establishing a new TCP connection to
  the device for each incoming TCP connection. That is not
  going to have great performance. I would instead mux all
  the data over a single connection (see MASQUE, supra).

* It seems like you are having the relay connect to the device.
  That is going to be a problem if the device is behind a
  NAT or any kind of stateful inspection filter. Instead,
  I would have all connections be outgoing.

* Requiring the Relay to validate the server's TLS certificate,
  as defined in S 4.2, makes the Relay much more complicated
  as it has to have a WebPKI stack in it.

I also, I don't understand this text:

   Since each certificate issued by a CA remains on the certificate
   transparency public records, it is RECOMMENDED for SNIF CA Proxy to
   only issue Certificates with a wildcard CN.  This way, the actual
   Connector's hostname (Section 3.2) will not be listed on the public
   records.

Can you provide an example of what you mean here? If the Connectors
are named a.example.com, b.example.com, and c.example.com, you obviously
cannot issue any of them *.example.com. OTOH, if you have them have
<something>.a.example.com and <something-else>.b.example.com, then
how does it help to issue *.a.example.com?


SECDISPATCH QUESTIONS
I think the next steps here are to resolve what problem is being
solved. In particular, if what I propose above will work, then
this should go to MASQUE with a limited scope of defining incoming
connections. If not, then I think we need to get clearer on why
it won't.

-Ekr





















On Tue, Feb 8, 2022 at 10:18 AM Jim Zubov <[e-mail]>
wrote:

> Please consider the following draft:
>
> https://datatracker.ietf.org/doc/draft-zubov-snif/
>
> The document describes a set of protocols for publicly trusted serverless
> TLS that can be used as an end-to-end IoT security solution.
>
> The solution had been tested in pre-production. The complete source code
> is in the public domain -
>
> https://github.com/vesvault/snif
>
> Any feedback, suggestions, and recommendations of an IETF group adoption
> are welcome.
>
>
> Thank You -
>
> Jim Zubov
> VESvault Corp
> CTO / Co-founder
>
> _______________________________________________
> Secdispatch mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/secdispatch
>