Re: [homenet] I-D Action: draft-ietf-homenet-dot-10.txt

[Ted Lemon]

Thanks, Mark.   That was sufficient detail. :)

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] I-D Action: draft-ietf-homenet-dot-10.txt

[Mark Andrews]

In message <916eeeb9-3709-492b-8e19-5c832b11a...@fugue.com>, Ted Lemon writes:
> On Jul 31, 2017, at 1:02 AM, Mark Andrews  wrote:
> > The delegatation is INSECURE and SIGNED not UNSIGNED.  The wording
> > here is *important*.
>
> Can you explain what the distinction is, and what the problem is that you
> see in point five?  The reason I ask is that we explicitly changed the
> wording from "insecure" to "not signed" because someone else said that it
> wasn't clear what "insecure" meant.   It seems to me that the current
> language is explicit and unambigious; I think this is better than being
> "correct."   So what is the bad outcome that might occur as a result of
> using the term "not signed" rather than "insecure"?

The delegation has *signed* NEC/NSEC3 records that prove that there
is no DS record at the delegation *and* that the delegation *exists*
unless OPTOUT is also set in the covering NSEC3 record.  The presence
of the NS bits without a SOA and DS bits in the validated NSEC/NSEC3
record proved that the child zone is insecurely delegated.  Note
this does not work if the delegation is unsigned.

All delegations from a signed zone are signed.  These is no such
thing as a unsigned delegation.  There are only secure (with signed
DS) and insecure (without DSi but with signed NSEC/NSEC3).

This is different to a unsigned delegation in a unsigned zone where
there is no proof of anything.

RFC 4033

   Insecure: The validating resolver has a trust anchor, a chain of
  trust, and, at some delegation point, signed proof of the
  non-existence of a DS record.  This indicates that subsequent
  branches in the tree are provably insecure.  A validating resolver
  may have a local policy to mark parts of the domain space as
  insecure.

RFC 4035

   Insecure: An RRset for which the resolver knows that it has no chain
  of signed DNSKEY and DS RRs from any trusted starting point to the
  RRset.  This can occur when the target RRset lies in an unsigned
  zone or in a descendent of an unsigned zone.  In this case, the
  RRset may or may not be signed, but the resolver will not be able
  to verify the signature.

Then add to that "insecure delegation" is the existing term for this
type of delegation.

RFC 6063

   As DNSSEC is deployed within the IN-ADDR.ARPA and IP6.ARPA
   namespaces, the zones listed above will need to be delegated as
   insecure delegations, or be within insecure zones.  This will allow
   DNSSEC validation to succeed for queries in these spaces despite not
   being answered from the delegated servers.

RFC 7719:

   Insecure delegation:  a name containing a delegation (NS RRSet), but
  lacking a DS RRSet, signifying a delegation to an unsigned child
  zone.


   Opt-out:  "The Opt-Out Flag indicates whether this NSEC3 RR may cover
  unsigned delegations."  (Quoted from [RFC5155], Section 3.1.2.1.)
  Opt-out tackles the high costs of securing a delegation to an
  insecure zone.  When using Opt-Out, names that are an insecure
  delegation (and empty non-terminals that are only derived from
  insecure delegations) don't require an NSEC3 record or its
  corresponding RRSIG records.  Opt-Out NSEC3 records are not able
  to prove or deny the existence of the insecure delegations.
  (Adapted from [RFC7129], Section 5.1)

As for point 5 the delegation for "home.arpa." will exist once IANA
adds it to the ARPA zone.  The content of the delegation won't match
but it will exist.  Note any server that performs such tests is
already broken as STD 13 requires that the child zone be setup
before the delegation is made.  I know there are DNS hosters that
require the delegation exists and list the server but they are
actually wrong to do this.  DNS delegations are make before break.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Ted's security talk at IETF99: DNCP Security

[Ted Lemon]

On Jul 31, 2017, at 8:20 PM, Michael Richardson  wrote:
>  a) do they really want this kind of traffic?
>  b) the certs issued will go into their cert transparency list, and I think
> that means we lose privacy.
>  c) to make it work, they have to verify things.  IPv6 makes the
> connectivity easy to arrange, but it seems like it's a big exposure for
> the device.  We are talking more than just routers... I'm thinking
> printers and all sorts of things.

Probably they don't, although they appear to be handling rather a lot of 
traffic already.   The problem is, we have no way to establish trust on a 
domain name because the browser vendors don't support DNSSEC-based TLS certs.   
For some reason.   Not that I am bitter...

