Re: TLS and ACAP/IMAP/POP

On Fri, 17 Apr 1998, Chris Newman wrote:

> There was a brief discussion of this specification at the ACAP WG (it's
> not a WG document, but is related to the WG):
> 
>  <ftp://ds.internic.net/internet-drafts/draft-newman-tls-imappop-03.txt>
> 
> At the meeting it was suggested that language be added concerning shutting
> down the TLS connection without shutting down the underlying TCP 
> connection.  I don't know how to write this or what needs to be said, if
> anything.  

As Paul mentioned, this has come up in the process of finishing up the
LDAP-over-TLS spec, and has (we think) been resolved.  Tim Dierks has
suggested the following for the TLS protocol spec:

 Existing text:

   Each party is required to send a close_notify alert before closing
   the write side of the connection. It is required that the other
   party respond with a close_notify alert of its own and close down
   the connection immediately, discarding any pending writes. It is not
   required for the initiator of the close to wait for the responding
   close_notify alert before closing the read side of the connection.

 Text to be added:

   If the application protocol using TLS provides that any data may be
   carried over the underlying transport, the TLS implementation must
   recieve the responding close_notify alert before indicating to the
   application layer that the TLS connection has ended. If the
   application protocol will not transfer any additional data, but
   will only close the underlying transport connection, then the
   implementation may choose to close the transport without waiting for
   the responding close_notify.

The ldapv3-tls draft spec has the following:

  5.1.  Graceful Closure

  Either the client or server MAY terminate the TLS connection on an LDAP
  association by sending a TLS closure alert. This will leave the LDAP
  association intact.

  Before closing a TLS connection, the client MUST either wait for any
  outstanding LDAP operations to complete, or explicitly abandon them
  [LDAPv3].

  After the initiator of a close has sent a closure alert, it MUST discard
  any TLS messages until it has received an alert from the other party.
  It will cease to send TLS Record Protocol PDUs, and following the
  reciept of the alert, MAY send and receive LDAP PDUs.

  The other party, if it receives a closure alert, MUST immediately
  transmit a TLS closure alert.  It will subequently cease to send TLS
  Record Protocol PDUs, and MAY send and receive LDAP PDUs.

Similar language would presumably work in the IMAP/POP/ACAP draft.

> There are other issues concerning restrictions on certificates
> and naming in certificates which were raised by others and may also not be
> well specified by reference.

You may be referring to the issue of whether the TLS client should check
the server cert, and just what it should check for.  We have also
considered this in LDAP-TLS.  There is proposed language for this action
in draft-ietf-tls-https-01.txt (which is a spec documenting current
practice, not proposing new better practice). Debate at the ldapext WG
session in LA indicated that there is a diversity of opinion on the topic,
from "the client MUST do it or you've thrown security out the window" to
"this is a black hole of poorly-defined nasty interminable issues".  Some
might hold both opinions (8^).

One murky issue:  PKIX has gone back and forth on whether the "*" wildcard
character is allowed in DNS-style subjectAltNames.  I think the decision
in LA was to put them back in, but it's still up in the air until PKIX
part 1 is really finally done.  Furthermore, PKIX part 1 doesn't say
exactly how the * is used in matching; this is left to apps.

The other murky issue:  should the client compare against whatever name it
used to initiate the connection, or try to come up with the host's
canonical name (as Kerberos does)?  The former is easier for the client
but would presumably require the server to have all of its aliases in its
cert.

If I were the IESG I'd like to see all TLS-using apps protocols address
this server-name-checking issue the same way.  But exactly what that way
is isn't obvious to me.

> I see two choices:
> 
> (1) Delay this indefinitely until a co-author volunteers who is
> comfortable writing the necessary text.  I don't have time to learn all
> about variations in X.509 certs and SSL/TLS APIs which I consider 
> necessary to write clear text on these topics.
> 
> (2) Do an IETF 4 week last call on the current document, publish as a 
> proposed standard RFC and if it is necessary to revise it later we can 
> recycle at proposed status.
> 
> I favor option (2) as I believe it is more important to have a standards
> track spec describing how to integrate TLS into these protocols than it is
> to have a perfect spec.  If I get no complaints, I will ask for a last
> call on the current spec in one week.  Otherwise I will wait for a
> volunteer (anyone who complains will be the obvious choice for
> co-author :-).

I suggest that dealing with the connection-closing issue is easy, and
should just be done.  The server-name-checking is not, so the quickest way
forward is to leave it out and if it makes it through last call that way,
yippee.

 - RL "Bob" Morgan
   Stanford