Subject: Re: [TLS] Security concerns around co-locating TLS and non-secure on same port (WGLC: draft-ietf-tsvwg-iana-ports-08)

From: Paul Hoffman <[email-masked]>
Date: Mon, 8 Nov 2010 17:07:42 +0800

At 6:46 PM +1300 11/8/10, Peter Gutmann wrote:
>I kinda missed this in the original, but I can't let it go unchallenged:
>
>> My summary of that comment is that STARTTLS for SMTP (RFC 3207) has
>> shown to have some security issues, be complexer to implement than using
>> two ports and thus less popular.
>
>What is this claim based on?

"some security issues": See the long Security Considerations section on RFC 3207.

"be complexer to implement than using two ports": See the state machine described in section 4 and its subsections in RFC 3207. That's much more complex than "OK, let's go".

"thus less popular": Developers would like fewer code paths and more failure states.

> About a year after the initial STARTTLS spec was
>published, I and a few other security geeks did some informal surveys of mail
>being processed at a couple of large sites and found that STARTTLS, after a
>year, was securing more mail than all other email encryption protocols
>combined, and that was a decade ago. 

"more than a bunch of slacker protocols" is a pretty low bar.

>(And going back to Paul Hoffman's
>original post, as the author of the world's most successful email encryption
>RFC I don't think he has anything to apologise about).

We disagree. :-)

>So, what research or figures is the above claim, that STARTTLS is less popular
>than using port 465, based on?

I don't think that is what Magnus said, but he can speak for himself. STARTTLS in POP and IMAP is much less popular than POP and IMAP on a second port for TLS.

--Paul Hoffman, Director
--VPN Consortium

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 08 Nov 2010 18:11:22 +0800

Peter Gutmann skrev 2010-11-08 13:46:
> What is this claim based on?  About a year after the initial STARTTLS spec was
> combined, and that was a decade ago.  (And going back to Paul Hoffman's

Sorry, for the confusion I made a mistake in summarization. Paul has
straighten this out.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------

---

From: Marsh Ray <[email-masked]>
Date: Mon, 08 Nov 2010 11:27:46 -0600

> "some security issues": See the long Security Considerations section

Hmmm, yes, the little matter of the downgrade attack.

"Other than that, Mrs. Lincoln, how did you like the play?" :-P

> "be complexer to implement than using two ports": See the state
> machine described in section 4 and its subsections in RFC 3207.
> That's much more complex than "OK, let's go".
>

It's a decision that ends up in the hands of the admin anyway. Admins 
are already maintaining the ACLs on their firewall.

What are the advantages of running different versions of a protocol 
(having radically different security properties) on the same vs. 
different TCP ports?

As I see it, running on different ports has some advantages:

* Developers don't have to implement and test protocol support for some 
negotiation scheme.

* Developers don't have to code support for configuration

* Admins don't have to learn more configuration, site security doesn't 
depend as much on the perfection of sendmail.cf.

* Admins can look at their firewall rules, use wireshark and 
telnet-level test tools to gain confidence that they have blocked off 
unencrypted traffic.

* Passive network monitoring tools can't observe a STARTTLS handshakes 
and conclude that there is not still a vulnerability to downgrade. 
Testing tools which can prove the absence of a STARTTLS downgrade 
vulnerability are likely to be complex and not fully conclusive (perhaps 
it could even depend on complex mail delivery rules).

Running on the same port has some advantages:

* It saves a port number allocation.

* It may be compatible with some existing firewall rules.

I think a secure-only port number is the superior solution for many 
reasons. The ability to reliably block insecure connections based on 
looking only at the TCP/IP header is a powerful thing.

>> About a year after the initial STARTTLS spec was published, I and a
>> few other security geeks did some informal surveys of mail being
>> processed at a couple of large sites and found that STARTTLS, after
>> a year, was securing more mail than all other email encryption
>> protocols combined, and that was a decade ago.

That's great. Did you test resistance to downgrade attacks?

Should we only be concerned with passive eavesdropping? If so, then 
consider how much higher adoption could have been if the specs had 
endorsed anon-anon DH connections such that there was no need for admins 
to set up certificates for their mail servers before deploying encryption.

>> So, what research or figures is the above claim, that STARTTLS is
>> less popular than using port 465, based on?
>
> STARTTLS in POP and IMAP is much less popular than POP and IMAP on a
> second port for TLS.

FWIW, Mozilla Thunderbird seems to try STARTTLS first. But their scheme 
is hardly a gold standard:  http://extendedsubset.com/?p=22

Security is obtained only when both endpoints refuse to exchange 
meaningful data (or engage in any forwardable authentication scheme) 
until a mutually authenticated and encrypted channel has been 
established. So IMHO, that should be the default configuration setting 
and the starting point for the discussion.

 From there we can negotiate downwards, but we should recognize that 
it's the game of "My data (and perhaps even my authentication 
credentials) hold little enough value that an attacker will probably not 
go to the trouble of an active attack. I hope."

- Marsh

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 8 Nov 2010 14:12:19 -0600

> "some security issues": See the long Security Considerations section on RFC 3207.

In-band (StartTLS) and out-of-band (separate ports) negotiation have
almost the same overall security considerations regarding downgrades.
One difference, for example: in the in-band case the client has to re-do
any other negotiations after starting TLS, if it did do any other
negotiations -- but this is easily avoided by doing no other
negotiations prior to starting TLS.  The fact that the former are
documented where the in-band negotiation protocol may be misleading some
to believe that the out-of-band negotiation is much safer than in-band.

> machine described in section 4 and its subsections in RFC 3207. That's
> much more complex than "OK, let's go".

This is true.  Specifically it complicates the task of making the
security layer transparent to the application.  But really, not _that_
much.  Most StartTLS protocols involve an in-band negotiation of whether
to start TLS, then a switch to raw TLS (as opposed to encapsulating TLS
records in the application protocol's message framing) followed by
continuing the application protocol over raw TLS -- not very
complicated, even for implementations that use external processes to
handle the TLS security layer.

> "thus less popular": Developers would like fewer code paths and more

Maybe the lack of popularity has more to do with StartTLS requiring a
smidgen more thought and design than raw TLS of port XYZ :)

