And thats assuming that all the server installed base upgrade
when these TLS servers become available (which is unlikely).
I'm open to other wording in the spec, but we need to
document that SSL3 servers CAN interoperate with clients
that implement TLS, and vice versa.
And I totally agree that we need to try to meet our security
requirements without mandating encumbered security
mechanisms. To this end, some combination MD5,
Diffie-Hellman, and Triple-DES should give us a reasonable
level of security.
I don't feel that these technologies place an undue
burden on simple IPP services since we have agreed that
"secure" IPP clients and servers are optional.
Randy
> -----Original Message-----
> From: Keith Moore [SMTP:moore@cs.utk.edu]
> Sent: Monday, December 08, 1997 10:23 AM
> To: Carl-Uno Manros
> Cc: ipp@pwg.org; Harald.T.Alvestrand@uninett.no; moore@cs.utk.edu
> Subject: IPP> Re: Area Directors' comments on IPP
>
> > 1) Support for SSL3 in TLS. Harald and Keith wanted to make sure
> that our
> > specs say that we MUST support the mandatory features that are
> minimum
> > requirements for TLS, such as the cypher suite.
>
> 1. IESG has not allowed other groups to reference SSL, and it unlikely
> that an exception would be made for IPP. If IPP uses SSL-like
> technology, the reference should be to the TLS RFC.
>
> 2. If IPP specifies TLS authentication, IPP must either implicitly use
> the mandatory ciphersuite from the TLS spec, or specify at least one
> mandatory TLS ciphersuite.
>
> 3. It will be very difficult for IPP to convince IESG to accept any
> mandatory TLS ciphersuite that uses encumbered algorithms, especially
> given that adequate unencumbered algorithms seem to be available.
>
> Suggestion: specify MUST implement ciphersuite
> TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA, and MAY (or SHOULD?) implement one
> or more of the ciphersuites commonly used with SSL3.
>
> Keith
>