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

[Daniel Kahn Gillmor <[e-mail]>]

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?

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

	--dkg