OTOH, we've seen requests for StartTLS support in some applications
where the user preferred StartTLS.  So popularity is in the eye of the
beholder.  For example, more TCP ports -> more firewall rule complexity.
Yes, opening the regular port requires a leap of faith that StartTLS
will be used, but if the firewall admin can ensure that the servers
implement and require StartTLS, then fewer ports -> simpler.

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 8 Nov 2010 14:24:08 -0600

> Hmmm, yes, the little matter of the downgrade attack.

You have that with the out-of-band negotiation case too though.

1. Try the TLS port.

   Fail.

2. ???

   If you connect to the non-TLS port you've just been downgraded,
   possibly not on purpose.  Or maybe the client will then try StartTLS
   and give up if the server won't.

   If the client falls back on not using TLS at all then you have a
   problem.

Every IM and e-mail client I've used has the option to not require TLS.
That means they can be configured to fall back on not using TLS at all.
Worse, there's usually a checkbox for using TLS as opposed to a checkbox
for being insecure -- as a result, regardless of what the default is for
that checkbox the user is likely to check it off if they run into any
trouble.

> It's a decision that ends up in the hands of the admin anyway.
> Admins are already maintaining the ACLs on their firewall.

Yes.

> * Developers don't have to implement and test protocol support for
> some negotiation scheme.
> 

When was the last time you saw a major IM or e-mail client that didn't
let you toggle TLS?  I can't remember when I last saw such a thing.

If such an app gives you that toggle it's because the developers were
willing to deal with the complexity of negotiation (whether starttls or
not) and configuration (that toggle is it).

> * Admins don't have to learn more configuration, site security
> doesn't depend as much on the perfection of sendmail.cf.

If you're going to use TLS chances are you'll be depending at least on
server certs, and at least a small PKI or pre-shared self-signed certs
or client-side SSH-style leap-of-faith.  The PKI approach -> lots of
admin (TA deployment, CA cert signing procedures, ...).  Making sure
that servers require TLS, whether StartTLS or otherwise, is not much
harder.

> looking only at the TCP/IP header is a powerful thing.

You still have to be sure that the client and server will actually, you
know, run TLS.

The only benefit of a "secure-only port number" is that you don't have
to make sure that the server requires TLS -- chances are near 100% it
just won't work if it doesn't, in which case the problem is self-
correcting (user files ticket, admins fix the problem).

Nico
--

---

From: Richard Hartmann <[email-masked]>
Date: Mon, 8 Nov 2010 21:57:59 +0100

On Mon, Nov 8, 2010 at 21:12, Nicolas Williams
<[email-masked]> wrote:

> For example, more TCP ports -> more firewall rule complexity.

Let's assume only StartTLS/TLS is allowed at a site:

One overloaded port:
  firewall: one open port
  daemon: extra configuration to disallow non-TLS

Two ports:
  firewall: one open port as the non-TLS port is blocked
  daemon: default config which allows TLS, only

Personally, I prefer a distinct port as, assuming no one is doing
anything funny, it does more to ensure encryption than overloading a
single port. And yes, this does not guarantee anything. But then, as
we all know, security is not measured in absolutes. It's a sliding
process.

Richard

---

From: Marsh Ray <[email-masked]>
Date: Mon, 08 Nov 2010 15:46:44 -0600

> You have that with the out-of-band negotiation case too though.

Right, I think I covered that in the blog post I linked. It always bears 
repeating. I suppose it depends on whether you define TCP port number as 
out-of-band or in-band so it's maybe relative to which RFC you're reading.

Regardless, the solution is to have the endpoints refuse to engage in 
risky behavior. Dynamically negotiating authentication parameters has 
proven to be inherently perilous.

> Every IM and e-mail client I've used has the option to not require TLS.

We have to be prepared to face the possibility that the status quo kinda 
sucks.

> that checkbox the user is likely to check it off if they run into any

Where there is an option, it really ought to be called "send all my 
bank^H^H^H^H naked Facebook photos to the bad guys."

> let you toggle TLS?  I can't remember when I last saw such a thing.

It's awful, isn't it?

The only silver lining in this is that the existence of insecure 
connections may be keeping the bad guys busy enough that they never feel 
the need to attack our secure ones.

> not) and configuration (that toggle is it).

Right, there's still some configuration, so maybe this is by itself is 
not a huge win.

Looking at T-bird IMAP configuration I see:

A) Port number: [defaults according to other setting]

B) Connection security: three options
    None
    STARTTLS [default]
    SSL/TLS

C) Use secure authentication: [checkbox]

It seems like this configuration could be simplified a little bit.

(A) Looks simple and obvious.

(B) Doesn't say whether its STARTTLS is strict, or if it's vulnerable to 
a downgrade attack.

(C) Doesn't say what "secure authentication" means. I suppose I could 
look up some RFCs and guess that it might mean that. But what it doesn't 
say is whether or not non-forwardable auth can be used. If I select 
STARTTLS and check "Use secure authentication" it appears likely that an 
active attacker could still downgrade my connection to non-TLS and then 
do a forwarding attack taking my credentials to to some other server, 
perhaps not even mail related.

