Re: [dane] [saag] Need better opportunistic terminology
Paul Lambert <paul@marvell.com> Wed, 12 March 2014 00:28 UTC
Return-Path: <paul@marvell.com>
X-Original-To: dane@ietfa.amsl.com
Delivered-To: dane@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EE891A08A6; Tue, 11 Mar 2014 17:28:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.567
X-Spam-Level:
X-Spam-Status: No, score=-1.567 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, SPF_PASS=-0.001] autolearn=no
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 JouO2-OaYlC4; Tue, 11 Mar 2014 17:28:03 -0700 (PDT)
Received: from mx0b-0016f401.pphosted.com (mx0b-0016f401.pphosted.com [67.231.156.173]) by ietfa.amsl.com (Postfix) with ESMTP id 4E1C01A08A7; Tue, 11 Mar 2014 17:28:03 -0700 (PDT)
Received: from pps.filterd (m0045851.ppops.net [127.0.0.1]) by mx0b-0016f401.pphosted.com (8.14.5/8.14.5) with SMTP id s2C0QOp6025498; Tue, 11 Mar 2014 17:27:54 -0700
Received: from sc-owa03.marvell.com ([199.233.58.149]) by mx0b-0016f401.pphosted.com with ESMTP id 1jh9xj8gvp-2 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 11 Mar 2014 17:27:54 -0700
Received: from SC-vEXCH2.marvell.com ([10.93.76.134]) by SC-OWA03.marvell.com ([fe80::4561:8e1c:d59b:f770%17]) with mapi; Tue, 11 Mar 2014 17:27:53 -0700
From: Paul Lambert <paul@marvell.com>
To: Joe Touch <touch@isi.edu>, Stephen Kent <kent@bbn.com>, "dane@ietf.org" <dane@ietf.org>, saag <saag@ietf.org>
Date: Tue, 11 Mar 2014 17:27:52 -0700
Thread-Topic: [saag] [dane] Need better opportunistic terminology
Thread-Index: Ac89eXqdh5qFJQD5Q724mDexPHA3zQAB5Ikg
Message-ID: <7BAC95F5A7E67643AAFB2C31BEE662D018B8660CCD@SC-VEXCH2.marvell.com>
References: <CAMm+LwjF9To+w3K4RR=72BbLNE2hJa9CibWOEARYmODiuFNu9g@mail.gmail.com> <082D04F9-DBB4-4492-BE91-C4E3616AC24D@isi.edu> <531F85D5.2070209@bbn.com> <531F8A53.1040103@isi.edu> <531F8E5F.8030705@isi.edu>
In-Reply-To: <531F8E5F.8030705@isi.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.11.87, 1.0.14, 0.0.0000 definitions=2014-03-11_07:2014-03-11, 2014-03-11, 1970-01-01 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1305240000 definitions=main-1403110159
Archived-At: http://mailarchive.ietf.org/arch/msg/dane/wBMHuYULWPdKDynQGdlroasd6zc
X-Mailman-Approved-At: Wed, 12 Mar 2014 05:46:19 -0700
Subject: Re: [dane] [saag] Need better opportunistic terminology
X-BeenThere: dane@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:dane-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane/>
List-Post: <mailto:dane@ietf.org>
List-Help: <mailto:dane-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:dane-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 12 Mar 2014 00:28:05 -0000
]On 3/11/2014 3:12 PM, Joe Touch wrote: ]> Hi, Steve, ].... ]>> I have ]>> suggested "opportunistic keying" as a preferred term, since its the ]>> key management, not the encryption per se, that distinguishes other ]>> proposed modes of operation for IPsec, TLS, etc. ]> ]> I agree if you're replacing OE with OK ;-) ] ]One clarification: I don't see the use of unauthenticated keying as ]opportunistic in any sense of the word. ] ]Opportunistic would mean making an assumption that might be wrong, but ]when it's right it saves time/effort. Opportunistic keying does provide authentication, it's just that the authentication is only to the public key and is not tightly bound to any other type of identification (address, name, etc.) The binding of the key to other information useful for access control decisions is deferred. Other mechanisms are used to associate the key with an appropriate access policy. At this point is where it seems to get a little trickier to describe a generic model for multiple protocols. Different applications have different identifiers and binding requirements. I'm assuming the intent generally that the first key discovered for a specific context would be bound to that specific usage. Without some type of pinning of the key to a context we end up with unauthenticated encryption. This implies that we will be creating more applications that display public keys or hashes of public keys. Human validation of key ownership is always a good security check (although not always the best user experience). The definition should be clear on the necessity of the additional binding and possible check of the key ownership. One idea for formalization of such opportunistic mechanisms would be to clearly define the state of the key binding to it's use in a particular context. A key newly discovered and being used for a particular dns address could be in an invalidated state, while one that was explicitly checked in some manner would be in a validated state. Note - I'm working on protocols for bootstrapping P2P security that are very close to these discusions. Basic design is that all devices have a public Key and they are introduced for a particular set of communications (service). In this application out-of-band channels can be used to support the introduction (e.g. NFC, QR Code, label on device, dynamic label on display). I've been calling aspects of this bootstrap process 'key centric' versus opportunistic since we are trying to always have a means to securely bind the key to the specific usage. Keys are the identity and are maintained in ACLs and groups for access control. Usability concerns in products will introduce implementations that are more promiscuous and connect opportunistically with minimal human interaction. The different types of security policies that this creates is a problem in that it lacks clear user oriented definitions. Right now, in the Wi-Fi industry the terminology is either 'open' or 'encrypted' (aka WPA2). Now there will be new modes like: encrypted but anyone can connect (e.g. open printer kiosk). I suspect that that this differentiation in policies will also occur in other uses of opportunistic encryption. Paul ] ]There's no savings here; by using unauthenticated key exchange, you're ]really just lowering the bar. ] ]That said, I don't like the term "anonymous encryption" because it ]implies identity hiding, which isn't the purpose either. ] ]Why not just use the term "unauthenticated encryption", when that's ]exactly what's happening? ] ]Joe ] ]_______________________________________________ ]saag mailing list ]saag@ietf.org ]https://www.ietf.org/mailman/listinfo/saag
- Re: [dane] Need better opportunistic terminology Viktor Dukhovni
- [dane] Need better opportunistic terminology Phillip Hallam-Baker
- Re: [dane] [saag] Need better opportunistic termi… Joe Touch
- Re: [dane] Need better opportunistic terminology Viktor Dukhovni
- Re: [dane] Need better opportunistic terminology Michael Richardson
- Re: [dane] Need better opportunistic terminology Viktor Dukhovni
- Re: [dane] [saag] Need better opportunistic termi… Stephen Kent
- Re: [dane] [saag] Need better opportunistic termi… Joe Touch
- Re: [dane] [saag] Need better opportunistic termi… Joe Touch
- Re: [dane] [saag] Need better opportunistic termi… Michael Richardson
- Re: [dane] [saag] Need better opportunistic termi… Peter Palfrader
- Re: [dane] [saag] Need better opportunistic termi… Tony Finch
- Re: [dane] [saag] Need better opportunistic termi… Stephen Farrell
- Re: [dane] [saag] Need better opportunistic termi… Paul Lambert
- Re: [dane] [saag] Need better opportunistic termi… Stephen Kent
- Re: [dane] Need better opportunistic terminology Tony Finch
- Re: [dane] [saag] Need better opportunistic termi… Joe Touch
- Re: [dane] [saag] Need better opportunistic termi… Stephen Farrell
- Re: [dane] [saag] Need better opportunistic termi… Nico Williams
- Re: [dane] [saag] Need better opportunistic termi… Joe Touch
- Re: [dane] [saag] Need better opportunistic termi… Joe Touch
- Re: [dane] [saag] Need better opportunistic termi… Michael Richardson
- Re: [dane] [saag] Need better opportunistic termi… Stephen Farrell
- Re: [dane] [saag] Need better opportunistic termi… Michael Richardson
- Re: [dane] [saag] Need better opportunistic termi… Stephen Farrell
- Re: [dane] [saag] Need better opportunistic termi… Stephen Kent
- Re: [dane] [saag] Need better opportunistic termi… Stephen Kent
- Re: [dane] [saag] Need better opportunistic termi… Joe Touch
- Re: [dane] [saag] Need better opportunistic termi… Viktor Dukhovni
- Re: [dane] [saag] Need better opportunistic termi… Phillip Hallam-Baker
- Re: [dane] [saag] Need better opportunistic termi… Derek Atkins
- Re: [dane] [saag] Need better opportunistic termi… Paul Lambert
- Re: [dane] [saag] Need better opportunistic termi… Derek Atkins
- Re: [dane] [saag] Need better opportunistic termi… Stephen Farrell
- Re: [dane] [saag] Need better opportunistic termi… Nico Williams
- Re: [dane] [saag] Need better opportunistic termi… Olle E. Johansson
- Re: [dane] [saag] Need better opportunistic termi… Tony Finch
- Re: [dane] [saag] Need better opportunistic termi… Joe Touch