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

At 10:42 PM -0700 5/3/00, Julien Pierre wrote:
>I know this is an old messsage, but I must ask : has anybody tried to
>implement this TLS upgrade draft ?

Yes, Scott has, and some other Internet Printing Protocol folks.

>At first, as a server implementer, the proposal in this draft looks good,
>and quite straightforward to implement .

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

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

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

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

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

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

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

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

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

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

Late night thoughts,
Rohit Khare

Received on Wednesday, 3 May 2000 23:12:27 UTC