So the Thunderbird developers implemented some extra configuration (and 
I don't really know what it does) which would not be necessary if there 
were just an "requre port 993 TLS" checkbox.

>  Making sure

Yeah, not much harder. But it seems like "just a little more work" can 
make a huge difference in real world uptake rates.

> You still have to be sure that the client and server will actually, you

...and validate the certificates properly, and so on.

> correcting (user files ticket, admins fix the problem).

I.e., the default failure mode is secure, rather than insecure.

This is a pretty big win IMHO.

- Marsh

---

From: Marsh Ray <[email-masked]>
Date: Mon, 08 Nov 2010 15:59:33 -0600

On 11/08/2010 02:12 PM, Nicolas Williams wrote:
> much.

Does it have implications for session resumption I wonder?

Not so much for the protocol itself, but for what you get with the 
straightforward use of a normal TLS library.

For example, if a developer let the TLS library handle the socket 
connections it seems like it could be smart enough to support 
resumption, but a STARTTLS-based protocol would seem to prevent this. In 
cases where the app code is just passing buffers to the TLS library, the 
TLS stack may not even know the hostname at the time of the Hello 
message exchange.

It's probably not a big deal for most mail protocols, but it might make 
a perceptible difference for a user of IMAP.

- Marsh

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 8 Nov 2010 16:10:16 -0600

> >let you toggle TLS?  I can't remember when I last saw such a thing.

I'm not sure.  It's not always the case that you have a trust path to a
server, so if we force TLS on all the time then we're also training
users to do SSH leap-of-faith (or worse, if the client isn't very good).
Now, SSH leap-of-faith is actually a pretty good solution, so maybe
that's OK.  But we'd still be training users to keep clicking "OK [give
all my money to the bad guy]".

> I.e., the default failure mode is secure, rather than insecure.

Only on the server side.  If the firewall is not close to the client
then the client can still fallback on insecure connections.  In many
cases it's the client that matters most.

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 8 Nov 2010 16:16:25 -0600

> Does it have implications for session resumption I wonder?

What, StartTLS?  I don't think so, not over raw TLS.

> straightforward use of a normal TLS library.

Any implementation that attempts to make TLS transparent to the
application does have all sorts of issues.  You can't hide all TLS
details from the app, or the user for that matter.

> resumption, but a STARTTLS-based protocol would seem to prevent
> this. In cases where the app code is just passing buffers to the TLS
> library, the TLS stack may not even know the hostname at the time of
> the Hello message exchange.

Clearly a raw StartTLS approach requires that the app pass in all the
parameters that the TLS library might have been able to obtain by itself
in a raw TLS case.

> It's probably not a big deal for most mail protocols, but it might
> make a perceptible difference for a user of IMAP.

Shouldn't be.

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 8 Nov 2010 16:22:58 -0600

> we all know, security is not measured in absolutes. It's a sliding

If the firewall is not close to the client then the client can still
fallback on no TLS.

There's trade-offs all over.  I'm not sure that this one is worth all
that much either way.  I prefer StartTLS over having two ports for
everything.  I might also be happy with forcing TLS on always for new
ports, but I do worry about training users to click through the
"is this the right server" dialog ("leap-of-faith").

Nico
--

---

From: Richard Hartmann <[email-masked]>
Date: Tue, 9 Nov 2010 00:19:25 +0100

> If the firewall is not close to the client then the client can still

True. I understood your example as "if you only allow TLS, an
overloaded port makes things easier for the firewall admin" which I
did not agree with.

> everything.

I doubt that everyone will rush to register new ports.

>  I might also be happy with forcing TLS on always for new
> ports,

IMO, this is not realistic.

> but I do worry about training users to click through the

Agreed.

Richard

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 8 Nov 2010 17:30:49 -0600

> overloaded port makes things easier for the firewall admin" which I

Provided that all servers and clients of interest implement the the app
protocol on the raw TLS ports, then yes, it's easier for the firewall
admin to only open the raw TLS ports.

> I doubt that everyone will rush to register new ports.

But ports are a limited commodity.

> > "is this the right server" dialog ("leap-of-faith").

So what you propose is... what exactly?  That every application protocol
have raw TLS and non-TLS (but with StartTLS?) ports?  Or that every
application be based on HTTP(S)?

I'm proposing this: stop the FUD regarding StartTLS, bake it into all
new app protocols where TLS is appropriate.  In existing apps that have
both raw TLS and non-TLS ports, leave well enough alone.

Nico
--

---

From: Bill Frantz <[email-masked]>
Date: Mon, 8 Nov 2010 16:58:08 -0800

On 11/8/10 at 9:27 AM, [email-masked] (Marsh Ray) wrote:

>Should we only be concerned with passive eavesdropping? If so, 
>then consider how much higher adoption could have been if the 
>specs had endorsed anon-anon DH connections such that there was 
>no need for admins to set up certificates for their mail 
>servers before deploying encryption.

Don't underestimate the value of protection from passive 
eavesdropping. It buys you quite a bit in the mobile WiFi world, 
where trusting the network providers is not an unreasonable 
level of trust compared with trusting anyone who can hear your 
radio connection.

As an exercise for the student: Do you trust your network 
provider more than you trust our current version of PKI?

My answer might depend on how the three letter agencies active 
where my packets may flow fit into my threat model.

Cheers - Bill

---------------------------------------------------------------------------
Bill Frantz        |"We used to quip that "password" is the most common
408-356-8506       | password. Now it's 'password1.' Who said 
users haven't
www.periwinkle.com | learned anything about security?" -- Bruce Schneier

---

From: Marsh Ray <[email-masked]>
Date: Mon, 08 Nov 2010 19:46:57 -0600

Sorry Nico, this is not so much a reply to you specifically as I started 
thinking and writing about the SSH leap-of-faith/trust-on-first-use model.

On 11/08/2010 04:10 PM, Nicolas Williams wrote:
>
> It's not always the case that you have a trust path to a
> server,

Why not? Or, rather, isn't that a reasonable prerequisite for security?

Shouldn't the discussion of a secure protocol be able to presume it, 
much like RFCs tend to assume the existence of electrical power or 
non-backdoored computer hardware to run on?

> so if we force TLS on all the time then we're also training

The old "Click 'OK' to fail or click 'Cancel' to not succeed." dialog.

The merits and limitations of leap-of-faith or trust-on-first-use (ToFU) 
have gotten a lot of discussion over the years, but I don't think 
there's an agreed-upon set of principles for deciding when it's 
appropriate for use in any given design. Most of us probably feel that 
it seems to work acceptably well in practice for administering servers 
via SSH, but is no good for general e-commerce web connections. Hard to 
say why.

With ToFU, an unknown server to which the client has never previously 
attempted to connect is trusted implicitly, even with a higher level of 
privilege than an authenticated trusted server. Unauthenticated server X 
is allowed to permanently set the auth credentials of any arbitrary new 
target server T, whereas the fully authenticated and trusted server A is 
not.

Aside from that, I think the thing that bugs me about ToFU is the 
definition of the term "first use".

This subtly introduces state into the client side where it did not exist 
previously. For every possible target server, the client must be able to 
answer "Have I ever connected to this server before?".

It's easy enough to think that the client doesn't need state on "every 
possible" target server and that he can just store the list of those 
that he has seen. But it's not so simple. When the question is posed of 
the data "have I seen this server before?" now a false negative outcome 
translates into vulnerability.

But for most systems, it's usually action based on a false positive 
result that is the more costly to remediate. Many systems experience 
little consequence from false negatives (e.g., a missed cache opportunity).

This relates to the concept that "it's very hard to prove a negative". 
In this case, the negative being accepted is "I have not used this 
server before". From a security design perspective, if there's something 
that's famously hard to do, you don't want your success at it to be a 
necessary condition for rejecting auth attempts from attackers.

It really seems to go against a fundamental principle of cryptography: 
the legitimate parties can succeed with relatively easy computations 
whereas the attacker finds impractically hard logic problems stacked 
against him.

But maintaining a mapping of servers to credentials on the client seems 
like a straightforward implementation task, something that we could 
implement reliably. But is it really? Many a developer has figured it 
would be simple to look for a server names in an x509 cert, but look how 
many issues that has raised. Why should looking up a server name in the 
client's ToFU history be different? (Except that, again, the failure 
mode is insecure in this case.)

