Re: draft-ietf-tls-http-upgrade reissued
Julien Pierre (jpierre@netscape.com)
Fri, 05 May 2000 19:27:42 -0700
This is a cryptographically signed message in MIME format.
--------------ms461C22525316104CDBFBF09D
Content-Type: multipart/mixed;
boundary="------------68AF001CF36FB0451CBAE0BF"
This is a multi-part message in MIME format.
--------------68AF001CF36FB0451CBAE0BF
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Hi,
Rohit Khare wrote:
> You know, we send the HTTP/1.1 and Host: tokens 100% of the time.
> Isn't that wasteful, too?
Not as much. I meant also that the 98% of the time security pop-up *
millions of users would be a huge waste of time. I'm sure most everyone
would disable the browser setting if it existed.
> >Now, suppose that in 2% of the cases, the request data was intended
> >to be confidential
> >and the user really didn't want to submit the data unsecured, but
> >the server didn't
> >negotiate TLS.
>
> This client would have to force the upgrade via OPTIONS as outlined
> in the spec.
But how would the end-user inform its client of the fact that he wanted
the data to be secure ? You would have to remember to "force" security
somehow before submitting on a form ?
The security requirement is usually dictated by application logic. I
think the web application should have a way to hint the client, in the
way of something in the referring document, so that it would happen
transparently.
I'm not criticizing the underlying network protocol. I'm criticizing the
URL specification that clients will use.
The server will support both HTTP and HTTP with TLS upgrade. But there is
no good way for the client to decide when to use which, since http://
URLs are used.
> >The whole point I'm trying to make is that there should be a way for
> >a web application
> >that is intended to be secure to enforce that fact and reasonably
> >function on a server
> >running on a common port with HTTP and TLS upgrade support. The
> >draft does not propose a
> >way to do that.
>
> We believe it does, the last-call in the working group and the ietf
> announce list believes it does, and now it falls to all of us,
> including yourself, to find out if any of that rough consenus can be
> backed by running code.
I am quite confident that I can, but I'm not convinced yet that this is
the right way to do it.
> An "application" -- say,
> http://www.foo.edu/randompath/ReallySecureApp.cgi should send back a
> 426 for ANY request for a resource under /randompath/. A "user" who
> requires the same can use OPTIONS. A user who does not care, but
> wants to follow the lead of the server, should reuse the Upgraded TLS
> connection as long as he would have an equivalent port 443.
Again, what mechanism tells the client to use OPTIONS ?
> And recall that this method is *not* being proposed as the idea for
> hypertext publishing. The common browser is too deployed to be
> changed in its ways.
I don't think that's true. The rate of adoption for new HTTP software may
not be what it was in 1994 - 1996, but HTTP is still evolving, and there
is still an evolution in the mainstream browsers and servers. In fact,
the whole reason I'm here on this list is that I'm trying to make the
Netscape server support this evolution. I know some Netscape client
engineers are reading this as well, and they would like to make it happen
on their side too.
The fact is, routable static IP addresses have become expensive due to
the fact that we are quickly running out of them. ISPs want a way to do
secure software virtual servers, without buying expensive IP addresses
for each. There is a demand in the marketplace for this, maybe not
necessarily for the purpose of hypertext publishing, but certainly for
electronic commerce. Since the current protocols do not allow this, the
solution calls for a new generation of servers and clients. It will
certainly take time to upgrade a significant portion of HTTP clients and
servers in use today, but I think it can happen gradually. My wish is to
see it happen using open IETF standards in the next generation of HTTP
servers and clients, rather than have to wait for the one after that,
once the quirks in the current specs are acknowledged.
--
for a good time, try kill -9 -1
--------------68AF001CF36FB0451CBAE0BF
Content-Type: text/x-vcard; charset=us-ascii;
name="jpierre.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Julien Pierre
Content-Disposition: attachment;
filename="jpierre.vcf"
begin:vcard
n:Pierre;Julien
tel;work:408 276 3664
x-mozilla-html:FALSE
url:http://www.iplanet.com
org:iPlanet E-commerce Solutions, a Sun-Netscape Alliance;Web Server
adr:;;;Santa Clara;California;95054;USA
version:2.1
email;internet:jpierre@netscape.com
title:Software Developer
x-mozilla-cpt:;31920
fn:Julien Pierre
end:vcard
--------------68AF001CF36FB0451CBAE0BF--
--------------ms461C22525316104CDBFBF09D
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
MIIIiQYJKoZIhvcNAQcCoIIIejCCCHYCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
BlwwggMPMIICeKADAgECAgIY9zANBgkqhkiG9w0BAQQFADCBkzELMAkGA1UEBhMCVVMxCzAJ
BgNVBAgTAkNBMRYwFAYDVQQHEw1Nb3VudGFpbiBWaWV3MRswGQYDVQQKExJBbWVyaWNhIE9u
bGluZSBJbmMxGTAXBgNVBAsTEEFPTCBUZWNobm9sb2dpZXMxJzAlBgNVBAMTHkludHJhbmV0
IENlcnRpZmljYXRlIEF1dGhvcml0eTAeFw0wMDAzMDkyMzA0NTNaFw0wMDA5MDUyMzA0NTNa
MIGFMRMwEQYKCZImiZPyLGQBGRYDY29tMRgwFgYKCZImiZPyLGQBGRYIbmV0c2NhcGUxIzAh
BgkqhkiG9w0BCQEWFGpwaWVycmVAbmV0c2NhcGUuY29tMRYwFAYDVQQDEw1KdWxpZW4gUGll
cnJlMRcwFQYKCZImiZPyLGQBARMHanBpZXJyZTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC
gYEA3QSGxo7n60AUq9zfp96BwOzboYbjYXBhxILxpbkJBSh6wlLqQvjlyO3EZ2+KwDZvgBuh
5Z6uy95ZTfT32bIrr0p97eNXLKGFEN87KQhR7kltc8CSelu0ZP3MsfqBYMnEJBH2myrWpySd
vflZR0cOz4jaudtp4/Stfx99rLL5YUcCAwEAAaN+MHwwEQYJYIZIAYb4QgEBBAQDAgWgMA4G
A1UdDwEB/wQEAwIEsDAfBgNVHSMEGDAWgBSiO2Uy9/cbifxVDQcBvIdIWv2QPTA2BggrBgEF
BQcBAQQqMCgwJgYIKwYBBQUHMAGGGmh0dHA6Ly9uc29jc3AubmV0c2NhcGUuY29tMA0GCSqG
SIb3DQEBBAUAA4GBAEXeJ+7JMiFzcHgDXl359MR39rWnjg8Bm9dWNnUwHeWyfWdWBoplIxQI
gVFRVsUrNuAR9C6SW5FMm8mbsKfZXh08jREidxoH3jgIkq8TrLdGe2WyWdWnPL2oSMDiTLW7
pDTg8IXQpmHPkomGgbxha+Pgn9lL4d17iaZT5Op3pO4rMIIDRTCCAq6gAwIBAgIBJzANBgkq
hkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAG
A1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMf
Q2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNv
bmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3
dGUuY29tMB4XDTk5MDYwMzIyMDAzNFoXDTAxMDYwMjIyMDAzNFowgZMxCzAJBgNVBAYTAlVT
MQswCQYDVQQIEwJDQTEWMBQGA1UEBxMNTW91bnRhaW4gVmlldzEbMBkGA1UEChMSQW1lcmlj
YSBPbmxpbmUgSW5jMRkwFwYDVQQLExBBT0wgVGVjaG5vbG9naWVzMScwJQYDVQQDEx5JbnRy
YW5ldCBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGB
AOLvXyx2Q4lLGl+z5fiqb4svgU1n/71KD2MuxNyF9p4sSSYg/wAX5IiIad79g1fgoxEZEarW
3Lzvs9IVLlTGbny/2bnDRtMJBYTlU1xI7YSFmg47PRYHXPCzeauaEKW8waTReEwG5WRB/AUl
Yybr7wzHblShjM5UV7YfktqyEkuNAgMBAAGjaTBnMBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYD
VR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMBEGCWCGSAGG+EIBAQQEAwIBAjAfBgNVHSME
GDAWgBRyScJzNMZV9At2coF+d/SH58ayDjANBgkqhkiG9w0BAQQFAAOBgQC6UH38ALL/QbQH
CDkMIfRZSRcIzI7TzwxW8W/oCxppYusGgltprB2EJwY5yQ5+NRPQfsCPnFh8AzEshxDVYjtw
1Q6xZIA0Tln6xlnmRt5OaAh1QPUdjCnWrnetyT1p5ECNRJdGb756wFiksR9qpw8pUYqBDSmO
neQPMwuPjSQ97DGCAfUwggHxAgEBMIGaMIGTMQswCQYDVQQGEwJVUzELMAkGA1UECBMCQ0Ex
FjAUBgNVBAcTDU1vdW50YWluIFZpZXcxGzAZBgNVBAoTEkFtZXJpY2EgT25saW5lIEluYzEZ
MBcGA1UECxMQQU9MIFRlY2hub2xvZ2llczEnMCUGA1UEAxMeSW50cmFuZXQgQ2VydGlmaWNh
dGUgQXV0aG9yaXR5AgIY9zAJBgUrDgMCGgUAoIGxMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B
BwEwHAYJKoZIhvcNAQkFMQ8XDTAwMDUwNjAyMjc0MlowIwYJKoZIhvcNAQkEMRYEFJ2SvWKE
BzjqvWIGv5sI0yNcBqdrMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN
AwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEoMA0GCSqGSIb3
DQEBAQUABIGAQYW1yPjvp2hlyepO27aJjlDuVzSuRoWya0R4C9FHgC9hnCFdy/m+c+cNAln2
0Ql8qttzbUyxIb3LfZSCLe++MsItkUD/QT4vkwlP76qVE0Kqt0ygY9RDQLTAUlJdf10xrhad
asr/IqamRBRVpX7l2IK/aoQvAU4bJCxzojQBBEg=
--------------ms461C22525316104CDBFBF09D--