Subject: Re: [keyassure] HTTPS -> HTTP downgrade

From: "Jeffrey A. Williams" <[email-masked]>
Date: Mon, 20 Dec 2010 15:29:57 -0600 (GMT-06:00)

Phillip and all,

Yeah this is a very good business and enterprise security case that will/should be

or become popular IMO.

-----Original Message-----
From: Phillip Hallam-Baker
Sent: Dec 20, 2010 2:50 PM
To: Matt McCutchen
Cc: [email-masked]
Subject: Re: [keyassure] HTTPS -> HTTP downgrade

Must use TLS is only one use case and not necessarily the most interesting.

TLS is always offered is rather more interesting to me. Particularly when combined with lightweight DNSSEC validated keys.

As of today 0% of browsers support DANE. And it will be ten years or so before the proportion supporting DANE is above 90%. If all DANE offers is a 'cheap' substitute for CA issued certs it is probably going to fail. Who is going to deploy such a scheme at a server? It is certainly not going to work for any commercial application that requires security since nobody is going to accept a 10% drop in sales as the price of using a 'free' cert.

Now consider what is possible when a site has a way of saying 'TLS is always offered, here is the key'.

Deployment now becomes a no-downside option for any server which would not normally have used security.

On Mon, Dec 20, 2010 at 8:32 PM, Matt McCutchen <[email-masked]> wrote:

On Mon, 2010-12-20 at 11:35 -0800, Zack Weinberg wrote:
> On Mon, Dec 20, 2010 at 10:24 AM, Paul Wouters <[email-masked]> wrote:
> > On Mon, 20 Dec 2010, Paul Hoffman wrote:
> >> ... If you are running
> >> a server on port 80, you *cannot* prevent ssslstrip attacks: that is the
> >> whole point of the HASTLS document.
> >
> > - for clients not supporting HASTLS/TLSA, we can do nothing to prevent
> >   sslstrip
> > - for clients supporting HASTLS/TLSA, we can prevent sslstrip, if we can
> >   convey this by either the presence of HAS/TLSA or an option in those records.
> >
> > It would be a common deployment to leave port 80 running for old clients not
> > supporting  these records to continue to work (and be vulnerable to sslstrip)
>
> Why would you not simply turn off port 80?  Users of older clients
> would have to manually type https://, and inbound links might break,
> but I don't see any other negative consequences.

Those are pretty significant consequences!  I'd imagine the last thing a
major online business wants is for a significant fraction of its
customers to suddenly get an error page when they type in the name of
the site.  It would take a massive PR effort to get everyone to upgrade
their browsers or type https: .  Yes, that's eventually needed anyway to
realize the security benefits, but for now I strongly prefer a scheme
that can be adopted without breaking legacy clients.  (Perhaps the
PayPal folks would offer their perspective?)

--
Matt

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

--
Website: http://hallambaker.com/

Kindest regards,
Jeffrey A. Williams
"Obedience of the law is the greatest freedom" -
Abraham Lincoln

"Credit should go with the performance of duty and not with what is very
often the accident of glory" - Theodore Roosevelt

