Subject: CSV and STARTTLS

From: Andrew Newton <[email-masked]>
Date: Wed, 30 Jun 2004 17:25:06 -0400

From section B.4.1 of draft-marid-csv-intro:

> B.4.1  StartTLS
>
>    A common certificate method as used with StartTLS [RFC3207] can
>    authenticate an unknown server after an investment in signed 
> periodic
>    digital certificates, encryption capabilities, and services of a
>    Certificate Authority.  This investment creates a barrier for
>    large-scale use over the open Internet.  Reliance on the certificate
>    signature also adds a need to vet Certificate Authorities in 
> addition
>    to the confirmed domains.
>
>    Spontaneous communications are at the core of Internet design and
>    operation.  So omission of a Certificate Authority is typically
>    allowed of clients.  When this is allowed, StartTLS loses any 
> ability
>    to authenticate the relationship of the client to its claimed domain
>    name

Does this imply that the strong authentication provided by certificate 
validation of TLS is to be subjugated by CSV, which is most likely to 
be weaker authentication?

Also, I think many security-minded folks may disagree with the 
characterization in the first paragraph.  Opportunistic encryption with 
peer authentication using TLS happens every day on the Internet.

-andy

---

From: Douglas Otis <[email-masked]>
Date: Wed, 30 Jun 2004 14:59:44 -0700

On Wed, 2004-06-30 at 14:25, Andrew Newton wrote:
> >  periodic digital certificates, encryption capabilities, and
> >  services of a Certificate Authority.  This investment creates a
> >  barrier for large-scale use over the open Internet.  Reliance on
> >  the certificate signature also adds a need to vet Certificate
> >  Authorities in addition to the confirmed domains.
> >
> >  ability to authenticate the relationship of the client to its
> >  claimed domain name
> 

I do not speak for the other authors, but there was a discussion
involving this issue that Dave Crocker had been addressing.  It is my
understanding this needs to change to reflect StartTLS is stronger but
defines a different namespace which is why Dave indicates it does not
authenticate the HELO domain.  He was working on the wording for this. 
The accreditation may need to compose something like
cert-name._ca.cert-auth.accredit.com to recognize this differing
namespace for StartTLS.

-Doug

---

From: John Levine <[email-masked]>
Date: 30 Jun 2004 22:26:43 -0000

>> B.4.1  StartTLS ...

>be weaker authentication?

I think you're misreading it.  They're saying that in practice people
don't use signed SSL certs to validate the other end of an SMTP
connection.  Looking at the logs of my mail servers, I see plenty of
TLS connections, but more often than not the certs are self-signed,
and in a lot of cases they just use a default cert shipped with the
MTA.  If people were going to use TLS certs to authenticate their
mail channels, they'd be doing so already, but they're not.

Opportunistic encryption is fine, but I don't see that as relating
to CSV one way or the other.  If you want to do CSV checks and then
STARTTLS, you can easily do so.

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Information Superhighwayman wanna-be, http://www.johnlevine.com, Mayor
"I shook hands with Senators Dole and Inouye," said Tom, disarmingly.

---

From: Roy Badami <[email-masked]>
Date: Wed, 30 Jun 2004 23:52:25 +0100

>>>>> "Andrew" == Andrew Newton <[email-masked]> writes:

    Andrew> Opportunistic encryption with peer authentication using
    Andrew> TLS happens every day on the Internet.

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.

    -roy

---

From: "Hector Santos" <[email-masked]>
Date: Wed, 30 Jun 2004 20:24:16 -0400

----- Original Message ----- 
From: "John Levine" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, June 30, 2004 6:26 PM
Subject: Re: CSV and STARTTLS

> mail channels, they'd be doing so already, but they're not.

Good point. We implemented outbound SSL/TLS but it is rare for us to hear or
know if anyone is really using it.  I would be interested to know your
thoughts as to why "they are not."

The only possible reason I can think of is because it usually means
exclusive arrangements which is already done with IP Relays tables or SMTP
AUTH accounts.   Any TLS security advantage is not guarantee between
multi-hop routes.

> STARTTLS, you can easily do so.

hmmm, the way I see it is probably makes sense after TLS (and possible SMTP
AUTH) is established.  Here is me reasoning:

From RFC 2847:

5.2 Result of the STARTTLS Command

   Upon completion of the TLS handshake, the SMTP protocol is reset to
   the initial state (the state in SMTP after a server issues a 220
   service ready greeting). The server MUST discard any knowledge
   obtained from the client, such as the argument to the EHLO command,
   which was not obtained from the TLS negotiation itself. The client
   MUST discard any knowledge obtained from the server, such as the list
   of SMTP service extensions, which was not obtained from the TLS
   negotiation itself. The client SHOULD send an EHLO command as the
   first command after a successful TLS negotiation.

This could suggest TLS trumps CVS or CVS trump/alter the SASL/TLS standard
behavior.

