Re: [certid] [xmpp] Fwd: Fwd: I-D Action:draft-saintandre-tls-server-id-check-10.txt

[Peter Saint-Andre <[e-mail]>]

On 11/1/10 5:27 AM, Philipp Hancke wrote:
> Peter Saint-Andre wrote:
> [...]
>> Oops, there were some typos and missing words. That's what I get for
>> replying to email while eating breakfast at 6 AM. Corrected text:
>>
>> ###
>>
>>     Note:  In some application protocols, the procedure described in
>>     this section can be performed by an application server acting as a
>>     TLS client when verifying a server-to-server connection, not only by
> 
> s/TLS client/TLS server/

In XMPP at least, if Romeo's personal server (montague.lit) attempts to
connect to Juliet's personal server (capulet.lit), he asserts to her
that he is montague.lit and she takes that as her reference identifier.
Thus her server is acting as a TLS client in relation to the presented
identifiers in the certificate that Romeo's personal server provides.
This is what's distinctive about the server-to-server case -- an
application service is acting as a TLS client.

>>     an application client when verifying a client-to-server connection
>>     (e.g, this is true of XMPP).  In this case, the application server
>>     verifies the identity of the peer server that is attempting to
>>     connect and therefore the reference identifier is in essence
>>     supplied by the peer server (e.g., as triggered by a request to send
>>     a message from an entity associated with the peer server to an
> 
> I think it is not clear who is verifying 

If you try to connect to me, I'm going to verify you -- even if I'm an
XMPP server.

> (probably because both parties
> are for xmpp-s2s). 

Yes, ideally the verification happens in both directions.

> What about:
> 
> In some application protocols, the procedure described in this section
> can also be performed by an application server when verifying a incoming
> [server-to-server?] connection from a peer, not only when verifying an
> outgoing connection (e.g., this is true for XMPP).
> In this case, the application server, acting as a TLS server, verifies
> the identity of the TLS client and the reference identifier is in
> essence supplied by the peer [...]
> 
> [where the peer server is the TLS client]

I think the peer server is the TLS server and the application service is
the TLS client.

>>     entity associated with the application service).  Other than the
>>     source of the reference identifier and the inverted roles of the TLS
>>     client and TLS server, the verification process remains unchanged.
> 
> +1

I suggest the following modified text:

      Note: In some application protocols (e.g., XMPP), the procedure
      described in this section can be performed by an application
      server acting as a TLS client when verifying an incoming server-
      to-server connection, not only by an application client acting as
      a TLS client when verifying the server with which it is
      interacting to establish an outgoing client-to-server connection.
      In this case, the application server verifies the identity of the
      peer server that is attempting to connect and uses as its
      reference identifier the DNS domain name asserted by the peer
      server (e.g., as triggered by a request to send a message from an
      entity associated with the peer server to an entity associated
      with the application service).  Other than the source of the
      reference identifier and the fact that an application service is
      acting as a TLS client, the verification process remains
      unchanged.

/psa