Re: What to advertise when mandatory ciphers not implemented

According to John Myers:
> Due to scheduling constraints, it is likely that some future release of
> Netscape's messaging server will be capable of supporting the STARTTLS
> mechanism in IMAP and SMTP, but will not be capable of supporting the
> ciphers which the TLS specification makes mandatory.
    If it doesn't support the MUST sections of the TLS document then you 
should not call it TLS as it is not TLS by definition. It is that simple.

> 1) I can advertise the STARTTLS extension even though the extension does
> not conform to the mandatory-to-implement cipher requirements.
    This is not a smart thing to do ... if it isn't TLS then using STARTTLS
is not the right approach. This certainly sets the wrong precedence.

> 2) I can advertise a private XSTARTSSL extension which behaves exactly
> like STARTTLS, but does not have the mandatory cipher requirement.
    One option is to just call it STARTSSL ... I did argue for this being 
acceptable in a number of public and private forums but was told that everyone 
will support TLS and SSLv3 is no longer relevant. Personally I think that
adding a mechanism that allowed for SSLv3 *or* TLSv1 support would have
avoiding the fun and games that are about to commence as TLS implementations
start making their way into products.

    What sections of the TLS specification do you anticipate will not be 
supported? Are there plans to do a proper TLS implementation?

> (The trick is to keep marketing from claiming TLS conformance.)  
    You will be the first non-marketing person to achieve that in my
experience ... how could you reasonably expect something that supports 
STARTTLS to not imply that TLS was supported? Certainly if you did achieve
that then I'm sure others would be interesting in learning your secret :-)

Tim.