Re: [TLS] AD review of draft-ietf-tls-oob-pubkey

Sean Turner <turners@ieca.com> Tue, 14 May 2013 19:21 UTC

Return-Path: <turners@ieca.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4798121F8F24 for <tls@ietfa.amsl.com>; Tue, 14 May 2013 12:21:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.713
X-Spam-Level:
X-Spam-Status: No, score=-100.713 tagged_above=-999 required=5 tests=[AWL=0.398, BAYES_05=-1.11, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IGU4U6EEGTAK for <tls@ietfa.amsl.com>; Tue, 14 May 2013 12:20:59 -0700 (PDT)
Received: from gateway03.websitewelcome.com (gateway03.websitewelcome.com [74.52.223.144]) by ietfa.amsl.com (Postfix) with ESMTP id 2EF0921F8C4C for <tls@ietf.org>; Tue, 14 May 2013 12:20:55 -0700 (PDT)
Received: by gateway03.websitewelcome.com (Postfix, from userid 5007) id A4EF2CF4430CF; Tue, 14 May 2013 14:20:46 -0500 (CDT)
Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway03.websitewelcome.com (Postfix) with ESMTP id 7606ECF442FF7 for <tls@ietf.org>; Tue, 14 May 2013 14:20:46 -0500 (CDT)
Received: from [198.180.150.142] (port=51298 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from <turners@ieca.com>) id 1UcKmE-00063m-5U; Tue, 14 May 2013 14:20:46 -0500
Message-ID: <51928E8C.7070905@ieca.com>
Date: Tue, 14 May 2013 20:20:44 +0100
From: Sean Turner <turners@ieca.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130328 Thunderbird/17.0.5
MIME-Version: 1.0
To: "Joseph Salowey (jsalowey)" <jsalowey@cisco.com>
References: <516D5ADE.3050506@ieca.com> <A95B4818FD85874D8F16607F1AC7C628BCDCF4@xmb-rcd-x09.cisco.com> <518BFECB.8050501@fifthhorseman.net> <A95B4818FD85874D8F16607F1AC7C628BE391F@xmb-rcd-x09.cisco.com>
In-Reply-To: <A95B4818FD85874D8F16607F1AC7C628BE391F@xmb-rcd-x09.cisco.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - gator1743.hostgator.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - ieca.com
X-BWhitelist: no
X-Source:
X-Source-Args:
X-Source-Dir:
X-Source-Sender: (thunderfish.local) [198.180.150.142]:51298
X-Source-Auth: sean.turner@ieca.com
X-Email-Count: 2
X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20=
Cc: "<tls@ietf.org>" <tls@ietf.org>, "<draft-ietf-tls-oob-pubkey@tools.ietf.org>" <draft-ietf-tls-oob-pubkey@tools.ietf.org>
Subject: Re: [TLS] AD review of draft-ietf-tls-oob-pubkey
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 14 May 2013 19:21:27 -0000

On 5/10/13 4:19 AM, Joseph Salowey (jsalowey) wrote:
>
> On May 9, 2013, at 12:53 PM, Daniel Kahn Gillmor <dkg@fifthhorseman.net> wrote:
>
>> On 05/07/2013 11:11 PM, Joseph Salowey (jsalowey) wrote:
>>
>>>> 12) In s6, it indicates:
>>>>
>>>> This document assumes that such
>>>> binding can be made out-of-band and we list a few examples in
>>>> Section 1.
>>>>
>>>> This statement begs the question as to whether there needs to be a requirement on protocols that use this extension to specify the method used to provide the out-of-band binding.  In other words something like:
>>>>
>>>> Specifications that make use of the extension MUST specify the
>>>> mechanism by which the identity and the public key are bound.
>>>> Otherwise, authentication is not possible.
>>>>
>>> [Joe] Or maybe
>>> "In order to address these vulnerabilities, specifications that make use of the extension MUST specify how the identity and public key are bound."
>>
>> Why is this a MUST?  What would be wrong with a specification that makes
>> use of the extension and declines to mandate a specific OOB mechanism
>> (e.g. leaves that choice of selection up to the service administrator or
>> local configuration or something else)?
>>
>> Being deliberately agnostic about corners of a protocol that you don't
>> want to constrain is pretty healthy.  If a spec for some new service
>> comes out that uses OOB keys, and then later someone publishes a novel
>> (and useful) mechanism for verifying the binding between those keys and
>> identities, do we want that spec to be considered invalid when used in
>> combination with the new verification mechanism?
>>
>
> [Joe]  In order for this specification to be used securely this binding must be done.  A document using this specification could possibly leave this up to administrative configuration if that was OK for their environment.  They could also specify a separate interoperable mechanism for achieving the binding.    If a new mechanism is develop then that new mechanism would have to be specified somewhere and documents would need to be updated to describe how to use that mechanism in an interoperable way.
>
> In any case I would be OK with removing the normative MUST and saying something like:
>
> "Specifications that make use of this extension need to describe how the identity and the public key are bound.
> Without this binding, authentication is not possible. "

Joe you read my mind.  I'm also okay without the MUST.

>>>> 14) Are there any other extensions that don't make sense to negotiate if raw keys are chosen?  For example, if the the client and server settle on raw keys do either of the ocsp stapling extensions make sense anymore?
>>>
>>> [Joe] At least the multi-ocsp extension could be extended to support other Status mechanisms.
>>
>> I'm not convinced that this extension of an extension should be coupled
>> into the same draft as oob-pubkey itself.  It seems likely to make it
>> harder to reach consensus on oob-pubkey without providing a significant
>> benefit.
>>
>
> [Joe]  I agree, but to your point above would you want to restrict the use of an extension that could easily be extended to use a different mechanism in the future?   I think here we would probably want to add text to the document to say that this document does not cover how revocation either.
>
> "Revocation of keys is not covered by this document.  Specifications that make use of this extension need to describe if and how revocation of keys is performed.  At the time of this document's publication, OCSP does not support the revocation of raw public keys so [TLS-OCSP] and [TLS-MULTI_OCSP]  do not apply. "

Not thrilled with this answer but I could live with it.

How about adding a new section that groups these two issues together and 
call it "What specifications that use this document must specify" or 
something like that.

spt