There's the one-shot timing attack: if MitM can be in a position to 
intercept a client's actual "first use" of a server, then he can supply 
fake credentials which allow him to impersonate the server indefinitely.

There's a cookie-jar-overflow attack, too. No client can store an 
unlimited amount of server entries, so an attacker may be able to stuff 
entries in until the client software (or the user) is forced to discard 
some in order to make room for new ones.

These attacks would likely be very practical for protocols involving 
HTTP or HTML because they allow an unauthenticated server to cause the 
client to initiate requests at arbitrary other servers. Frequently this 
capacity is used for things like precaching images on a web site, but an 
attacker could equivalently use it to preload one or more entries into 
the client's ToFU state.

Even if a client presents a confirmation prompt to the user before 
adding an entry to the ToFU state (like SSH does), it could represent an 
information leak. An attacker could trigger requests to arbitrary 
servers and find out which ones the client had _ever_ accessed by the 
clients behavior when he goes to access those servers. Again, some other 
attackers could possibly preload false positive results which the first 
might misinterpret as evidence against the client.

Also, the idea of "first use" is tied to the client system. Or to the 
user. Or to a specific user on the client system. Or something. The list 
of every web server your client system had ever connected to would 
obviously be confidential data.

Yet, insofar as a client's loss of "first use" state represents a 
regression in its security, it needs to be continuously available too. 
What happens when the user transfers to another device? Aren't they 
obligated to back up that state and use it to initialize their new 
client system?

What if you're the kind to get a new smartphone every few months. Do end 
up with less security than the person who's been running the same IE6 
for the past 5 years?

What if a server needs to revoke and start using new credentials for 
whatever reason? It's one thing to convince a single CA of a legitimate 
change in the server's credientials, but how would a popular site 
convince every client independently?

Consider SSH's known_hosts files. If you're like me, you have used many 
SSH systems as clients over the years. I usually have filesystem 
permission bits protecting that file, but I don't consider it to contain 
anything interesting enough to think of as confidential either. When you 
have changed systems in the past, how often have you gone to the trouble 
of copying over your known_hosts file? I admit that I usually just 
accept a new first use of every server I access from the new client. Now 
consider the security of SSH if every random web page on the net were 
allowed to (or cause a prompt for) adding arbitrary entries to that file.

> cases it's the client that matters most.

Good point.

In that sense, egress rules on client-based firewalls could be as 
important as the inbound connections on the server side.

- Marsh

P.S. Just for the record, I do really like tofu (the curd) and eat it on 
a regular basis.

---

From: Marsh Ray <[email-masked]>
Date: Mon, 08 Nov 2010 20:38:10 -0600

Marsh Ray <[email-masked]> writes:
> endorsed anon-anon DH connections such that there was no need for
> admins to set up certificates for their mail servers before deploying
> encryption.

On 11/08/2010 06:38 PM, Peter Gutmann wrote:
> The spec already does, RSA-as-anon-DH-equivalent seems to be the
> default deployment mode outside of HTTPS in browsers (I've always
> found it amusing that anon-DH use in SSL/TLS is treated as some form
> of leprosy by SSL developers and then the admins who use it turn RSA
> into anon-DH anyway by whatever means they can, self-signed certs,
> openssl ca ...', throwaway free certs, ...).

:-)

On 11/08/2010 06:58 PM, Bill Frantz wrote:
> eavesdropping.

For the record, I was sincerely more interested in how Peter would 
respond than I was arguing against the merits of unauthenticated encryption.

I do think, however, that unauthenticated encryption is scary. It has 
that combination of being easy to set up, it looks like great 
pseudorandom data on a network monitor, yet it provides absolutely no 
defense against an entire class of practical "attack". (I put it in the 
quotes to question the use of the term in cases where the specific 
security property is explicitly disclaimed.)

So maybe a little dogmatic phobia of ADH is appropriate to keep us on track?

> It buys you quite a bit in the mobile WiFi world,
> where trusting the network providers is not an unreasonable level of
> trust compared with trusting anyone who can hear your radio
> connection.

Which did you mean:

Mobile, i.e. GSM and CDMA?   - varying degrees of pwned.

Or "mobile" WiFi hotspots?   - pwned.

> As an exercise for the student: Do you trust your network provider
> more than you trust our current version of PKI?

Yeah good question.

My answer is that it's meaningless to talk about "trusting" my network 
provider, other than having expectation that they will deliver my 
packets with high probability and low latency (and bill me for it 
accurately). No security properties per se are guaranteed by the design 
of the Internet. This was an intentional decision on the part of its 
designers. There were plenty of other networks back then that tried to 
build in all sorts of properties like that, but use the net we have 
today because it just works better this way.

> My answer might depend on how the three letter agencies active where
> my packets may flow fit into my threat model.

You don't know the route your packets will take across the public net. 
Every packet may take a different route. Really.

Or alternatively, an attacker could arrange for your data to be 
transmitted from a geosynchronous satellite over an unencrypted downlink 
where they could be received anonymously by consumer equipment anywhere 
on the entire continent:
http://www.blackhat.com/presentations/bh-dc-10/Nve_Leonardo/BlackHat-DC-2010-Nve-Playing-with-SAT-1.2-wp.pdf

- Marsh

---

From: Marsh Ray <[email-masked]>
Date: Mon, 08 Nov 2010 20:47:46 -0600

> both raw TLS and non-TLS ports, leave well enough alone.

Are people actually making that many new app protocols not based on TCP 
port 443?

