Re: [homenet] Privacy risks with smart home local device communication

[Stephen Farrell]

Hi Aniketh,

Thanks for forwarding the paper - interesting work!

The homenet working group was closed some time back. I think
the currently open IETF venues that might be relevant for this
work would be madinas (considering mac address randomisation),
snac (working on a subset of home n/w issues) and pearg which
is a privacy related IRTF research group.

I'd say best might be to send a mail to the pearg list and
see if folks there start some discussion.

If mac address randomisation would/would-not mitigate some
of these issues then posting about that to the madinas wg list
would be a good thing. (Better in that case to send a mail
setting out why mac address ramdomisation would or would not
make things better rather that expecting many list members to
read the paper - you need to tempt 'em in:-)

I'm not sure if this'd be relevant for snac, but there are
people active there on this list so perhaps silence from
them means it's not that relevant.

Cheers,
S.


On 15/11/2023 18:13, Aniketh Girish wrote:

Hi,

I am writing to share our research paper[1] published recently at ACM IMC 2023, 
which addresses critical security and privacy concerns in smart home local 
networks. Our study focuses on characterizing local device communication and 
reveals substantial privacy risks associated with the misuse of discovery 
protocols. Additionally, we discover the inadvertent exposure of personally 
identifiable information (PII) by smart devices in discovery 
broadcasts/multicasts and detail the methods used by entities like advertisers 
and trackers to covertly exfiltrate this data.

Key findings of our paper include:

- Unintentional PII Broadcasts and Protocol Vulnerabilities: Our study shows 
that half of the devices in our dataset directly communicate with each other 
without any user interactions, often conspicuously broadcasting sensitive 
information like device names, private IDs, and household geolocations. This is 
amplified by vulnerabilities in network protocols such as DHCP, mDNS, and UPnP, 
leading to risks like outdated DHCP clients being vulnerable to exploitation 
and cross-device tracking due to unique identifiers in discovery protocol 
fields such as hostnames.

-  Broadcasts exploited by Mobile Apps and Third-Party Libraries: We find that 
mobile apps and third-party libraries exploit these network broadcasts to 
secretly extract PIIs and device identifiers and relay this local network data 
to remote endpoints. This occurs without user consent, using discovery 
protocols to access data protected by Android and iOS permissions, enabling 
network observers to infer precise user geolocation and other sensitive 
information.

We have diligently disclosed all risks found in the paper to the affected 
vendors and they are actively working on several remedial measures. We would 
also like to engage with IETF Working Groups, as our work is closely aligned 
with the efforts of groups like DNS-SD, Homenet, and the Open Connectivity 
Foundation (OCF).We are reaching out to the relevant working groups to seek 
interest in our findings and to engage in discussions to improve the current 
state.

Would your group be interested in reconsidering these issues or connecting us 
with other ongoing efforts within the IETF where our work might be more 
relevant?  We would also be open to present our paper at one of your upcoming 
meetings and engage in a discussion on how we can collectively enhance network 
protocol security and privacy standards.

For more details, please refer to the paper. Your feedback on our paper and 
thoughts on how it impacts the work of the IETF would be invaluable. We look 
forward to hearing back from you soon.


[1]: https://dl.acm.org/doi/pdf/10.1145/3618257.3624830


Cheers.
--
Aniketh Girish
PhD Student, IMDEA Networks Institute
https://anikethgirish.in/

This message may contain confidential or privileged information. If you have 
received it in error, please do not use it, notify the sender and delete it. 
See https://networks.imdea.org/legal-notice-email/



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


OpenPGP_0xE4D8E9F997A833DD.asc
Description: OpenPGP public key


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

Re: [homenet] Homenet Mission accomplished ?

[Stephen Farrell]

Hiya,

On 01/02/2023 15:00, Ted Lemon wrote:

Congratulations on getting this
done!


Indeed! Well done to the authors for sticking with it.
(And to Eric for pushing it over the line too!)

And thanks all for the WG fun! I agree that it's closing
time now.

Cheers,
Stephen.


OpenPGP_0xE4D8E9F997A833DD.asc
Description: OpenPGP public key


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

Re: [homenet] Request to join mailing list of IETF homenet WG

[Stephen Farrell]

Hiya,

On 15/10/2021 07:36, Prabhu, Shailesh (Nokia - IN/Bangalore) wrote:

Respected Chairs,

I am working as a Senior Technical Specialist at Nokia. As a
beginner, I am looking forward to contributing to IETF. Home
Networking (homenet) WG aligns with my interest, and I would like to
join the mailing list of homenet WG. Kindly let me know if one of the
chairs can add me to the mailing list. Also, please let me know if
there is any procedure that I need to follow to join the mailing
list.


You should be able to subscribe at [1]. There's no need to
ask for permission:-) If you experience any issues, just drop
me a mail offlist.

Cheers,
Stephen.

[1] https://www.ietf.org/mailman/listinfo/homenet



Thanks, Shailesh Prabhu Senior Technical Specialist, Nokia Contact:
(+91) 8971135516



OpenPGP_0x5AB2FAF17B172BEA.asc
Description: OpenPGP public key


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

Re: [homenet] Looking for a Homenet co-chair

[Stephen Farrell]

Hiya,

On 31/08/2021 15:53, Daniel Migault wrote:

I also support that homenet work being made in homenet. It is unclear to me
why we are looking at an alternate way to proceed.


From my POV, mostly because, as co-chair, it's very hard
to be confident that we have sufficient participation to
usefully claim WG consensus for the (good) work being done
when we put that forward for e.g. IETF LC.

As a WG, we're suffering from lack of input and at some
point (and now being a good point) we should consider whether
or not the WG is still tractable or not.

Cheers,
S.

PS: As it's still just about vacation season, I figure
it makes sense to let this discussion go on for another
week or two, so if someone hasn't yet chimed in, it's
still a fine time to do that!



Yours,
Daniel

On Fri, Aug 27, 2021 at 7:05 AM Michael Richardson  wrote:



Michael Richardson  wrote:
 >> progress the stub networks draft because I've been too busy doing
 >> dnssd work, but that would be an example. I'd really like to
progress
 >> that draft /somewhere/, and it seems a /bit/ off-topic for dnssd. It
 >> could go in v6ops, but it's pretty off-topic for v6ops. Same with
 >> intarea.

 >> But of course the stub networks document isn't what Homenet set out
to
 >> do.  It's just a building block that might lead there. The original
 >> work of homenet doesn't seem to have caught on in the market, and I
 >> think it's because we didn't have an adoption strategy. Personally I
 >> think stub networks is a good bottom-up beginning to a strategy that
 >> could ultimately produce an adoptable version of what we originally
 >> tried to do. But again, only if people here want to pursue that.

 > I thought that you *wanted* to go to INTAREA with this document.  I
 > agree that it's an important document.

If we need to keep HOMENET open to do stub networks, then let's do that.

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





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



OpenPGP_0x5AB2FAF17B172BEA.asc
Description: OpenPGP public key


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

Re: [homenet] Looking for a Homenet co-chair

[Stephen Farrell]

Hiya,

On 24/08/2021 08:59, Eric Vyncke (evyncke) wrote:

Dear all,

As you are probably aware, Barbara Stark is retiring from her WG
chair position after IETF-112 


I'd also like to thank Barbara for all her fine work for this
WG, and everything else in IETF-land too!


and I now have ‘mission impossible n++’
to find a new WG chair to assist Stephen Farrel.

As Stephen is an experimented WG chair, having a ‘junior’ co-chair
would be welcome (of course ‘senior’ as well!), i.e., even if you are
new at the IETF and if you have never been a WG chair, then feel free
to reply unicast[1] to me: we can then have a chat about the job and
the motivation. The job itself is not a big chunk of time outside the
IETF weeks but requires human skills (herding cats !) and of course
good technical knowledge.

Looking forward to reading your email about you or about any
suggestion


So, (having checked with Eric and Barbara) I'd also like
to know whether (or not) participants consider that the
homenet WG may now have reached the time when it's more
appropriate to close the WG. That might (or might not)
make a search for a new co-chair moot.

If closing the WG were the better option then we'd want
to have a discussion about how to handle ongoing work
(e.g. see if there's a better venue), but that's a
separate discussion.

Cheers,
S.

PS: FWIW, I'd be just as happy if there's consensus to
continue or to call it a day - either is a fine outcome
if it matches reality.



Regards

-éric

[1] unicast is preferred but not required



OpenPGP_0x5AB2FAF17B172BEA.asc
Description: OpenPGP public key


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

Re: [homenet] naming drafts

[Stephen Farrell]

Hiya,

On 08/06/2021 14:55, Daniel Migault wrote:

I disagree that discussing whether the proposal will take over DDNS
is a side discussion that unfortunately happens at a bad time. 


Sorry, I don't get what you mean.


If I
interpret the WGLC report, it is clearly noted as a lack of support.


No. It's me being critical of the text. I neither support
nor oppose this stuff, but the arguments presented for that
part aren't convincing IMO, which is what my comment said.



Predictions are not a technical discussion and can be very wrong (
"we will never make a 32 bit operating system", "there is no reason
anyone would want a computer in their home"... the list can be as
long as we wish). It should not be considered in the decision to move
the document forward. Will it replace DDNS - I do not know. Not more
than Stephen or Juliusz. I am happy to have this discussion in 2
years. Today it gives a toxic tone to the discussion.


Toxic? That's seems quite overblown. And plain wrong, if
you mean it to describe my review. I can understand the
frustration of working on something like this and not
seeing it progress as planned, but accusing me of creating
toxicity is not a fair accusation for you to make.


I agree that more reviews is always preferred, but I am wondering how
many reviews would have been considered sufficient.


Oh come on - we've tried a number of times to get people
to review these documents and we've never really gotten
that to happen. The level of review is nowhere near
sufficient to declare some meaningful WG consensus.


Looking at the
homenet mailing list we can see that the number of reviews reflects
the participation of the mailing list.


That's true. I think it may be time to recognise reality
and close the WG perhaps.


Though I really value your
review, I am not sure that (even with no hat) it encourages
additional reviews, as it forces the potential reviewer to take
position against the opinion of the chair. It seems to me that, if
the number of reviews were an issue, this could have been addressed
otherwise.


Sorry, that doesn't make sense. As chair I wouldn't ask
for it to be published without doing my own personal review.
And I refuse to guarantee all such reviews will be positive.


From my perspective all comments have been responded to, and
technical

comments have been addressed.


Personally, I don't agree. As chair, I think it's moot,
as we don't have sufficient review to declare consensus
either way. (To be clear - the DDNS point is also moot
in terms of whether or not the technical comments have
been handled - that was a non-nit editorial point.)


Regarding the support, the proposal was initiated by an ISP. Today, I
am interested in this proposal because we have some demand for it.
That some folks prefer using DDNS for their own purpose is orthogonal
to us. This is why we want it to be published.


Sure, and as I said I'm not opposed to that. I suspect the
best thing is for the authors to chat with our AD and see
if he's either willing to AD-sponsor it, or to ask another
WG to adopt, or try find a dispatch-like process to see if
enough interest/review can be found that way.

Cheers,
S.




Yours, Daniel

On Tue, Jun 8, 2021 at 6:06 AM Stephen Farrell
 wrote:



Hiya,

On 08/06/2021 10:29, Ray Hunter (v6ops) wrote:


Just trying to understand this hurdle/ line of reasoning.

So in addition to achieving "rough consensus", the IETF
standardization process must also produce drafts that are very
likely to gain traction to displace non-IETF non-standardised
products that are already widely commercially deployed?


No. This is not a process hurdle. It was one amongst a bunch of
personal comments I sent. And that I'm happy to discuss with the
authors without wearing any chair or other hat.

The process problem with these drafts is the lack of review means
there's no way to claim they represent any useful level of WG
consensus.

Cheers, S.

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







OpenPGP_0x5AB2FAF17B172BEA.asc
Description: OpenPGP public key


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

Re: [homenet] naming drafts

[Stephen Farrell]

Hiya,

On 08/06/2021 10:29, Ray Hunter (v6ops) wrote:


Just trying to understand this hurdle/ line of reasoning.

So in addition to achieving "rough consensus", the IETF standardization 
process must also produce drafts that are very likely to gain traction 
to displace non-IETF non-standardised products that are already widely 
commercially deployed?


No. This is not a process hurdle. It was one amongst
a bunch of personal comments I sent. And that I'm happy
to discuss with the authors without wearing any chair
or other hat.

The process problem with these drafts is the lack of
review means there's no way to claim they represent any
useful level of WG consensus.

Cheers,
S.



OpenPGP_0x5AB2FAF17B172BEA.asc
Description: OpenPGP public key


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

Re: [homenet] naming drafts

[Stephen Farrell]

Hi Michael,

On 05/06/2021 19:46, Michael Richardson wrote:

Well, I'd be happy to discuss with this them again, but they'd have to
actually tell us what "DDNS" really is for them.


Just to clarify: I don't think/claim DDNS is "better" than
the proposal here, rather I don't find the arguments as to
why this is "better" convincing, and so, given that DDNS is
deployed, and has some similarity, I'm wondering if this
spec really has much of a chance at gaining traction.

As a result, I don't really think there's that much value
in attempting a point-scoring exercise comparing the two,
the question for me is really whether or not this spec is
so much better than DDNS that it could displace DDNS, and
I'm not convinced as of now. (But I'm often wrong of course.)

Cheers,
S.


OpenPGP_0x5AB2FAF17B172BEA.asc
Description: OpenPGP public key


OpenPGP_signature
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-front-end-naming-delegation-15.txt

[Stephen Farrell]

Hiya,

A few responses below...

On 26/05/2021 18:02, Daniel Migault wrote:

Hi Stephen,

Thanks for the questions / suggestions / comments. Please find some 
responses inline. I updated the document [1] and added issues on the

git repo.

Yours, Daniel

[1] 
https://github.com/ietf-homenet-wg/ietf-homenet-hna/commit/cc07384cf6a93794f984d3393100e700a306317c#diff-1fb3d4609e8b03755bf2390df10a5ccd792f989796a0b922a273cd63418fcaa5




On Mon, May 24, 2021 at 5:01 PM Stephen Farrell
 wrote:



Hiya,

I had a read of this one. My comments (as an individual, not as
chair) below. I'll chat with Barbara to see if we have a common
position on how to handle next steps but am happy to chat about
stuff below whenever.

Cheers, S.

review of draft-ietf-homenet-front-end-naming-delegation-15 sf,
20210524

general/technical:

#1 This needs significant editorial work, there are too many 
grammatical issues, at least some of which lead to ambiguity.


#2 If a home network/CPE isn't robust enough to serve as a DNS 
server for it's public zone, then how is it robust enough to resist

attack/DoS on the addresses exposed in that zone? That seems to me
to counter a bunch of the arguments for this approach, so I'd like
to understand the proponents arguments there. At minimum, any 
for an "inside" server/name means that the CPE's f/w will be
subject to the same kind of attacks that might happen if the CPE
was the only/primary DNS server for the zone.


CPE are optimized for packet l2/l3 packet switching as opposed to 
terminate services. Resources of the CPE are estimated for

volumetric attacks that are expected to be handled by the ISP.
Hosting DNS changes the scope on that the CPE becomes an addressable
target, subject to application DoS attacks which it has not been in
general designed for and which are much harder to tackle for an ISP
as this is "legitimate" traffic. The document does not specify the
HNA is addressable from inside the network and Figure 1 clearly
separates the authoritative server from the HNA. Of course this could
be implemented this way, but I am wondering if there is any text that
suggests such an approach.  It seems to me that discussion over the
management of the authoritative DNS server on the CPE is out of the
scope of the document. In addition, if an DDoS attack is handled from
inside the homenet, the network admin is more likely to unplug that
device than if performed from the Internet. 


I still don't get it sorry. Shodan and zmap will allow anyone
to find the listening port in many cases, regardless of that
being port 53/853 on the CPE or 443 (or even, gulp! port 80)
on some host further into the homenet.

My point here is not that one ought not provide a listening
process within a homenet, but only that this proposal doesn't
really solve robustness issues.


#3 The arguments about handling "disruption with the ISP" could do
with some more evidence, not necessarily as text in the draft, but
it ought exist - does it? E.g. do we know that publishing ULAs
isn't problematic? Do we know that GUAs in such scenarios aren't
still usable for longish durations given a realistic pattern of ISP
disruption?



