[Uta] How can we help app developers and operators FIND the UTA go-to security guides?

Dan York <york@isoc.org> Tue, 18 February 2014 22:01 UTC

Return-Path: <york@isoc.org>
X-Original-To: uta@ietfa.amsl.com
Delivered-To: uta@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48BD01A02A3 for <uta@ietfa.amsl.com>; Tue, 18 Feb 2014 14:01:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-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 popo-5031yi1 for <uta@ietfa.amsl.com>; Tue, 18 Feb 2014 14:01:49 -0800 (PST)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0153.outbound.protection.outlook.com [207.46.163.153]) by ietfa.amsl.com (Postfix) with ESMTP id 4D5651A0296 for <uta@ietf.org>; Tue, 18 Feb 2014 14:01:49 -0800 (PST)
Received: from BLUPR06MB243.namprd06.prod.outlook.com (10.242.191.154) by BLUPR06MB243.namprd06.prod.outlook.com (10.242.191.154) with Microsoft SMTP Server (TLS) id 15.0.878.16; Tue, 18 Feb 2014 22:01:44 +0000
Received: from BLUPR06MB243.namprd06.prod.outlook.com ([169.254.2.87]) by BLUPR06MB243.namprd06.prod.outlook.com ([169.254.2.59]) with mapi id 15.00.0878.008; Tue, 18 Feb 2014 22:01:44 +0000
From: Dan York <york@isoc.org>
To: "uta@ietf.org" <uta@ietf.org>
Thread-Topic: How can we help app developers and operators FIND the UTA go-to security guides?
Thread-Index: AQHPLPUCPcx2vXQRbU+gDR1eOwHODA==
Date: Tue, 18 Feb 2014 22:01:43 +0000
Message-ID: <CF294275.63067%york@isoc.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.255.101.5]
x-forefront-prvs: 0126A32F74
x-forefront-antispam-report: SFV:NSPM; SFS:(10019001)(6009001)(377454003)(164054003)(24454002)(479174003)(199002)(189002)(35774003)(52254002)(56816005)(49866001)(85306002)(87266001)(74662001)(19580395003)(47736001)(19580405001)(83322001)(47446002)(87936001)(80976001)(86362001)(15202345003)(4396001)(92726001)(63696002)(81542001)(59766001)(31966008)(50986001)(85852003)(77982001)(47976001)(83072002)(79102001)(74502001)(46102001)(2656002)(90146001)(80022001)(65816001)(92566001)(74366001)(94316002)(77096001)(81342001)(53806001)(54356001)(76796001)(76786001)(81816001)(51856001)(15395725003)(15975445006)(16236675002)(69226001)(95416001)(95666001)(93516002)(74876001)(93136001)(81686001)(76482001)(36756003)(76176001)(94946001)(54316002)(74706001)(56776001)(16573002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR06MB243; H:BLUPR06MB243.namprd06.prod.outlook.com; CLIP:10.255.101.5; FPR:AC44F11D.AEEAA5C1.EED36377.4C67B961.20538; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
Content-Type: multipart/alternative; boundary="_000_CF29427563067yorkisocorg_"
MIME-Version: 1.0
X-OriginatorOrg: isoc.org
Archived-At: http://mailarchive.ietf.org/arch/msg/uta/3y7zdikkPrAqcNsnKqPSXrxsGe4
Subject: [Uta] How can we help app developers and operators FIND the UTA go-to security guides?
X-BeenThere: uta@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: UTA working group mailing list <uta.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/uta>, <mailto:uta-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/uta/>
List-Post: <mailto:uta@ietf.org>
List-Help: <mailto:uta-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/uta>, <mailto:uta-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 18 Feb 2014 22:01:53 -0000

On 2/10/14 3:49 AM, "Orit Levin (LCA)" <oritl@microsoft.com>; wrote:

> UTA deliverables are intended to serve as the go-to security guides for applications'
> developers and providers/operators. Navigating through numerous IETF RFCs (and drafts)
> in order to implement a specific protocol or deploy a service can be a very challenging task.

I think this is a key point and one reason I'm personally so pleased to see this UTA working group created.  We definitely need to make it easier for application developers to understand how they can best implement TLS in their applications - and for network operators to best allow customers to use TLS-encrypted apps while still meeting their own operational and security needs.

While the focus of the UTA group and list right NOW needs to be on *creating* these "go-to security guides", I'd like to suggest that there's a second stage that needs to be thought about later in the process... and perhaps it is something that a few of us who are not directly involved in writing the documents can start thinking about now.  This second stage is to answer these questions:

1. How will application developers find these "go-to security guides"?  How will they learn that we've created them?
2. How will network operators / ISPs find these "go-to security guides" that help them understand how they can best work with TLS-encrypted application traffic?

The basic question is - if we write these docs and publish them as RFCs (or BCPs), how can we help people know that these documents are out there to help them?

There's a second aspect, too - how will they know we are in the process of *writing* these documents and that we are seeking feedback?

In thinking about some of the application developers I know, I don't think many of them have a particular connection to the IETF and wouldn't necessarily think of RFCs as a source for documentation like this.  Similarly, I think many network operators (particularly smaller ones) don't have a strong connection to the IETF - or if they do, it may be more with some of the networking parts of the IETF versus something in the applications area.

I know that within the IETF we generally have a vehement allergic reaction to anything that remotely smells of (cough)(cough)"marketing"(cough)(cough) ... but if our end goal is to make activity over the Internet more secure through the widespread use of TLS, I think we *do* need to think about how we promote the fact that we (IETF) will have these "go-to security guides" available.

What do others think?   Are there people on the list now interested in talking a bit more about this?  Either on the list or sometime in London? (Perhaps outside of the main UTA meeting so as not to distract from a focus on getting the documents done?)

I have one way that I can personally help with this second stage of work.  The team I work on within the Internet Society operates the Deploy360 website ( http://www.internetsociety.org/deploy360/ ) and our task is to find, create and publicize materials to help accelerate the deployment of Internet technologies like IPv6 and DNSSEC.  Most recently we opened up a topic area on "Securing BGP" to help promote best practices and technologies that make BGP more secure.  Our focus is on finding (or creating if we can't find) high-quality materials with real-world deployment info and then sharing that out through social media, specialized conferences, speaking at events, online interaction, etc.

In talking about how we could help with this work here, it occurred to us that we could open up a new topic on the Deploy360 site about "TLS in Applications" and help promote the work this group is doing and do what we can to encourage developers and network operators to read the current drafts, provide feedback and get engaged with the process.  As the UTA documents get published we can then help promote the documents.  We can also promote other documents, tutorials, videos, etc. that people have created that would complement the guidance being written in these documents... and work with anyone interested from the list to make all this happen.

Some of you know of our work... does this seem like a reasonable way we (Deploy360) could help?

If so I'm glad to help in that way... but I'd also note that anything we can do on Deploy360 is just a part of what I see as the broader need to help people find these documents.  Our efforts will help, but there needs to be more done by more people than just us.

Thoughts? Comments?  Feedback?   (Including telling me why I'm wrong about any or all of this...)

Thanks,
Dan

--
Dan York
Senior Content Strategist, Internet Society
york@isoc.org <mailto:york@isoc.org>   +1-802-735-1624
Jabber: york@jabber.isoc.org <mailto:york@jabber.isoc.org>
Skype: danyork   http://twitter.com/danyork

http://www.internetsociety.org/deploy360/