It seems like the general trend is to run all new things over TCP 443 
whether it fits the HTTP 'web services' model or not. Because, 
ironically, everything else is more likely to be "managed" out of 
existence by the firewall admin. :-)

Microsoft, for example, has that VPN protocol that transparently 
multiplexes on that port. There's also the "next protocol notification" 
proposal being circulated.

- Marsh

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 8 Nov 2010 21:50:40 -0600

On Mon, Nov 08, 2010 at 07:46:57PM -0600, Marsh Ray wrote:
> 
> Sorry Nico, this is not so much a reply to you specifically as I
> started thinking and writing about the SSH
> leap-of-faith/trust-on-first-use model.
> 

Because not every pair of communicating systems do so as part of a
corporate network with well-staffed IT departments complete with PKIs,
bridge PKIs, Kerberos, and other trust path mechanisms, with all hosts
pre-registered, and so on.

Usability is part of the security equation.  If secure applications are
unusable, don't be surprised when users don't use them.

SSH has been so successful in large part because leap-of-faith works
rather well -- it has a very small window of vulnerability, a very big
vulnerability, yes, and requiring persistent storage, true, but
difficult to exploit without users eventually noticing.

> definition of the term "first use".

Me too.  Leap of faith is not for all.  But clearly it has its place,
and that's not yet the ash heap of history.

> important as the inbound connections on the server side.

So what you're proposing is that we require TLS on all the time, via raw
TLS ports?

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 8 Nov 2010 21:57:15 -0600

On Mon, Nov 08, 2010 at 08:47:46PM -0600, Marsh Ray wrote:
> Are people actually making that many new app protocols not based on
> TCP port 443?

I see lots of port 80 stuff still.  Don't you?  Do you live in a better
world than I do?  :)

> It seems like the general trend is to run all new things over TCP
> 443 whether it fits the HTTP 'web services' model or not. Because,
> multiplexes on that port. There's also the "next protocol
> notification" proposal being circulated.

Well, it's true that because of firewalls everything runs on ports 80
and 443, often doing CONNECT.

Nico
--

---

From: Bill Frantz <[email-masked]>
Date: Mon, 8 Nov 2010 21:24:06 -0800

On 11/8/10 at 6:38 PM, [email-masked] (Marsh Ray) wrote:

>...

Is my home WiFi router pwned? How about the one at the airport? 
The one at the coffee shop where I know the owner? The one set 
up by the conference committee?

While any of these entry points can be pwned by exploitation of 
flaws in their implementation, I don't think the 
people/organizations that set them up have an incentive to 
install MITM attacks in them.

I think there is little incentive for the more backbone network 
providers to install MITM attacks. (But see the comment about 
three letter agencies below.)

Now I think it requires an active attack to install a MITM. Just 
being able to eavesdrop the bits won't do it. (Please tell me if 
I am wrong.)

>My answer is that it's meaningless to talk about "trusting" my 
>network provider, other than having expectation that they will 
>deliver my packets with high probability and low latency (and 
>bill me for it accurately). No security properties per se are 
>guaranteed by the design of the Internet. This was an 
>intentional decision on the part of its designers. There were 
>plenty of other networks back then that tried to build in all 
>sorts of properties like that, but use the net we have today 
>because it just works better this way.

My reaction is, there are no guarantees in life. Given the 
frequency of security patches in all major software, doubly so. 
However you can get a useful level of confidence by looking at 
peoples incentives.

>You don't know the route your packets will take across the 
>public net. Every packet may take a different route. Really.
>
>transmitted from a geosynchronous satellite over an unencrypted 
>downlink where they could be received anonymously by consumer 
>equipment anywhere on the entire continent:

Unless there are nodes in the network over which my packets pass 
which are pwned, this attack does not seem possible. Once I have 
set up an encrypted session with the mail server, I don't care 
if the bits are read.

Now I fully agree that a system with authentication would be 
better than just anon-DH. However, such a system has costs as 
well, and in many practical situations you get real value from anon-DH.

My own taste would be to know when the public key of the mail 
server changed. I really can afford to store the public keys of 
all the mail servers I use. I can erase one of the 500+ megabyte 
photos I have to make room. :-)

I checked what my email provider (Earthlink) does. When I set 
SSL in my mail agent to "disabled", I can pick up mail. When I 
set it to "negotiated", the connection is quickly dropped and I 
can't pick up mail. When I set it to "Required" connection setup 
hangs. YMMV.

Cheers - Bill

---------------------------------------------------------------------------
Bill Frantz        |"Web security is like medicine - trying to 
do good for
408-356-8506       |an evolved body of kludges" - Mark Miller
www.periwinkle.com |

---

From: "Steingruebl, Andy" <[email-masked]>
Date: Mon, 8 Nov 2010 22:30:28 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Bill
> Frantz
> 
> The one at the coffee shop where I know the owner? The one set up by the
> conference committee?

Some of us are actually trying to get some real stats on that.  We have existence proofs, but I don't have a likelihood measure.  

Anyone else working on getting those statistics?  Perhaps we can share data...

- Andy

---

From: Marsh Ray <[email-masked]>
Date: Tue, 09 Nov 2010 11:51:18 -0600

> pre-registered, and so on.

Quite often, those are the places that have hardest time getting systems 
to interop.

> unusable, don't be surprised when users don't use them.

+1 that's absolutely true in reality.

However, doesn't there need to be

> difficult to exploit without users eventually noticing.

I know I read a study somewhere of what users (a university setting I 
think) typically did when presented with the "WARNING: REMOTE HOST 
IDENTIFICATION HAS CHANGED!...Are you sure you want to continue 
connecting (yes/no)?" question. I think the results were pretty dismal.

> So what you're proposing is that we require TLS on all the time, via raw

Not really, although it wouldn't be a bad idea to migrate in that 
direction. I'm more trying to ask a philosophical question.

We know that the properties we expect of the "secure communications" we 
discuss in in this WG depend on authentication or authenticated 
encryption. Authentication is thus something of a prerequisite for the 
security, unless we have justification to rule out the possibility of an 
active attacker. Although there are many scenarios in practice where 
active attacks are more difficult, any general-purpose protocol will 
have to resist them effectively.

So, except in cases where explictly unauthenticated endpoints are 
involved, isn't it reasonable that for WG discussions to presume that a 
security protocol will be building upon some form of trust framework?

