Section 5.7.3 has been added to define the use of TLS in messaging associations
(and there have been minor editorial changes elsewhere to match):

5.7.3.  Protocol Definition: Transport Layer Security

   This defines the use of transport layer security as a basic channel
   security mechanism.  Support for this protocol is mandatory;
   associations using it can carry messages with the transfer attribute
   Secure=True.  For use with TCP, implementation of TLS1.0 [11] is
   REQUIRED and implementation of TLS1.1 [12] is RECOMMENDED.  (If an
   unreliable transport such as DCCP or UDP is defined for GIST
   messaging associations in the future, TLS would be implemented with
   it using DTLS [37].)  This specification makes no additional
   requirements on the TLS implementation (e.g. ciphersuites or
   authentication mechanisms) since these can be negotiated within TLS
   itself.

   No higher-layer-addressing format is defined for TLS.

with references:

Normative:

   [11]  Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
         RFC 2246, January 1999.

   [12]  Dierks, T. and E. Rescorla, "The TLS Protocol Version 1.1",
         draft-ietf-tls-rfc2246-bis-13 (work in progress), June 2005.

Informative:

   [37]  Rescorla, E. and N. Modadugu, "Datagram Transport Layer
         Security", draft-rescorla-dtls-05 (work in progress),
         June 2005.

Changed to 'Text Proposed' on the basis that we have a working assumption.

[updated to refer to -07.]

The current status is probably that xTLS is our working assumption. However, it
seems reasonable to leave this open for future discussion.

The following (crude) pro/con list was outlined at the interim meeting;

TLS issues:
+) Widely available; nice APIs; implement in user space
-) Currently TCP/SCTP only; mainly restricted to certificate-based authentication

IPsec issues:
+) Widely available; wide choice of authentication infrastructures; works with
any transport
-) Horrible APIs (or none at all); may have to access kernel operation

And a followup from Roland Bless:
"...TCP remains vulnerable to the rogue packet problem (as Radia 
Perlman calls it), i.e. an attacker may inject a "valid" TCP packet
that will desynchronize the TCP/TLS connections, i.e. TCP will never
recover from that. In this respect, TLS is less robust than IPsec.
Possibly a combination of TCP/MD5+TLS may prevent this attack, but this
would not be so easy anymore..."

Updated to refer to -06 version; no other changes on this issue.

[updated to refer to -05; no other changes on this issue.]

The protocol specification allows channel security mechanisms to be negotiated,
but so far none have been defined. Obvious candidates are TLS, IPsec, maybe ssh.
Typically we will need to select a mandatory-to-implement one, and may also need
to define more precisely how it is used (e.g. if there are any options within it
which need to be chosen consistently to provide the necessary security services).