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]>]

Hi Jim,

I'm going to respond to this message, but I don't think we're saying much
new
here, so I'll probably stop after that. There will be plenty of time to
discuss
disposition during the SECDISPATCH meeting.

On Thu, Feb 24, 2022 at 7:22 PM Jim Zubov <[e-mail]>
wrote:

>
>
> On February 24, 2022 7:10:25 PM EST, Eric Rescorla <[e-mail]> wrote:
> >On Thu, Feb 24, 2022 at 3:22 PM Jim Zubov <[e-mail]>
> >wrote:
>
> >What I am proposing also has this property.
> >
> >- For TLS, the proxy behaves as in your document, switching on SNI (though
> >not validating the certificate) and forwarding the encrypted data.
> >- For HTTP, the proxy behaves much the same way but switches on the Host:
> >header.
> >
> >Therefore it is end-to-end for any encrypted traffic.
>
> Basically, everything boils down to 2 questions -
> 1. who has access to the private key,
> 2. who interacts with the CA to issue the cert
>
> When the solution is end-to-end - the answer to (1) is always - only the
> device itself.
> Let's review (2) assuming the CA speaks ACME. There are 3 common challenge
> types - HTTP, DNS and ALPN.
> HTTP: Need to either relay plain HTTP from/to the device, or the proxy to
> serve HTTP.
> DNS: Need to either relay DNS from/to the device, or the proxy to serve
> DNS.
>

Or to have the proxy *configure* the DNS (which it will have to anyway,
because it controls the zone) but we can ignore that for the moment, as I
agree that we want to support non-DNS challenge types.


ALPN: Need to either relay TLS to a device with a self-signed cert,
> authenticated by means other than the cert, or the proxy to route specific
> hostname to TLS with a self-signed cert hosted by the proxy itself.
>
I follow simple security rules in SNIF design which I believe are
> reasonable - the control connection MUST present a valid certificate that
> matches the hostname, and the service connection MUST be TLS with the same
> certificate. According to these rules, plain HTTP is out, self-signed cert
> is out, relayed DNS would involve some new protocol layer.
>

Yes but my point is that these rules are to some extent arbitrary and they
result in a lot of complexity in the rest of the system. And if you relax
them, then you are left with a simple proxy system that seems to have
roughly the same security properties. So I think you need a stronger
argument than that these rules are reasonable. Rather, you need to argue
that they produce a better system, which I don't see you doing here. The
only real benefit I see you list is:

> As an additional benefit of such design, the proxy may switch between
CAs, or use any applicable protocols, whether ACME or something else,
without any modification to the SNIF connector on the device.

It's not clear to me that this is an advantage. It seems to me one could
just as easily argue it was a disadvantage because it makes it impossible
for the device to select its own CA and ACME methods.



> >>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.
> >>
> >> ALPN involves communications to the target hostname using a self-signed
> >> certificate. SNIF relay is designed to not allow any self-signed, or
> >> otherwise not publicly trusted, certificates, it makes security audit a
> >> whole lot easier. Therefore, a trusted certificate needs to be
> negotiated
> >> through the CA proxy (or by other means) before being able to accept any
> >> relayed connections to the hostname.
> >>
> >
> >I understand that this is part of your design, but I don't see that it
> >provides much security value. Because the proxy assigns the hostnames, it
> >already knows which IoT device is associated with which hostname, so it
> can
> >use that information directly without having to examine the server's
> >certificate. Regardless, you could use the HTTP ACME Challenge without
> >allowing self-signed certs.
>
> Yes, the proxy knows the hostname. But it doesn't have the private key,
> thus cannot use the cert. And if it issues a duplicate cert - it's
> auditable through the transparency logs (more on it later).
> As for the proxy knowing the identity of the IoT device - it depends on
> how the initUrl and the cert issue authorization are implemented, I left it
> to the liberty of the implementor in the draft.


I think perhaps you're misunderstanding me. As far as I can tell, there are
only two reasons for the proxy to look at the data coming to it at all:

1. To route to the right device via the SNI
2. To authenticate that the device it is routing to is the correct one
authorized for that name (and hence associated with the SNI).

My point is that (2) can be just as handily done by having the device
authenticate to the proxy via some non-certificate mechanism: the proxy
doesn't need to authenticate the device via the WebPKI because it knows a
priori which device has which name. The consequence of that change is that
the proxy need not do any TLS cert validation and can simply switch on SNI
without looking at the rest of the handshake.


>>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.
> >>
> >> The reason I use a separate TCP socket for each connection is to
> simplify
> >> the implementation of SNIF connector in conjunction with a server
> process
> >> on the IoT device. Using snif-srv, the connector opens a TCP socket,
> sends
> >> a SNIF ACCEPT message in plain text, and immediately hands the socket
> off
> >> to the process which will start TLS negotiation as a server peer, just
> like
> >> a regular server would do after accepting the socket. It's possible to
> >> design the control and multiple service connections to be multiplexed
> over
> >> QUIC, and use a software demux, and possibly fifos, on the connector
> side
> >> to interact with the server processes, but I believe separate TCPs is a
> >> cleaner answer in a resource constrained IoT environment.
> >>
> >
> >Hmm... It's not clear to me why you think that this uses fewer resources.
> >Can you explain why you think that?
>
> Sure. TCP has been around for ~50 years, is implemented in every modern
> OS, has been tested, refined and optimized for decades.
> QUIC, on the other side, is still one foot in a petri dish. No disrespect
> here, but a TCP socket is a standard OS call while QUIC needs libraries to
> be supported, and either more libraries to route it to a socket/fd like
> fifos, or more libraries to handle the stream outside of a normal socket by
> a server process. I believe it makes sense to stick with a lightweight and
> reliable solution. The benefit of QUIC that I see is less stress on a NAT
> router, but multiple TCP sockets work just fine in the wild, I've been
> testing SNIF for months now.
>

I would make two points here:

1. MASQUE is specified to work over H2, not just QUIC. H2 is very widely
used, so I don't think there's much concern about stability.
2. The Internet is a complicated place and just because you are not seeing
issues in your environment does not mean that there will not be issues in
others.



> >2. It means you can't have two keys for the same server name, so (for
> >instance) you can't easily change from RSA to ECDSA.
>
> If you want to experiment with algorithms - hard reset the device to rekey
> it. I believe makes sense. And, a combo RSA+EC is always an option.
>

This is inconsistent with essentially all modern TLS practice for upgrading,
which is to have the server able to run multiple algorithm profiles and
have the client and server negotiate an acceptable intersection. That
seems like a big regression to take, and will create real interop issues
during periods of transition, for instance, when some clients only
support A and some support A+B.

I'm not sure what you mean by "combo RSA + EC". It's true that you
can run RSA with EC key establishment, but what I'm talking about is
having both an RSA and an EC certificate. To the best of my knowledge
it is not possible to get a WebPKI certificate with both algorithms and it's
very unclear what the semantics of such a certificate would be.

I'm going to stop here because I don't think the rest of this is that useful
to try to nail down at this time.

-Ekr