Or is there a new world happening where we're retreating from that 
principle and we now expect systems to somehow bootstrap their own 
security out-of-the-box or not get used at all?

- Marsh

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 9 Nov 2010 12:11:14 -0600

On Tue, Nov 09, 2010 at 11:51:18AM -0600, Marsh Ray wrote:
> I know I read a study somewhere of what users (a university setting
> I think) typically did when presented with the "WARNING: REMOTE HOST

For small deployments (say, home networks) the user can know that the
keys shouldn't have changed.  For larger-but-still-smallish deployments
this is a problem, and for sufficiently large deployments it's not a
problem at all because large organizations should be using GSS/Kerberos,
PKI, or else should be distributing known_hosts files, preferably via
DNSSEC.

> direction. I'm more trying to ask a philosophical question.

Philosophy is fine, but the original poster proposed something concrete
(that we drop StartTLS and just always use raw TLS); we should have an
answer to that.  Mine is that the arguments against StartTLS are weak,
and the arguments for always using raw TLS are also weak.  I'm
unconvinced by the OP's and others' arguments against StartTLS.

> We know that the properties we expect of the "secure communications"
> we discuss in in this WG depend on authentication or authenticated
> encryption. Authentication is thus something of a prerequisite for
> the security, unless we have justification to rule out the
> possibility of an active attacker. Although there are many scenarios
> in practice where active attacks are more difficult, any
> general-purpose protocol will have to resist them effectively.

Yes.  But don't go to extremes, don't rule out leap-of-faith.  I'd be
very cross if I had to deploy a PKI in my house :)

> involved, isn't it reasonable that for WG discussions to presume
> that a security protocol will be building upon some form of trust
> framework?

Yes, but what does that have to do with the OP's post?

> security out-of-the-box or not get used at all?

Bootstrapping security is a good thing.  Ideally we'd all have
smartcards and we could use those to bootstrap joining systems to a PKI,
Kerberos realm, etcetera, but often all we have is passwords, and
sometimes not even that.  For small scale deployments leap-of-faith
works wonders.  For larger scale deployments you can rely on capable IT
departments to pre-load trust anchors, etcetera.

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 9 Nov 2010 12:32:44 -0600

On Tue, Nov 09, 2010 at 11:22:41AM -0700, Steingruebl, Andy wrote:
> > From: [email-masked] [mailto:[email-masked]] On Behalf Of
> > Nicolas Williams
> > 
> > Philosophy is fine, but the original poster proposed something concrete (that
> > we drop StartTLS and just always use raw TLS); we should have an answer to
> > that.  Mine is that the arguments against StartTLS are weak, and the
> > arguments for always using raw TLS are also weak.  I'm unconvinced by the
> > OP's and others' arguments against StartTLS.
> 
> Maybe I missed it but from a performance standpoint how do you solve
> the fast restart problem with StartTLS bootstrapping instead of
> implicit-TLS with a dedicated port?  Seems like for anything that is
> user-interactive (HTTP, etc) rather than async (SMTP) that the
> performance differences will be extreme. Yes?

First, I'm not proposing that we all start using StartTLS in HTTP.
HTTPS is here to stay.  IIRC the OP was talking about StartTLS in SMTP.

Second, I don't think "the performance differences will be extreme".
StartTLS implies one more round-trip.  That sucks, but for apps that
tend to maintain long-lived connections it's a wash.  For HTTP it's not
a wash, I agree.

> I think the downgrade attacks can both be solved with the
> oft-discussed generic "Strict Transport Security" work going on in
> multiple forums, and isn't dependent on which TLS bootstrap mode we
> choose, implicit, or StartTLS variety.

The downgrade problems are only solved by the client/user knowing that
fallback on not using TLS is not in their interest.  Note that forcing
TLS on all the time isn't a solution either unless at least servers are
authenticated by TLS all the time too (i.e., fallback on ADH is not good
either).  I think I've just agreed with what you wrote.

Nico
--

---

From: Martin Rex <[email-masked]>
Date: Tue, 9 Nov 2010 22:31:45 +0100 (MET)

> Does it have implications for session resumption I wonder?

I really do not think so.   For a sensible implementation of
client-side TLS session caching, it is always necessary to
know the original target hostname&protocol/port, and not the
naked target IP address & port on the connected socket.

> straightforward use of a normal TLS library.

I don't know what you mean by "normal TLS library".  In the abstraction
that I provide to our application callers,  I do not offer a connect
capability -- it is the task of the application to provide a fully
connected socket that is ready for starting the SSL/TLS handshake.

If there is any plain text communication necessary prior to starting
the TLS handshake on a socket (such as a proxy CONNECT method or
probably in a STARTTLS scenario), preparing the connection is entirely
up to the application.

I do require the application caller to provide a target hostname&port
for the handshake to be started, so that my abstraction layer can
transparently provide client-side TLS session caching.  By default,
that target hostname is going to be used for server endpoint identification,
but the application can specify this to be ignored, retrieve the
server certificates or DNames from it and perform other kinds of
server endpoint identifications it considers adequate.

>
> In cases where the app code is just passing buffers to the TLS library,
> the TLS stack may not even know the hostname at the time of the Hello 
> message exchange.

It is the duty of the application caller to either provide the
TLS implementation that hostname&port of the destination prior to
starting the handshake, or to perform client-side TLS session
cache management itself or live without client-side TLS session caching.

> resumption, but a STARTTLS-based protocol would seem to prevent this.

Letting a TLS library do network reads and writes directly is a
completely seperate issue from how is a communication channel
established (and closed) and how to get to the exact point in
the communication where the TLS handshake can be started.

Since the application will usually implement/provide things like
HTTP proxy-traversal (with optional proxy password) and
STARTTLS-enabled protocols without TLS, I would never try to duplicate 
that part of the non-TLS communication within TLS.

Same goes for most part of the IPv6 support by the application.
By leaving the connect entirely up to the application (which needs
to implement it for all non-TLS protocols anyways), the amount
of changes that my SSL abstraction needed for IPv6 was very minor.

Calling SSL_connect() and SSL_accept() does not imply that the
TLS library calls socket()+connect()s or socket()+listen()s.

Since a lot of applications includes support for non-TLS protocols,
it is much easier to have the application perform all select()/poll() 
operations, including connect() and listen(), and in particular
when doing the latter asynchronously.  This also facilitates
consistent error handling&visualizations for network errors.

