Re: What to advertise when mandatory ciphers not implemented

Tim Hudson wrote:
>     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.

I wasn't talking about calling it TLS, I was talking about piggybacking the
IMAP and SMTP extensions named STARTTLS.  The definitions of those extensions
aren't yet carved in stone, my proposal could be made technically legal.

> 
> > 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.

IETF lore tends to set interoperability before elegance.  Sounds like the
right precedence to me.

>     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.

Full TLS support has apparently taken longer than originally suspected.  It is
likely to miss a product release.  In any case, this is a short-term issue,
should it be solved by creating a potential long-term interoperability problem?

> 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.

Likewise, and I think that this mechanism should be called STARTTLS. 
Interoperability is not served by having two different extensions, both of
which are capable of negotiating TLSv1.

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

I don't have all the details, but it will likely be SSL v3.0, not v3.1.  I've
arranged it so that no SSL v2 ciphers will ever be offered by the server. 
Yes, there are plans on doing a proper TLS implementation.  Of course, that
implementation would only be available domestically.  Is any of this relevant
to the question at hand?

> > (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 :-)

When talking to marketing, I don't use the term "TLS", I use the term "SSL". 
I also volunteer to review their compliance document.