> It doesn't establish initial trust, it gives the user a trusted icon in their
> browser once we have initial trust.

Blrk.   I just don't think it's a good idea to burn certs into routers.   And I 
don't want the end user to be relying on their router vendor for their PKI.   
But I will admit that I haven't done a thorough threat analysis, so I can't 
justify my collywobbles.

>The Pledge can choose to accept vouchers using less secure methods.
>These methods enable offline and emergency (touch based) deployment
>use cases:

That ain't going to work.   But we can probably figure something out.

> Christian's comments in DNSSD (which I also watched today) is right though:
> for many applications in *discovery* is important you probably don't want
> certs, because they reveal too much, and the relationship is too ephermeral.
> The link between Dave's Laptop and Dave's Cool Printer is probably longer.

Indeed, but we don't want Dave's Laptop going around asking for Dave's Cool 
Printer when Dave's Laptop is not on the home network where Dave's Cool Printer 
lives.


___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Ted's security talk at IETF99: DNCP Security

[Michael Richardson]

Ted Lemon  wrote:
> That partly gets rid of the security exception on each access to the
> web interface: provided the web browser loads the new trust anchor.


> I don't know how to make that work without a fake domain tree. Can't we 
just
> use ACME+letsencrypt.org?

I hadn't thought about that.
The objections I can think about involves three kinds of things:
  a) do they really want this kind of traffic?
  b) the certs issued will go into their cert transparency list, and I think
 that means we lose privacy.
  c) to make it work, they have to verify things.  IPv6 makes the
 connectivity easy to arrange, but it seems like it's a big exposure for
 the device.  We are talking more than just routers... I'm thinking
 printers and all sorts of things.

> Sure. The question is, what value does the PKI cert add here? I agree that
> having a cert that validates is good for the web UI, but I don't see how 
it
> helps in establishing trust.

It doesn't establish initial trust, it gives the user a trusted icon in their
browser once we have initial trust.

> I would be tempted to do something like what Christian is doing with DNSSD
> privacy: print a QR code on the box, take pictures of all the QR codes 
with
> your smartphone, and then use your smartphone app to bootstrap trust using
> those QR codes. You could do something similar by just flashing the front
> panel LEDs really fast when the "pair" button is pressed, and have the
> smartphone decode that, as is being done with exfiltration malware now. I
> suspect there's code we could download... :)

I think that these are all really good ways to establish initial trust.
BRSKI mentions the whole category at:
  
https://tools.ietf.org/html/draft-ietf-anima-bootstrapping-keyinfra-07#section-4.2

  3.  The Pledge MAY have an operational mode where it skips Voucher
  validation one time.  For example if a physical button is
  depressed during the bootstrapping operation.  This can be
  useful if the vendor service is unavailable.  This behavior SHOULD be
  available via local configuration or physical presence methods to
  ensure new entities can always be deployed even when autonomic
  methods fail.  This allows for unsecured imprint.

Christian's comments in DNSSD (which I also watched today) is right though:
for many applications in *discovery* is important you probably don't want
certs, because they reveal too much, and the relationship is too ephermeral.
The link between Dave's Laptop and Dave's Cool Printer is probably longer.

--
Michael Richardson , Sandelman Software Works
 -= IPv6 IoT consulting =-





signature.asc
Description: PGP signature
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Ted's security talk at IETF99: DNCP Security

[Stephen Farrell]

On 31/07/17 19:00, Ted Lemon wrote:
> I don't know how to make that work without a fake domain tree.
> Can't we just use ACME+letsencrypt.org ?
I think the protocols would work fine, but I'm not sure there's
a current challenge type that'd work here, for LE or any similar
service. (The current set of challenges in the acme spec is at
[1].)

For my main home router (a Turris), I setup a VPN connection so
that the  for a name I control is routed to the Turris when
the VPN is up, and then I just used acme.sh [1] to talk to LE
and all that works just fine and gets rid of the annoying browser
insecurity warning when I use luci.

(I further cheat by only having that VPN up when I need to talk
to LE for renewal checks and otherwise just resolve the name
using 10/8 inside the home, but I'm sure there're better options.)

So the plumbing/protocols all do work if you have a name and
address that works from the CA service provider POV. It's just
that almost nobody can do that today.

Is this something where it'd be worth trying to get a few folks
from the various communities on a call to see if we can come up
with something that might work for the openwrt/lede type cases?