ISP disruption is not an argument but a requirement from RFC7368
section 3.7.5. I think we all experience some connectivity
disruption, so I do not believe there is a need to clarify this
exists. The most obvious case is equipment that goes down for some
time.  


Sure. To try re-phrase my question: do we have evidence
that the approach proposed here is more robust in that
scenario? Yes I can see that resolving foo.myhome.example
from inside to the HNA should still work, but how much better
will that be *overall* given that foo.myhome.example may be
cached in the stub resolver of clients on the homenet? I'm
wondering if anyone's tried that kind of thing and said
what they found basically. (And similarly wondering if
publishing ULAs in the public DNS has any downsides.)


A transition from one ISP to another seems to me a bit out of
scope of the document. The document considers renumbering which could
be a good start for a more complex management transition, that sounds
to me very specific and out of scope of the document. We have added a
section in the security consideration that I think covers your
concern: """ The HNA enables to handle network disruption as it
contains the Public Homenet Zone, which is provisioned to the Homenet
Authoritative Servers.

However, DNSSEC validation requires to validate the chain of trust
with the DS RRset that is stored into the parent zone of the
Registered Homenet Domain. As currently defined, the handling of the
DS RRset is left to the Homenet DNSSEC resolver which retrieves from
the parent zone via a DNS exchange and cache the RRset according to
the DNS rules, that is respecting the TTL and RRSIG expiration time. 
Such constraints do put some limitations to the type of disruption

the proposed architecture can hand

Re: [homenet] I-D Action: draft-ietf-homenet-front-end-naming-delegation-15.txt

[Stephen Farrell]

Hiya,

I had a read of this one. My comments (as an individual, not
as chair) below. I'll chat with Barbara to see if we have a
common position on how to handle next steps but am happy to
chat about stuff below whenever.

Cheers,
S.

review of draft-ietf-homenet-front-end-naming-delegation-15
sf, 20210524

general/technical:

#1 This needs significant editorial work, there are too many
grammatical issues, at least some of which lead to ambiguity.

#2 If a home network/CPE isn't robust enough to serve as a DNS
server for it's public zone, then how is it robust enough to
resist attack/DoS on the addresses exposed in that zone? That
seems to me to counter a bunch of the arguments for this
approach, so I'd like to understand the proponents arguments
there. At minimum, any  for an "inside" server/name means
that the CPE's f/w will be subject to the same kind of attacks
that might happen if the CPE was the only/primary DNS server
for the zone.

#3 The arguments about handling "disruption with the ISP" could
do with some more evidence, not necessarily as text in the
draft, but it ought exist - does it? E.g. do we know that
publishing ULAs isn't problematic? Do we know that GUAs in such
scenarios aren't still usable for longish durations given a
realistic pattern of ISP disruption?

#4 My home network is IPv6 renumbered every time there's a
reboot/power outage at the DSLAM, which happens maybe twice a
year. How would this protocol handle that? Would the DM get
overloaded maybe?

#5 The arguments why this is better than DDNS don't convince
me, except for the last one (new RR types).  Given that DDNS is
deployed, what's the chances that this would also get traction?
(Not asking that all be in the document, but I am asking.)

#6 Do the DM/DOI care about the names published? If not, why
not? E.g. say an ISP has the DOI servers "first" in how it
resolves names for a local area, what'd stop some home from
claiming to be windowsupdate.com?

#7 If the DOI sends the DS to the parent, then the DOI can
cheat on the home - why is that ok? If it is ok, then shouldn't
there really be a MUST for the HNA to check that the correct DS
is/was published via some recursive outside the control of the
DOI?

#8 Do the DS TTL and RRSIG expiry times set the limit for how
long the home n/w can handle ISP disruption? If so, be good to
say so. I also wonder if that limits the added-value here or
not.

#9 Requiring mutually authenticated TLS between HNA and DM
(section 3.2 has that MUST, even if it says TLS is only
RECOMMENDED), seems like a circular dependency. How does the
HNA get that client-cert before/at the start?

#10 4.x: I don't understand how we get interop based on all
this.  Wouldn't this kind of thing need a bunch of people to
have implemented and interop'd before we could be confident of
the spec?

#11 I don't understand what problem we're really solving with
the reverse zone stuff, nor do I see the overall thing here
would work where the ISP provides those reverse-IP stanzas for
a zone file but where that ISP has no way to update the
parent's DS record. Are there a set of "just doens't work"
configurations there really?  If so, shouldn't that be either
stated or solved somehow?

#12 Section 10 seems like a mix of generic guidance and
requirements but also things needed for interop (e.g. use DoT
on 853). I'm not convinced that's a good plan if we want
multiple implementations that interop.

specific/editorial:

- abstract: "often" where's the evidence for that? Why do you
  even need to make that (questionable) assertion? Better to
just set out the mechanism.

- abstract: "using names" should probably be "using DNS names
  or similar"

- abstract: documents don't "automate" things

- abstract: "servers" - you don't know, and shouldn't require
  that, the FQDNs published are those of servers.

- abstract: "the naming service" - what's that exactly? Isn't
  this just a new flavour of feeding zones to a DNS
authoritative?

- 1.0: what is "a single universal view"? Are you contrasting
  that with split horizon or something?

- 1.1: Publishing ULAs because of a VPN seems like an odd
  justification. Seems more likely a VPN could/would set a
different DNS recursive for clients and ULAs could be handled
there.

- 1.2: that might be better as an appendix or deleted. It's
  probably a bad idea to name specific commercial DDNS
services.

- section 2: "DOI" isn't a good choice - every RFC has one of
  those and it's not what's defined here:-) If you could avoid
the acronym collision that'd be better. Maybe "domain name
outsourcing infrastructure"/DNOI?

- section 2: I'm not seeing why you need (new?) terms for types
  of recursive resolver. Aren't those already defined
elsewhere?

- 3.1: I have no idea what is meant by: " The ".local" as well
  as ".home.arpa" are explicitly not considered as Public
Homenet zones and represented as Homenet Zone in Figure 1."
That seems like an important thing to be clear about.

 - 3.1: How is backup 

Re: [homenet] [Editorial Errata Reported] RFC8375 (6378)

[Stephen Farrell]

On 02/01/2021 15:15, Kulvinder wrote:

My apologies, you are correct. I’ve now seen RFC 1034 which details the 
terminator.


Grand so. I'll ask Eric V. to hit the reject button on this
when he gets back to work after the holidays.

Thanks all,
S.



--

Kulvinder Matharu

*From: *Ted Lemon <mailto:mel...@fugue.com>
*Sent: *02 January 2021 15:02
*To: *Stephen Farrell <mailto:stephen.farr...@cs.tcd.ie>
*Cc: *pierre.pfis...@darou.fr <mailto:pierre.pfis...@darou.fr>; Erik Kline
<mailto:ek.i...@gmail.com>; Eric Vyncke (evyncke) <mailto:evyn...@cisco.com>;
STARK, BARBARA H <mailto:bs7...@att.com>; ksmath...@gmail.com
<mailto:ksmath...@gmail.com>; homenet@ietf.org <mailto:homenet@ietf.org>
*Subject: *Re: [Editorial Errata Reported] RFC8375 (6378)

It’s nonsense. We put the dots on the end on purpose—it’s not an FQDN 
otherwise. :/

  > On Jan 2, 2021, at 9:33 AM, Stephen Farrell  
wrote:

  >

  >

  > Any opinions on this from authors/list? My take would be that

  > this can be rejected as inclusion of full stops within quotes

  > is stylistically correct and that there's no technical issue

  > with including the root's dot in a DNS name. But maybe some

  > other convention has been followed for DNS RFCs in the past?

  >

  > Cheers,

  > S.

  >

  > On 02/01/2021 08:27, RFC Errata System wrote:

  >> The following errata report has been submitted for RFC8375,

  >> "Special-Use Domain 'home.arpa.'".

  >> --

  >> You may review the report below and at:

  >> https://www.rfc-editor.org/errata/eid6378

  >> --

  >> Type: Editorial

  >> Reported by: Kulvinder Matharu 

  >> Section: GLOBAL

  >> Original Text

  >> -

  >> "home.arpa."

  >> Corrected Text

  >> --

  >> "home.arpa"

  >> Notes

  >> -

  >> The domain "home.arpa." is used throughout the document. The domain should,
instead, be "home.arpa".

  >> Instructions:

  >> -

  >> This erratum is currently posted as "Reported". If necessary, please

  >> use "Reply All" to discuss whether it should be verified or

  >> rejected. When a decision is reached, the verifying party

  >> can log in to change the status and edit the report, if necessary.

  >> --

  >> RFC8375 (draft-ietf-homenet-dot-14)

  >> --

  >> Title   : Special-Use Domain 'home.arpa.'

  >> Publication Date: May 2018

  >> Author(s)   : P. Pfister, T. Lemon

  >> Category: PROPOSED STANDARD

  >> Source  : Home Networking

  >> Area: Internet

  >> Stream  : IETF

  >> Verifying Party : IESG

  > 



OpenPGP_0x5AB2FAF17B172BEA.asc
Description: application/pgp-keys


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

Re: [homenet] [Editorial Errata Reported] RFC8375 (6378)

[Stephen Farrell]

Any opinions on this from authors/list? My take would be that
this can be rejected as inclusion of full stops within quotes
is stylistically correct and that there's no technical issue
with including the root's dot in a DNS name. But maybe some
other convention has been followed for DNS RFCs in the past?

Cheers,
S.

On 02/01/2021 08:27, RFC Errata System wrote:

The following errata report has been submitted for RFC8375,
"Special-Use Domain 'home.arpa.'".

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid6378

--
Type: Editorial
Reported by: Kulvinder Matharu 

Section: GLOBAL

Original Text
-
"home.arpa."

Corrected Text
--
"home.arpa"

Notes
-
The domain "home.arpa." is used throughout the document. The domain should, instead, be 
"home.arpa".

Instructions:
-
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party
can log in to change the status and edit the report, if necessary.

--
RFC8375 (draft-ietf-homenet-dot-14)
--
Title   : Special-Use Domain 'home.arpa.'
Publication Date: May 2018
Author(s)   : P. Pfister, T. Lemon
Category: PROPOSED STANDARD
Source  : Home Networking
Area: Internet
Stream  : IETF
Verifying Party : IESG



OpenPGP_0x5AB2FAF17B172BEA.asc
Description: application/pgp-keys


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

Re: [homenet] [Captive-portals] [Int-area] [EXTERNAL] Re: Evaluate impact of MAC address randomization to IP applications

[Stephen Farrell]

Hiya,

I don't agree with that conclusion...

On 30/09/2020 18:16, Michael Richardson wrote:
> My take home from your work is that MAC address randomization is a useless
> waste of time.  It causes significant costs to the network operator(s) without
> actually providing any benefit to the mobile phone owner, because the
> adversary is inside the device, invited in by the owner.
> In such a situation, MAC randomization feels like security theatre to me.

I think MAC address randomisation *alone* isn't very useful
but even so still has some utility as it makes some forms
of tracking (based purely on a static MAC) harder. IIRC
exactly that form of tracking was reported as being done by
the security services in Canada linking MACs seen in
Pearson with those later seen downtown or something. (I
didn't go find the reference so that may be inaccurate.)

MAC address randomisation, when well-coupled to changes
at other layers can be more beneficial. That is how the GAEN system is
designed - the beacon payload (the RPI) is
intended to change with the BLE MAC address about every
10 minutes.

Getting similar benefits for randomised WiFi MAC addresses
with IP and more layers above is hard, but it's still worth
having the basic mechanism so that people can try address those harder
problems over time.

So, no, not "theatre" but far from complete.

I'd probably also disagree with you on the practicality of
depending on 802.1X outside enterprise environments, but
that's a different topic too.

Cheers,
S.



0x5AB2FAF17B172BEA.asc
Description: application/pgp-keys
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] [Captive-portals] [Int-area] [EXTERNAL] Re: Evaluate impact of MAC address randomization to IP applications

[Stephen Farrell]

Hiya,

On 29/09/2020 20:56, Michael Richardson wrote:
> 
> Stephen Farrell  wrote:
> 
> > On 29/09/2020 19:41, Michael Richardson wrote:
> >> It will be good if we can get a document from the MAC randomization
> >> proponents (if there is such a group), to explain the thread profile.
> >> I don't think it includes active compromised hosts.
> 
> > That is a problem yes. I no longer think "compromised host" is the
> > correct term there though. In the case of android, we found google play
> > services regularly calls home linking all these identifiers and more
> > (phone#, sim serial, imei...) [1] for Google's own uses. I'd be very
> 
> I feel that you have confounded two things, and I don't think it's helpful.
> I won't dispute your observatrions about surveillance capitalism, but I feel
> that you've sensationalized what I thought was a pretty specific technical
> point. Namely:
> You can't see into the L3 layer of WIFI, even when there are
> ARP broadcasts, unless your are also part of that L2 network.

I disagree about sensationalising, obviously;-)

The point is that we tended to think of a compromised host
as one that had been subject to a successful attack often
run by an unknown party. For mobile phones, the privacy
adversary seems more often to be an entity that the phone
user has accepted one way or another, whether that be the
OS or handset vendor or whoever wrote that cute spirit-
level app.

> 
> I'm sure that Google Play calls home and tells Google all the your
> L2/L3/IMEI/etc.  I don't doubt it.
> 
> I don't see how this relates to a local passive eavesdropping observing the
> L2 frames with the encrypted L3.  One not involved with the operation
> of the wifi, nor connected to that link.

The MAC address and other identifiers are payload with the
source IP address and thus correlated at the destination
without having to locally eavesdrop. But they can be used
to later correlate with the local eavesdropper's data,
probably after that's also been centralised (perhaps via
another app using the same SDK).

> 
> Unless you are saying that Google Play operates as active eavesdropper on all
> the networks on which it is connected?  I.e. it sends the L2/L3 mappings for
> all devices on that network?

I don't believe google do that for that attack, but they
can correlate the MAC and IP addresses, yes, for all the
devices on a n/w running their OS.

> 
> > More on-topic, 

But yeah the above is a bit off-topic, except that it
shows there's a *lot* more to do in the mobile context
to get benefit from address randomisation.

S.

PS: to be clear - the above's not really anti-google -
we've seen similar looking traffic from handset vendors'
pre-installed s/w too.


> I do think MAC address randomisation has a role to play
> > for WiFi as it does for BLE, but yes there is a lack of guidance as to
> > how to implement and deploy such techniques well. It's a bit tricky
> > though as it's fairly OS dependent so maybe not really in scope for the
> > IETF?
> 
> The IEEE has a spec on how to do MAC address ramdomization.
> It says nothing about how to automatically update the accept-list rules
> created by RFC8520, or RFC8908/RFC8910 (CAPPORT).  Or EAP-FOO.
> 
> > (For the last 3 years I've set a possible student project in
> > this space, but each time a student has considered it, it turned out
> > "too hard";-)
> 
> :-(
> 
> --
> ]   Never tell me the odds! | ipv6 mesh networks [
> ]   Michael Richardson, Sandelman Software Works|IoT architect   [
> ] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on rails
> [
> 
> 
> 
> ___
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet
> 


0x5AB2FAF17B172BEA.asc
Description: application/pgp-keys
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] [Captive-portals] [Int-area] [EXTERNAL] Re: Evaluate impact of MAC address randomization to IP applications

[Stephen Farrell]

Hiya,

On 29/09/2020 19:41, Michael Richardson wrote:
> It will be good if we can get a document from the MAC randomization
> proponents (if there is such a group), to explain the thread profile.
> I don't think it includes active compromised hosts.

That is a problem yes. I no longer think "compromised host"
is the correct term there though. In the case of android,
we found google play services regularly calls home linking
all these identifiers and more (phone#, sim serial,
imei...) [1] for Google's own uses. I'd be very surprised
if other entities (e.g. other OS and handset makers)
weren't doing the same kind of thing (in fact I've seen
some of that but we've not yet written it up). And
supposedly innocuous "apps" can and do embed SDKs that also
do that kind of thing. [2]

I don't think "compromised" is an apt term for such a host.
Perhaps it is apt for almost the entire mobile ecosystem?

More on-topic, I do think MAC address randomisation has a
role to play for WiFi as it does for BLE, but yes there is
a lack of guidance as to how to implement and deploy such
techniques well. It's a bit tricky though as it's fairly
OS dependent so maybe not really in scope for the IETF?
(For the last 3 years I've set a possible student project
in this space, but each time a student has considered it,
it turned out "too hard";-)

Cheers,
S.

[1] https://www.scss.tcd.ie/Doug.Leith/pubs/contact_tracing_app_traffic.pdf
[2] https://arxiv.org/abs/2009.06077



0x5AB2FAF17B172BEA.asc
Description: application/pgp-keys
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] [Int-area] Evaluate impact of MAC address randomization to IP applications

[Stephen Farrell]

Hiya,

On 23/09/2020 01:13, Brian Dickson wrote:
> IMNSHO, MACs should be relegated to the role reflected in their name: Media
> Access Control, basically a disambiguator, not an identity.

With s/disambiguator/local disambiguator/ I would entirely
agree I think.

> The work being done by the exposure notification may be a good reference
> model.
> (Google Apple Exposure Notification, aka GAEN, for the SARS-CoV-2 aka
> Covid-19 protocols for privacy-first automatic exposure notification over
> BLE).
> That too uses identifiers that are non-linkable and rotate periodically (on
> the order of 10 minutes IIRC).

I don't think the GAEN system is a good example.

Mainly because, despite what I think are the good
intentions of all involved (that I've talked to anyway),
I doubt it could ever work reliably (and so is to some
extent theatre) but also because it's inherently vulnerable
to replay attacks, implementations can be very privacy
unfriendly, and the governance part is pretty sucky. It
also turns out that integrating GAEN into a real contact
tracing system seems quite failure prone too. (Apologies
for the self-references but our reports at [1] cover all
the above and more.)

That said, some of the protocol constructs used by GAEN may
well be good things to re-use though - there are some good
ideas there, in addition to the unjustified optimism. (*)

Cheers,
S.

[1] https://down.dsg.cs.tcd.ie/tact/

(*) "unjustified optimism" isn't quite right - I figure
it was more a case of "something must be done;  is
something that is less bad than , therefore 
will be done."


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


0x5AB2FAF17B172BEA.asc
Description: application/pgp-keys
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] [Int-area] Evaluate impact of MAC address randomization to IP applications

[Stephen Farrell]

Hiya,

On 22/09/2020 22:08, Lee, Yiu wrote:
> Hi Stephen,
> 
> Thanks for the notes. Actually, we believe that there are good
> privacy reasons to randomize mac-address. This BoF isn't trying to
> "fix" randomized mac-address. On the contrary, we want the community
> to embrace it. In order to ease the anxiety for transitioning, we
> want to document what may break and propose best practice to
> transition to dynamic mac-address.

Sure, I get that. However, we've seen a number of these
efforts start thusly but end up being perceived to be
partly trying to unwind the privacy benefits, so I think
a good way to avoid that mis-perception is to also present
the reasons for (in this case, MAC address randomisation)
as fully as the description of the challenges caused.

Cheers,
S.


> 
> Thanks, Yiu
> 
> 
> On 9/22/20, 4:51 PM, "Int-area on behalf of Stephen Farrell"
> 
> wrote:
> 
> 
> That agenda and draft seem to make the seemingly common enough
> mistake of only focusing on what a new privacy or security mechanism
> breaks and glossing over the good reasons why people introduce these
> mechanisms. I hope the BoF proponents fix that because otherwise they
> may end up giving the impression that they would prefer to not see 
> the privacy benefits (which I'd guess is not their goal at all). One
> reason those good reasons need to be included is that they constrain
> the kinds of additions that might make sense to better handle the new
> mechanism.
> 
> We've seen a number of these kinds of reactions and I figure it'd
> really be better if the reaction were not to appear purely
> reactionary;-)
> 
> If that were fixed, then there may be a better discussion of what, if
> any, additional things need doing. If that is not fixed, I'd not be
> surprised if the putative BoF were to devolve into a "it's bad" vs.
> "no, it's good" bun fight that won't really take us further.
> 
> Cheers, S.
> 
> On 22/09/2020 21:40, Michael Richardson wrote:
>> 
>> Damn. Spelt captive-portal without the s again.  Reposting, sorry
>> for duplicates. I hate when WG names and list names do not match,
>> and that we can't have aliases. And I think that reply-to gets
>> filtered.
>> 
>> Archived-At:
>> <https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/int-area/14Skgm84GslPZ9UcGoWY3uzmK6I__;!!CQl3mcHX2A!Q0pEjWrLTcmcryUR2EMbSc6uWBNU-xJadaznxWvwmDk2-ARoR0DYYq_eprXSEjo$
>> > To: int-a...@ietf.org, captive-por...@ietf.org, homenet@ietf.org 
>> From: Michael Richardson  Date: Tue, 22 Sep
>> 2020 16:34:33 -0400
>> 
>> This thread was started today on the INTAREA WG ML.
>> 
>> While I don't object to a BOF, I don't know where it goes. What I
>> see is that much of this problem needs to be resolved through 
>> increased use of 802.1X: making WPA-Enterprise easier to use and
>> setup, this changing core identity from MAC Address to IDevID.
>> 
>> My understanding is that Apple intends to randomize MAC every 12
>> hours, even on the same "LAN" (ESSID), and that they will just
>> repeat the WPA authentication afterwards to get back on the
>> network.   If the per-device unique policy (including CAPPORT
>> authorization) can be tied to the device better, than the MAC
>> address based "physical" exception can be updated.
>> 
>> But, WPA-PSK doesn't work, because it does not, in general,
>> distinguish between different devices.
>> 
>> It can be made to work if every device is given a unique PSK, and
>> there are some successful experiments doing exactly that.  Mostly
>> it just works, but the challenge is communicating the unique PSK
>> through an unreliable human. BRSKI can certainly do this, and it
>> can leverage that unencrypted ESSID present at most hospitality
>> locations to get onto the encrypted WPA-Enterprise.  Or BRSKI-TEEP,
>> or some other BRSKI-EAP method.  The unencrypted SSID is not going
>> away at those locations.
>> 
>> Thus QR-code based methods are best, yet those do not work for many
>> IoT devices.   EMU's EAP-NOOB can help in certain cases, but we, as
>> a community need be clear on what direction we want to go.  One
>> answer is that IoT devices have little reason to randomize their
>> MAC if they are not generally ported.
>> 
>> 
>> On 2020-09-22 3:49 p.m., Lee, Yiu wrote:
>>> Hi team,
>>> 
>>> We proposed a BoF. The agenda is in 
>>> https://urldefense.com/v3/__https://github.com/jlivingood/IETF109BoF/blob/master/109-Agenda.md__;!!CQl3mcHX2A!Q0pEjWrLTcmcryUR2EMbSc6uWBNU-xJadaznxWvwmDk2-ARoR0DYYq_e7alyc8U$
>>>

Re: [homenet] [Int-area] Evaluate impact of MAC address randomization to IP applications

[Stephen Farrell]

That agenda and draft seem to make the seemingly common
enough mistake of only focusing on what a new privacy or
security mechanism breaks and glossing over the good
reasons why people introduce these mechanisms. I hope the
BoF proponents fix that because otherwise they may end up
giving the impression that they would prefer to not see
the privacy benefits (which I'd guess is not their goal
at all). One reason those good reasons need to be included
is that they constrain the kinds of additions that might
make sense to better handle the new mechanism.

We've seen a number of these kinds of reactions and I
figure it'd really be better if the reaction were not to
appear purely reactionary;-)

If that were fixed, then there may be a better discussion
of what, if any, additional things need doing. If that is
not fixed, I'd not be surprised if the putative BoF were
to devolve into a "it's bad" vs. "no, it's good" bun fight
that won't really take us further.

Cheers,
S.

On 22/09/2020 21:40, Michael Richardson wrote:
> 
> Damn. Spelt captive-portal without the s again.  Reposting, sorry for 
> duplicates.
> I hate when WG names and list names do not match, and that we can't have 
> aliases.
> And I think that reply-to gets filtered.
> 
> Archived-At: 
> 
> To: int-a...@ietf.org, captive-por...@ietf.org, homenet@ietf.org
> From: Michael Richardson 
> Date: Tue, 22 Sep 2020 16:34:33 -0400
> 
> This thread was started today on the INTAREA WG ML.
> 
> While I don't object to a BOF, I don't know where it goes.
> What I see is that much of this problem needs to be resolved through
> increased use of 802.1X: making WPA-Enterprise easier to use and setup, this
> changing core identity from MAC Address to IDevID.
> 
> My understanding is that Apple intends to randomize MAC every 12 hours, even
> on the same "LAN" (ESSID), and that they will just repeat the WPA
> authentication afterwards to get back on the network.   If the per-device
> unique policy (including CAPPORT authorization) can be tied to the device
> better, than the MAC address based "physical" exception can be updated.
> 
> But, WPA-PSK doesn't work, because it does not, in general, distinguish
> between different devices.
> 
> It can be made to work if every device is given a unique PSK, and there are
> some successful experiments doing exactly that.  Mostly it just works, but
> the challenge is communicating the unique PSK through an unreliable human.
> BRSKI can certainly do this, and it can leverage that unencrypted ESSID
> present at most hospitality locations to get onto the encrypted
> WPA-Enterprise.  Or BRSKI-TEEP, or some other BRSKI-EAP method.  The
> unencrypted SSID is not going away at those locations.
> 
> Thus QR-code based methods are best, yet those do not work for many IoT
> devices.   EMU's EAP-NOOB can help in certain cases, but we, as a community
> need be clear on what direction we want to go.  One answer is that IoT
> devices have little reason to randomize their MAC if they are not generally
> ported.
> 
> 
> On 2020-09-22 3:49 p.m., Lee, Yiu wrote:
>> Hi team,
>>
>> We proposed a BoF. The agenda is in
>> https://github.com/jlivingood/IETF109BoF/blob/master/109-Agenda.md and the
>> proposal is in
>> https://github.com/jlivingood/IETF109BoF/blob/master/BoF-Proposal-20200918.md.
>>  You
>> can also find the draft here
>> https://tools.ietf.org/html/draft-lee-randomized-macaddr-ps-01.
>>
>> At this stage, we are looking for inputs for more use cases and interests
>> of working together in this domain. Please post your comments in the
>> mailing list.
>>
>> Thanks
>>
> 
> 
> --
> Michael Richardson. o O ( IPv6 IøT consulting )
>Sandelman Software Works Inc, Ottawa and Worldwide
> 
> 
> ___
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet
> 


0x5AB2FAF17B172BEA.asc
Description: application/pgp-keys
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

[homenet] Fwd: IETF 107 Vancouver In-Person Meeting Cancelled

[Stephen Farrell]

Hi all,

Many of you will have seen this but we'll not be meeting
f2f in Vancouver this time. Hopefully things will have
improved by the timeframe of IETF108.

In the meantime, we'd like to know if WG participants
would like to hold a virtual interim for homenet. If
you think that would be useful, please let the chairs
or the list know.

The IESG have asked for a bit of time to do some scheduling
that they need to do before WGs start to schedule such
virtual interims. So if we do want a virtual interim please
bear with us for a bit and we'll get back with a poll for
a timeslot as soon as we can.

Cheers,
S.


 Forwarded Message 
Subject: IETF 107 Vancouver In-Person Meeting Cancelled
Date: Tue, 10 Mar 2020 12:10:27 -0700
From: The IESG 
Reply-To: i...@ietf.org
To: IETF Announcement List 
CC: irtf-annou...@irtf.org, i...@ietf.org, 107...@ietf.org

The IESG and the IRTF Chair have decided to cancel the in-person IETF
107 Vancouver meeting. This decision is based on input we gathered from
Working Group (WG) and Research Group (RG) chairs about our ability to
hold productive WG and RG sessions at IETF 107. Our assessment of this
feedback is that a majority of sessions would not be viable if we were
to hold the in-person IETF meeting. On this basis, we believe we cannot
hold an effective in-person meeting.
As a result of this cancellation, the in-person Hackathon, Code Sprint,
all other in-person events planned for the weekend of March 21-22, the
chairs training scheduled for March 20, and all other in-person sessions
during the week are cancelled.

The IESG is working on an alternative all-virtual agenda for the week of
March 21-27 with a limited schedule adapted to accommodate the time
zones of as many participants as possible. We are also planning to
support an increased volume of virtual interim meetings during the weeks
that follow. We will send another update to the community soon with more
information about these plans. The Hackathon organizers are also
considering plans for virtual Hackathon support.

We have re-opened Internet-Draft submissions, which had been closed on
March 9 in anticipation of the in-person meeting. Internet-Drafts may be
submitted at .

A separate announcement from the IETF Executive Director will follow
with details about registration cancellations and refunds.
These are unusual times given the circumstances created by the spread of
COVID-19.  We hope that everyone remains safe and healthy.

Regards,
The IESG and the IRTF Chair

___
IETF-Announce mailing list
ietf-annou...@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce



0x5AB2FAF17B172BEA.asc
Description: application/pgp-keys


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

Re: [homenet] DoH??

[Stephen Farrell]

On 18/09/2019 23:51, Ted Lemon wrote:
> Let’s not discuss this here. This is a topic for add. 

Yes. The ADD list was setup for that discussion (and
exploded). A review of it's archive [1] might be eye
opening, if tedious.

Cheers,
S.

[1] https://mailarchive.ietf.org/arch/browse/add/

> 
>> On Sep 18, 2019, at 18:27, Michael Thomas  wrote:
>>
> 
> ___
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet
> 


0x5AB2FAF17B172BEA.asc
Description: application/pgp-keys


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

Re: [homenet] DoH??

[Stephen Farrell]

Hiya,

On 18/09/2019 23:07, Michael Thomas wrote:
> 
> So I'm a little unclear about the specifics of Firefox using DNS over
> HTTP, but wouldn't this affect homenet naming, or any split horizon kind
> of naming?

FWIW, I just tested with FF nightly in my home n/w for a
name that is locally resolved within net10 but that also
has a global IPv6 address. It worked fine with FF's TRR
mode 2, though there was maybe a short but visible delay
before FF fell back to the system resolver.

So - doesn't have to be a problem.

Cheers,
S.

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


0x5AB2FAF17B172BEA.asc
Description: application/pgp-keys


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

Re: [homenet] IPv6 & firewall config in a home net

[Stephen Farrell]

On 05/09/2019 14:45, Ray Hunter (v6ops) wrote:
> That will likely mean regular renumbering of IA PD by ISP's as the norm
> rather than the exception.

I get a bit of both. If there's a power outage or some other
kinds of service outage I don't get, then I get renumbered
when some bit of ISP kit reboots. Happens about 2-3 times a
year maybe.

S.


0x5AB2FAF17B172BEA.asc
Description: application/pgp-keys


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

Re: [homenet] homenet: what now? ... next?

[Stephen Farrell]

Thanks Michael,

More such input is very welcome! As chairs we'll try ask
again in a bit, but it'll be the same questions basically
so answering now is just as good:-)

On 23/04/2019 22:40, Michael Richardson wrote:
> I think that perhaps the naming work could move to DNSSD WG if closing down
> the WG was important.

Two things on that: a) I'd not thought about moving work
to dnssd, will check it out a bit though, (I believe I may
know one of the chairs:-) and b) closing the WG isn't a
goal, it's just an option, if that's what WG participants
(or the lack thereof) indicate is the right thing.

Cheers,
S.


0x5AB2FAF17B172BEA.asc
Description: application/pgp-keys


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

Re: [homenet] homenet: what now? ... next?

[Stephen Farrell]

Hiya,

Given the level of list inactivity, it's actually really
helpful that you took the time to re-tx those points!

One clarifying question below...

On 08/03/2019 12:48, Juliusz Chroboczek wrote:
> Hi Stephen,
> 
> Sorry if I'm repeating myself -- I've already expressed the opinions
> below, both at the mike and on the list.
> 
>> (a) work on simple naming
> 
> I think that this work should be stalled until we have an implementation
> to play with and make some in vivo experiments. 

Our (chairs), plan for that has been to try help the WG get the
draft to the point where one would normally do a WGLC and to then
hold off on that WGLC, waiting for the kind of implementation
experience you mention. Given the level (i.e., lack) of engagement
though, I'm wondering if that's still a viable plan, despite the
good work Ted and others continue to do it this space.

I'm not sure if by "stalled" you mean sticking with the plan above,
or something else (e.g., for the WG to go entirely quiescent until
the authors come back and claim the draft is done and have running
code). Can you clarify?

Thanks,
S.

> (Experience shows that
> the best way to break a protocol is to give an implementation to Dave.)
> 
>> (b) the drafts on handling names with help from your ISP.
> 
> I fear that these drafts are a bad case of complexity for the sake of
> complexity (or perhaps a case of involving the ISP for the sake of
> involving the ISP).  I still haven't seen a compelling argument that they
> do solve a problem that a trivial end-to-end protocol wouldn't solve.
> Back in July 2018, I wrote the following:
> 
> This is a question that I've been asking since July 2014, and I still
> haven't received an answer I could understand.
> 
> Please see the thread starting on 18 July 2018:
> 
> https://www.mail-archive.com/homenet@ietf.org/msg07012.html
> 
>> (We also have a chartered work item [4] on security that has seen no
>> progress but you can comment on that as item (c) if you like;-)
> 
> Some pointers for the rare people who don't spend most of their leisure
> time reading Internet-Drafts:
> 
>   - HNCP is based on DNCP, which includes a security mechanism designed to
> provide authenticity, integrity and confidentiality of the HNCP data:
> 
> RFC 7525 Section 8
> 
> I believe that this is implemented in hnetd.  (Yeah, Markus and
> Stephen did some remarkable work.)
> 
>   - Babel has two security mechanisms:
> 
> https://tools.ietf.org/html/draft-ietf-babel-hmac
> https://tools.ietf.org/html/draft-ietf-babel-dtls
> 
> There appear to be no standards-track key distribution and rotation
> protocols for either of OSPF, IS-IS, BGP or BFD (static keying seems
> to be the norm), so a natural question is whether HNCP could serve
> this purpose, or whether it would be better to use a dedicated key
> distribution and rotation mechanism.
> 
>   - RFC 3971 Section 6 says the following:
> 
>To protect Router Discovery, SEND requires that routers be
>authorized to act as routers.  This authorization is provisioned in
>both routers and hosts.
> 
> Since hosts don't participate in HNCP, it is not clear if HNCP can be
> used as a SEND trust anchor.  I believe there's the same issue with
> securing access the DNS stub resolver (DNSCrypt, DNS over TLS, etc.).
> 
> -- Juliusz
> 
> ___
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet
> 


0x5AB2FAF17B172BEA.asc
Description: application/pgp-keys


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

Re: [homenet] homenet: what now? ... next?

[Stephen Farrell]

Hi all,

We'd really appreciate more feedback on this topic,
so could you please take a few minutes to give us
some more guidance on where you want to see the
work go from here...

Thanks,
S.

On 01/03/2019 21:21, Stephen Farrell wrote:
> 
> Dear WG,
> 
> At IETF-103 Ted lead a good discussion of where we're at and where we
> and others in the homenet space may be heading. One key aspect of that
> discussion is that we might (or might not) be working on specs that have
> been overtaken by events e.g. in the sense that perhaps there are now
> sufficient other options that people are less likely to implement the
> specs we currently have as WG documents.
> 
> As chairs, we have also noted the relative lack of activity on the list
> in recent months, which could also be related to a lack of interest in
> implementing and deploying our current WG drafts.
> 
> We'd therefore like to have a discussion on the list, between now
> and IETF-104 as to what the WG ought be doing.
> 
> It's fine to offer general opinions, but as a way to break it down, we
> basically have two bits of work in-hand: (a) work on simple naming [1]
> and (b) the drafts on handling names with help from your ISP. [2,3]
> (We also have a chartered work item [4] on security that has seen no
> progress but you can comment on that as item (c) if you like;-)
> 
> Ted also has some concrete ideas for work to do at the upcoming
> hackathon. We've asked him to start a separate thread on that and
> would love to see people participate in that.
> 
> We think there are a few potential positions that participants in the
> discussion may have (or end up having) with respect to each of those,
> perhaps:
> 
> (1) it's great work and I plan to implement or deploy - see
> you at the hackathon!
> (2) it's great work and I'll be actively engaged with it in
> the coming months reviewing drafts and posting to the
> list
> (3) I do care about this stuff getting done, but I don't have
> the time/management interest to spend the time I'd like.
> (4) I'm not that interested in this stuff, but I don't object,
> and I'll read some drafts as I'm able to.
> (5) it's fine stuff, but IMO not going to be used, so there's
> not much point in producing RFCs
> (6) not sure at the moment, maybe the WG should go quiescent for
> a while 'till we know more
> 
> If one of those positions captures your opinion, feel free to respond
> in shorthand. Otherwise, please tell us where you think we ought be
> going, as a WG, with (a), (b) and/or (c).
> 
> To be clear, we're happy to proceed according to the consensus of the
> WG participants whatever that may be. That could mean trying to
> accelerate some work, or closing down the WG, or anything in between,
> assuming we see enough engagement in discussion and that there's a
> rough consensus that we can call.
> 
> As chairs, we want to allow plenty of time for this, and are considering
> devoting (part of) a f2f session to bottoming out on this topic at
> IETF-104 if that's needed, but we'd like to be reassured that the WG
> think we're working on the right things now, and that those are likely
> to be implemented and hopefully deployed.
> 
> We'd really appreciate it if you can send an initial response to
> this mail in the next week so we can start to build an agenda for
> our session at IETF-104.
> 
> Thanks
> B (As chairs)
> 
> 
> [1] https://tools.ietf.org/html/draft-ietf-homenet-simple-naming
> [2]
> https://tools.ietf.org/html/draft-ietf-homenet-front-end-naming-delegation
> [3]
> https://tools.ietf.org/wg/homenet/draft-ietf-homenet-naming-architecture-dhc-options/
> [4] https://tools.ietf.org/wg/homenet/charters
> 
> 
> 
> 
> 
> 
> ___
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet
> 


0x5AB2FAF17B172BEA.asc
Description: application/pgp-keys


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

[homenet] homenet: what now? ... next?

[Stephen Farrell]

Dear WG,

At IETF-103 Ted lead a good discussion of where we're at and where we
and others in the homenet space may be heading. One key aspect of that
discussion is that we might (or might not) be working on specs that have
been overtaken by events e.g. in the sense that perhaps there are now
sufficient other options that people are less likely to implement the
specs we currently have as WG documents.

As chairs, we have also noted the relative lack of activity on the list
in recent months, which could also be related to a lack of interest in
implementing and deploying our current WG drafts.

We'd therefore like to have a discussion on the list, between now
and IETF-104 as to what the WG ought be doing.

It's fine to offer general opinions, but as a way to break it down, we
basically have two bits of work in-hand: (a) work on simple naming [1]
and (b) the drafts on handling names with help from your ISP. [2,3]
(We also have a chartered work item [4] on security that has seen no
progress but you can comment on that as item (c) if you like;-)

Ted also has some concrete ideas for work to do at the upcoming
hackathon. We've asked him to start a separate thread on that and
would love to see people participate in that.

We think there are a few potential positions that participants in the
discussion may have (or end up having) with respect to each of those,
perhaps:

(1) it's great work and I plan to implement or deploy - see
you at the hackathon!
(2) it's great work and I'll be actively engaged with it in
the coming months reviewing drafts and posting to the
list
(3) I do care about this stuff getting done, but I don't have
the time/management interest to spend the time I'd like.
(4) I'm not that interested in this stuff, but I don't object,
and I'll read some drafts as I'm able to.
(5) it's fine stuff, but IMO not going to be used, so there's
not much point in producing RFCs
(6) not sure at the moment, maybe the WG should go quiescent for
a while 'till we know more

If one of those positions captures your opinion, feel free to respond
in shorthand. Otherwise, please tell us where you think we ought be
going, as a WG, with (a), (b) and/or (c).

To be clear, we're happy to proceed according to the consensus of the
WG participants whatever that may be. That could mean trying to
accelerate some work, or closing down the WG, or anything in between,
assuming we see enough engagement in discussion and that there's a
rough consensus that we can call.

As chairs, we want to allow plenty of time for this, and are considering
devoting (part of) a f2f session to bottoming out on this topic at
IETF-104 if that's needed, but we'd like to be reassured that the WG
think we're working on the right things now, and that those are likely
to be implemented and hopefully deployed.

We'd really appreciate it if you can send an initial response to
this mail in the next week so we can start to build an agenda for
our session at IETF-104.

Thanks
B (As chairs)


[1] https://tools.ietf.org/html/draft-ietf-homenet-simple-naming
[2]
https://tools.ietf.org/html/draft-ietf-homenet-front-end-naming-delegation
[3]
https://tools.ietf.org/wg/homenet/draft-ietf-homenet-naming-architecture-dhc-options/
[4] https://tools.ietf.org/wg/homenet/charters







0x5AB2FAF17B172BEA.asc
Description: application/pgp-keys


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

Re: [homenet] Reminder: homenet call

[Stephen Farrell]

On 23/10/2018 17:44, Ted Lemon wrote:
> Thanks, Stephen.   The new version of the document is out.

Excellent.

Folks - there's no need to wait for the IETF meeting to
comment on this - review on the list in the meantime is
very welcome!

Cheers,
S.


> 
> On Tue, Oct 23, 2018 at 12:01 PM Stephen Farrell 
> wrote:
> 
>>
>> Hi all,
>>
>> And draft minutes are now at [1].
>>
>> Ted is hoping to get a new simple-naming I-D out today
>> before the cutoff, so you may be as well to wait a bit
>> and read that vs. the text referenced in those minutes.
>>
>> Cheers,
>> S.
>>
>> [1]
>>
>> https://datatracker.ietf.org/meeting/interim-2018-homenet-11/materials/minutes-interim-2018-homenet-11-201810231100
>>
>> On 22/10/2018 18:45, STARK, BARBARA H wrote:
>>> Hi homenet,
>>> I just wanted to remind everyone we have a call scheduled tomorrow to
>> progress the simple-naming draft.
>>>
>>> Time: 11:00-12:00 EDT
>>> Place:
>> https://ietf.webex.com/ietf/j.php?MTID=mca447be3b15845189801f00cf05f1d21
>>> Agenda:
>> https://datatracker.ietf.org/doc/agenda-interim-2018-homenet-11-homenet-01/
>>>
>>> Join Webex meeting
>>> Meeting number (access code): 642 133 910
>>> Meeting password: G7ShuHYV
>>>
>>> Join by phone
>>> 1-650-479-3208 Call-in toll number (US/Canada)
>>>
>>> Barbara
>>>
>>> ___
>>> homenet mailing list
>>> homenet@ietf.org
>>> https://www.ietf.org/mailman/listinfo/homenet
>>>
>>>
>> ___
>> homenet mailing list
>> homenet@ietf.org
>> https://www.ietf.org/mailman/listinfo/homenet
>>
> 
> 
> ___
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet
> 


0x5AB2FAF17B172BEA.asc
Description: application/pgp-keys


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

Re: [homenet] Reminder: homenet call

[Stephen Farrell]

Hi all,

And draft minutes are now at [1].

Ted is hoping to get a new simple-naming I-D out today
before the cutoff, so you may be as well to wait a bit
and read that vs. the text referenced in those minutes.

Cheers,
S.

[1]
https://datatracker.ietf.org/meeting/interim-2018-homenet-11/materials/minutes-interim-2018-homenet-11-201810231100

On 22/10/2018 18:45, STARK, BARBARA H wrote:
> Hi homenet,
> I just wanted to remind everyone we have a call scheduled tomorrow to 
> progress the simple-naming draft.
> 
> Time: 11:00-12:00 EDT
> Place: 
> https://ietf.webex.com/ietf/j.php?MTID=mca447be3b15845189801f00cf05f1d21
> Agenda: 
> https://datatracker.ietf.org/doc/agenda-interim-2018-homenet-11-homenet-01/
> 
> Join Webex meeting 
> Meeting number (access code): 642 133 910 
> Meeting password: G7ShuHYV
> 
> Join by phone  
> 1-650-479-3208 Call-in toll number (US/Canada)  
> 
> Barbara
> 
> ___
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet
> 
> 


0x5AB2FAF17B172BEA.asc
Description: application/pgp-keys


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

Re: [homenet] Minutes of today's interim

[Stephen Farrell]

On 22/08/18 00:05, Brian E Carpenter wrote:
> On 2018-08-22 09:05, Stephen Farrell wrote:
>>
>> Hi all,
>>
>> I posted minutes at [1]. Comments welcome!
> 
> Thanks for the detailed notes.
> 
> The github repo URL is wrong. Try 
> https://github.com/ietf-homenet-wg/simple-naming

Thanks for the correction, fixed now in tracker.
Cheers,
S.

> 
>   Brian
>  
>> Next session is same time (1500 UTC) on Sep 4th.
>>
>> Cheers,
>> S.
>>
>> [1]
>> https://datatracker.ietf.org/meeting/interim-2018-homenet-01/materials/minutes-interim-2018-homenet-01-201808211600
>>
>>
>>
>> ___
>> homenet mailing list
>> homenet@ietf.org
>> https://www.ietf.org/mailman/listinfo/homenet
>>
> 


0x5AB2FAF17B172BEA.asc
Description: application/pgp-keys


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

[homenet] Minutes of today's interim

[Stephen Farrell]

Hi all,

I posted minutes at [1]. Comments welcome!

Next session is same time (1500 UTC) on Sep 4th.

Cheers,
S.

[1]
https://datatracker.ietf.org/meeting/interim-2018-homenet-01/materials/minutes-interim-2018-homenet-01-201808211600


0x5AB2FAF17B172BEA.asc
Description: application/pgp-keys


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

Re: [homenet] Home Networking (homenet) WG Virtual Meeting: 2018-09-04

[Stephen Farrell]

Hiya,

On 20/08/18 17:58, Ted Lemon wrote:
> I believe that this meeting was originally scheduled for 1500 UTC, which
> would be 1600 Dublin time, not 1100 Dublin time.   A time change the day
> before the meeting is (a) not enough notice and (b) I suspect not what was
> intended. :)

Yep, all meetings will be at 1500 UTC (at least until clocks
change, and we can discuss what we want closer to time for
that). I suspect I likely screwed up something in the meeting
request, but we're fixing it with Amy.

Apologies for the distraction;-)

Cheers,
S.

> 
> On Mon, Aug 20, 2018 at 12:21 PM, IESG Secretary 
> wrote:
> 
>> The Home Networking (homenet) Working Group will hold
>> a virtual interim meeting on 2018-09-04 from 11:00 to 12:30 Europe/Dublin.
>>
>> Agenda:
>> Continuing progressing issues with https://tools.ietf.org/html/dr
>> aft-ietf-homenet-simple-naming-02
>>
>> Information about remote participation:
>> Remote participation information will be obtained at the time of approval
>>
>>
> 
> 
> 
> ___
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet
> 


0x5AB2FAF17B172BEA.asc
Description: application/pgp-keys


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

[homenet] Fwd: (Forward to others) Webex meeting invitation: homenet wg interim

[Stephen Farrell]

Hi all,

Here's webex connection information for our virtual
interim meeting for August 21st.

I've also attached the agenda and our template for
minutes - feel free to reply to this if there're
any changes you'd like.

If someone needs to test webex, please let the chairs
know - we've also setup a meeting for the same time on
the day before (so 1500UTC august 20th). We'll unicast
the connection details for that to anyone who needs to
do such a test.

Talk to (some of) you next Tuesday!

Cheers,
Stephen/Barbara.


 Forwarded Message 
Subject: (Forward to others) Webex meeting invitation: homenet wg interim
Resent-Date: Fri, 17 Aug 2018 08:36:44 -0700 (PDT)
Resent-From: alias-boun...@ietf.org
Resent-To: bs7...@att.com, stephen.farr...@cs.tcd.ie
Date: Fri, 17 Aug 2018 15:36:40 + (GMT)
From: Homenet Working Group 
Reply-To: homenet-cha...@ietf.org
To: homenet-cha...@ietf.org


You can forward this invitation to others.
Hello,

Homenet Working Group invites you to join this Webex meeting.


homenet wg interim
Tuesday, August 21, 2018
11:00 am  |  Eastern Daylight Time (New York, GMT-04:00)  |  1 hr
Meeting number (access code): 640 646 421 Meeting password: JsvmjXMY



Add to Calendar
https://ietf.webex.com/ietf/j.php?MTID=mf8fee166577112f750f3241dd6ff0d77

When it's time, join the meeting.
https://ietf.webex.com/ietf/j.php?MTID=m2f68121c49aaf07cc3bb11571ca55c1c


JOIN BY PHONE
1-650-479-3208 Call-in toll number (US/Canada)


Can't join the meeting?
https://collaborationhelp.cisco.com/article/WBX29055


IMPORTANT NOTICE: Please note that this Webex service allows audio and
other information sent during the session to be recorded, which may be
discoverable in a legal matter. By joining this session, you
automatically consent to such recordings. If you do not consent to being
recorded, discuss your concerns with the host or do not join the session.


Webex_Meeting.ics
Description: Binary data

20180821 IETF homenet wg interim meeting

Agenda/minutes template

Logistics:
==

Webex details: 
https://ietf.webex.com/ietf/j.php?MTID=m2f68121c49aaf07cc3bb11571ca55c1c
Jabber room: xmpp:home...@jabber.ietf.org?join
etherpad: TBD 

[ Chairs - don't forget to hit "record" button:-) ]

Attendees:
==

Chairs:
- Barbara Stark
- Stephen Farrell

Present:
- TBD

Minute taker:
- chairs + help, in etherpad

Agenda:
===

1. Agenda bash
2. Identify/progress issues with 
https://tools.ietf.org/html/draft-ietf-homenet-simple-naming-02
3. AOB

Minutes:


1. Agenda bash

TBD

2. Identify/progress issues with 
https://tools.ietf.org/html/draft-ietf-homenet-simple-naming-02

- Question for editors: any updates on state of play/plans?

- Issues: 1st pass - just list to see if some are missing...

- Issues from IETF-102 slides:

https://datatracker.ietf.org/meeting/102/materials/slides-102-homenet-naming-slides-01
- slide 3: remove discussion of "advanced" architecture from draft
- slide 4: name and authority, resolution proposd, HNCP question
- slide 5: how do we allow hosts that don't do MPvD to be effective on 
a homenet?
- slide 6: reverse mappnings
- slide 7: link naming
- slide 8: stateful versus stateless service discovery
- slide 9: name resolution
- slide 10: DNSSEC

- Questions for group: how do we want to process issues?
- ordering?
- tracking? 
options: goodle docs, move to github, wiki issues, other?

- 2nd pass: discuss issues...

3. AOB

TBD



0x5AB2FAF17B172BEA.asc
Description: application/pgp-keys


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

Re: [homenet] regular wg virtual interims - doodle poll for which day (due Friday)

[Stephen Farrell]

And the winner is...

First call Tuesday August 21st 1500-1630 UTC
(but with the goal of being done in 45 mins).

Calls to follow at two week intervals for 4-5
iterations.

1500 UTC is 1700 in France, 1600 in Ireland,
1100 US east coast and 0800 US west coast.
If the calls are useful and we keep going
and span clocks going back an hour, we will
move to 1600 UTC to keep the local time the
same.

I'll get the secretariat stuff setup and we
should see some more official announcements.
Barbara and I will send an agenda for call#1
in a week or so.

Cheers,
S.

On 30/07/18 15:35, Stephen Farrell wrote:
> 
> Hiya,
> 
> As previously discussed, [1] we'd like to schedule
> four or five bi-weekly virtual interims to progress
> the simple naming document.
> 
> Feedback so far seems to indicate that 1500 UTC is an
> ok time, (that's 1600 here in Dublin, 1100 in EDT
> and 0800 US west coast), and maybe Tue, Wed or Thu
> are ok days. I've created a doodle poll to see which
> is the least bad day [1], and which week to start.
> 
> Please fill that in before 1300 UTC this Friday and
> we'll go with whatever the poll shows.
> 
> When we've picked a day, we'll get the secretariat
> to announce/setup the virtual interims and send
> logistics and agendas. Calls will use the IETF webex
> setup.
> 
> We'll schedule the calls for 90 minutes but try to
> use less time if we can. (Ideally <=45 mins.)
> 
> Separately, Barbara is going to try setup a github
> organisation for the WG, as we'd like to be able to
> process text during these calls. But we plan to try
> see if that works, or if e.g. a google doc (to which
> anyone can write w/o a google a/c) is a better tool
> to use during calls. More on that as we play with the
> tools and chat with the editors, but so long as we're
> willing to be a bit patient in finding out what works
> for the folks who join the calls, things should work
> out ok.
> 
> Thanks,
> S.
> 
> [1] https://www.ietf.org/mail-archive/web/homenet/current/msg07738.html
> [2] https://doodle.com/poll/w75myvv3pxps2ax8
> 
> 
> 
> ___
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet
> 


0x5AB2FAF17B172BEA.asc
Description: application/pgp-keys


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

[homenet] regular wg virtual interims - doodle poll for which day (due Friday)

[Stephen Farrell]

Hiya,

As previously discussed, [1] we'd like to schedule
four or five bi-weekly virtual interims to progress
the simple naming document.

Feedback so far seems to indicate that 1500 UTC is an
ok time, (that's 1600 here in Dublin, 1100 in EDT
and 0800 US west coast), and maybe Tue, Wed or Thu
are ok days. I've created a doodle poll to see which
is the least bad day [1], and which week to start.

Please fill that in before 1300 UTC this Friday and
we'll go with whatever the poll shows.

When we've picked a day, we'll get the secretariat
to announce/setup the virtual interims and send
logistics and agendas. Calls will use the IETF webex
setup.

We'll schedule the calls for 90 minutes but try to
use less time if we can. (Ideally <=45 mins.)

Separately, Barbara is going to try setup a github
organisation for the WG, as we'd like to be able to
process text during these calls. But we plan to try
see if that works, or if e.g. a google doc (to which
anyone can write w/o a google a/c) is a better tool
to use during calls. More on that as we play with the
tools and chat with the editors, but so long as we're
willing to be a bit patient in finding out what works
for the folks who join the calls, things should work
out ok.

Thanks,
S.

[1] https://www.ietf.org/mail-archive/web/homenet/current/msg07738.html
[2] https://doodle.com/poll/w75myvv3pxps2ax8


0x5AB2FAF17B172BEA.asc
Description: application/pgp-keys


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

[homenet] virtual interims to progress simple naming draft

[Stephen Farrell]

Hiya,

As mentioned in Montreal, we're thinking of organising a set
of virtual interims to try help progress this [1] draft. The
goal is to try more quickly move it along to the point where
(we think) it's editorially complete, at which point it ought
be easier for implementers to use, and to give feedback to
the WG. IOW, the proximate goal of these virtual interims is
not WGLC and publication, but to get us to what some other WGs
call an "implementation draft."

In Montreal we spoke about maybe 4-5 meetings, with one every
two weeks or so, and each for something like 60-120 minutes.
Given the rules for these kinds of meeting [2] we'd be starting
those in a few weeks.

Before doing that it'd be great to get feedback as to whether:

a) you will/won't participate,
b) which day(s) of the week are good/bad,
c) which times of day (in UTC) are good/bad,
d) and how long would you say such meetings ought be?

We won't find anything perfect but if enough active participants
are ok with doing this, we can cut it down to a few options and
do a poll to see which option is least bad.

So please send your answers to a,b, c and d above to the
chair's alias (cc'd on this message) this week and we'll get
back to the list with specific options in about a week.

If you want to discuss this as a plan, please do and use this
thread but please try not to end your specific answers to the
list:-)

Cheers,
S.

[1] https://tools.ietf.org/html/draft-ietf-homenet-simple-naming
[2]
https://www.ietf.org/blog/guidance-face-face-and-virtual-interim-meetings/?primary_topic=7;




0x5AB2FAF17B172BEA.asc
Description: application/pgp-keys


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

Re: [homenet] draft-ietf-homenet-front-end-naming-delegation vs. DynDNS

[Stephen Farrell]

(with no hats...)

On 19/07/18 10:42, Juliusz Chroboczek wrote:

>> Also, think of the privacy implications if all of the services on the
>> homenet had to be discovered from a shared zone like dyndns.org.

> Quite the opposite.  In the trivial update protocol, the update is
> end-to-end, encrypted, and only the host and the DNS provider see the
> data.  Every Homenet, every host, heck, even every application can use
> a different DNS provider, and each DNS provider only sees the data that
> was explicitly sent to it.

I'm also a bit puzzled by how the subset of records to be
globally published relates to the set of records that are
to be internally visible. I guess this is not something
that we'd fully standardise, but there are privacy issues
here if too much gets published globally, so there may be
some protocol (change/tweak) required to make it possible
for implementers to distinguish which information ought be
globally visible, and which not.

Cheers,
S.


0x5AB2FAF17B172BEA.asc
Description: application/pgp-keys


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

Re: [homenet] Alvaro Retana's Discuss on draft-ietf-homenet-babel-profile-06: (with DISCUSS and COMMENT)

[Stephen Farrell]

On 09/05/18 23:19, STARK, BARBARA H wrote:
> I do believe that, given the hyper-awareness of the 2015 discussion,
> the WG knew what it was agreeing to (or not objecting to). I believe
> the WG is knowingly saying it wants to move on.
FWIW, I concur.

S.


0x5AB2FAF17B172BEA.asc
Description: application/pgp-keys


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

[homenet] ietf 101 provisional agenda is out...

[Stephen Farrell]

Hiya,

The preliminary agenda has been published. [1]

That has us meeting Friday morning, at the same time as:
ice, mmusic, iccrg, detnet, roll, i2nst, suit and dtn.

If that causes a significant issue for anyone who'd be
needed for the homenet session, please let Barbara and
I know (offlist) and we'll see if anything's fixable.

Doing that in the next day or so is usually when there's
a chance of getting things changed more easily.

Note that given the recent security thread we asked to
meet after the babel wg had their session so there may
not be as many changes possible as would otherwise be
the case.

And lastly, don't depend on this agenda not changing.
There will be some changes in the next week or two.
So either wait for the final agenda before booking
travel or else (and better) plan to do the full IETF
week long experience:-)

Cheers,
S.

[1] https://datatracker.ietf.org/meeting/101/agenda.html

-- 
PGP key change time for me.
New-ID 7B172BEA; old-ID 805F8DA2 expires Jan 24 2018.
NewWithOld sigs in keyservers.
Sorry if that mucks something up;-)


0x7B172BEA.asc
Description: application/pgp-keys


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

Re: [homenet] security work items - what do we want to do?

[Stephen Farrell]

Hi All,

Barbara and I chatted about the discussion in this thread,
and here's our summary, please correct us if we've gotten
stuff wrong.

- On item 1, work on the security considerations of
draft-ietf-homenet-simple-naming will proceed as usual.

- On item 2, (the perimeter security draft milestone in
our charter), we don't see anyone stepping up right now
to do that work, so unless someone does in the next few
days, we'll have a chat with our AD about whether or not
it makes sense to remove that milestone from the charter,
or do something else. We'll report back on that at
IETF-101 or before.

- On item 3, (profiling HNCP and Babel security stuff
for homenet), it seems like folks would like to wait a
bit and see how at least the Babel work progresses, and
maybe we should have a discussion at IETF-101 about when
it makes sense to start work on profiling what gets picked
in the Babel WG, for use in homenets, and whether there's
any chance of near-term progress on HNCP security
mechanisms for homenets. We'll also allocate a slot in
our draft agenda for a presentation about anima enrolment
(as offered by Michael Richardson, assuming he's still up
for doing that:-) to provide some additional background
for that discussion.

Again, thanks for the discussion so far, and please
do correct the above if we've mis-interpreted the
sense of the list.

Cheers,
Barbara and Stephen.


0x7B172BEA.asc
Description: application/pgp-keys


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

Re: [homenet] security work items - what do we want to do?

[Stephen Farrell]

Hiya,

On 24/01/18 19:21, Michael Richardson wrote:
> 
> Stephen Farrell <stephen.farr...@cs.tcd.ie> wrote:
> > On 24/01/18 15:36, Ted Lemon wrote:
> >> Yes, enrollment is the process by which trust is established. Google
> >> home has an example, but it's rickety. It's actually not too bad for
> >> actual Google devices, but the third party enrollment process could
> >> really benefit from some open standards (imho).
> 
> > While I don't disagree with you, I do still wonder if we'd
> > not be better off using another term for cases where maybe
> > all that are involved are a couple of routers in the home,
> > and where there's no external party, such as google in the
> > example you give.
> 
> If you are suggesting we should write a clear problem statement with
> new-fangled and terminology devoid of historical baggage, and then argue
> about that for 6-10 months... well...  we could start that now :-)

You are entirely correct that I'm not suggesting that:-)

> Two routers exchanging some keys on a TOFU basis might qualify as (mutual)
> enrollment, as the keys are stored someplace for the "second use".

Sure. OTOH, using the term enrollment I think might confuse
folks and perhaps the discussion as there's quite a bit of
(mostly PKI;-) baggage associated with that term, for me anyway.

Aside from terminology the main thing is the distinction between
situations that do, or do not, involve a party external to the
homenet, which makes a very big difference.

Cheers,
S.

> 
> Stephen Farrell <stephen.farr...@cs.tcd.ie> wrote:
> > Without a chair hat on, I'm not sure that some of those
> > other bits of work need to be fully finished - if we know
> > what kind of keying that'll be used in the final results,
> > we could make some progress, but I do agree we'd need to
> 
> the reason I said that things should be finished, is because I believe that a
> 3/4 year problem statement discussion will distract the WG from actually
> finishing that existing work
> 
> --
> Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works
>  -= IPv6 IoT consulting =-
> 
> 
> 

-- 
PGP key change time for me.
New-ID 7B172BEA; old-ID 805F8DA2 expires Jan 24 2018.
NewWithOld sigs in keyservers.
Sorry if that mucks something up;-)


0x7B172BEA.asc
Description: application/pgp-keys


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

Re: [homenet] security work items - what do we want to do?

[Stephen Farrell]

Hiya,

On 24/01/18 15:36, Ted Lemon wrote:
> Yes, enrollment is the process by which trust is established. Google
> home has an example, but it's rickety. It's actually not too bad for
> actual Google devices, but the third party enrollment process could
> really benefit from some open standards (imho).

While I don't disagree with you, I do still wonder if we'd
not be better off using another term for cases where maybe
all that are involved are a couple of routers in the home,
and where there's no external party, such as google in the
example you give.

The reason I'm on about this is that if we use terms like
"trust" and "enrollment" without qualification, then we may
end up meaning quite different things, which might then
make it harder to try find some solutions to what are in
any case all hard problems.

Cheers,
S.


> 
>> On Jan 24, 2018, at 10:03 AM, Stephen Farrell
>> <stephen.farr...@cs.tcd.ie> wrote:
>> 
>> 
>> Hiya,
>> 
>> On 24/01/18 14:55, Ted Lemon wrote:
>>> I don't know what unmanaged enrollment really looks like, but
>>> sure. We've mostly been talking about models for managed
>>> enrollment, and that seems to be the way the market has been
>>> going (with remarkable suck-itude, if the Google Home enrollment
>>> process is typical).
>> 
>> A question for ya: I'm not sure if by "enrollment" you include such
>> things as two routers deciding to agree that some key material is
>> sufficient for subsequently protecting hncp or babel packets
>> between themselves? (I don't want to get into discussion now as to
>> how either might happen, I just wonder if we'd be better off using
>> different terms for these problems.)
>> 
>>> I think it might be worth having someone give a presentation on
>>> the anima enrollment model, if someone is willing to do that.
>> 
>> Sure. If someone wants to volunteer to do that, just ping Barbara
>> and I and we can throw that into pile for agenda construction.
>> 
>> Cheers, S.
>> 
>> 
>>> 
>>>> On Jan 24, 2018, at 8:51 AM, Stephen Farrell 
>>>> <stephen.farr...@cs.tcd.ie> wrote:
>>>> 
>>>> 
>>>> Hiya,
>>>> 
>>>> On 24/01/18 13:32, Michael Richardson wrote:
>>>>> 
>>>>> Stephen Farrell <stephen.farr...@cs.tcd.ie> wrote:
>>>>>> On 24/01/18 02:48, Michael Richardson wrote:
>>>>>>> 
>>>>>>> Stephen Farrell <stephen.farr...@cs.tcd.ie> wrote: > -
>>>>>>> Does this sound roughly right or off the wall?
>>>>>>> 
>>>>>>> It sounds right.  I think that bootstrap of security
>>>>>>> should become an recharter item in the future.  Some kind
>>>>>>> of BCP on interactions with MUD, SUIT, etc. IN THE
>>>>>>> FUTURE. NOT NOW.
>>>>> 
>>>>>> Can you say more? Eg. what would be needed before you
>>>>>> think it'd be sensible for homenet to start work in this
>>>>>> space?
>>>>> 
>>>>> a) finish (really finish) Babel work, that might mean
>>>>> interacting with BABEL WG
>>>>> 
>>>>> b) DNS naming and delegation in Last Call.
>>>>> 
>>>>> c) ANIMA and related groups publish *managed* enrollment, so
>>>>> that HOMENET can consider how *unmanaged* enrollment might
>>>>> work.
>>>> 
>>>> Reasonable points. Do others (dis)agree?
>>>> 
>>>> Without a chair hat on, I'm not sure that some of those other
>>>> bits of work need to be fully finished - if we know what kind
>>>> of keying that'll be used in the final results, we could make
>>>> some progress, but I do agree we'd need to know e.g. whether
>>>> Babel implementations would plan to support what flavours of
>>>> DTLS (e.g. pre-shared keys vs. bare public keys vs. certs if
>>>> they do plan to use DTLS), and other similar things, so I tend
>>>> to agree those bits of work would need to be at least
>>>> nearly-done.
>>>> 
>>>>> 
>>>>>>>> 2. We have this milestone in our charter:
>>>>>>> 
>>>>>>>> "Nov 2018 - Submission of the perimeter security draft
>>>>>>>> > to the IESG
>>>>>>> as Informational RFC"
>>>>>>> 
>>>>>>&g

Re: [homenet] security work items - what do we want to do?

[Stephen Farrell]

Hiya,

On 24/01/18 14:55, Ted Lemon wrote:
> I don't know what unmanaged enrollment really looks like, but sure.
> We've mostly been talking about models for managed enrollment, and
> that seems to be the way the market has been going (with remarkable
> suck-itude, if the Google Home enrollment process is typical). 

A question for ya: I'm not sure if by "enrollment" you
include such things as two routers deciding to agree
that some key material is sufficient for subsequently
protecting hncp or babel packets between themselves?
(I don't want to get into discussion now as to how
either might happen, I just wonder if we'd be better
off using different terms for these problems.)

>  I
> think it might be worth having someone give a presentation on the
> anima enrollment model, if someone is willing to do that.

Sure. If someone wants to volunteer to do that, just
ping Barbara and I and we can throw that into pile for
agenda construction.

Cheers,
S.


> 
>> On Jan 24, 2018, at 8:51 AM, Stephen Farrell
>> <stephen.farr...@cs.tcd.ie> wrote:
>> 
>> 
>> Hiya,
>> 
>> On 24/01/18 13:32, Michael Richardson wrote:
>>> 
>>> Stephen Farrell <stephen.farr...@cs.tcd.ie> wrote:
>>>> On 24/01/18 02:48, Michael Richardson wrote:
>>>>> 
>>>>> Stephen Farrell <stephen.farr...@cs.tcd.ie> wrote: > - Does
>>>>> this sound roughly right or off the wall?
>>>>> 
>>>>> It sounds right.  I think that bootstrap of security should
>>>>> become an recharter item in the future.  Some kind of BCP on
>>>>> interactions with MUD, SUIT, etc. IN THE FUTURE. NOT NOW.
>>> 
>>>> Can you say more? Eg. what would be needed before you think
>>>> it'd be sensible for homenet to start work in this space?
>>> 
>>> a) finish (really finish) Babel work, that might mean interacting
>>> with BABEL WG
>>> 
>>> b) DNS naming and delegation in Last Call.
>>> 
>>> c) ANIMA and related groups publish *managed* enrollment, so that
>>> HOMENET can consider how *unmanaged* enrollment might work.
>> 
>> Reasonable points. Do others (dis)agree?
>> 
>> Without a chair hat on, I'm not sure that some of those other bits
>> of work need to be fully finished - if we know what kind of keying
>> that'll be used in the final results, we could make some progress,
>> but I do agree we'd need to know e.g. whether Babel implementations
>> would plan to support what flavours of DTLS (e.g. pre-shared keys
>> vs. bare public keys vs. certs if they do plan to use DTLS), and
>> other similar things, so I tend to agree those bits of work would
>> need to be at least nearly-done.
>> 
>>> 
>>>>>> 2. We have this milestone in our charter:
>>>>> 
>>>>>> "Nov 2018 - Submission of the perimeter security draft > to
>>>>>> the IESG
>>>>> as Informational RFC"
>>>>> 
>>>>> Yes.  Are the authors still engaged?
>>> 
>>>> I'm not aware that we have authors;-( I guess someone could
>>>> have volunteered in the past before I was helping out as chair
>>>> (if so, please do let us know).
>>> 
>>> Ah, so it was Erik and some other people.  I see that the draft
>>> has even expired.  I'm thinking about:
>>> https://datatracker.ietf.org/doc/draft-kline-homenet-default-perimeter/
>>>
>>> 
Maybe you are thinking about something else?
>> 
>> Nope, I'd not seen that draft before.
>> 
>> Do others still consider we should work on this topic? (based on
>> that draft or not) and we'd still like to know who's willing to do
>> stuff, if so.
>> 
>> Cheers, S.
>> 
>>> 
>>> -- ]   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[
>>> 
>>> 
>>> -- Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software
>>> Works -= IPv6 IoT consulting =-
>>> 
>>> 
>>> 
>> 
>> -- PGP key change time for me. New-ID 7B172BEA; old-ID 805F8DA2
>> expires Jan 24 2018. NewWithOld sigs in keyservers. Sorry if that
>> mucks something up;-) 
>> <0x7B172BEA.asc>___ 
>> homenet mailing list homenet@ietf.org <mailto:homenet@ietf.org> 
>> https://www.ietf.org/mailman/listinfo/homenet
>> <https://www.ietf.org/mailman/listinfo/homenet>
> 
> 
> 
> ___ homenet mailing list 
> homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
> 

-- 
PGP key change time for me.
New-ID 7B172BEA; old-ID 805F8DA2 expires Jan 24 2018.
NewWithOld sigs in keyservers.
Sorry if that mucks something up;-)


0x7B172BEA.asc
Description: application/pgp-keys


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

Re: [homenet] security work items - what do we want to do?

[Stephen Farrell]

Hiya,

On 24/01/18 13:32, Michael Richardson wrote:
> 
> Stephen Farrell <stephen.farr...@cs.tcd.ie> wrote:
> > On 24/01/18 02:48, Michael Richardson wrote:
>     >>
> >> Stephen Farrell <stephen.farr...@cs.tcd.ie> wrote: > - Does this sound
> >> roughly right or off the wall?
> >>
> >> It sounds right.  I think that bootstrap of security should become an
> >> recharter item in the future.  Some kind of BCP on interactions with
> >> MUD, SUIT, etc. IN THE FUTURE. NOT NOW.
> 
> > Can you say more? Eg. what would be needed before you think it'd be
> > sensible for homenet to start work in this space?
> 
> a) finish (really finish) Babel work, that might mean interacting with BABEL
>WG
> 
> b) DNS naming and delegation in Last Call.
> 
> c) ANIMA and related groups publish *managed* enrollment,
>so that HOMENET can consider how *unmanaged* enrollment might work.

Reasonable points. Do others (dis)agree?

Without a chair hat on, I'm not sure that some of those
other bits of work need to be fully finished - if we know
what kind of keying that'll be used in the final results,
we could make some progress, but I do agree we'd need to
know e.g. whether Babel implementations would plan to
support what flavours of DTLS (e.g. pre-shared keys vs.
bare public keys vs. certs if they do plan to use DTLS),
and other similar things, so I tend to agree those bits
of work would need to be at least nearly-done.

> 
> >> > 2. We have this milestone in our charter:
> >>
> >> > "Nov 2018 - Submission of the perimeter security draft > to the IESG
> >> as Informational RFC"
> >>
> >> Yes.  Are the authors still engaged?
> 
> > I'm not aware that we have authors;-( I guess someone could have
> > volunteered in the past before I was helping out as chair (if so,
> > please do let us know).
> 
> Ah, so it was Erik and some other people.  I see that the draft has even
> expired.  I'm thinking about: 
> https://datatracker.ietf.org/doc/draft-kline-homenet-default-perimeter/
> Maybe you are thinking about something else?

Nope, I'd not seen that draft before.

Do others still consider we should work on this topic?
(based on that draft or not) and we'd still like to know
who's willing to do stuff, if so.

Cheers,
S.

> 
> --
> ]   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
> [
> 
> 
> --
> Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works
>  -= IPv6 IoT consulting =-
> 
> 
> 

-- 
PGP key change time for me.
New-ID 7B172BEA; old-ID 805F8DA2 expires Jan 24 2018.
NewWithOld sigs in keyservers.
Sorry if that mucks something up;-)


0x7B172BEA.asc
Description: application/pgp-keys


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

Re: [homenet] security work items - what do we want to do?

[Stephen Farrell]

Hiya,

On 24/01/18 02:48, Michael Richardson wrote:
> 
> Stephen Farrell <stephen.farr...@cs.tcd.ie> wrote:
> > - Does this sound roughly right or off the wall?
> 
> It sounds right.
> I think that bootstrap of security should become an recharter item in the
> future.  Some kind of BCP on interactions with MUD, SUIT, etc. IN THE
> FUTURE. NOT NOW.

Can you say more? Eg. what would be needed before you think
it'd be sensible for homenet to start work in this space?

> 
> > 2. We have this milestone in our charter:
> 
> > "Nov 2018 - Submission of the perimeter security draft
> > to the IESG as Informational RFC"
> 
> Yes.  Are the authors still engaged?

I'm not aware that we have authors;-( I guess someone could have
volunteered in the past before I was helping out as chair (if so,
please do let us know).

Cheers,
S.

> I think I've missed the last three homenet WG sessions due to conflicts.
> I find that the ML is too frequently ratholed when it isn't silent.
> 
> > - Does the homenet wg need to profile use of those
> > security mechanisms, for example to document a way to
> > establish initial keying material that we'd like to see
> > implemented when those protocols are used in home networks?
> 
> > - If so, (and without yet getting into discussions about ToFU
> > etc) do we have people who are interested in working on
> > that?
> 
> Yes, but not yet.
> 
> --
> Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works
>  -= IPv6 IoT consulting =-
> 
> 
> 

-- 
PGP key change time for me.
New-ID 7B172BEA; old-ID 805F8DA2 expires Jan 24 2018.
NewWithOld sigs in keyservers.
Sorry if that mucks something up;-)


0x7B172BEA.asc
Description: application/pgp-keys


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

[homenet] security work items - what do we want to do?

[Stephen Farrell]

Hi homenet folks,

Barbara and I were chatting about the security work that
may need to be done in the homenet wg in the coming months
and here are our thoughts on that. We'd like to get folks'
reactions to those:

- Does this sound roughly right or off the wall?
- If the former, do we think it's doable?
- If so, who'd like to help do the work etc.

It seems there are three possible work items for us
to consider:

1. Documenting the security considerations and any
security mechanisms needed for draft-ietf-homenet-simple-naming.
We assume that that work will be done as a normal part
of developing that draft, so is, or will be, in-hand.

2. We have this milestone in our charter:

"Nov 2018 - Submission of the perimeter security draft
 to the IESG as Informational RFC"

- Do we still agree that this is a good milestone?
- If not, why not?
- If so, do we have people who are willing to work on
  this?

3. HNCP and Babel define some security mechanisms that can
be used to secure those protocols, and more work is being
done at the moment in the babel WG on uses of HMAC and DTLS
with Babel.

- Does the homenet wg need to profile use of those
  security mechanisms, for example to document a way to
  establish initial keying material that we'd like to see
  implemented when those protocols are used in home networks?
- If so, (and without yet getting into discussions about ToFU
  etc) do we have people who are interested in working on
  that?

If possible, it'd be great to get a sense of the WG's
ideas on the above before we construct an agenda for
our meeting in London in March (which is not that far
away now).

Thanks,
Barbara & Stephen



-- 
PGP key change time for me.
New-ID 7B172BEA; old-ID 805F8DA2 expires Jan 24 2018.
NewWithOld sigs in keyservers.
Sorry if that mucks something up;-)


0x7B172BEA.asc
Description: application/pgp-keys


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

Re: [homenet] comments on babel-profile-03

[Stephen Farrell]

Hiya,

On 19/11/17 16:05, Juliusz Chroboczek wrote:
>> I re-read babel-profile-03 and have a few comments (below) offered
>> as a WG participant (i.e. chair hat off) as part of WGLC.
> 
> Thanks, this is appreciated.
> 
>> - Req5: Is "MUST be... of a similar magnitude..." clear enough?
> 
> Yes.  Minor tweaks to metrics don't cause suboptimal routing -- if
> one router vendor chooses 64 as the cose of a wired link, and another
> uses 96, then one hop is still preferred to two hops, which is what
> matters at the end.
> 
> On the other hand, if one router vendor picks a cost of 1 and another
> one chooses 256, then bad routing will occur.  Here, the costs are
> not of similar magnitude.
> 
> The reason we don't want to be too precise here is that we want to 
> encourage vendors to experiment with smarter out-of-the-box metrics.
> For example, a vendor that cares about powerline ethernet should be
> allowed to do something smart to prefer Ethernet to powerline.

I've no problem with some vagueness in this case, but combining that
with a MUST may cause various folks to argue that a MUST needs to be
clear enough that one can determine if some code complies or not and
that the current text doesn't do that. Others may argue that this is
a bogus use of 2119's MUST as it doesn't affect interop. Regardless
of the above, my own approach would be to avoid the argument by not
using a MUST if it's not really needed for interop or security.

> 
>> - 2.2: I'm not sure this entire section is useful. If there is 
>> something specific we'd like to avoid (at a MUST NOT or NOT 
>> RECOMMENDED level), it'd be better to say exactly what.
> 
> "Non-recommendations" are just MAYs.  Perhaps the term is badly
> chosen, if you have a better suggestion, I'm listening.

I'd suggest just dropping the 2.x and 3.x headings. (And maybe
change NR1 to OPTION1 or something.) While the meaning of 2.1
and 3.1 is clear, 2.2 and 3.2 are, I think, confusing. But if
nobody else finds that confusing, then better to ignore me.

> 
> What this section says is basically "if you want to be smart, that's
> cool, but if you're in a rush, don't bother, it's not expected to be 
> particularly useful in a home network".  Let me know if you have 
> suggestions to make it clearer.
> 
>> - NR2: I don't see the point of that. If
> 
> See above.  The point here is the rationale -- we're explaining why
> the smarter metric computation algorithms are not going to matter in
> a home network.
> 
>> - section 3: "...using the existing redistribution mechanisms" 
>> could maybe do with a reference for seme well known OS.
> 
> I think redistribution is a standard term -- it's used by Quagga and
> by Cisco, at least.

Sorry, I didn't mean a reference defining the term but rather a
reference to a non-HNCP way in which routes get installed in some
relevant OS.

That'd also help a bit with the security stuff below I think,
(but we might not agree about that), as it means that the set of
risks related to routes to be considered here is not limited to
those risks that can be realised via HNCP, but needs to ack the
other ways in which routes can be installed into an OS.

> 
>> - NR3: I don't see what is not required here, that seems like a 
>> straightforward 2119 MAY statement
> 
> Yes.  See above.
> 
>> - section 4: "only susceptible" seems like overstatment.  If babel
>> picks up routes from the OS and then annouces those,
> 
> [...]
> 
>> - section 4: "secured at a lower layer" includes links with no 
>> security (in reality), is that right?
> 
> [...]
> 
>> - section 4: "trusted X" is not a good term unless you say who/what
>> is trusting whom/what for what. So, s/trusted links/links/ would be
>> better.
> 
> [...]
> 
>> - section 4: The security properties here seem to be directly and
>> wholly dependent on nodes being able to safely identify interfaces
>> into the categories in 5.1 of 7788. I need to do some more reading
>> to convince myself that that's a good thing to assume.
> 
> [...]
> 
>> If there are weaknesses in that assumption, then it'd be better to
>> call those out here,
> 
> [...]
> 
>> - section 4: I dislike the plan of assuming lower layer security
> 
> [...]
> 
> You're right on all counts, as usual.  However, this document is
> called "Homenet Babel Profile", it's not called "Security
> Considerations for the Homenet Protocol Suite".

Nonetheless there are security considerations arising and IETF
processes (whatever one thinks of them), do call for those to be
documented.

> 
> I think the right thing to do would be to replace all of Section 4
> with a single sentence that says

I don't agree. (I bet you guessed:-)

While I am not arguing that this document needs to document a way
of running babel in a homenet in some more highly secure manner,
you do need to call out the risks I think, and I don't think that
that's currently been done quite right yet.

In this case I think the current text is nearly ok. I'd say there
are a few wording things as 

[homenet] breakfast meeting tomorrow (wed) on security

[Stephen Farrell]

Hiya,

We mentioned this in the session yesterday and someone suggested
it'd be good to send to the list so...

A bunch of folks who're at the IETF meeting and interested in
doing work on homenet security plan to meet for breakfast at
8am at the IETF registration desk. If you'd like to help then
please come along (bring your own breakfast). We'll meet there
and then go find a room somewhere to chat.

Cheers,
S.



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

[homenet] comments on babel-profile-03

[Stephen Farrell]

Hiya,

I re-read babel-profile-03 and have a few comments (below)
offered as a WG participant (i.e. chair hat off) as part of
WGLC.

If any of these were discussed already, then just pointing
me at the archive is a fine answer. (And apologies for not
having been active in the WG earlier if there are such cases.)

- Req5: Is "MUST be... of a similar magnitude..." clear enough?

- 2.2: I'm not sure this entire section is useful. If there is
something specific we'd like to avoid (at a MUST NOT or NOT
RECOMMENDED level), it'd be better to say exactly what.

- NR2: I don't see the point of that. If

- section 3: "...using the existing redistribution mechanisms"
could maybe do with a reference for seme well known OS.

- NR3: I don't see what is not required here, that seems like a
straightforward 2119 MAY statement

- section 4: "only susceptible" seems like overstatment.  If
babel picks up routes from the OS and then annouces those,
then it seems the statement is not true, as any way of getting a
route into the OS will cause babel to propogate that, or am I
wrong? If not, then the babel profile seems to be susceptible to
any problems that cause a dodgy route to be installed in the OS
kernel.

- section 4: "secured at a lower layer" includes links with no
security (in reality), is that right?

- section 4: "trusted X" is not a good term unless you say
who/what is trusting whom/what for what. So, s/trusted
links/links/ would be better.

- section 4: The security properties here seem to be directly
and wholly dependent on nodes being able to safely identify
interfaces into the categories in 5.1 of 7788. I need to do
some more reading to convince myself that that's a good thing
to assume. If there are weaknesses in that assumption, then
it'd be better to call those out here, as that'd help folks
who're implementing and might also help in the later process
for this draft. (IOW, I won't be the only one to ask, so we
might as well be up-front if there are weak points in that
argument;-)

- section 4: I dislike the plan of assuming lower layer security
but if that's the WG consensus, then that's what it is. Is
there a link to the discussion that concluded that in the WG
archive? I suspect we'll be asked by directorate reviewers/IESG
so good to have that now. If there's no such link, then we
probably should start a specific thread that ends with that
conclusion (or changes the draft.)

Cheers,
S.



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

[homenet] Agenda & Slides for tomorrow please...

[Stephen Farrell]

Hiya,

We're meeting tomorrow @ 1550 local, 0750 UTC.

Agenda is at [1], chair slides at [2]. Any comments
(agenda-bash, stuff I forgot) welcome, just reply to
this on or off list as appropriate.

If you have a presentation slot (Jordi, Ted, cc'd) then
please send any slides you want to use to the chairs
before local lunchtime tomorrow.

If you're willing to take notes or be a jabber scribe,
great, thanks and please just send the chairs a note
so we can thank you f2f at the meeting. (If nobody
does that, we'll be prowling the room to find victims,
so you may as well volunteer now:-)

Thanks,
S.

[1] https://datatracker.ietf.org/meeting/100/materials/agenda-100-homenet/
[2]
https://datatracker.ietf.org/meeting/100/materials/slides-100-homenet-chair-slides/



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

[homenet] charter item on perimeter security

[Stephen Farrell]

Hiya,

Our charter has the following milestone:

  Nov 2017 - First WG draft on perimeter security

Is anyone here working on or interested in that
topic?

If so, please ping me/chairs offlist. If people
are interested in doing that work, I'd like to
try setup a chat about that next week. If people
are not interested in doing that work, (or if it
might not happen until the heat-death of the
universe:-) then we should probably chat about
that @ IETF100 I guess.

Two people (Ted Lemon/Chris Wood) have told me
offlist that they're at least interested in a
chat about the topic.

I'll come back to the list with whatever happens.
(And just in case someone's worried about process,
this is just a chat to see if there's the beginnings
of a plan, with folks interested in doing work, or
not - nothing at all would be decided.)

Cheers,
S.

[1] https://tools.ietf.org/wg/homenet/charters



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

[homenet] Fwd: IETF 100 Preliminary Agenda

[Stephen Farrell]

FYI, homenet is currently scheduled to meet Monday
afternoon. That can still change of course.

S


 Forwarded Message 
Subject: IETF 100 Preliminary Agenda
Date: Fri, 13 Oct 2017 15:00:55 -0700
From: IETF Agenda 
Reply-To: IETF Agenda 
To: Working Group Chairs 

The IETF 100 preliminary agenda has been posted. The final agenda will
be published on Friday, October 20, 2017.
If you would like to request a change to the preliminary agenda, please
send a message to age...@ietf.org and copy all relevant Area Directors.

https://datatracker.ietf.org/meeting/100/agenda.html
https://datatracker.ietf.org/meeting/100/agenda.txt

Thank you!

IETF Secretariat





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

[homenet] early reminder...

[Stephen Farrell]

Hiya,

Just an early heads-up about the draft
submission cutoff for IETF-100 - that's
not for a month yet [1] but hey - time
flies if you let it:-)

Also, if folks know already that you'd
like some agenda time for a topic that's
not already a WG item, now would be a
fine time to start a thread on the mailing
list.

Cheers,
S.

[1] https://ietf.org/meeting/important-dates.html#ietf100



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

Re: [homenet] Incoming chairs for HOMENET

[Stephen Farrell]

Hi all,

On 23/07/17 07:42, Terry Manderson wrote:
> Dear WG,
> 
> I am pleased to announce that the new chairs for HOMENET will be
> Barbara Stark and Stephen Farrell.
> 
> Ray has graciously offered to assist in a smooth chair transition by
> staying on until IETF100 (thanks Ray!) so this means for a few month
> HOMENET will have a 3-chair team.
> 
> When will the new chairs take their seats? This coming week I will
> make the changes to the chair roster so that Barbara and Ray will be
> the chairs. In early August Stephen will be added, and then in
> Singapore Ray can finally rest.

Just to note that Terry's now added me as a co-chair, so Ray's
rest is getting closer:-)

I look forward to working with Barbara, Ray and you all to help
the WG complete it's work so feel free to ping me if there's
stuff where I can help,

Cheers,
S.


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



signature.asc
Description: OpenPGP digital 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] Please review security considerations of draft-homenet-babel-profile

[Stephen Farrell]

Hiya,

I suggest asking the chairs to hit the "request directorate" review
(iirc only they can see that button?) for an early secdir review.

For myself, I've not read the draft yet (I will over the next few
weeks) but have two questions while I'm here:

1) The first sentence seems to not say what to do if a packet comes
from a 1918 IPv4 address. Even if that's not supposed to happen, it
could be attempted. What's an implementation supposed to do then?

2) Again I need to read the rest of the draft, but does this mean
that anyone on that link of the homenet can inject these messages
without any authentication, and if so why is that ok? (I'm not
asking for now why doing better is too hard, just why it's ok for
any node on link to be able to play here.)

Cheers,
S.

On 25/07/17 21:27, Juliusz Chroboczek wrote:
> Dear all,
> 
> All security wizards are kindly requested to carefully read and if
> necessary criticise the following section:
> 
>   https://tools.ietf.org/html/draft-ietf-homenet-babel-profile-02#section-4
> 
> Nasty comments on list, please, compliments by private mail ;-)
> 
> Thanks,
> 
> -- Juliusz
> 
> ___
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet
> 



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

Re: [homenet] write up of time without clocks

[Stephen Farrell]

On 31/10/16 13:36, Michael Richardson wrote:
> 
> Hi, I know that we talked a lot (especially Dave Taht) about how CPE devices
> without RTCs could verify certificates and DNSSEC when they don't know the
> time, and they won't know the time until they securely find an NTP server.
> 
> But, we talked about how this wasn't a totally catch-22, that we could
> know how it was "at least" some time based upon file timestamp, or
> self-certificate not-before dates, or do DNSSEC without time validation
> first.
> 
> My question is: did this get captured into document somewhere?

This [1] seems relevant. I've not looked into it in
detail, but I'm guessing it has to be similar to the
above ideas.

S.

[1] https://roughtime.googlesource.com/roughtime

> 
> 
> --
> Michael Richardson , Sandelman Software Works
>  -= IPv6 IoT consulting =-
> 
> 
> 
> 
> 
> ___
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet
> 



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

Re: [homenet] Stephen Farrell's No Objection on draft-ietf-homenet-hncp-10: (with COMMENT)

[Stephen Farrell]

I had a peek at the diff and it's all good from my POV.

Isn't it amazing how you can look at a document for ages
and ages and not just see stuff like the hkdf thing? I do
it all the time;-(

S.


On 04/12/15 21:53, Markus Stenberg wrote:
>> On 4.12.2015, at 18.51, Stephen Farrell <stephen.farr...@cs.tcd.ie> wrote:
>> Thanks for addressing my discuss about the options for 
>> using DTLS. Sorry for being slow with this ballot update.
>>
>> The comments below are old, I didn't check if you've
>> made related changes. Happy to chat about that if you
>> want, (or not if you prefer not:-)
>>
>> - I agree with Kathleen's discuss that the implementation
>> requirements for DTLS need to be clarified, hopefully (from my
>> POV) to make that MTI but I'll leave that discussion to the
>> other thread.
> 
> We did some text clarification on this I believe in -10.
> 
>> -Section 9: You should refer to HKDF and not HMAC-SHA256 though
>> the reference to RFC 6234 is still right. HMAC-SHA256 itself
>> is not a key derivation function, which is what you want here.
> 
> Fixed in -10 (really sad failure on my part :-p)
> 
>> - Please take a look at the secdir review [1] and respond to
>> that as it raises one issue not (I think) otherwise mentioned.
>> What is the effect (on a home) of one compromised hncp router?
>> Perhaps you'll say that's obvious, or perhaps not, but I'm 
>> interested in what you do say, in case it's not obvious:-)
> 
> There's text about that in the security considerations, I believe. (Pointer 
> in the -09 DISCUSS thread IIRC).
> 
> Cheers,
> 
> -Markus
> ___
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet
> 

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

Re: [homenet] Stephen Farrell's Discuss on draft-ietf-homenet-hncp-09: (with DISCUSS and COMMENT)

[Stephen Farrell]

On 26/11/15 16:49, Juliusz Chroboczek wrote:
>> Hmm. I've also setup many small PKIs and don't agree. I do think someone
>> could easily make all that quite usable within the home.
> 
> Have you ever walked a non-specialist through the process?

I have not. But as others said, the key idea would be to make
it as invisible as possible, which is quite doable. And the
tools are there these days (much moreso than even 5-6 years
ago) in pretty much all platforms/languages.

S.

> 
> -- Juliusz
> 

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

Re: [homenet] Stephen Farrell's Discuss on draft-ietf-homenet-hncp-09: (with DISCUSS and COMMENT)

[Stephen Farrell]

On 20/11/15 15:35, Markus Stenberg wrote:
> 
> [1] 
> https://github.com/fingon/ietf-drafts/commit/f8275e165802a9c310f0bbde98e42087ecc891b1

Great, that's fine to sort my discuss point. I'll clear whenever
that's posted

Thanks,
S.

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

[homenet] Stephen Farrell's Discuss on draft-ietf-homenet-hncp-09: (with DISCUSS and COMMENT)

[Stephen Farrell]

Stephen Farrell has entered the following ballot position for
draft-ietf-homenet-hncp-09: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-homenet-hncp/



--
DISCUSS:
--


(Sorry for the N-th discuss, I quite like this protocol and
I'm sure we'll get 'em all cleared soon, but... ;-)
 
I'd like to chat about whether or not the DTLS recommendations
are correct here. To me, the consensus stuff (from section 8.3
of dncp) is not clearly baked (as I noted in iesg review of
dncp). The PKI stuff is well known, even if it it is a PITA from
many points of view. I don't think a SHOULD for the former and
a MAY for the latter is appropriate now. If the consensus based
stuff gets deployed and works, then it might be time to say
what you're now saying, but I don't think we're there yet. (I'd
be happy to look @ evidence that we are, and to change my
opinion accordingly.)

Please note that I think I like the consensus based scheme, I'm
just concerned it may not be ready for prime time. I'm also not
really convinced that all you need to do to get interop for
that is mention it and refer to dncp. But again, I could be
wrong and would appreciate being corrected if so.

In summary, I think you should say "when using DTLS with
asymmetric keying, then you SHOULD support the PKI-based method
and MAY support the consensus based method, which is still
somewhat experimental."


--
COMMENT:
--

- I agree with Kathleen's discuss that the implementation
requirements for DTLS need to be clarified, hopefully (from my
POV) to make that MTI but I'll leave that discussion to the
other thread.

-Section 9: You should refer to HKDF and not HMAC-SHA256 though
the reference to RFC 6234 is still right. HMAC-SHA256 itself
is not a key derivation function, which is what you want here.

- Please take a look at the secdir review [1] and respond to
that as it raises one issue not (I think) otherwise mentioned.
What is the effect (on a home) of one compromised hncp router?
Perhaps you'll say that's obvious, or perhaps not, but I'm 
interested in what you do say, in case it's not obvious:-)

   [1] https://www.ietf.org/mail-archive/web/secdir/current/msg06098.html


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

[homenet] Stephen Farrell's No Objection on draft-ietf-homenet-dncp-09: (with COMMENT)

[Stephen Farrell]

Stephen Farrell has entered the following ballot position for
draft-ietf-homenet-dncp-09: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-homenet-dncp/



--
COMMENT:
--


- 8.3 generally: I think this could be the basis for something
quite good but that'll only become clear really (to me) when I
go over it in a real protocol and not in the abstract. I'd
also speculate that you might end up changing this if it gets
more security review, but again that's hard to get in the
abstract.  Basically: be prepared for changes as this is made
concrete and if that would be a problem please yell now.  If
you do yell, I'm fine with making this a DISCUSS so we're sure
to resolve it. (I nearly did make this a DISCUSS, as I'm not
sure this is all fully worked out, but I'm ok that we can fix
that later. And you have enough DISCUSS ballots;-)

- The write up notes various drafts were input to what became
this one. I assume that none of those had associated IPR that
hasn't trickled through to being noted as applying to this
one? If not, as I expect, that's fine, no response is needed,
I'm just noting this since I didn't see any "replaced by"
entries in the history and it's those that cause IPR to be
transitively visible.

- section 2 - it's not clear to me why all node identifiers
need to be the same length - some protocols using DNCP could I
guess have variable length identifiers. IPv4 and IPv6 and
Ethernet for example all have different lengths.

- 4.2: seems to contradict itself. 1st para says that MC is
not used for anything sensitive, but 2nd-last para of section
says that network state TLVs can be sent "now and then."
(Reason to ask is that (D)TLS won't work if sensitive data is
sent via MC.)

- 4.4, 2nd para: what is a "valid" address? 

- 8.1: do you mean one PSK per network or per pair of nodes?
Better to say. I assume it's the former.

- 8.3: This is an example of (a fairly complex) use of
opportunistic security (RFC7435). Be good to note that.

- 8.3: Calling this "certificate based" is I think a misnomer.
I suspect all the same things could be done with raw public
keys (RFC 7250).

- 8.3: please do note that a concrete protocol might need
changes to this distributed algorithm and that this section is
guidance and not to be considered entirely fixed (when
coding).


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

Re: [homenet] Stephen Farrell's No Objection on draft-ietf-homenet-dncp-09: (with COMMENT)

[Stephen Farrell]

Hiya,

On 17/09/15 16:00, Steven Barth wrote:
> Hello Stephen,
> 
> thanks for your review.
> Please find some comments below.
> 
> 
> Cheers,
> 
> Steven
> 
> 
>> --
>> COMMENT:
>> --
>> - 8.3 generally: I think this could be the basis for something
>> quite good but that'll only become clear really (to me) when I
>> go over it in a real protocol and not in the abstract. I'd
>> also speculate that you might end up changing this if it gets
>> more security review, but again that's hard to get in the
>> abstract.  Basically: be prepared for changes as this is made
>> concrete
> 
> Understood, the intention is to potentially have something better
> suited than PSKs or PKIs for cases like bootstrapping a (mostly)
> unmanaged home network. We are aware that this is probably a
> first slab at such an approach and might benefit from a few more
> eyes and practical experience.
> 
> In any case, it is not substantial to the document and we would
> rather remove it if it would become a blocker.

As long as we're flexible with it, it's not a blocker. And
as I said I think it's good, but it may need tweaks as we
finish the concrete protocol that uses it.

All the rest below is fine but sorry I don't have a catchy
better name for 8.3 to hand. (And I don't care about the
name so much as e.g. considering RFC7250 which may fit
better here, as one wouldn't need a CA.)

S

> 
> 
>> - The write up notes various drafts were input to what became
>> this one. I assume that none of those had associated IPR that
>> hasn't trickled through to being noted as applying to this
>> one? If not, as I expect, that's fine, no response is needed,
>> I'm just noting this since I didn't see any "replaced by"
>> entries in the history and it's those that cause IPR to be
>> transitively visible.
> We are not aware of any IPR associated with those drafts, at
> least to my knowledge none was declared in the IETF IPR search.
> 
> 
>> - section 2 - it's not clear to me why all node identifiers
>> need to be the same length - some protocols using DNCP could I
>> guess have variable length identifiers. IPv4 and IPv6 and
>> Ethernet for example all have different lengths.
> Well, theoretically this is probably not a hard requirement,
> however the way we currently define our TLVs a variable length
> identifier here would require changing the TLVs to include a
> length field for it in some cases. I do not really see the big
> benefit of allowing this here so we will probably rather leave
> it as is.
> 
> 
>> - 4.2: seems to contradict itself. 1st para says that MC is
>> not used for anything sensitive, but 2nd-last para of section
>> says that network state TLVs can be sent "now and then."
>> (Reason to ask is that (D)TLS won't work if sensitive data is
>> sent via MC.)
> We do not consider the Network State TLV to be sensitive,
> since it is a merely a single hash-value over other hashes and
> a bit of metadata (see "Hash Tree"). The only reaction to the
> reception of a Network State TLV is triggering a unicast
> request to the originator (which whould then be authenticated
> and encrypted) using (D)TLS. We noted this in the Security
> Considerations already in the first paragraph and mandate
> rate-limitation of thereby triggered requests.
> 
> 
>> - 4.4, 2nd para: what is a "valid" address?
> A profile might e.g. restrict the transport to link-local scoped
> addresses or make other similar assumptions. I guess we will
> add a an example in -10.
> 
> 
>> - 8.1: do you mean one PSK per network or per pair of nodes?
>> Better to say. I assume it's the former.
> Well technically it could be either but in practice I'd think we'd
> assume it to be the former since latter is a bit impractical.
> 
> 
>> - 8.3: This is an example of (a fairly complex) use of
>> opportunistic security (RFC7435). Be good to note that.
> Staged for -10.
> 
>>
>> - 8.3: Calling this "certificate based" is I think a misnomer.
>> I suspect all the same things could be done with raw public
>> keys (RFC 7250).
> 
> Well most of it can, however there is one bit that somehow utilizes
> certificates:
> 
>A node MUST be
>trusted for participating in the DNCP network if and only if the
>current effective trust verdict for its own certificate or any one in
>its certificate hierarchy is (Cached or Configured) Trust and none of
>the certificates in its hierarchy have an effective trust verdict of
>(Cached or Configured) Distrust
> 
> In any case it could get a different name, do you have a fitting idea?
> 
> 
>> - 8.3: please do note that a concrete protocol might need
>> changes to this distributed algorithm and that this section is
>> guidance and not to be considered entirely fixed (when
>> coding).
> 
> Staged for -10.
> 

___
homenet mailing list
homenet@ietf.org

[homenet] Stephen Farrell's No Objection on draft-ietf-homenet-prefix-assignment-07: (with COMMENT)

[Stephen Farrell]

Stephen Farrell has entered the following ballot position for
draft-ietf-homenet-prefix-assignment-07: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-homenet-prefix-assignment/



--
COMMENT:
--


- section 3: I expected some security text here, not to say that
this all needs to be encrypted but rather to say that because
this is flooding, you can't really encrypt it and that hence
this scheme is only suited for smaller deployments and/or those
with lower layer security already in place. (And hence also
probably small.) 

- section 3: Similarly, you could also add some privacy text to
the effect that this scheme only applies where the privacy
characteristics of the various prefixes involved are all
roughtly similar, that is, where there's no real privacy
difference in which prefixes end up with which nodes. (Mind you,
I need to ponder that a bit myself to see if it's really the
case;-)

- sections 4  5: I found this impossible to understand in a
(quick) linear reading. I'd find actual code easier tbh. It's
interesting that Barry found this clear though (I did not,
clearly:-) so this isn't a discuss. But why didn't you first
provide an overview of the algorithm? 

- Where is the evidence that the algorithm converges? I'd have
thought there would be a reference to an academic publication
that also described the algorithm and a proof for convergence.


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

Re: [homenet] Security considerations for the Babel routing protocol

[Stephen Farrell]

On 08/04/15 02:56, Juliusz Chroboczek wrote:
 Dear Stephen,
 
 Following your request of 5 April 2015, 

Well, I didn't quite request exactly that, but fair play.
It's good to see the analysis begun, though I utterly
disagree with your main so-called conclusion.

I'll send a more detailed response off-list, as I don't
think it'd be right if the homenet list were dominated
by this (which could happen).

S.

 I have published the following
 Internet-Draft:
 
 Security considerations for the Babel routing protocol
   draft-chroboczek-babel-security-considerations-00
 
 I also attract your attention to the following RFC:
 
 RFC 7298: Babel Hashed Message Authentication Code (HMAC)
 Cryptographic Authentication
 
 I hope that these documents alleviate your concerns about the Babel
 community not thinking about security hard enough.  Should you have any
 further inquiries, please do not hesitate to contact me, and I'll do my
 best, time permitting, to update the security considerations document.
 
 With respectful regards,
 
 -- Juliusz Chroboczek
 
 

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

Re: [homenet] Selecting a routing protocol for HOMENET

[Stephen Farrell]

On 05/04/15 15:37, Juliusz Chroboczek wrote:
 a plan of the form produce base spec RCC and only then start to think
 about security will get pushback from me.
 
 Why?
 
 (If the answer is read BCP 61, I'll do that, but not right now.)

Partly that and partly the horrible experience with years of delay
with RPL. I inherited a DISCUSS on the base RPL spec in March 2011
from the previous security AD. I can't remember how much that delayed
the base RPL spec, maybe a year or so until we worked out a plan that
was going to not result in security being ignored. And their security
analysis RFC (7416) was only published in Jan 2015. And there was
loads and loads of gnashing of teeth in between for everyone involved.
And I also think the final result would have been better had the
security work been done up front whilst they had more energy and
motivation.

S.

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

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

Re: [homenet] Selecting a routing protocol for HOMENET

[Stephen Farrell]

Hiya,

Just on one topic...

On 05/04/15 14:56, Juliusz Chroboczek wrote:
 I'd like the charter to clearly state that security considerations are
 outside the scope of the base spec. 

FWIW, and wearing my security AD hat, I can guarantee that would
generate pushback.

We have BCPs that say we don't do that, e.g. BCP61 and others. And
the effort to get RPL to consider this properly added quite a bit
of delay for that WG partly because they wanted to take the
approach of doing security later which isn't really a good plan
IMO. And of course results tend to be mediocre as well when
folks take the graft on security later approach. You may
have an argument that that approach has already been taken,
but how we handle that is IMO one of the differences between
the ISE stream and IETF stream, esp. standards track.

Security in environments like this is tricky though I agree,
esp when one considers the impacts of the various security
mechanisms at the various layers. But that just does not mean
that it's ok to ignore those issues.

S.

PS: The above does not mean that I think it's a problem if a
WG want to produce a base spec and some other RFC that has the
security analysis and defines useful security mechanisms. IMO
so long as those are done at the same time, and so long as the
security mechanisms have the the 2119 keywords associated that
are justified by the security analysis, then that's just fine.

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

Re: [homenet] Selecting a routing protocol for HOMENET

[Stephen Farrell]

On 05/04/15 15:24, Juliusz Chroboczek wrote:
 I'd like the charter to clearly state that security considerations are
 outside the scope of the base spec. 
 
 PS: The above does not mean that I think it's a problem if a
 WG want to produce a base spec and some other RFC that has the
 security analysis and defines useful security mechanisms.
 
 I don't think we're disagreeing.  I was careful to say outside the scope
 of the base spec, as opposed to the scope of the WG.

You were indeed. And I'm being careful to say that a plan of the
form produce base spec RCC and only then start to think about
security will get pushback from me.

And that said, I'm not entirely sure if we're agreeing or not,
but we'd know pretty soon if this gets going, so we're fine for now:-)

S.

 
 (The base spec is 45 pages long, and can be explained in less than one
 hour.  I will fight to keep it that way.)
 
 I'll have a look at the BCP you refer to.
 
 Thanks for your input,
 
 -- Juliusz
 
 ___
 homenet mailing list
 homenet@ietf.org
 https://www.ietf.org/mailman/listinfo/homenet
 
 

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

Re: [homenet] Queries on draft-ietf-homenet-hncp-02

[Stephen Farrell]

On 26/11/14 07:39, Markus Stenberg wrote:
 public-key TLV, but currently not really implemented anywhere and
 going to be phased out probably in favor of leaving the asymmetric
 crypto details out of the protocol itself

oooh - there's a way to get my attention:-) Is that saying that
HNCP used have some asymmetric crypto that wasn't implemented and
that's going to be cut from the spec?

If so, can you explain what/why? (To someone who's yet to read
the spec sorry, if your answer is go read the spec that's a
fine answer.)

Ta,
S.

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

Re: [homenet] [Anima] Ted Lemon's Block on charter-ietf-anima-00-09: (with BLOCK)

[Stephen Farrell]

Hiya,

On 05/10/14 22:55, Brian E Carpenter wrote:
 So, in my opinion, model #1 (a shared secret known to every device)
 is pretty weak. It might be acceptable for a small home network
 with a very careful human owner, but not beyond that limit. This is exactly
 the kind of shared secret that people will write down and lose along with
 their wallet, or simply throw out in their household garbage.
 IMHO, for a network of any size or complexity, we need model #2.

Its not a question that needs to be answered now, but I don't see
how model #2 is consistent with the open-source model of doing
stuff. (I'm being intentionally vague there as many devices are
sort-of developed in an open-source manner.)

If there were a way to base things on a PKI for manufacturers that
worked for open-source communities that'd be really good, but I
don't think I've seen such a thing proposed so far.

I'm also very very unsure how model#2 might work in the face of
equipment being end-of-lifed by very small companies or what
happens after a teeny-tiny manufacturer goes bust.

Were the anima (or homenet) WG to try address those questions,
I think that'd be great. (And to repeat, I'm not looking for answers
right now, but just to see that a WG will commit to tackle this.)

S.

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

Re: [homenet] [Anima] Ted Lemon's Block on charter-ietf-anima-00-09: (with BLOCK)

[Stephen Farrell]

On 02/10/14 13:49, Michael Behringer (mbehring) wrote:
 My personal goal is that what we do in ANIMA is fully compatible with
 and ideally used in homenet. It would feel wrong to me to have an
 infrastructure that doesn't work in a homenet.
 
 The security bootstrap is a good example of what we can achieve, with
 reasonable effort.

FWIW, it is not clear to me that the reasonable requirements
for provisioning device security information (or bootstrapping
if we wanted to call it that) are the same.

In enterprise environments we see fewer larger vendors of devices.
In the home where we additionally have a large range of vendors
many of whom are tiny and leverage a lot of OSS and who could
perhaps not take part in the kind of provisioning infrastructure
that is quite reasonable for enterprises and their vendors.

I do think both want to end up in the same state, where devices
are authorised for connection to the network and where there is
some keying material usable for security, but I'd be surprised
if one approach to getting there worked the same way for both
homes and enterprises.

S.

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

Re: [homenet] HNCP security?

[Stephen Farrell]

Hiya,

I've not really been following this discussion sufficient
to comment in general, but just on this part...

On 29/09/14 08:39, Markus Stenberg wrote:
 DTLS has rather sad multicast story too 

The DICE WG [1] have also been discussing potential issues
with DTLS and multicast. That discussion has turned out
harder than envisaged in that the WG originally figured
a simple extension to the DTLS reccord layer might suffice
to get useful security when DTLS packets are sent via IP
multicast. Turns out to be less easy than that.

Anyway, if this WG do end up needing some multicast security
and are looking at DTLS it would be very good to co-ordinate
with the DICE WG.

Sooner would be much better than later for that as the DICE
WG are right now in the process of (re-)considering whether
they can in fact meet their chartered goals on this topic.

Thanks,
S.

[1] https://tools.ietf.org/wg/dice/

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

Re: [homenet] HNCP security?

[Stephen Farrell]

On 29/09/14 13:58, Ted Lemon wrote:
 On Sep 29, 2014, at 3:50 AM, Stephen Farrell
 stephen.farr...@cs.tcd.ie wrote:
 Sooner would be much better than later for that as the DICE WG are
 right now in the process of (re-)considering whether they can in
 fact meet their chartered goals on this topic.
 
 Unfortunately I think at this point we are distracted by a discussion
 about whether to use nails or screws when we haven't settled on what
 kind of house we're building.

Understood. And I don't want to side-track you here.

However, if your house is such that it only requires
confidentiality and data integrity of messages between
group members, but does not require origin authentication
that that'd be useful to know. What I mean by origin
authentication here is the ability for the receiver of a
multicast message to cryptographically verify exactly which
member of the group has sent a message.

If, OTOH, you can say that you would in fact also require
origin authentication, then that is also of interest. (It'd
mean that your use case could not be met by the initially
chartered work for DICE, and that factoid could be helpful
in figuring out how to handle the DICE work.)

Cheers,
S.

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

Re: [homenet] Mixing DNS in with routing information

[Stephen Farrell]

Not trying to get into the argument here, but just one
point:

On 10/26/2012 04:59 PM, RJ Atkinson wrote:
 This is not true if DHCP Authentication has been deployed.

My understanding is that 3118 is fictional, i.e. is never
deployed, ever. As an AD, I generally push back on any
draft where the security considerations say use 3118
and you'll be fine.

If I'm wrong, I'd be interested in knowing that and
about when/where 3118 is being used.

Ta,
S.

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

[homenet] security question for zeroconf stuff inside the homenet...

[Stephen Farrell]

Hi,

I've been reading the list with interest and have a question.

When various devices in the home figure out which does what,
and do that periodically to handle changes, there's clearly
the potential that a zombied host tries to try take over
stuff with undesirable consequences.

My question is whether this group are planning to think
about that now, or later, or never? (Or don't even think
there's a problem worth attempting to address.)

Note - I'm not trying to argue for any particular level of
security and certainly not for some unachievable fort knox
everywhere, I'm just asking what's the plan?

S.

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