Re: [Uta] Proposed definition of opportunistic encryption using TLS: draft-hoffman-uta-opportunistic-tls-00.txt
Stephen Farrell <stephen.farrell@cs.tcd.ie> Tue, 04 February 2014 00:47 UTC
Return-Path: <stephen.farrell@cs.tcd.ie>
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 42DE91A02B4 for <uta@ietfa.amsl.com>; Mon, 3 Feb 2014 16:47:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.435
X-Spam-Level:
X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535] 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 CeNPvKrOW9ib for <uta@ietfa.amsl.com>; Mon, 3 Feb 2014 16:47:23 -0800 (PST)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 83CED1A026A for <uta@ietf.org>; Mon, 3 Feb 2014 16:47:23 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id BC7BDBE29; Tue, 4 Feb 2014 00:47:22 +0000 (GMT)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z1HLVACQ1xAZ; Tue, 4 Feb 2014 00:47:19 +0000 (GMT)
Received: from [10.87.48.10] (unknown [86.45.58.86]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id B17B5BE25; Tue, 4 Feb 2014 00:47:19 +0000 (GMT)
Message-ID: <52F03897.5090403@cs.tcd.ie>
Date: Tue, 04 Feb 2014 00:47:19 +0000
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: Paul Hoffman <paul.hoffman@vpnc.org>
References: <20140203045910.9714.53880.idtracker@ietfa.amsl.com> <B8691415-07F3-4081-8247-E103A60E5CF0@vpnc.org> <52EF8F72.4050905@cs.tcd.ie> <3C6E4DFB-AD3D-421C-ACBD-151AEDFE0124@vpnc.org>
In-Reply-To: <3C6E4DFB-AD3D-421C-ACBD-151AEDFE0124@vpnc.org>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Cc: uta@ietf.org
Subject: Re: [Uta] Proposed definition of opportunistic encryption using TLS: draft-hoffman-uta-opportunistic-tls-00.txt
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, 04 Feb 2014 00:47:28 -0000
Hi Paul, On 02/03/2014 04:43 PM, Paul Hoffman wrote: > On Feb 3, 2014, at 4:45 AM, Stephen Farrell > <stephen.farrell@cs.tcd.ie> wrote: > >> On this one, I don't really care which, if any, WG, ends up >> processing a draft defining these terms, but it is important that >> the definitions related to the use of the term opportunistic and >> crypto be ones that work for more than TLS, this WG and the apps >> area, but are as well accepted for the entire IETF. For example, >> IPsec and even MPLS folk should be able to use the same terms >> without confusion arising. > > That would be nice, but it is also impossible. Having one coherent set of definitions seems entirely possible to me. > What *is* possible is > that each area's use of "opportunistic encryption using XYZ" felt > similar enough to prevent confusion. If you insist that all possible > definitions be in a single document, "insist"? Anyway what I'm asking for is a coherent set of definitions documented sensibly however best that's done. Seems quite far from insisting on anything to me. > the understanding of specific > use case (here, TLS) will be greatly diminished. > > As you can see for this document, whatever the apps-with-TLS folks > here in UTA do, we need to deal with terms for both "opportunistic > encryption" *and* "unauthenticated TLS". For some of the other places > that need to deal with "opportunistic encryption", the latter is not > needed. Similar issues arise elsewhere IMO. > Assuming that there are approximately five definition documents, > someone could write a short directory document that lists them and is > updated when new ones are added. That sounds wrong to me. I'd like to know why we can't have one set of generic definitions used by many other documents. >> Note also that there will be discussion on this topic at the STRINT >> w/s before IETF-89 and I have some hope that we can get agreement >> quickly enough between there and the following week of meetings >> that it won't matter which WG "owns" the draft. > > A different, and I hope better, conclusion from the workshop would be > agreement about what areas need definitions of "opportunistic > encryption using XYZ" and start coordination among them. Not sure I agree. Minor point though. >> On your draft Paul, I don't think it really covers that charter >> work item since it only has some definitions. But that said, if we >> conclude a WG document is better, I'm fine if this WG is the place >> to write down the definitions so long as those are more broadly >> accepted. > > The charter item is limited to TLS. Are you saying you want the WG to > ignore that and try to work with other encryption mechanisms as > well? No. I'm saying that the charter item was intended to allow the WG to (if necessary) define a way to do unauthenticated TLS that is not ANON-DH. Your draft does none of that (currently at least). >> And a few more near-random comments: >> >> Ending up with substantively different definitions for the term >> opportunistic e.g. when used with TLS and IPsec would be a dumb >> outcome IMO. > > Fully agree. > >> At present we do have such confusion and we do need to fix that, so >> a draft like Paul's that does define the terms is something we do >> want. I know that Steve Kent is also working on a different draft >> that defines these terms, perhaps differently. I've not thought >> about which of the two might be a better starting point, and >> Steve's isn't yet published so others can't either. (Steve's text >> will be published at the end of this week with other STRINT >> submissions though.) > > Steve let me see an early pre-draft of his draft. It is quite > comprehensive and complicated. While it might be useful to security > experts and academics, I don't think that is as helpful to protocol > developers as a short, concise document such as this one. Maybe. Or maybe not. Not sure yet myself. But again, I mostly care about a coherent set of definitions that won't confuse folks and a lot less about how we get that into an RFC. S. > > --Paul Hoffman _______________________________________________ Uta > mailing list Uta@ietf.org https://www.ietf.org/mailman/listinfo/uta > >
- [Uta] Proposed definition of opportunistic encryp… Paul Hoffman
- Re: [Uta] Proposed definition of opportunistic en… Olle E. Johansson
- Re: [Uta] Proposed definition of opportunistic en… Stephen Farrell
- Re: [Uta] Proposed definition of opportunistic en… Alan Johnston
- Re: [Uta] Proposed definition of opportunistic en… Paul Hoffman
- Re: [Uta] Proposed definition of opportunistic en… Paul Hoffman
- Re: [Uta] Proposed definition of opportunistic en… Alan Johnston
- Re: [Uta] Proposed definition of opportunistic en… Daniel Kahn Gillmor
- Re: [Uta] Proposed definition of opportunistic en… Leif Johansson
- Re: [Uta] Proposed definition of opportunistic en… Daniel Kahn Gillmor
- Re: [Uta] Proposed definition of opportunistic en… Alan Johnston
- Re: [Uta] Proposed definition of opportunistic en… Daniel Kahn Gillmor
- Re: [Uta] Proposed definition of opportunistic en… Paul Hoffman
- Re: [Uta] Proposed definition of opportunistic en… Paul Hoffman
- Re: [Uta] Proposed definition of opportunistic en… Paul Hoffman
- Re: [Uta] Proposed definition of opportunistic en… Daniel Kahn Gillmor
- Re: [Uta] Proposed definition of opportunistic en… Paul Hoffman
- Re: [Uta] Proposed definition of opportunistic en… Stephen Farrell
- Re: [Uta] Proposed definition of opportunistic en… Alan Johnston
- Re: [Uta] Proposed definition of opportunistic en… Paul Hoffman