Subject: Re: CSV and STARTTLS

From: Tony Finch <[email-masked]>
Date: Thu, 1 Jul 2004 12:32:51 +0100

On Wed, 30 Jun 2004, Douglas Otis wrote:
>
> 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.

Is this related to the distinction between service names and host names?

For example, our MX records refer to mx.cam.ac.uk which is a service name
which in turn refers to a number of hosts whose canonical host names (and
EHLO greetings) are of the form XXXX.csi.cam.ac.uk. If we were to turn on
opportunistic encryption for general SMTP with full certificate
verification, we would have to obtain a server certificate for
mx.cam.ac.uk for incoming email, and client certifcates for each of the
XXXX names for outgoing email.

I'm not sure if the behaviour of MTAs is sensible if they try to negotiate
TLS but fail at the certificate verification stage. I'm not sure I know
what sensible behaviour would be!

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
SELSEY BILL TO LYME REGIS: WEST 5 BACKING SOUTHWEST, PERHAPS INCREASING
LOCALLY 6, LATER VEERING WEST 5 LOCALLY 6. SCATTERED SHOWERS WITH RAIN FOR A
TIME. GOOD DECREASING OCCASIONALLY MODERATE OR POOR IN RAIN. MODERATE BUILDING
ROUGH.

---

From: Dave Crocker <[email-masked]>
Date: Thu, 1 Jul 2004 21:17:47 +0800

Andrew,

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

Your question is so confusing to me that I don't care whether of the
other responses guess your meaning correctly.

Since I believe that there is nothing in the CSV text that affects the
nature of TLS, nevermind "subjugating" it, I would appreciate your
clarifying your question thoroughly.  Honest, I cannot comprehend how
you arrived at such a question or what, exactly, it really means.

AN> Also, I think many security-minded folks may disagree with the 
AN> characterization in the first paragraph.  Opportunistic encryption with

encryption is not the same as authentication, and server
authentication is not the same as client authentication.

does our spec need to include a short tutorial on the difference?

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: Dave Crocker <[email-masked]>
Date: Thu, 1 Jul 2004 21:22:21 +0800

Douglas,

DO> I do not speak for the other authors, but there was a discussion
DO> involving this issue that Dave Crocker had been addressing.  It is my
DO> understanding this needs to change to reflect StartTLS is stronger but
DO> defines a different namespace which is why Dave indicates it does not
DO> authenticate the HELO domain.

So far, I do not see how that issue relates to Andrew's question.  I
can imagine all sorts of possibilities, but would rather not guess.

Since Doug raised the issue, but separate from Andrew's question (and,
hence, the different subject line), the discussion of multiple host
authentication techniques produced a basic hole, with the possibility
that the authenticated identity could be different from the one
asserted in HELO.  This is a dangerous hole, indeed.

The resolution is to use whatever domain is associated with the
authentication, rather than the one in the HELO.

And, yes, I do owe my co-authors some text.  I'll take a break from
the beach, tomorrow, and see about writing it.

d/

---

From: Andrew Newton <[email-masked]>
Date: Thu, 1 Jul 2004 09:40:52 -0400

From your draft:

> When this is allowed, StartTLS loses any ability
>    to authenticate the relationship of the client to its claimed domain
>    name.

-andy

---

From: Tony Finch <[email-masked]>
Date: Thu, 1 Jul 2004 15:10:39 +0100

> authentication, rather than the one in the HELO.

I think I've already noted that SASL is usually used to authenticate a
user name not a host name, so the potential for confusion and inadvertent
spelunking is high.

This is aside from the problems that it doesn't fulfill the requirement
for avoiding prior arrangement stated in section 2.2 of the CSV doc, and
that its organizational complexity is the square of the number of MTAs.
The cost of TLS with trusted third parties is linear in both dollars and
complexity. DNS-based authentication is free and scales linearly, and is
extremely efficient in conjunction with CSA.

(The above reasoning is why I think the CSV spec should not be over-
complicated with consideration of multiple authentication methods because
the alternatives are all substantially worse than using the DNS.)

