Re: [Add] [EXTERNAL] Re: New Version Notification for draft-pauly-add-resolver-discovery-01.txt

[tirumal reddy <[e-mail]>]

On Thu, 30 Jul 2020 at 13:28, Steffen Nurpmeso <[e-mail]> wrote:

> tirumal reddy wrote in
>  <[e-mail]>:
>  |Hi Chris,
>  |
>  |Good points, please see inline
>  |
>  |On Thu, 30 Jul 2020 at 06:00, Chris Box (BT) <[e-mail]>
>  |wrote:
>  |
>  |> Rob you appear to be saying you don’t need such features to secure a
> home
>  |> network, but I would certainly appreciate having Tiru’s (a) to (e) \
>  |> deployed
>  |> in my house. I don’t want the smart TV equipped with microphone and \
>  |> webcam
>  |> to be remotely compromised, nor any other device. Without such
>  |> network-level control, enabled by standards, my only defence is to
>  |> physically unplug the TV from the network when not in use.
>  |>
>  |
>  |> Following Eva’s talk in HRPC, I’ll put myself in the shoes of a
> dissident
>  |> in a hostile regime. In such a case I would feel even greater need \
>  |> for such
>  |> security. Of course I would choose my security supplier carefully, \
>  |> and not
>  |> one aligned to the regime. I then need one or two devices that route
>  |> through Tor.
>  |>
>  |> I fully agree the challenge is to distinguish legitimate network
> signals
>  |> from those of an attacker. Robustly identifying who they came from is
>  |> non-trivial, but hopefully not impossible?
>  |>
>  |
>  |Yes, identifying the trustworthiness of the peer is discussed in RATS WG
>  |(see https://datatracker.ietf.org/wg/rats/about/). Remote attestation
>  |procedures (RATS) enable relying parties to establish a level of
> confidence
>  |in the trustworthiness of remote system components through the creation
> of
>  |attestation evidence by remote system components and a processing
>  |chain towards the relying party. A relying party can then decide whether
>  |to consider a remote system component trustworthy or not.
>  |
>  |The claims used as evidence and attestation for DNS server is discussed
> in
>  |https://tools.ietf.org/html/draft-reddy-add-server-policy-selection-04.
>
> I personally do not get what yet another line of authorities
> transported via JSON encoded structures fetched via another DNS
> record that just exposes that JSON structure gives the world anew.
>

RATS allows the attestation to be represented in JSON or CBOR (see
https://tools.ietf.org/html/draft-ietf-rats-eat-03#section-1.1).  The PAT
object is retrieved using RESINFO RRtype (
https://tools.ietf.org/html/draft-pp-add-resinfo-01) and it uses JSON to
return the resolver information.


>
> Indirection may make everything possible, but, i mean, to me the
> key point of RFC 8572 for example is the
>
>   3.3 Ownership Voucher
>   [this] artifact is used to securely identify a device's owner,
>   as it is known to the manufacturer.  The ownership voucher is
>   signed by the device's manufacturer.
>
> _If_ i can find my way home i can securely update myself, where
> securely means manufacturer here.  Great that standard CMS is
> used.
>

https://tools.ietf.org/html/rfc8572 is specific to zero-touch provisioning
of networking devices and IoT devices in Enterprise networks. The owner
certificate can be used to validate the PAT signature (see the last
paragraph
https://tools.ietf.org/html/draft-reddy-add-server-policy-selection-04#section-10
).



>
>   Even if DNSSEC [RFC6698] is used to authenticate the various DNS
>   resource records [.] the device cannot be sure that the domain
>   returned to it, e.g., from a DHCP server, belongs to its
>   rightful owner.
>
> It then refers back to RFC 6763, DNS-based service discovery.
> Which has really nice, easy to parse content, and does not use
> JSON only to represent key/value pairs.  (Why not a fixed CBOR
> thing instead, they are talking maps at the moment, for example.
> And can easily be converted back and forth to JSON while still
> being parsed directly, as it is binary.)  What is so wrong with
> this service discovery thing, i think it could very well serve
> additional things.  But especially so if another registry is
> introduced for the concept.  RFC 8572 also says
>
>   Using a DHCP server may be a compelling option for deployments
>   having existing DHCP infrastructure, as it enables a touchless
>   bootstrapping option that does not entail utilizing an
>   Internet-based resource hosted by a third party.
>
>   A DHCP server is an untrusted source of bootstrapping data.
>   Thus, the information stored on the DHCP server either MUST be
>   signed or MUST be information that can be processed
>   provisionally (e.g., unsigned redirect information).
>
> I do not know (people can agree here), but if that could improve.
> Also being x-rayed yesterday (untreated bike accident last
> November) my pictures are now at healthdataspace.org even without
> me agreeing with that, they have a German data security seal of
> approval, but then it is just a QR-code and/or an access code
> (alphanumeric and length of 10 or 12, iirc).
>
> It is not an option for a light bulb, but that thing surely
> belongs behind a household router, and easy usable routers with
> why not ample-style use cases would be great, imho.  With a short
> fingerprint printed on a device that shows up on that router, just
> like for Bluetooth pairing.  I could imagine people could get used
> to that.  (Especially with some kind of those terrible apps on
> their smart phones which are linked to the "router" of the
> household, then, so they get informed of that event.  I think DHCP
> even allows ident strings to be emitted from DHCP client to
> server.)
>

There are several mechanisms to securely bootstrap IoT devices, you may
want to look into the recently adopted draft
https://tools.ietf.org/html/draft-sarikaya-t2trg-sbootstrapping-08 by T2TRG
and
within the scope of IETF is BRSKI and SZTP.

Cheers,
-Tiru

>
> Sorry, i do not seem to understand.
>
> --steffen
> |
> |Der Kragenbaer,                The moon bear,
> |der holt sich munter           he cheerfully and one by one
> |einen nach dem anderen runter  wa.ks himself off
> |(By Robert Gernhardt)
>