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

[Mohit Sethi M <[e-mail]>]

Hi Tiru,

https://tools.ietf.org/html/draft-sarikaya-t2trg-sbootstrapping-08 isn't adopted by T2TRG yet. Of course (as an author) it would be nice. It probably requires a couple of iterations and reviews before it can be considered for adoption.

I would also add EAP-NOOB to the list (https://tools.ietf.org/html/draft-ietf-emu-eap-noob-01).

--Mohit

On 7/31/20 9:20 AM, tirumal reddy wrote:
On Thu, 30 Jul 2020 at 13:28, Steffen Nurpmeso <[e-mail]<mailto:[e-mail]>> wrote:
tirumal reddy wrote in
 <[e-mail]<mailto:[e-mail]>>:
 |Hi Chris,
 |
 |Good points, please see inline
 |
 |On Thu, 30 Jul 2020 at 06:00, Chris Box (BT) <[e-mail]<mailto:[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<http://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)