When the client states its identity multiple times should all of the
statements agree? Should the server reject the client if they do not?
These questions almost go away if TLS and SASL authentication are no
longer considered relevant to CSV. However there should probably be some
comment in the CSA specification about what the server does when the
client says EHLO more than once.

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
ST DAVIDS HEAD TO COLWYN BAY, INCLUDING ST GEORGES CHANNEL: WEST 4 OR 5
BACKING SOUTHWEST AND INCREASING 5 OR 6. SCATTERED SHOWERS BECOMING MORE
FREQUENT LATER. GOOD DECREASING MODERATE AT TIMES IN SHOWERS. MODERATE
BUILDING LOCALLY ROUGH.

---

From: Douglas Otis <[email-masked]>
Date: Thu, 01 Jul 2004 13:33:28 -0700

> user name not a host name, so the potential for confusion and inadvertent

This is covered in Dave's CSV draft, but as SASL is useful only within a
Closed system, perhaps a statement that both authentication and
authorization are presumed of a holder of secret information, used to
authenticate, where the relevant accreditation namespace is dependent
upon the Open method used.  This would presume a Closed method would not
require accreditation. 

> statements agree?

No. Not as currently defined by RFC3207.

REF3207 states:

: 4.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.

It should be assumed the HELO/EHLO domain may not be indicative of the
HELO/EHLO once privacy is established.  This may mean that if StartTLS
is in progress, not to act upon the HELO until the TLS process
completes.  There are never two valid HELO domains of which to choose. 
The specification clearly states to discard previous results.

Caveat:
If it is felt StartTLS is not useful in this role of authenticating and
authorizing with a public server, then requiring the initial HELO/EHLO
domain to be valid (or perhaps understood as a site defined pass
phrase), then exposures would be reduced as there would be no need to
wait for TLS.  The TLS session HELO/EHLO domain would be unimportant if
the client was validated by a Certificate Authority and thereby
recognized.  If not, then the TLS session HELO domain should match.

> Should the server reject the client if they do not?

No. Discard the first as currently defined.

> longer considered relevant to CSV.

SASL is a closed mechanism, with the exception made by RFC2245, stronger
than CSV, except for the exception made by RFC2245.  

TLS _may_ become an open mechanism, albeit expensive to use.   

> However there should probably be some comment in the CSA specification
> about what the server does when the client says EHLO more than once.

I feel this is not needed as it is covered in RFC3207.  I would also
like to limit the topic of TLS to a single document... Dave's of course.
: )

-Doug

---

From: "Hector Santos" <[email-masked]>
Date: Thu, 1 Jul 2004 20:07:12 -0400

----- Original Message ----- 
From: "Douglas Otis" <[email-masked]>
To: "Tony Finch" <[email-masked]>
Cc: "Andrew Newton" <[email-masked]>; "MARID WG" <[email-masked]>
Sent: Thursday, July 01, 2004 4:33 PM
Subject: Re: CSV and alternative authentication techniques

> upon the Open method used.  This would presume a Closed method would not

I believe "closed" is the wrong term to use here as it implies everyone must
be authenticated as it usually is in a "closed system."

SASL extremely useful for an OPEN system.  It offers a system with an User
Database a way to authenticate users based on user name/id and password
pretty much for the sole purpose of allowing "routing."   I mean, what other
access priveledge can a SMTP server offer other than final destination vs
routing mail?

In my opinion, I don't think CSV should stay clear, far away from trying to
alter or change the usefulness of SASL.  Many operators depend on it and
have put many support hours getting they users setup for it - for one reason
only - to allow their users to route.

Anyway, I see this as an implementation issue, because from what I see, if I
were to put this in today, I could only do so after SASL is established or
not.   If so,  CVS is skipped.  If not, then the delayed CVS logic is
started.

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

---

From: "Hector Santos" <[email-masked]>
Date: Thu, 1 Jul 2004 22:35:16 -0400

Dave,   I am honestly trying to keep focus with addressing CVS to see how we
can make it work for our package.  If it was something we can test today,
it would be done.  Feedback is the only way I can see if I understand it
all.

1)  I don't see how TLS applies.  I don't think it is even relevant.  TLS
protects (addressed) secured transmission.  I believe you documented TLS is
not useful or reliable. Here.

2) I do see a conflict with SASL (ESMTP AUTH).  I think for maximum
compatibility CVS *may* best apply until SASL is known (established or not)
by the client.

3) How do I best merge or not, a bad reputation status against a CVS
certified status?

Please confirm, correct me or fill me on the about.

#2 and #3 are related. Here's how:

I have 20,000 user accounts.   To route mail, they have to use SASL.