"If the probability be called P; the injury, L; and the burden, B; liability
depends upon whether B is less than L multiplied by
P: i.e., whether B is less than PL."
United States v. Carroll Towing  (159 F.2d 169 [2d Cir. 1947]
===============================================================
Updated 1/26/04
Network security Eng. SR. Eng. Network data security,
IT/information security.
ABA member in good standing member ID 01257402
E-Mail [email-masked]
Phone: 214-244-4827

---

From: "Jeffrey A. Williams" <[email-masked]>
Date: Tue, 21 Dec 2010 12:43:54 -0500 (EST)

Paul and all,

-----Original Message-----
>From: Paul Hoffman <[email-masked]>
>Sent: Dec 20, 2010 11:30 PM
>To: Matt McCutchen <[email-masked]>
>Cc: [email-masked]
>At 9:47 PM -0500 12/20/10, Matt McCutchen wrote:
>>I would argue that if http://foo:80 is just a redirection to
>>https://foo:443, that is not really "service" in the sense envisioned by
>>draft-hoffman-server-has-tls and hence it is not a lie to specify "0
>>443". 
>
>It *is* a lie because you control the redirection. The semantics of "0 443" are "if you find a responder at port 80, it isn't me, and you are probably getting scammed". If, insetad, you announced "80 443" and did a redirect as above, it is not at all a lie.
>
>>The effect is really the same as that described for an SSO for a
>>protocol that uses in-band security update, except that the "band"
>>consists of two ports.
>
>...and, as you say, something that is not a service.
>
>>The more controversial case is when the server offers real service on
>>both http://example.com:80 and https://example.com:443 . 
>
>Something on 80 that redirects to 443 *is* a real service in every sense of the word.
>
>>I think the
>>real question here is who gets blamed if the desired level of security
>>is not achieved.  In some cases there's only one party that can be
>>blamed (e.g., if one side leaks the master key or the client accepts an
>>invalid PKIX certificate or DNSSEC chain).  Beyond that, it's a gray
>>area and I'm having difficulty formulating any coherent statement, so I
>>will stop here.
>
>The real question, one that will be addressed in both DANE and WEBSEC, is whether it is reasonable to say "I speak on port 80 but you MUST use 443 instead, even if you wanted to do port 80". If you can come up with non-silly semantics for that without obvious problems, the WGs might buy it. I'm skeptical, though; I see many reasons for a client to say "I know 443 is going to fail me, so I'm willing to fall back to 80". The most obvious example is "you're using a CA who I don't trust, so I'm going to fail during the TLS handshake".

  Your last statement/sentance here is what is of the most importance
IMO.  We all know but are often times reluctant to directly mention
that there are some and/or few CA's that may be questionable and
that ALL CA's from time to time inadvertantly or otherwise loose some
level of control of integraty of their key database for any number
of reasons.  Question(s) then become how to deal with such effectively?
>--Paul Hoffman, Director
>--VPN Consortium

Kindest regards,
Jeffrey A. Williams

---

From: "Jeffrey A. Williams" <[email-masked]>
Date: Thu, 30 Dec 2010 12:35:09 -0600 (GMT-06:00)

Phillip and all,

I could not agree more.  The key term here is "Willing".  PKI needen't have cost over $1b to

provide for a method by which the Military or any other government agency/department could

with relitive ease change over to a very secure email platform, and BTW clouds ain't it.

-----Original Message-----
From: Phillip Hallam-Baker
Sent: Dec 29, 2010 6:51 PM
To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: Re: [keyassure] HTTPS -> HTTP downgrade

Chatting on an iphone all day is somewhat tedious. An iPad on the other hand - no problem.

I think that is one of the changes that argues for restrictions to be thought through more carefully. But in general there are a whole rack of issues that mobile computers are bringing.

Trying to get institutions to take security realistically is really difficult. Recently we discovered that a French bank had lost over $1.2 billion due to an internal fraud. The relevant compliance records were kept using a manually updated excel spreadsheet. And last I heard, not a single one of the people responsible for that fiasco lost their jobs.

Over the last decade the US government has spent over a billion dollars on a PKI. Yet none of the emails sent out by the US military to journalists are signed and a low ranking clerk was allegedly able to extract and leak a quarter million classified diplomatic cables.

We have to deliver security in a form that people are willing to use.

On Thu, Dec 30, 2010 at 12:17 AM, Martin Rex <[email-masked]> wrote:

Phillip Hallam-Baker wrote:
>
> There is also a fairly important Wall Street use case.
>
> Regulators require banks to have complete archives of client-broker
> communications. So brokers connecting up to TLS protected Web sites from
> work machines becomes problematic. So some block TLS entirely.

So everyone is using their private SmartPhone to do HTTPS traffic?
... which also prevents any traces from improper communication
to ever get created on the work machines...

-Martin

Kindest regards,
Jeffrey A. Williams