[siesta] Another Siesta approach

Robert Moskowitz <rgm@labs.htt-consult.com> Wed, 04 December 2013 11:20 UTC

Return-Path: <rgm@labs.htt-consult.com>
X-Original-To: siesta@ietfa.amsl.com
Delivered-To: siesta@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D91F71AE106 for <siesta@ietfa.amsl.com>; Wed, 4 Dec 2013 03:20:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lNh_Kv-Hi5zH for <siesta@ietfa.amsl.com>; Wed, 4 Dec 2013 03:20:54 -0800 (PST)
Received: from klovia.htt-consult.com (klovia.htt-consult.com [IPv6:2607:f4b8:3:0:218:71ff:fe83:66b9]) by ietfa.amsl.com (Postfix) with ESMTP id 168081AE242 for <siesta@ietf.org>; Wed, 4 Dec 2013 03:20:53 -0800 (PST)
Received: from localhost (unknown [127.0.0.1]) by klovia.htt-consult.com (Postfix) with ESMTP id 054F762A6E for <siesta@ietf.org>; Wed, 4 Dec 2013 11:20:46 +0000 (UTC)
X-Virus-Scanned: amavisd-new at localhost
Received: from klovia.htt-consult.com ([127.0.0.1]) by localhost (klovia.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LPzArwjvjeiZ for <siesta@ietf.org>; Wed, 4 Dec 2013 06:20:34 -0500 (EST)
Received: from lx120e2.htt-consult.com (ip-64-134-168-45.public.wayport.net [64.134.168.45]) (Authenticated sender: rgm@labs.htt-consult.com) by klovia.htt-consult.com (Postfix) with ESMTPA id 1EA3A62A6B for <siesta@ietf.org>; Wed, 4 Dec 2013 06:20:33 -0500 (EST)
Message-ID: <529F1000.5040006@labs.htt-consult.com>
Date: Wed, 04 Dec 2013 06:20:32 -0500
From: Robert Moskowitz <rgm@labs.htt-consult.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7
MIME-Version: 1.0
To: siesta@ietf.org
Content-Type: multipart/alternative; boundary="------------070306010901040805000103"
Subject: [siesta] Another Siesta approach
X-BeenThere: siesta@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "SessIon layEr SecuriTy Approach discussion list." <siesta.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/siesta>, <mailto:siesta-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/siesta/>
List-Post: <mailto:siesta@ietf.org>
List-Help: <mailto:siesta-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/siesta>, <mailto:siesta-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 04 Dec 2013 11:20:58 -0000

I saw this come through on the SAAG list, so it is appropriate to bring 
it up here and see how well it fits the problem statement and goals I 
have attempted to articulate:

=========================================

On 11/25/2013 09: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
apps-discuss@ietf.org  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<iesg-secretary@ietf.org>
Reply-To:ietf@ietf.org
To: IETF-Announce<ietf-announce@ietf.org>

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<barryleiba@computer.org>


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.

- 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: