FYI,
Carl-Uno
>>Minutes from TLS Working Group Meeting
>40th IETF, Washington, DC
>10 December 1997
>Reported by Win Treese <treese at OpenMarket.com> (WG Chair), based in part
>on notes by Chris Allen <ChristopherA at Consensus.com>.
>>Mailing list: ietf-tls at consensus.com>Web site: http://www.consensus.com/ietf-tls>>Win Treese called the meeting to order, with the following agenda:
>>- Status
>- Old business: ports, patents, IANA registration
>- Other drafts before the WG: Kerberos, SSL Tunneling Proxy
>- Applications using TLS
>- Description of server-gated crypto (Dierks)
>- Implementation notes
>- Next Steps
>- Summary of Actions
>>Status
>-------
>The TLS draft has been moved by the IESG to Proposed Standard, and it
>will be issued as an RFC shortly. Congratulations to everyone on the
>working group for contributing to this milestone.
>>>Old Business
>------------
>>Ports. Over time, there has been much discussion about whether or not
>TLS applications should use different ports from their non-TLS
>relatives. This decision must be made for each application
>individually, so the issue is out of scope for the working group. As it
>turns out, many applications are negotiating TLS within their own
>protocols.
>>Patents. There has been some concern about a patent for SSL recently
>issued to Netscape. Netscape has provided a statement that is appended
>to the TLS specification. In general terms, Netscape is granting a
>royalty-free patent license to anyone who implements TLS, as long as
>they do not assert that Netscape's implementation infringes on any
>patents they hold. See the forthcoming RFC for the precise statement.
>>IANA registration of ciphersuites and other numbers. Based on advice
>from several sources, new TLS ciphersuites and similar identifiers will
>not be registered through the IANA. Rather, they will be the subject of
>new documents, which may be put on the standards track as appropriate.
>>Other Drafts
>------------
>>Two other drafts are before the working group:
>>Kerberos ciphersuites for TLS. This document has been on hold until the
>main draft moved to Proposed Standard. Now that it has, the Kerberos
>document will be sent out for last call in the working group as soon
>as an updated revision is available.
>>SSL Tunneling for HTTP. This document is not formally before the
>working group, but it might make sense for the WG to adopt it. Win
>Treese will discuss this with the author.
>>Applications
>------------
>>Quite a few application protocols are specifying TLS. These include
>SOCKS, LDAP, FTP, SMTP, IMAP4+POP3, and PPP EAP. WebDAV and IPP are in
>progress and planning to use TLS. At this point, there is no draft
>specifying the use of TLS with HTTP (for any version of HTTP). Eric
>Rescorla volunteered to write a draft describing the current usage of
>HTTP 1.0 over TLS, and we will try to find one for HTTP 1.1 as well.
>>Paul Hoffman noted that LDAP with TLS is currently before IESG, with
>SMTP over TLS and IMAP4+POP3 likely to follow.
>>Bob Morgan, author of LDAP over TLS, is interested in hearing from WG
>members about the way LDAP uses TLS.
>>Carl-Uno Manros, co-chair of the IPP working group, said that IPP has
>all printing related issues done, but still are wobbly on exact use of
>TLS. Issues are using insecure way. They wanted to use null_null_null,
>but this is not allowed. They are packaging IPP it over http.
>>Micheal Bowe said the TN3270 working group has a problem: if a suitable
>ciphersuite can't be negotiated, the TCP connection must be dropped. A
>response from the floor was that this was changed in the latest TLS
>draft. Only TLS has to be dropped, not the TCP connection.
>>Discussions of TLS applications take place on the mailing list
>ietf-apps-tls at imc.org.>>Server-Gated Crypto
>-------------------
>>Tim Dierks described a mechanism called by some "server-gated
>cryptography." Variations of this are used by both Netscape and
>Microsoft. The idea is that a client may be exported from the US with
>both strong and export-grade cryptography, but the strong cryptography
>is enabled only if the server has a particular kind of certificate.
>>In both SSL and TLS, the client must drop the connection and restart
>the handshake once it knows that it can use additional ciphers. It
>would simplify things if the client can simply send a new hello message.
>>A more detailed proposal will be forthcoming.
>>TLS Implementation Warning
>--------------------------
>>Tim Dierks also warned implementors about the following problem so
>they would not repeat it:
>> The definition of an SSL/TLS vector <1..65335> is:
>> Hi Lo Contents
> |LM|LL| | | | ...
> In all SSL implementations, the client key exchange field is
> miscoded in RSA and RSA_EXPORT key exchanges: it is missing the
> length field. Please avoid this error in TLS implementations.
>>Next Steps
>----------
>>Chris Allen noted that the applications protocols are, in essence, our
>customers now, and we should talk to them often.
>>There were a number of proposed changes discussed in Memphis (two
>meetings ago), but we have not seen detailed proposals or new drafts to
>follow up on them. There is continued interest in combining IPSec key
>exchange mechanisms with TLS.
>>Thanks to Chris Allen for taking the notes during the WG meeting.
>>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