On Mon, Sep 27, 2021 at 03:52:44PM +0000, Salz, Rich wrote:
> John Mattson had pointed out that the document uses client and server,
> when in fact if you use mutual auth or machine-to-machine, that’s not
> really correct.
The client and server roles in TLS are well defined and independent of
any roles the peers might have at the application layer. Nothing
fundamentally changes even with "mutual TLS", because there is still
a significant asymmetry in what the client and server learn at the
conclusion of the handshake.
* It is the client's job to ensure that the connection was made
to the intended peer. The client uses the server certificate
to ensure end-to-end channel integrity.
* In almost all cases, where the server serves multiple clients,
and has no prior expectation of connection from any particular
client, the client's certificate is optional, and is used to
establish a client identity for *authorisation*.
If the client failed to check the server's certificates properly,
there's nothing the legitimate server can do to protect it when it
fails to detect that is talking to a rogue server.
When the client is authenticated, the legitimate server can have
some confidence that the channel is currently encrypted end to
end, and that the authorised actions may proceed safely.
> Peter st Andre explained that it’s the terms used in TLS.
Indeed, and for good reason, the client and server roles are not
symmetric.
> I just merged a PR that addresses some of this, but not all. John and
> others interested in this issue, should look at the new draft when
> published next week.
I'll try to take a look. Which PR number?
--
Viktor.
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
