Christian Huitema <huit...@huitema.net> wrote:
>> I'd love to find a way to send the identifier only to an authorized
>> operator,
>> which is resistant to an active MITM, given that the new device (the
>> pledge)
>> doesn't know who the authorized operator is yet.
> We are looking at that in the pairing draft in DNSSD
> (https://tools.ietf.org/html/draft-kaiser-dnssd-pairing-00). The
hypothesis
> is that the two paired devices can display a short authentication
This might be fine for larger devices with displays, but it's a fail
everywhere else. Even in ANIMA, one could have a $300K BFR being deployed,
but it doesn't have a display or a person to read the display.
But, does this device need privacy?
But, the same system ideally bootstraps home routers, which at $39.95, still
don't have a display or a competent human to read the display.
> e.g. 6-7 digits. Given that, we can establish a TLS connection without
prior
> credentials between the two parties, with a probability 99.9999% that
Such as was done with the STU-III phone...
> There is another trick, used in the privacy extensions to DNS-SD
> (https://tools.ietf.org/html/draft-huitema-dnssd-privacy-02). Use TLS PSK,
> or better yet TLS/ECDH/PSK. Instead of PSK ID, send a puzzle that can only
> be solved by parties knowing the PSK, e.g. nonce + hash (nonce, PSK). That
> guarantees connection without MITM, and also without disclosure of the
> identities to third parties. Problem, it scales as O(number of PSK) known
by
> the server. We could probably devse an extension of that using public key
> technology.
How does the responding end know which PSK to try?
I guess that's why it scales O(number of devices), because the responder has
to try *all* of the PSK it knows? Wow.
With public key technology, one could sign something, send the signature, and
let the responder try all the public keys it knows? Basically, just omit the
Certificate in the handshake.
--
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman Software Works | network architect [
] m...@sandelman.ca http://www.sandelman.ca/ | ruby on rails [
_______________________________________________
perpass mailing list
perpass@ietf.org
https://www.ietf.org/mailman/listinfo/perpass
