Recently some comments were brought up at the 39th IETF meeting held in Munich
related to security. Some of the questions, and my clarifications are written
below.
Q: Why not start a secure session and then drop to an insecure level.
A: You could have two separate sessions - first secure - then drop the session
- and then start a new insecure session. You cannot drop to an insecure level
in one session. However, once a secure session has been started, it is not
advisable to drop to an insecure level or session. First, it is usually not a
security practice. Second, security protocols do not allow such a transition.
For example, such a thing does not exist in SSL, nor can Netscape visualize
having such a feature in SSL in the near future. Third, customers or clients
who have security would continue to make use of that session rather than
switch to an insecure session immediately following a secure session. Fourth,
you may find certain customers or clients not to have security features
(i.e., the relevent certificates, browsers or software) on their system and
hence may want to start an insecure session first and then discover that they
require certificates to continue with the print request. This essentially
means that they may want to start off in an insecure inquistive mode, but move
over to a secure exchange later on. Finally, the very purpose of having a
secure session is lost if you want to drop to an insecure level later on.
This may give rise to other questions:
a. Don't you think that SSL encrypts data, and this is time consuming? Users
may want to switch to a lower level just for that reason. The answer is
simple, there is nothing you can do about it in the current version of SSL. If
you do not want to encrypt, the best you can do is use the fetch-and-print
feature where you can fetch a document without encryption and print it off.
This is the print-by-reference feature. Then, this is how we need to design
this.
b. Then how about starting an insecure session and then moving over to a
secure session? The answer is again simple, one cannot do the transition in a
single step. First, one will discover that the print request requires a secure
session by looking at the HTTP 403 error message. Then, one should use https
or provide the required and necessary certificates (in case you are already
using https) to make a secure session. I demo'ed this to you on Monday.
c. So, what do you think? should I use an LDAP server to know if a printer
can communicate securely? No. It is not necessary to use LDAP to discover the
printer's secure capabilities. As explained above, the server to which the
printer is tied has the capability of notifying the client that it needs to
use a secure SSL exchange.
Q: I am not sure if a client can connect to a https port when it uses a http
URL.
A: Again, I showed this to you. The client will get an error message. Ah - now
we need IPP to interpret this message - Is the client using http instead of
https or is it just that the client does not have the right certificates or is
due to something else? The error message is - "Access Forbidden Secure Channel
Required - This ... requires a browser that supports the configured encryption
options". By looking at this error message, one is not sure if the encryption
options are correctly used (as one sets it up in netscape browser) or if it is
just the wrong use of http instead of https. This is something that HTTP or
HTTP-NG needs to look into, and probably pass on a different error for
different things. This is not IPP's task. I do remember that we need to
participate in HTTP-NG efforts for security too.
Q: Why don't we start with SSL2 and then transition to SSL3?
A: Remember, TLS supports servers that can talk either SSL2 or SSL3. This
transition should be transparent though it should be verified. However, we do
not have an implementation of TLS available at this time. It is hard to check
this with current implementations of SSL2 and SSL3 separately. We probably
need changes to SSL client software.
Dan.