Re: draft-ietf-tls-http-upgrade reissued

Hi,

Rohit Khare wrote:

> Thanks! Scott  & I will take all the credit for the fine editing job,
> and none of the blame for the ideas :-)

I don't think you'll get away with that. See below.

> >1) It is a fact that many server products out there use confidential data,
> >like application session keys, or other confidential state information, as
> >part of the URI.
>
> Can't do much about that.
>
> This is a general theme of my following comments. Guns can be pointed
> at feet. Triggers can be pulled...
>
> >Even if a server enforces such a restriction, the URI will already be
> >compromised as part of the TLS upgrade process, because it is transmitted in
> >clear by the client before the server instructs it to upgrade to TLS.
>
> In general, I suspect that a secure-real-time web application should
> be negotiating TLS *before* handing out a FORM at all.

My question is : what would cause it to perform that TLS negotiation before hand,
since the URL is regular http ?

> But even if it
> did, the following rule applies:
>
> You can *never* prevent a client from publishing data in the New York Times.
>
> If the user's filling in sensitive data, it's the user-agent's job to
> demand secure upgrades before sending as much as the server's, if not
> more.

I don't think users will waste their time filling forms if they are not ahead of
time certain that it will be transmitted securely.
The user-agent can only warn after the negotiation fails, and the user only has
the option of discarding all the data he entered.

> >2) Nowadays, web users know if they have an http link that the connection is
> >not secure, and that if it's https it is secure (SSL).
>
> User behavior has little to do with TCP port numbers. On the other
> hand, nothing in the draft supposes that we will ever change the
> existing practice for Web Hypertext surfing applications.

Maybe your draft is appropriate for your internet printing applications. But
clearly, it will not fill the needs of web surfers and ISPs who want to provide
secure virtual hosting without exhausting the IPv4 address space.

The duplicate TCP port number issue is IMHO less of a problem because it is rare
to exhaust all 2**16 possible TCP ports on a server. That would mean you are
running that many different daemons ...

> >A current-generation HTTP client will create a request with the form data
> >from the user, and submit it in clear text to the server, compromising the
> >data even before the server gets a chance to deny it by requesting a TLS
> >upgrade with an HTTP 426 return code. This compromises security in order to
> >retain compatibility with existing HTTP clients. I do not think it is an
> >acceptable compromise.
>
> Don't send the FORM in the clear, either.

Again, how do you propose that the client make the decision to upgrade ?
Does it have to try to upgrade on every non-secure HTTP link ?
Will the browser prompt users for every link whether they want security ?

> >When it comes to security, I don't think ambiguity is a good thing, and it
> >is not good to leave it entirely
> >"up to the client and server" to determine what security characteristics are
> >needed for the connection.
>
> There is no such thing as absolute security. It is always, in the
> end, in the eye of the beholders.

That's no reason to make it easier for people to shoot themselves in the foot,
which is what this draft does.

> >I think the draft should define at least one standard way to tell clients
> >that an upgrade is in order before connection establishment.
>
> Yes, it does -- 426.

Just how do you get a 426 before you establish a connection with the server ?
Take the case with my HTML form, residing on site a, a product catalog site,
which has no security.
It's got a link to POST the order data to site b , which is a secure virtual
server supporting TLS upgrade.
With your proposal, this link must be a regular http link.
What will cause the browser to negotiate security when the credit card
information is submitted to site b ?
I contend that there has to be something on the order page to tell it to do so. I
think it should be part of the URL, perhaps a protocol of "httpt" - to specify
http over TLS with upgrade.
The trigger cannot be a prompting option configured globally in the user-agent,
because it would not be practical for users to be prompted for security on every
regular HTTP request, and they would just disable it.


> >That would certainly work technically and ensure best possible security, but
> >it would be a major waste of bandwidth in 99% of the cases since current
> >servers will not understand the upgrade request and reject it. Many existing
> >servers don't support keep-alive and will even close the connection,
> >introducing extra latency due to the need to reconnect.
>
> Bala Krishnamurthy's PRO-COW compliance survey can tell you about the
> smaller fraction that don't support any form of keep-alive.

Even so, the original point is bandwidth waste, and it is still valid.
To implement this, the user-agent must always initiate an upgrade request to the
server as its first request, then wait for the server to accept or ignore that
request. This also adds latency in the initial client request to the server,
which is delayed by this negotiation.


> >It may also be a waste of CPU for both the server and client, since perhaps
> >the connection didn't really need to be secure, but ended up as TLS because
> >of the way the client negotiated the upgrade for every server, and the
> >server just accepted it.
>
> Purely as a matter of opinion, I'm worried about keeping Andy Grove
> employed, not the other way around :-) Someday, every packet will
> finally be encrypted, and the cycle-time argument is moot.

I'm in very strong disagreement. Keeping Intel (or Sun, for the matter) in
business is not the issue.
You may not be aware of that fact, but in a typical secure web server today, the
overhead of doing encryption represents about 90% of CPU cycles spent. This means
a web server is an order of magnitude slower if it has to server secure
connections vs non-secure.

In turn, your proposal would result in an average tenfold increase in the
hardware requirement for servers, as well as waste of energy to power all those
CPUs, all for no good reason at all. Or the alternative would be a tenfold
increase in average web server latency, given no hardware upgrade.

I contend that there are web applications for which it's perfectly ok to not be
secured - for instant, accessing publicly available content. And there is a
minority of web applications where security is absolutely required, like
electronic commerce.

So far, I have never heard of a single application where security "would be nice,
but it's ok if it is not available" . This is what this draft really enables. I
call it a misfeature and I'm not eager to see it appear in mainstream HTTP
clients and servers.

I think it is necessary for a web application to be able to enforce security or
no security.


> >It cannot be a regular https:// URL since that
> >will not allow the server to differentiate the virtual host for which the
> >data is intended.
>
> Sure it can -- interpret https: in a next-generation "client" as an
> invitation to first try Upgrade on port 80, then fall-back to 423.

No, this would break the semantic of the https URL.
When you specify an https URL nowadays, it implicitly tells the client to connect
onto the default https protocol port, which is 443, as long as the port is not
explicitly specified.
It is not very common, but I certainly have seen URLs of the form
https://mysite:443 , with the port explicitly.
But the biggest problem is , if a different port is specified.
What would be the behavior that you would propose for, say, an https://mysite:444
URL ?
Should the client skip the connection to port 80 and try TLS directly on 444 ?
This proposal seems shaky to me, because it effectively modifies the protocol by
virtue of running on a different port. I think the protocol should be able to run
on any TCP port without major behavior changes like this.

> >Instead of trying to define a mechanism to upgrade the connection from
> >non-secure to secure, the virtual host negotiation could be made a standard
> >part of the SSL/TLS protocols. I think that makes sense since these
> >protocols exchange certificates which are tied to the virtual host names.
>
> This has long been on the "to-do" list for TLS/SSL. Installed base
> strikes again, though, in making this case fairly unlikely. But I
> agree that's the "right" solution for so many more TLS/SSL enabled
> apps than HTTP alone.

Good. I think I will join their mailing list. Any pointers ?

--
for a good time, try kill -9 -1