Subject: comments on draft-rosenberg-sipping-spam-00.txt

From: Andrew Newton <[email-masked]>
Date: Wed, 14 Jul 2004 21:51:53 -0400

It would appear that participants of the SIPPING working group have a 
different opinion on the utility of TLS than do participants of the 
MARID working group.

 From Section 3.11 of draft-rosenberg-sipping-spam-00:

> 3.11  Sender Checks
>
>    In email, there has been a lot of interest in defining new DNS
>    resource records that will allow a domain that receives a message to
>    verify that the sender is a valid MTA for the sending domain.
>    Standards are now being developed for this within the MARID working
>    group in the IETF [14].
>
>    Are these techniques useful for SIP? They can be used for SIP but 
> are
>    not necessary.  In email, there are no standards established for
>    securely identifying the identity of the sending domain of a 
> message.
>    In SIP, however, TLS with mutual authentication can be used
>    inter-domain.  A provider receiving a message can then reject any
>    message coming from a domain that does not match the asserted
>    identity of the sender of the message.  Such a policy only works in
>    the "trapezoid" model of SIP, whereby there are only two domains in
>    any call - the sending domain, which is where the originator 
> resides,
>    and the receiving domain.
>
>    Thus, instead of creating DNS entries containing the IP address of
>    each legitimate relay for a domain, the provider can give each
>    legitimate relay a certificate that allows them to authenticate
>    themselves as coming from that domain.  Such a technique would work
>    even in the face of IP address spoofing, which the marid techniques
>    are susceptible to.

 From a thread on the MARID list: 
http://www.imc.org/ietf-mxcomp/mail-archive/msg02466.html
(not to be picking on Roy... others expressed similar feelings)

> I question that peer authentication is commonplace (although I don't
> doubt that it happens every day).  I get the impression most people
> use self-signed certs with STARTTLS.

STARTTLS for ESMTP has been around for some time.  In fact, it is not 
uncommon for my mail streams to be encrypted via TLS (such as my 
message exchanges with the MARID mailing list MTA) but have neither the 
server nor the client use TLS for authentication.

-andy

---

From: Dave Crocker <[email-masked]>
Date: Thu, 15 Jul 2004 21:42:29 +0800

Andrew,

>>    themselves as coming from that domain.  Such a technique would work

 no said that public-key based client authentication was not possible.

 it is a perfectly reasonable idea.
 
 they said that it has not established any significant track record of use.

 blithely relying on a public key infrastructure ignores approximately
 15 years of failure to get one deployed and used on any large scale.
 
d/
--
 Dave Crocker <mailto:[email-masked]>
 Brandenburg InternetWorking <http://www.brandenburg.com>
 Sunnyvale, CA  USA <tel:+1.408.246.8253>, <fax:+1.866.358.5301>

---

From: Tony Finch <[email-masked]>
Date: Thu, 15 Jul 2004 14:56:42 +0100

>  they said that it has not established any significant track record of use.

There are also significant interoperability problems if the server asks
the client for a certificate and the client doesn't have one.

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
FORTIES CROMARTY FORTH: WESTERLY OR SOUTHWESTERLY, BECOMING VARIABLE IN NORTH
FOR A TIME, 3 OR 4. SHOWERS IN NORTH. GOOD.

---

From: [email-masked] (Edwin Aoki)
Date: Thu, 15 Jul 2004 21:10:21 -0700

By my read, Jonathan isn't referring to the client to server interaction 
here; he's referring to the two proxy servers in the SIP trapezoid model:

            SIP Proxy A  <--TLS-->  SIP Proxy B
                /                       \
               /                         \
          Client A                     Client B
 
In this model, clients talk to their  home server (analogous to a 
submission server), which would use its certificate to authenticate 
itself to the destination server.  Depending on trust and deployment 
scenarios, Client A may also use TLS to communicate with SIP Proxy A, 
but it's an independent decision, so the client-server mismatch isn't 
really an issue.  Of course, SIP also has provisions for encrypting of 
its message bodies (using S/MIME) for end-to-end security.

This all works for SIP, because, among other things, it does not have 
the problem of transparent forwarders, of greeting card companies, or 
the legacy of years of deployed systems, so its approach to the problem 
can be a little cleaner.

-Edwin

---

From: Dave Crocker <[email-masked]>
Date: Sat, 17 Jul 2004 07:57:13 -0700

Edwin,

EA> In this model, clients talk to their  home server (analogous to a submission server), which would use its certificate to authenticate itself to the destination server.  Depending on trust and
EA> deployment scenarios, Client A may also use TLS to communicate with SIP Proxy A, but it's an independent decision, so the client-server mismatch isn't really an issue.  Of course, SIP also has
EA> provisions for encrypting of its message bodies (using S/MIME) for end-to-end security.

EA> This all works for SIP, because, among other things, it does not have the problem of transparent forwarders, of greeting card companies, or the legacy of years of deployed systems, so its
EA> approach to the problem can be a little cleaner.

This requires that random proxies be able to authenticate each other,
without prior arrangement.

So far, that scenario has not scaled well on the net, at least due to
the lack of a global PKI. We have pretty good 'server' authentication to
the client but essentially no client authentication to the server,
without prior arrangement.

d/