Subject: Re: [apps-discuss] [saag] Fwd: WG Review: Using TLS in Applications (uta)

From: Joe Touch <[email-masked]>
Date: Tue, 03 Dec 2013 07:35:19 -0800

Comments below:

On 11/25/2013 6:27 AM, Stephen Farrell wrote:
>
> FYI, please note this proposed new APPS area WG. We'll need
> to try get a bunch of security folks involved in that so
> please consider spending a few cycles to help out with the
> work.
>
> I'd say discussion of that charter would be best done on
> [email-masked] since its proposed as an APPS area
> WG and the apps-discuss list is probably where there's
> the best concentration of relevant expertise, so please
> direct any substantive discussion there.
>
> Thanks,
> S.
>
>
> -------- Original Message --------
> Subject: WG Review: Using TLS in Applications (uta)
> Date: Fri, 22 Nov 2013 09:35:54 -0800
> From: The IESG <[email-masked]>
> Reply-To: [email-masked]
> To: IETF-Announce <[email-masked]>
>
> A new IETF working group has been proposed in the Applications Area. The
> IESG has not made any determination yet. The following draft charter was
> submitted, and is provided for informational purposes only. Please send
> your comments to the IESG mailing list (iesg at ietf.org) by 2013-12-02.
>
> Using TLS in Applications (uta)
> ------------------------------------------------
> Current Status: Proposed WG
>
> Assigned Area Director:
>    Barry Leiba <[email-masked]>
>
>
> Charter:
>
> There is a renewed and urgent interest in the IETF to increase the
> security of transmissions over the Internet. Many application protocols
> have defined methods for using TLS to authenticate the server (and
> sometimes the client), and to encrypt the connection between the client
> and server. However, there is a diversity of definitions and
> requirements, and that diversity has caused confusion for application
> developers and also has led to lack of interoperability or lack of
> deployment. Implementers and deployers are faced with multiple security
> issues in real-world usage of TLS, which currently does not preclude
> insecure ciphers and modes of operation.
>
> This WG has the following tasks:
>
> - Update the definitions for using TLS over a set of representative
> application protocols.  This includes communication with proxies, between
> servers, and between peers, where appropriate, in addition to
> client/server communication.
>
> - Specify a set of best practices for TLS clients and servers, including
> but not limited to recommended versions of TLS, using forward secrecy,
> and one or more ciphersuites and extensions that are mandatory to
> implement.
>
> - Consider, and possibly define, a standard way for an application client
> and server to use unauthenticated encryption through TLS when server
> and/or client authentication cannot be achieved.

See BTNS, RFC 5387. This ought to be very easy, but it's not clear 
whether associated connection latching (RFC 5660) is useful here, 
because there might not be a useful upper-layer security standard to 
latch to.

It would also be very important to discuss the limitations of TLS, 
notably in protecting the transport connection from interference (RFC 4953).

> - Create a document that helps application protocol developers use TLS in
> future application definitions.
>
> The initial set of representative application protocols is SMTP, POP,
> IMAP, XMPP, and HTTP 1.1. It is expected that other protocols that use
> TLS might later be updated using the guidelines from this WG, and that
> those updates will happen through other WGs or through individual
> submissions.
>
> The WG will make the fewest changes needed to achieve good interoperable
> security for the applications using TLS.  No changes to TLS itself will
> be made in this WG, and the WG will ensure that changes to current
> versions of popular TLS libaries will not be required to conform to the
> WG's specifications.
>
> This WG will collaborate with other IETF WGs, in particular with the TLS
> and DANE WGs.
>
> Milestones:
>
>
>
>
>
> _______________________________________________
> saag mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/saag
>