Subject: IPP> ADM - Minutes for TLS WG meeting, 12/10/97

From: Carl-Uno Manros <[email-masked]>
Date: Fri, 2 Jan 1998 10:00:17 PST

FYI,

Carl-Uno

>
>Minutes from TLS Working Group Meeting
>40th IETF, Washington, DC
>10 December 1997
>Reported by Win Treese <[email-masked]> (WG Chair), based in part
>on notes by Chris Allen <[email-masked]>. 
>
>Mailing list: [email-masked]
>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
>[email-masked]. 
>
>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: [email-masked]