If so, I'd be happy to try set that up in a month or so, when
holliers are done and I'm supposedly gonna be a chair-like being:-)
I'd be happy to try that even if the chances of a Eureka! moment
aren't very high. (And btw, the reason I suggest that scope is
that I figure commercial device vendors can figure out the cert
issuance part just fine already, and with better assurance, but
probably have the same issues with browser trust stores as do the
openwrt/lede folks, so I'm not suggesting excluding commercial
device vendors, just limiting the scope to stuff that could be
worked on today by anyone if we did have that Eureka! moment.)

Cheers,
S.

[1] https://tools.ietf.org/html/draft-ietf-acme-acme-07#section-8
[2] https://github.com/Neilpang/acme.sh



signature.asc
Description: OpenPGP digital signature
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] I-D Action: draft-ietf-homenet-dot-10.txt

[Ted Lemon]

On Jul 31, 2017, at 2:21 PM, Walter H.  wrote:
> Just a thought of mine, would it be possible to add a section, to make it 
> possible
> to get official SSL certificates for these 'home.arpa.' domains (for free),
> so there would not be the need of running a own PKI?

I don't see how that could work.   I agree that it's a problem in need of a 
solution, but since home.arpa wouldn't be externally visible, you couldn't use 
the fact that you can publish in a name in it to do the ACME authentication.

I was hoping to get IP-based certs, but it turns out that letsencrypt (probably 
wisely) doesn't offer them.

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] I-D Action: draft-ietf-homenet-dot-10.txt

[Walter H.]

On 28.07.2017 22:11, internet-dra...@ietf.org wrote:

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Home Networking WG of the IETF.

 Title   : Special Use Domain 'home.arpa.'
 Authors : Pierre Pfister
   Ted Lemon
Filename: draft-ietf-homenet-dot-10.txt
Pages   : 9
Date: 2017-07-28

Abstract:
This document specifies the behavior that is expected from the Domain
Name System with regard to DNS queries for names ending with
'.home.arpa.', and designates this domain as a special-use domain
name. 'home.arpa.' is designated for non-unique use in residential
home networks.  Home Networking Control Protocol (HNCP) is updated to
use the 'home.arpa.' domain instead of '.home'.
Just a thought of mine, would it be possible to add a section, to make 
it possible

to get official SSL certificates for these 'home.arpa.' domains (for free),
so there would not be the need of running a own PKI?

Greetings,
Walter



smime.p7s
Description: S/MIME Cryptographic Signature
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Ted's security talk at IETF99: DNCP Security

[Michael Richardson]

Ted Lemon  wrote:
mcr> Is there a document for this Ted? I will offer to help.

> Your help would be much appreciated, but I don't know why there would
> be an election, so there's at a minimum some thinking to do
> there. There is no document yet.

I think that we need to have a Registrar that issues certificates.
ANIMA's BRSKI document automates much of this.

That partly gets rid of the security exception on each access to the
web interface: provided the web browser loads the new trust anchor.

> Also, bear in mind that a vendor-centric approach to this probably isn't
> going to work, because right now all the Homenet work I'm aware of is
> happening on OpenWRT and LEDE. I'm sure that will change if we come up

This is where all the other pairing mechanisms come into play.
You mentioned having a laundry list of them.

--
Michael Richardson , Sandelman Software Works
 -= IPv6 IoT consulting =-





signature.asc
Description: PGP signature
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] I-D Action: draft-ietf-homenet-dot-10.txt

[Ted Lemon]

On Jul 31, 2017, at 11:42 AM, Warren Kumari  wrote:
> It really is an insecure delegation, not an unsigned delegation --
> calling it unsigned would be confusing to many people. The person I
> was discussing it with wasn't aware of the term "insecure delegation"
> and assumed that it meant an "unsigned delegation", which is, um,
> difficult to achieve in a non-NSEC3 OO zone...

Ah, I wrote that text not imagining that .arpa was signed using good 
old-fashioned NSEC, which was silly of me.   That said, I would rather not rely 
on interpretations of terminology the meaning of which isn't agreed upon.   I 
think it would be better to simply specify that there will be no DS record.   
Does that make sense, or is there some reason why we have to say "unsigned?"

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] I-D Action: draft-ietf-homenet-dot-10.txt

[Warren Kumari]

