At 11:14 AM 12/16/97 PST, Michael Boe wrote:
>> Harald,
>>>> We have been following the TLS activities for some time and have also held
>> discussions with individual members of the WG. We were happy to use the TLS
>> functionality as documented up to their last draft but one, but in the
>> final version that was passed by the IESG they suddenly introduced some new
>> mandatory stuff, for which we have so far seen little or no rationale or
>> explanation.
>>>> Just now I am only interested to get a recommendation, from whoever
>> consider themselves qualified, about a "politically correct" combination of
>> TLS security features that provides the same functionality as SSL3. Is this
>> concrete enough?
>>Not really concrete enough. You are leaving it to the rest of us to figure
out
>(by scanning the last two versions of the TLS drafts) what it is you
object to.
>Guessing, I suppose it's:
>> a) the mandatory cipher-suite
> b) the prohibition of using (NULL,NULL) as a possible cipher-suite
>>Like yourself, I'm merely a "consumer" of the TLS spec. However, it became
>quite clear to me at the Munich IETF that these two items were going to
become
>part of the standard. How did I discover this? Just by attending the
meetings
>and having a few very short conversations with people more familiar with TLS
>than I was (and still am :-).
>>As I understand your complaints, these two new provisions conflict with your
>goals in the following ways:
>> i) printers are not (and shouldn't be?) high-cost items. Mandating a
>heavy-weight cipher suite that uses PKI-based authentication and a thick
>encryption mechanism drives up the price of a printer (and the price of
>education & maintenance associated with that printer).
>> ii) the manufacturers want to roll out security-capable product based on
>today's printer hardware specs. The technical "footprint" of most of today's
>printers really isn't up to implementing provisions (a) & (b) with any speed.
>> iii) the mechanism for IPP is HTTP (and, I suppose, HTTPS), and it sure
would
>be nice to use the same security mechanisms that HTTP/HTTPS uses. Use of
>anything other than SSL/TLS is going to complicate IPP security tremendously.
>>If I can be so bold, let me toss out conflict (ii) immediately. The easiest
>thing to solve in computing is CPU horsepower. Just wait half a year and
>somebody's going to offer a CPU unit that does things faster and with less
>wattage than what they currently available units do. A spec which has a
>lifetime of, say, ten to twenty years should not be hobbling itself to
>yesterday's CPU speeds.
>>Conflict (iii) is certainly legitimate, but is really only a conflict because
>of (i) and (ii). So let's put that on hold right now and see if (i) can be
>solved.
>>I'm suggesting that conflict (i) is the core of your problems. Is this
>correct? Can you expand on why (i) conflicts? What other conflicts am I
>missing?
>>/msb
>
Michael,
Sorry for being so late to reply, but I had managed to "save" most of my
vacation to the end of the year and was out of the office for most of the
time since your message.
Most of your analysis is correct and the main problems are really two:
1) Due to cost considerations for low end printers, it is desirable to be
able to allow printers to get away with using the security features that
are part of HTTP, including the features described in RFC 2069, which
offers some help in protecting the printer from unautherized use. A number
of IPP scenarios do not really need more protection in parallel to the use
of fax machines at present. The use of TLS is therefore an IPP option that
may or may not be supported by a particular printer. In the case where an
IPP Printer only supports either HTTP or HTTPS there is no problem, but in
the case where it may supports both, we still need a negotiation mechanism,
for which we had hoped to use the TLS negotion, with the option to come out
with the NULL-NULL-NULL case if only HTTP was needed. We now have to build
that kind of negotiation into our own application protocol instead (which
is probably a better solution after all).
2) Even in the case where printer vendors want to include TLS in IPP
products that are currently under development we have a timing problem. My
understanding is that there is only a handful or so guys that actually
build this kind of security software. They then produce SDKs that are being
used by everybody else, including some of the bigger guys. Last I checked,
nobody seemed to be prepared to supply a production quality SDK for TLS
earlier than mid to late 1998, to which you then need to add the time to
actually use the SDK and integrate and test it with the "real" product. I
am sure that you would have some sympathy for not including somebody elses
prototype or alpha code for TLS in a product that you expect to sell for
money and risk your good name as a vendor on.
Carl-Uno
Carl-Uno Manros
Principal Engineer - Advanced Printing Standards - Xerox Corporation
701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231
Phone +1-310-333 8273, Fax +1-310-333 5514
Email: manros at cp10.es.xerox.com