We have not received any complaints of any of our users abusing others (and
don't
expect it from the professional group), but if we did, what does that mean?

Can CVS help?

I add a CVS record and I registered with MAPS new CVS compliant
"Accreditation" service.

This will not stop the abuse of any specific individual user.

Am I to believe that I need to make sure all our users are CVS ready too?

Even so, it seems to me that I am still stuck of directly addressing user
abuse issues on a personal basis.

Also, another system may be using RBL and quite maybe CVS.  They see we have
abusive users and even with our CVS certification,  they decided to use RBL
to block us.

Or, is this now a administrative policy issue where a complaint is sent to
accreditation agent to get my status remove or suspended?

These are real possible issues and scenarios.

thanks

---

From: John Leslie <[email-masked]>
Date: Thu, 1 Jul 2004 22:35:32 -0400

Andrew Newton <[email-masked]> wrote:
> 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.

   This (IMHO) intends to say that StartTLS can offer strong authentication,
but it comes at the expense of a lot of certificate-related baggage.

>>   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
>>   name

   This intends to say that, in order to allow communication between
MTAs lacking any prior relationship, StartTLS is implemented with a
critical piece of that baggage removed. It goes on to warn that, with
this critical piece of baggage removed, StartTLS is no longer able to
authenticate the relationship claimed to the EHLO 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?

   That certainly was not intended. StartTLS, even in its weakend form,
is still useful for its intended purpose: it's just not useful as a
means of authenticating the EHLO name.

> 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.

   You've lost me, Andy. I can only guess that you interpreted "creates
a barrier" to mean that the expense of the investment "creates" an
"insurmountable barrier", which strikes me as an unlikely parsing, even
with the following paragraph amputated. Given the paragraph which follows,
it seems clear to me that "omission of a Certificate Authority" is a
common method of surmounting the barrier.

   Or did you mean something else?

--
John Leslie <[email-masked]>

---

From: Tony Finch <[email-masked]>
Date: Fri, 2 Jul 2004 11:32:00 +0100

On Thu, 1 Jul 2004, Douglas Otis wrote:
>
> There are never two valid HELO domains of which to choose. The
> specification [RFC 3207] clearly states to discard previous results.

OK.

> The TLS session HELO/EHLO domain would be unimportant if

This isn't covered by RFC 3207 so needs to be explained by HNA.

> like to limit the topic of TLS to a single document... Dave's of course.

Note that a client can say EHLO more than once in a non-TLS SMTP session.
Should the server only use the most recent one for CSV, or the first one?
(Using the first one is probably contrary to RFC 2821.) Do they have to be
all the same?

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
GERMAN BIGHT HUMBER: SOUTHWEST 3 OR 4, OCCASIONALLY 5 LATER. THUNDERY SHOWERS.
MODERATE OR GOOD.

---

From: Andrew Newton <[email-masked]>
Date: Fri, 2 Jul 2004 06:40:36 -0400

> means of authenticating the EHLO name.

Ah.  This makes sense to be now.  Thanks.

-andy

---

From: Douglas Otis <[email-masked]>
Date: Fri, 02 Jul 2004 10:05:22 -0700

> (Using the first one is probably contrary to RFC 2821.) Do they have to be

You ask good questions.  There could be the fall-back of EHLO to HELO
and the use of EHLO to act as RSET.  As the intent of this domain in
each case (separate from the TSL issue) is to identify the client's host
name, I would not expect this to change.  However, there could be a
valid reason it may change.  To credit a portion of the mail stream to
"client-xxx.big-provider.com."  This may allow the receiver to accredit
different entities for the mail stream without requiring a new
connection.  Using EHLO would be expensive and is why RSET is used to
avoid this overhead.  Perhaps there should be a mention that if the
HELO/EHLO domain changes during a session, it should be re-evaluated.

-Doug

---

From: Dave Crocker <[email-masked]>
Date: Sat, 3 Jul 2004 11:58:05 +0800

Douglas,

My feeling is that CSV should simply say what to do with a HELO/EHLO
but not say anything about larger, SMTP state transitions.

That is:

     When the HELO contains a name, do CSV and apply the results to
     the session.

(I'd rather not explicitly say to do it again if there is another
HELO, since then we have to worry about interpretations of the SMTP
state machine. If the rule just says what I wrote, above, then it is
simple and rigorous and entirely covers the case of repeated HELO.)

d/