On Mon, Jul 31, 2017 at 5:36 AM, Ted Lemon  wrote:
> On Jul 31, 2017, at 1:02 AM, Mark Andrews  wrote:
>
> The delegatation is INSECURE and SIGNED not UNSIGNED.  The wording
> here is *important*.
>
>
> Can you explain what the distinction is, and what the problem is that you
> see in point five?   The reason I ask is that we explicitly changed the
> wording from "insecure" to "not signed" because someone else said that it
> wasn't clear what "insecure" meant.   It seems to me that the current
> language is explicit and unambigious; I think this is better than being
> "correct."   So what is the bad outcome that might occur as a result of
> using the term "not signed" rather than "insecure"?


Having recently had exactly this discussion with someone, this area is
fraught with opportunities for misunderstandings.

Let's take example.com as an example[0]. The .com zone is signed.
Example Corp hired a DNS geek, who signed the example.com zone, but
never quite got around to publishing a DS record in the parent.

There is now a signed, insecure delegation to a signed zone; the
delegation itself is signed (.com is a signed zone and so there there
is an RRSIG for the NS for example.com), but there is no DS record, so
it is insecure.

It really is an insecure delegation, not an unsigned delegation --
calling it unsigned would be confusing to many people. The person I
was discussing it with wasn't aware of the term "insecure delegation"
and assumed that it meant an "unsigned delegation", which is, um,
difficult to achieve in a non-NSEC3 OO zone...

I spend an almost infinite amount of time[1] trying to explain this
very point (to someone who understands DNSEEC) over the phone - it's
tricky to communicate without a whiteboard and / or diagram.
I ended up opening an issue on the terminology-bis document to get it
added: 
https://github.com/DNSOP/draft-ietf-dnsop-terminology-bis/issues/26#issuecomment-314275871


W
[0]: For the purpose of discussion, let's pretend that .COM uses NSEC,
not NSEC3 with Opt-Out.
[1]: Ok, perhaps it wasn't almost infinite, but it sure felt like it...

>
>
> ___
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet
>



-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Ted's security talk at IETF99: DNCP Security

[Ted Lemon]

On Jul 31, 2017, at 11:21 AM, Michael Richardson  wrote:
> The things that Ted wants, such "this the ID of the router", and the like,
> and this really the topic of the ANIMA BRSKI protocol.  It can be profiled
> to work in Homenet, provided that HNCP can elect a registrar.
> I think that is entirely workable, btw.
> I don't think that Homenet has to invent any protocols here.
> 
> Is there a document for this Ted?  I will offer to help.

Your help would be much appreciated, but I don't know why there would be an 
election, so there's at a minimum some thinking to do there.   There is no 
document yet.

Also, bear in mind that a vendor-centric approach to this probably isn't going 
to work, because right now all the Homenet work I'm aware of is happening on 
OpenWRT and LEDE.   I'm sure that will change if we come up with something 
vendors want to deploy, but it has to work for the prototype case too.   And 
there's no particular reason to think that a PKI key from a vendor makes a 
device trustworthy.

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

[homenet] Ted's security talk at IETF99: DNCP Security

[Michael Richardson]

So I'm watching via meetecho the meeting.  Some minor comment that it seems
like many things have happened in homenet that haven't really been on the
list.  {Or maybe it was just DMARC vs ietf.org forwarding "helping" me. I've
had to whitelist the ietf.org mail servers}

The things that Ted wants, such "this the ID of the router", and the like,
and this really the topic of the ANIMA BRSKI protocol.  It can be profiled
to work in Homenet, provided that HNCP can elect a registrar.
I think that is entirely workable, btw.
I don't think that Homenet has to invent any protocols here.

Is there a document for this Ted?  I will offer to help.

--
Michael Richardson , Sandelman Software Works
 -= IPv6 IoT consulting =-





signature.asc
Description: PGP signature
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] The HOMENET WG has placed draft-tldm-simple-homenet-naming in state "Call For Adoption By WG Issued"

[Michael Richardson]

Ted Lemon  wrote:
> to put the CFA on hold pending that update. There have been some good
> comments already, though; in particular, I think Juliusz' point that it
> would
> be nice to actually try some of this in practice is good, and is what
> I'm

We require interoperable implementations for Internet Standard, not to adopt
a document.  Implementation reports would be good for WGLC, not here!
We need to lower the bar here, not raise it.  WGs can abandon documents too.

> That said, what I said in the working group is that we've been spinning
> our wheels on this for several years, and I wanted to know if the scope
> of this is reasonable and is what the working group wants to take
> on. If it's not,
> then I don't actually know how to proceed.

I think that it's the right approach, and given the sort out of the MVDP,
I support adoption.

--
]   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[

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] The HOMENET WG has placed draft-tldm-simple-homenet-naming in state "Call For Adoption By WG Issued"

