Subject: msgtrk: MTQP, TLS, & SRV

From: Lawrence Greenfield <[email-masked]>
Date: Fri, 8 Feb 2002 15:42:40 -0500

There is currently a discussion going on in LDAPEXT about STARTTLS and
the interaction with SRV records that is probably of interest to MTQP.

I note that MTQP uses SRV records (or MX records) to find which host
to connect to, but I don't see any text on what name to expect once it
gets there.  This should probably be clarified.

It might also be nice to point out that, on multi-homed MTQP servers,
use of SRV records with the port specification can get around not
knowing what certificate to hand back.

Another possibility would be to add a "certificate expected" argument
to the STARTTLS command, allowing the server to choose which
certificate to return.  I believe there was discussion of this in a
working group meeting, but I don't recall what the outcome of it was.

Larry

---

From: Lawrence Greenfield <[email-masked]>
Date: Fri, 8 Feb 2002 15:55:21 -0500

Date: Fri, 8 Feb 2002 12:53:27 -0800
   From: Gregory Neil Shapiro <[email-masked]>
[...]
   When this was discussed for updating RFC 2487, the decision was to leave
   that to the TLS working group.  As I recall, it was then brought up in that
   working group and it was agreed it should be part of the TLS client hello
   protocol.

Yeah, they've been arguing about it for quite some time over there and
I've mostly lost interest in following it, especially when their
listserver bounced my message and then bounced my annoyed reply to
their bounce.

   Personally, I'd rather see this solved in the underlying protocol then have
   each application protocol fix it independently (and differently).

Regardless, MTQP needs to specify what certificate name needs to be
sent.

Larry

---

From: Gregory Neil Shapiro <[email-masked]>
Date: Fri, 8 Feb 2002 13:00:17 -0800

> each application protocol fix it independently (and differently).

leg+> Regardless, MTQP needs to specify what certificate name needs to be
leg+> sent.

Why "regardless"?  If it is solved in the TLS protocol, why duplicate it in
the MTQP protocol?  Or are you assuming it will never be solved by the TLS
protocol?

---

From: Lawrence Greenfield <[email-masked]>
Date: Fri, 8 Feb 2002 16:03:46 -0500

Date: Fri, 8 Feb 2002 13:00:17 -0800
   From: Gregory Neil Shapiro <[email-masked]>
   Cc: [email-masked], Tony Hansen <[email-masked]>

The multi-homed server problem can be solved in the TLS protocol.
What name the client expects cannot.

I do a SRV look on _mtqp._tcp.smtp3.example.com and get back
msgtrk.example.com, port 4530.  I connect to msgtrk.example.com 4530,
and issue STARTTLS.

What certificate name should I expect?  (In a future TLS protocol,
what certificate name should I request?)

"smtp3.example.com" might not be a great choice: that certificate name
may already be in use on a different machine.  "msgtrk.example.com" is
definitely wrong---I received it from the insecure DNS system.

"_mtqp._tcp.smtp3.example.com" makes some sense but is kinda ugly.

You can see the LDAP SRV discussion on ldapext for more on this.

Larry

---

From: Gregory Neil Shapiro <[email-masked]>
Date: Fri, 8 Feb 2002 12:53:27 -0800

leg+> Another possibility would be to add a "certificate expected" argument
leg+> to the STARTTLS command, allowing the server to choose which
leg+> certificate to return.  I believe there was discussion of this in a
leg+> working group meeting, but I don't recall what the outcome of it was.

---

From: Keith Moore <[email-masked]>
Date: Fri, 08 Feb 2002 19:39:56 -0500

> may already be in use on a different machine. 

is that really a problem?  can't there be different keys (on different
machines) for a single principal?

---

From: Lawrence Greenfield <[email-masked]>
Date: Fri, 8 Feb 2002 22:26:46 -0500

From: Keith Moore <[email-masked]>
   cc: Gregory Neil Shapiro <[email-masked]>, Tony Hansen <[email-masked]>,
      [email-masked]
   Date: Fri, 08 Feb 2002 19:39:56 -0500

If the two machines are under identical adminstrative control
(probably an ok assumption for msgtrk) and if compromising one machine
is acceptable for impersonating the other, this is ok.

Larry