-Martin

---

From: Marsh Ray <[email-masked]>
Date: Tue, 09 Nov 2010 16:21:23 -0600

On 11/09/2010 03:31 PM, Martin Rex wrote:
> naked target IP address&  port on the connected socket.
>
> capability

Yeah, that's not normal. :-)

> -- it is the task of the application to provide a fully
...
> the communication where the TLS handshake can be started.

In theory.

In practice, most app developers seem to use an HTTP/HTTPS client library.

Client apps making plain TLS connections seem to fall in to two classes:

1. Those that pass a hostname and port into the library and have the 
library handle DNS lookup and sockets.

2. Those that are vulnerable because nobody checks the CN on the cert.

At this point, everybody in this group thinks to themselves: "well I've 
written a client or three that does it correctly". You are the 
exceptions to the rule. We would not let any of our friends make that 
mistake either, so we also end up not knowing anyone who writes class 2 
apps.

But look around online. There are far more SSL client apps than there 
are apps which parse names out of x509 certificates.

For example searching for "openssl connect" vs "openssl x509":

http://www.google.com/codesearch?hl=en&lr=&q=openssl+connect&sbtn=Search
Results 1 - 10 of about 99,800

http://www.google.com/codesearch?hl=en&lr=&q=%22openssl%2Fx509%22&sbtn=Search
Results 1 - 10 of 6,970.

There are probably more accurate ways to search that, but they all 
indicated that calling SSL/TLS functions was significantly more popular 
than parsing x509.

It's not their fault. Read the OpenSSL docs, there's hardly any 
explanation about the need to check x509 fields in the server's cert and 
your client still runs fine if you don't do it.

> HTTP proxy-traversal (with optional proxy password)

Most apps use HTTPS libraries for that, or don't implement it at all.

> consistent error handling&visualizations for network errors.

Right, these are the "class 2" apps. More often than not, they don't 
properly check the name on the server's cert. Don't even ask about cert 
revocation handling and such.

Higher level APIs like to present SSL sockets and connection methods 
with the same interface as the plain sockets. This might work OK as long 
as the API sees the host and port names. Once the app grows a little in 
complexity, say by doing its own DNS resolution, then it may silently 
become vulnerable.

This might make another argument against starttls, albeit a weak one.

A raw TLS client app written by an non-TLS-expert developer that does 
everything perfectly is a rare bird indeed.

- Marsh

---

From: Martin Rex <[email-masked]>
Date: Wed, 10 Nov 2010 04:25:14 +0100 (MET)

> connecting (yes/no)?" question. I think the results were pretty dismal.

How surprising.  If you furnish your users with software that will
perform a social engineering attack on your users whenever an
outside attacker asks for it, why should you expect a different
reaction?  (btw. the SSH clients that I'm using do not suggest
to override a changed host key and in particular don't offer to
do so with a simple "Y" keypress, they just fail.)

Curiosity kills cats and makes social attacks succeed.

If you send an intriguing Email with a dangerous attachment to
a significantly large fraction of employees in a company, _some_
of the users _will_ double-click the attachment -- guaranteed.

For something that sounds moderately interesting it may be
around ~10% of the recipients blindly relying on the safety of
the AV-software to protect them from dangerous stuff.

The underlying problem with the "TLS PKI" is that it is an
ants-level solution to ant-level problems.  "Smells like its from
our nest -- just let it in".

Evolution caused more advanced species to use more sophisticated
schemes of trust and protection against impersonation, and I really do
not understand why there is so much resistance against evolving
TLS security beyond ants level.

All trust decisions performed by more advanced species are based on
leap-of-faith on initial encounter and memorizing information for
validating future encouters of the same individuals (and things),
including recognizing ones parents.

Personally, I find it frightening just how wildly successful
a tool like Firesheep is in attacking services like GoogleMail,
Hotmail, Facebook, ebay and sorts.  If the services themselves
already subvert the security so throughly by doing parts or most
of the communication totally unprotected, then it seems pretty
pointless to discuss the (lack of) value of the commercial CA TLS PKI.

For a number of "selling" players around the TLS technology, the most
interesting part appears to be the business models / business opportunities,
not the security.  And for a number of "consumers" of the TLS technology
the most appealing part is continuity in authenticating end users
with weak passwords.

> security protocol will be building upon some form of trust framework?

There will always be both.  Starting from scratch with no
trust framework, and integrating into an existing trust framework
(personal, home/family, organizational/corporate or governmental).

> security out-of-the-box or not get used at all?

There are out-of-band key distribution & personalization schemes,
One that is being used quite heavily around the globe is distribution
"SIM" cards.  Another one is TPM modules.  Or smartcards containing
public key crypto and credentials.

The most popular schemes are "bootstrapping" with leap-of-faith,
and bootstrapping with (simple|default|anything) passwords.

And "thanks to TLS" traffic encryption, password based authentication
schemes will be with us for very much longer...

-Martin

---

From: "t.petch" <[email-masked]>
Date: Thu, 11 Nov 2010 17:41:15 +0100

---- Original Message ----- 
From: "Nicolas Williams" <[email-masked]>
To: "Marsh Ray" <[email-masked]>
Cc: <[email-masked]>; "Paul Hoffman" <[email-masked]>; <[email-masked]>
Sent: Tuesday, November 09, 2010 7:11 PM
<snip>
> unconvinced by the OP's and others' arguments against StartTLS.

To return to (what I see as) the main purpose of the thread, I too
think that StartTLS is a good, if not an excellent idea; I see no 
difference in the vulnerabilities (although my cryptanalysis is weak).

Sadly, whenever I have been involved in a WG developing App-X 
over TLS, my record of convincing the rest of the WG is 100% failure.

Also, this decision, StartTLS or separate ports, tends to be taken 
early in the development cycle, while the request to IANA will only materialise
five years or so later, so back pressure from IANA or the IESG will then meet
an immovable mountain.  Really, any advice to a WG needs to put in front
of them about the time the BOF is approved, which I don't see this I-D 
having any material impact on!

Tom Petch

> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 11 Nov 2010 12:06:38 -0600

> difference in the vulnerabilities (although my cryptanalysis is weak).

There's no need for cryptanalysis w.r.t. what happens before TLS starts:
it must all be in the clear (relative to the application; IPsec could be
involved, of course).