[Ted Lemon]

This is an architecture document, not a protocol specification.

On Jul 31, 2017 7:36 AM, "Juliusz Chroboczek"  wrote:

> > I wanted to know if the scope of this is reasonable and is what the
> > working group wants to take on.
>
> I think the scope of this is too wide.  It tries to solve a number of
> different problems:
>
>   1. naming within the Homenet;
>   2. publishing names of Homenet nodes outside the Homenet;
>   3. resolving names outside the Homenet in the presence of multiple
> providers;
>   4. announcing multiple providers' naming spaces when the providers
>  provide inconsistent information.
>
> My gut feeling is that if you insist on a single protocol that solves all
> four, you'll end up with more complexity than if you solve each problem on
> its own.
>
> > If it's not, then I don't actually know how to proceed.
>
> I suggest picking just one problem and solving it.  (1) in the above list
> would be the obvious choice.
>
> -- Juliusz
>
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] The HOMENET WG has placed draft-tldm-simple-homenet-naming in state "Call For Adoption By WG Issued"

[Juliusz Chroboczek]

> I wanted to know if the scope of this is reasonable and is what the
> working group wants to take on.

I think the scope of this is too wide.  It tries to solve a number of
different problems:

  1. naming within the Homenet;
  2. publishing names of Homenet nodes outside the Homenet;
  3. resolving names outside the Homenet in the presence of multiple providers;
  4. announcing multiple providers' naming spaces when the providers
 provide inconsistent information.

My gut feeling is that if you insist on a single protocol that solves all
four, you'll end up with more complexity than if you solve each problem on
its own.

> If it's not, then I don't actually know how to proceed.

I suggest picking just one problem and solving it.  (1) in the above list
would be the obvious choice.

-- Juliusz

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] The HOMENET WG has placed draft-tldm-simple-homenet-naming in state "Call For Adoption By WG Issued"

[Ted Lemon]

On Jul 30, 2017, at 9:20 PM, Michael Richardson  wrote:
>> and then there is draft-ietf-mif-mpvd-ndp-support as a normative reference.
> 
> concerns me most.  Unless it's in RFC-editor queue (it's not, it's expired!),
> I'm pretty sure it's a very much normative reference.  So Homenet needs an
> answer as to how to deal with this dependancy.  It seems that we'd need to
> adopt it, copy and paste the text into this document, or reboot MIF...

There was widespread agreement in INTAREA to adopt this:

https://tools.ietf.org/html/draft-bruneau-intarea-provisioning-domains-02 


I actually intended to reference this—I just got my wires crossed because 
google gave me the link to the other one, which as you say is dead.

The current rev of the homenet naming architecture is pretty thin—I put a lot 
of work into the dnssd stuff, because I wanted to have it pretty solid before 
referencing it in the MPVD architecture document.   If you weren't in homenet, 
it might indeed be worth reviewing my presentation in the meetecho.   Stuart's 
presentation in dnssd might also be worth reviewing.

Anyway, a consequence of the emphasis on the dnssd work is that I had about an 
hour to update the naming architecture document before the submission deadline, 
and the update is minimal, to be as charitable as possible.

Daniel wanted to do another update, but we needed to sync up first, and I don't 
know where he is at with that now, but I think it would be reasonable to put 
the CFA on hold pending that update.   There have been some good comments 
already, though; in particular, I think Juliusz' point that it would be nice to 
actually try some of this in practice is good, and is what I'm working on now.  
 I think having that done before the document is adopted is a pretty high bar, 
but I don't really care either way.

That said, what I said in the working group is that we've been spinning our 
wheels on this for several years, and I wanted to know if the scope of this is 
reasonable and is what the working group wants to take on.   If it's not, then 
I don't actually know how to proceed.

(BTW, Juliusz, yes, HNCP is where the domain name is agreed upon.)

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] I-D Action: draft-ietf-homenet-dot-10.txt

[Ted Lemon]

On Jul 31, 2017, at 1:02 AM, Mark Andrews  wrote:
> The delegatation is INSECURE and SIGNED not UNSIGNED.  The wording
> here is *important*.

Can you explain what the distinction is, and what the problem is that you see 
in point five?   The reason I ask is that we explicitly changed the wording 
from "insecure" to "not signed" because someone else said that it wasn't clear 
what "insecure" meant.   It seems to me that the current language is explicit 
and unambigious; I think this is better than being "correct."   So what is the 
bad outcome that might occur as a result of using the term "not signed" rather 
than "insecure"?

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet