On Wed, Mar 10, 2021 at 7:12 AM Dan Harkins <[email protected]> wrote:
<snip>
>
>
>   I'm not sure of the distinction you're making here. But let me address
> a misconception mentioned earlier (not by you, but mentioned nonetheless)
> to hopefully clear this up:
>
> In DPP the public key is not secret, but the knowledge of the public key is
> supposed to be restricted to those who are legitimate owners of the thing.

What you want I think is a security property akin to an asymmetric
PAKE, although a bit easier to design since everything is high
entropy: the protocol succeeds only if the endpoints each know the
things they are supposed to, even in the face of concurrent sessions
and adversarial corruption of some parties. And we're using these
credentials in an entirely different protocol as well, which needs to
be considered.

Having the public key not be public is unusual. As I stated on the
call lots of signature schemes do reveal the public key.  When you're
working with these unusual needs a lot of care is required.

> The more gratuitously a thing distributes it's public key the less assurance
> the thing will get that the holder of it's public key is legit. Consider that
> the Oprah level of bootstrapping-- "you get my public key!, and you get my
> public key!, and you get my public key!"-- would end up being TOFU since the
> thing doesn't actually know who it ended up talking to (everyone could
> theoretically have gotten the public key), but restriction of the thing's
> public key to someone who purchased the thing-- consider transfer of data
> in the cloud upon delivery of a paid purchase order-- can allow the thing
> to have a higher level of assurance that it's talking to the legitimate owner.

Only if the protocol has the security properties you want.  That's not
clear to me, and the Wifi Alliance should have something to back this
up.

Sincerely,
Watson Ladd



-- 
Astra mortemque praestare gradatim

_______________________________________________
TLS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tls

Reply via email to