A server can offers SASL/TLS which the client may use if offered.   When the
client issues its EHLO domain, could the server CVS logic be activated in
such a way to turn off SASL or TLS EHLO response extensions display?

For example:

Client - SASL, TLS compliant, may or may not be CVS compliant
Server - SASL, TLS, CVS compliant

Client connects to server::

   S: 220 mail.example.org SMTP service ready
   C: EHLO mail.john.org

CVS activated. You have two scenarios.

#1 Client is non CVS compliant and the normal SMTP extension exposes TLS
and possible AUTH and other MARID features.

   S: 250-mail.example.org welcomes you
   S: 250-SIZE
   S: 250-SUBMITTER
   S: 250-AUTH LOGIN [plus other SASL methods. using LOGIN for simplicity]
   S: 250 STARTTLS

#2 Client is CVS compliant.  What will be the response?

   S: 250-mail.example.org welcomes you
   S: 250 SIZE

What you are saying that CVS should not change the response?  Right?

Ok, I can see that and it makes sense for scenario #2 we have:

#2 Client is CVS compliant.  Normal SMTP extension response.

   S: 250-mail.example.org welcomes you
   S: 250-SIZE
   S: 250-SUBMITTER
   S: 250-AUTH LOGIN
   S: 250 STARTTLS

However, the problem (design conflicts) I see  is more overhead and whether
there is a need for any more validation.  If the client CVS is compliant and
is accepted, do we need anything else?

My plan for implementation, as it has been for all the LMAP (now MARID) is
to delay all validation overhead until it is 100% absolutely necessary.

Lets go thru this and lets assume that we continue displaying the SMTP
extensions after a successful CVS validation has taken place.

Scenario 2.1:  Client continues with a TLS and fails.

Seems easy enough, the transaction doesn't continue.

Scenario 2.2:  Client continues with a TLS and succeeds

In this case, the client per RFC 2847 reissues the EHLO

   C: STARTTLS
   S: 220 Go ahead
   C & S: <negotiate a successful TLS session>
   C: EHLO mail.john.org

So what I see here for a CVS server, it needs to turn off CVS validation at
this point and offer a new set SMTP extension responses:

   S: 250-mail.example.org welcomes you again!
   S: 250-SIZE
   S: 250-SUBMITTER
   S: 250 AUTH LOGIN

The new implementation question here is whether SUBMITTER and/or AUTH LOGIN
are still required.

I have no trouble removing SUBMITTER (Badly quoting Dorothy Parker: "Don't
throw it away. Throw it away with full force!").

But with SMTP AUTH we now begin to get new design issues and conflicts of
whether AUTH is required.

This will change quite a few things because the traditional SMTP mode of
operation is that trusted transaction using SMTP AUTH or IP relay tables
allows for routing, and to allow routing, well, that means "trust!"

So to keep with tradition, compatibility,  reduce overhead and most
importantly sysop expectations for operations intact with all their roaming
users, we have no choice but to implement a delayed CVS processing after TLS
is applied and the establishment of any SASL negotiation as well.

In short:

I don't think CVS will directly change TLS but it will change how the SMTP
extensions are altered.   Will CVS trump SMTP AUTH?  It may if its applied
before the TLS process.

Make sense?

Thanks

-- 
Hector Santos, Santronics Software, Inc.
http://www.santronics.com

---

From: Andrew Newton <[email-masked]>
Date: Wed, 30 Jun 2004 21:56:28 -0400

> AUTH accounts.   Any TLS security advantage is not guarantee between

Not that I disagree with this observation, but couldn't it also apply 
to CSV since it is doing the same thing?

Or in other words, if it isn't worth it to authenticate via TLS because 
SMTP is a hop-by-hop protocol, why is CSV authentication more 
compelling?

-andy

---

From: John Levine <[email-masked]>
Date: 1 Jul 2004 02:03:59 -0000

>use self-signed certs with STARTTLS.

I looked at a bunch of the certs that my MTA met while sending mail
today.  I'd estimate that about half of them were signed by one of the
commercial signers familiar from web SSL certs, and the other half
were self-signed.

It seems unlikely to me that there's any widescale authentication
going on, since the unsigned half would all fail, and I can report
that I don't think I've ever seen a remote MTA reject my certs which
are only signed by my own local CA whose cert is only known to
machines on my network.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
http://www.taugh.com

---

From: Claus Assmann <[email-masked]>
Date: Wed, 30 Jun 2004 20:03:52 -0700

> mail channels, they'd be doing so already, but they're not.

It's hard to do that with the hierarchical structure of X.509 unless
you are a commercial entity and you want to pay money a certain
company.... I exchange CA certs with some people (and enforce
authenticated mails) but it's a bit ugly to maintain.

There was a draft that described using the OpenPGP trust structure
("web of trust") which unfortunately didn't lead to an implementation.