> over TLS, my record of convincing the rest of the WG is 100% failure.

I think it's fine for _some_ applications to require TLS at all times.
For most applications I'd prefer StartTLS, but that's due to my port-

> having any material impact on!

We should probably have a BCP indicating which method is preferred, so
we can flog it at WGs early on.

Nico
--

---

From: Marsh Ray <[email-masked]>
Date: Thu, 11 Nov 2010 12:17:22 -0600

> difference in the vulnerabilities (although my cryptanalysis is weak).

Well, that's the thing. In theory there is no difference, in practice 
however...

Look at HTTP/HTTPS as an example. It doesn't use STARTTLS to negotiate 
an optional security upgrade. Well there is an RFC for it but I've never 
heard of anyone using it, if that functionality is latent, no one is 
depending on it.

The first thing users learn about web security is to put the 's' on the 
end of HTTPS.

The first thing web developers/admins do when setting up a secure site 
is to bind it to port 443. They can set port 80 to redirect port 443. 
The web developer can easily test that this is working in his web 
browser. The web site publishes 'https:' links and the user bookmarks 
them. If the TLS isn't working, no data is transferred. The TLS isn't 
optional. (You might raise the point that most users don't know the 
difference, but consider all the programmatic SOAP/web service clients 
which do.)

On the other hand, my email program gives me an option to use 
"STARTTLS". Even after I took packet captures of the connection process 
and observed it correctly negotiating the use of encryption, I still 
cannot tell if my email is vulnerable to a downgrade attack. The only 
way to find out is by performing exhaustive testing with an attack tool, 
or by direct inspection of the source code!

There are certainly a lot of things we could say about HTTPS security, 
but I believe that in this case has something valuable which 
STARTTLS-based protocols typically do not.

- Marsh

---

From: Martin Rex <[email-masked]>
Date: Thu, 11 Nov 2010 20:52:29 +0100 (MET)

> Well, that's the thing. In theory there is no difference, in practice 

The good thing about STARTTLS is that you can distinguish and
seperately analyze network connectivity from protocol interop issues.

For "upgrading/enhancing" an existing usage scenario in an installed
base, where connectivity is a solved problem, it offers
a smoother upgrade.

Distinguishing network connectivity issues from protocol interop
issues can be a royal PITA if you think of the complete absence
of TLS alerts from TLS peers running on top of Microsoft SChannel
or apps that produce utterly useless error messages like MSIE 6/7/8.

(the latter looks somewhat like an inbreed problem -- when ones
 implementation fails to implement part of the spec, then
 black-box testing with oneself can not possibly cover
 a sensible interop with that part of the spec.)

> or by direct inspection of the source code!

Black-box testing of security protocols with shelved has never produced
any meaningful information about protocol compliance or security and
never will.  Unless a protocol uses a fail-safe design by itself,
you will always need specialized interop tests with test tools that
can produce all sorts of very security-relevant deviations from
the communication between ordinary applications.

When I built GSSTEST to test GSS-API interoperability ~10 years ago,
I added test cases for common usage/configuration errors and typos
as well as test for various modifications of the stream of protected
messages to get an idea how implementations react (replay, reflection,
duplication, loss, reordering, truncation, extension, corruption)
and whether implementations detect the modifications, how they report it,
and whether they can get back in sync with the peer after a detected
modification (as GSS-API allows to make these errors non-fatal for the
underlying security context).

While most of the implementations were relatively well-behaved
for usage/configuration errors and typos, the results for modified
message streams were somewhat disappointing, so that we excluded
that part from the interoperability certification with our app.

When testing modified message streams, leaking memory was a pretty
common "mild" reaction.

-Martin

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 11 Nov 2010 14:14:04 -0600

On Thu, Nov 11, 2010 at 12:17:22PM -0600, Marsh Ray wrote:
> Well, that's the thing. In theory there is no difference, in
> practice however...

FUD alert.

> Look at HTTP/HTTPS as an example. It doesn't use STARTTLS to
> negotiate an optional security upgrade. Well there is an RFC for it
> but I've never heard of anyone using it, if that functionality is
> latent, no one is depending on it.

You're not explaining why no one uses HTTP StartTLS.  I assure you that
people use LDAP with StartTLS.  The specific reasons that led to one
being used and the other not are likely to be of interest, though I
can't say I have much insight into either.

> The first thing users learn about web security is to put the 's' on
> the end of HTTPS.

I think HTTP is a bit special.  HTTP/1.0 has resulted in a very high
number of round-trips to GET anything.  That Sucks.  More round-trips
(for StartTLS) would just suck more.  If HTTP/1.0 had had pipelining
from the get-go then the situation would be different, and then we could
say that HTTP + StartTLS is a fair thing to do when given an HTTPS URL.

> "STARTTLS". Even after I took packet captures of the connection
> process and observed it correctly negotiating the use of encryption,
> I still cannot tell if my email is vulnerable to a downgrade attack.

Without tracing every program you can't tell if the program is lying to
you about anything, anything at all.  Your program could be trojaned and
might be sharing your secret credentials with the bad guys.

Nico
--

---

From: Marsh Ray <[email-masked]>
Date: Thu, 11 Nov 2010 14:34:44 -0600

>> Well, that's the thing. In theory there is no difference, in

I suppose this conversation isn't going anywhere useful. I'll not burden 
the WG list(s) with it any longer.

Anyone who wants to, feel free to keep up the discussion with 'reply all'.

> You're not explaining why no one uses HTTP StartTLS.

Because my point was that it's not relevant to the discussion. But I 
seemed to have just confused the issue by mentioning it at all.

> might be sharing your secret credentials with the bad guys.

Why stop there? There is a whole industry's worth of evidence that even 
professional programmers working in heavily peer-reviewed environments 
can't write substantial programs without backdoors, intentional or not. 
The CPU in your/my computer (or most any of the other chips) has 
undocumented opcodes. The chip designers send their stuff off to someone 
else to be manufactured, too. Still, I need to know if my email program 
is willing to send my password in plaintext.

I claim only that there is a difference between the way my web browser 
handles http/https over TCP ports 80/443, and the way my email program 
handles STARTTLS. It may, in fact, be entirely implementation issues 
that make the difference. But still something could be gained by the 
discussion.

- Marsh