Subject: [homenet] Kathleen Moriarty's Discuss on draft-ietf-homenet-hncp-09: (with DISCUSS)

From: "Kathleen Moriarty" <[email-masked]>
Date: Tue, 17 Nov 2015 15:50:34 -0800

Kathleen Moriarty 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:
----------------------------------------------------------------------

I have a couple of pints to discuss that should be pretty easy to resolve
as I wasn't clear on the first because of wording (should be very simple)
and would like to chat about the second.  Thanks.

1. I'm not clear on one of the bullets in section 3, 
  o  HNCP nodes MUST use the leading 64 bits of MD5 [RFC1321] as DNCP
      non-cryptographic hash function H(x).

Is this meant to use a message digest (RFC1321) or a cryptographic hash
for authentication (RFC2104)?  If it's the former, can you make this more
clear in the bullet?  If it's the latter, can you update the reference
and the number of bits to use for truncation is 80 for the minimum.  You
do explicitly mention HMACs later on for PSKs using SHA256, so maybe the
reference is correct and the wording should just be a bit more clear?

2. Can you explain why DTLS is a SHOULD and not a MUST?  The bullet in
section 3 reads as if this is for use, not implementation.  Is there a
MUST for implementation (I didn't see one, but maybe I missed that)? 

Could you add a reference to RFC7525 to help with configuration and
cipher suite recommendations?  This could be in section 12, security
considerations.

---

From: Juliusz Chroboczek <[email-masked]>
Date: Wed, 18 Nov 2015 14:24:51 +0100

Dear Kathleen,

> MUST for implementation (I didn't see one, but maybe I missed that)? 

I am not one of the authors of the draft, but I'm the author of the
independent reimplementation of HNCP (shncpd), so I have a fair
understanding of what the protocol does.

HNCP is an amazingly flexible protocol, and one that will hopefully be
used well beyond it's original area of application.  Many of the possible
applications of HNCP don't require DTLS, either because the network is
secured at a lower layer, or because they use a different application
layer mechanism.

To many people, a "Should Deploy, Must Implement" requirement in HNCP will
just seem like an arbitrary and useless hoop, and will needlessly reduce
the prestige and authority of the IETF.  If a MUST related to DTLS in
Homenet is required (and this is open to discussion), it belongs in
a different document, not in the HNCP protocol specification.

Regards,

-- Juliusz

---

From: Steven Barth <[email-masked]>
Date: Wed, 18 Nov 2015 15:20:19 +0100

Hello Kathleen,

thanks for the review.

> reference is correct and the wording should just be a bit more clear?

I have staged this text now:

  HNCP nodes MUST use the leading 64 bits of the <xref
  target="RFC1321">MD5 message digest</xref> as the DNCP hash function
  H(x) used in building the DNCP hash tree.

I hope that makes it more clear, that the hash is only used for
comparison and to detect changes, not as a form of signature or
authentication.

> MUST for implementation (I didn't see one, but maybe I missed that)? 

The basic idea behind the SHOULD is that there may be cases where either
physical security of links (e.g. cables) can be ensured or link-layer
security such as WPA for WiFi is present. In these cases (e.g. some sort
homenet wifi repeater) the DTLS would be redundant.

In the Security Considerations sections we currently have a requirement:

  On links where this is not practical and lower layers do not provide
  adequate protection from attackers, DNCP secure mode MUST be used to
  secure traffic.

which should ensure that devices MUST use HNCP security over both
physically and link-layer-wise unsecured links. I guess this could be
reflected in the DNCP profile section as well if that makes it more clear.

Would that work better or do you have something different in mind?

> cipher suite recommendations?  This could be in section 12, security

Staged for next revision.

Cheers,

Steven

---

From: Ted Lemon <[email-masked]>
Date: Wed, 18 Nov 2015 14:56:15 +0000

> secured at a lower layer, or because they use a different application

Which possible applications of HNCP don't require security?   The problem we have with HNCP is that we have no basis for establishing trust, not that we don't need security.

The argument against DTLS that I think makes some sense is "we don't know how to key it, and therefore don't know if it will work if/when we figure out security," not "we don't need it."   I actually have a great deal of sympathy for Kathleen's view here; if we make DTLS MTI, then at least we'll have an encryption/authentication mechanism when we figure out how we want to do that.

I think there's a pretty strong case to be made that the security mechanism will require public key cryptography.   If that's the case, then DTLS will work as an encryption/authentication layer.   The fact that the current draft refers to DTLS and makes it mandatory to use when transmitting pre-shared keys means that we've already got consensus that DTLS is a necessary option for encryption/authentication.

That being the case, I actually don't see any argument against making DTLS mandatory to implement.   You didn't give a reason for your opinion that we should not.   If you do have a reason for thinking that DTLS shouldn't be MTI, please state it plainly--your opinion may well be correct, but if we don't know why you have that opinion, we have no way to evaluate it other than to trust you or not, and that's not a good way to do standards work.   If the concern is whether there's a good DTLS implementation that can be used, I don't know how good it is but tinydtls looks like it might work.   It uses a license that is GPL-compatible.

--
Sent from Whiteout Mail - https://whiteout.io

My PGP key: https://keys.whiteout.io/[email-masked]

---

From: Ted Lemon <[email-masked]>
Date: Wed, 18 Nov 2015 15:46:28 +0000

> homenet wifi repeater) the DTLS would be redundant.

WPA2, at least in PSK mode, does not provide confidentiality from attackers who have the PSK.   WPA isn't even as good as WPA2.   I think relying on this level of security makes sense if we have no alternative, but in no other case.

> reflected in the DNCP profile section as well if that makes it more clear.

So doesn't that make DTLS MTI already?   If so, maybe we should just say so explicitly.

---

From: Juliusz Chroboczek <[email-masked]>
Date: Wed, 18 Nov 2015 16:57:43 +0100

> Which possible applications of HNCP don't require security?

It's not about not requiring security -- it's about mandating this
particular security mechanism.

> If you do have a reason for thinking that DTLS shouldn't be MTI, please
> state it plainly

The mesh community has been using a wide range of techniques for
configuring routers, static configuration, configuration protocols built
into routing protocols, AHCP, etc.  I am currently working on promoting
the use of a subset of HNCP instead.

This work is made difficult by the way the HNCP draft is written -- it is
not immediately obvious that HNCP is a small and elegant protocol, and
that most of the messy baggage is optional.  The general perception is "we
don't need the complexity of HNCP, let's do something ad hoc".  See for
example

  http://mid.gmane.org/[email-masked]

Adding MTI DTLS to HNCP will only make this situation worse: either HNCP
will be ignored by the communities, or the DTLS requirement will be
ignored.  The latter will enforce the (widely held) belief that the IETF
is a fossilised bureaucracy more interested in following its bureaucratic
rules than producing useful documents.  Neither is a desirable outcome.

-- Juliusz

---

From: Henning Rogge <[email-masked]>
Date: Wed, 18 Nov 2015 17:04:14 +0100

> WPA2, at least in PSK mode, does not provide confidentiality from attackers who have the PSK.   WPA isn't even as good as WPA2.   I think relying on this level of security makes sense if we have no…

I don't think DTLS with PSK is much better than WPA2 with PSK...

Henning Rogge

---

From: Ted Lemon <[email-masked]>
Date: Wed, 18 Nov 2015 16:11:34 +0000

> rules than producing useful documents.  Neither is a desirable outcome.

There is a reason why IETF standards are harder than ad hoc protocols: we specify what's needed to solve the problem generally and interoperably, and try to think about the problem from a systems perspective, not from the perspective of the immediate problem we have.    Ad hoc protocols do not suffer from that constraint.

If someone's argument for why not to adopt HNCP is "it's too hard," then they are discounting the technical debt that they accumulate when they do a one-off ad hoc protocol.   Do you have any idea, for example, how much technical debt was accumulated with the simple decision many years ago to adopt dbus as the notification protocol for Linux?   That decision was made in precisely the way you describe, and the damage has been incalculable.   It barely works now, a decade later, and the idea of a "linux" desktop is a laughingstock due to this decision, among several other similar decisions made the same way.

There is a reason why the IETF seems slow.  It is because we think hard about problems, together, through a consensus process.   This definitely takes more time than just deciding to do something to solve the immediate problem.   The way the IETF competes with people who think that way is by producing protocols that actually work and are extensible, not by sinking to their level.   There are problems with the consensus process.   We sometimes get stuck in annoying ways, as with the routing discussion.  That was actually a process failure from which I hope all involved have learned (I certainly have).   The slower process is the price we pay for doing things the way we do, but please don't make the mistake of thinking that we get nothing for that price.

The bottom line is that I think the reason you have given for not making DTLS MTI is a really bad one.   There is a perfectly good DTLS implementation out there, which is quite easy to use as far as I can tell, and if people really think that they don't need to be thinking about security of network protocols in this day and age, then it's best that they fail quickly at minimal cost, and don't drag the network down with them.  I am really tired of crappy embedded network devices with no security, no upgrade path and no thought to system design.   We should not support the proliferation of such devices.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 18 Nov 2015 16:17:26 +0000

> I don't think DTLS with PSK is much better than WPA2 with PSK...

True.   And that does rule out tinydtls but there are quite a few other DTLS implementations available.   Is your point that we need to say more than just that DTLS is MTI?   Certainly the text requiring DTLS to protect symmetric key TLVs would need to be updated to address this point!

---

From: Juliusz Chroboczek <[email-masked]>
Date: Wed, 18 Nov 2015 17:28:28 +0100

> There is a reason why IETF standards are harder than ad hoc protocols: we
> specify what's needed to solve the problem generally and interoperably,

A lot of the MUST in HNCP are not about interoperability, they are about
mandating the features that we want Homenet routers that we have.  In
other words, HNCP does not distinguish between "MUST or else you won't
interoperate" and "MUST because we are Homenet and we tell you so".

> If someone's argument for why not to adopt HNCP is "it's too hard," then
> they are discounting the technical debt that they accumulate when they do
> a one-off ad hoc protocol.

That's very well put, and exactly what I'm trying to explain to the
community.  Please help me do that rather than adding to the perception
that HNCP contains dozens of random, arbitrary requirements.

> There is a reason why the IETF seems slow.

You're changing the subject, Ted.  Nobody mentioned timeliness.

I'm arguing against making strong requirements that will be ignored by any
sensible implementer.  "Hey, you don't need to deploy that, but you still
MUST carry the dead code in your implementation".

How much more silly can one get?

-- Juliusz

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 19 Nov 2015 06:23:10 +1300

Ted,

> The bottom line is that I think the reason you have given for not making DTLS MTI is a really bad one.   There is a perfectly good DTLS implementation out there, which is quite easy to use as far as I can tell,

So I am puzzled. If that is the case, it is not the HNCP implementer who has to
write any DTLS code (in my book, the word "implement" in a protocol spec means
"write code"). At most there would need to be a few extra instructions to wrap
a socket in DTLS, and that code would likely be ifdeffed because it would
only be used when needed. Which sounds exactly like a SHOULD to me.
Or maybe "mandatory to be able to switch on." In any case, not part of the
HNCP protocol itself.

Regards
   Brian

---

From: Kathleen Moriarty <[email-masked]>
Date: Wed, 18 Nov 2015 13:36:09 -0500

Sent from my iPhone

> On Nov 18, 2015, at 12:23 PM, Brian E Carpenter <[email-masked]> wrote:
> 
> Ted,
> 

Hmm, I'm reading it the same way as Ted.  Right now, you have a SHOULD use and while I'm okay with that, a MUST implement enables the option for the SHOULD use, but that they are separate.

If there is a strong enough argument against MTI, I'll be okay with that.  I haven't seen it yet.  The SHOULD use can stay to meet some of the arguments stated, but can a MUST implement be added?

Thanks,
Kathleen

---

From: Kathleen Moriarty <[email-masked]>
Date: Wed, 18 Nov 2015 13:39:53 -0500

Hi Steven,

Thanks for your response and text suggestions.  Inline.

Sent from my iPhone

> On Nov 18, 2015, at 9:20 AM, Steven Barth <[email-masked]> wrote:
> 
> Hello Kathleen,
> 
> thanks for the review.
> 

This does help, thank you!
>  adequate protection from attackers, DNCP secure mode MUST be used to

This may be okay.  I will have to look at the draft again to see the references for DNCP security and will get back yo you as soon as I can do that.  I've had some day job responsibilities this morning.
> Would that work better or do you have something different in mind?

More later.  Thanks again!
Kathleen

---

From: Ted Lemon <[email-masked]>
Date: Wed, 18 Nov 2015 22:06:35 +0000

> that HNCP contains dozens of random, arbitrary requirements.

That's what I thought I was doing by writing that message!   I am not sure it's helpful for me to pop up on the olsr mailing list and start talking about this, and I also don't really have time, but I will see what I can do.

> You're changing the subject, Ted.  Nobody mentioned timeliness.

That's how I read what you said.   I don't think it matters--whether it's timeliness or complexity, there are definitely costs to writing standards for everybody to follow.

> MUST carry the dead code in your implementation".

Right, but I am disputing your claim that they don't need to deploy that.   Deploying it may be a regrettably manual process at the moment, but I think it is very much needed.
 
> How much more silly can one get?

I suspect that collectively we can get very silly indeed, should we choose to seriously put this question to the test, but perhaps that's more of a thing for a bar bof than a working group... ;)

---

From: Ted Lemon <[email-masked]>
Date: Wed, 18 Nov 2015 22:13:34 +0000

> Or maybe "mandatory to be able to switch on." In any case, not part of the

That's why I said MTI, not MTU!   But MTI means not #ifdef.

---

From: Juliusz Chroboczek <[email-masked]>
Date: Thu, 19 Nov 2015 00:49:23 +0100

> That's what I thought I was doing by writing that message!  I am not
> sure it's helpful for me to pop up on the olsr mailing list

You already know that, Ted, but I'd like to clarify for the list.

It's not a simple matter of sending a few mailing list messages -- it's
a long-term effort that consists of writing portable, open source,
lightweight implementations (hnetd, shncpd), of deploying HNCP ourselves
(Paris network, Henning's network somewhere in Germany), of getting HNCP
implementations into Linux and Unix distributions (OpenWRT by Steven,
Debian/Ubuntu soon, I'm not telling), of speaking to people at community
meetings (Battlemesh, IETF, CCC, FOSDEM), in short, making HNCP familiar
and easily available.

(And as we're trying to communicate our message in a clear and accurate
manner, how helpful it is to be able to say that a feature is "mandatory
to implement, optional to use, but you're not allowed to #ifdef it away".)

-- Juliusz

---

From: Kathleen Moriarty <[email-masked]>
Date: Wed, 18 Nov 2015 20:44:53 -0500

> This may be okay.  I will have to look at the draft again to see the references for DNCP security and will get back yo you as soon as I can do that.  I've had some day job responsibilities this mor…

I don't see any references for "DNCP secure mode" in this draft.  I
see the term used in
https://datatracker.ietf.org/doc/draft-ietf-homenet-dncp/?include_text=1

but that is also without reference.  Can you point me to the
definition for "DNCP secure mode"?  This may help, I'm not sure until
I can see the definition and can understand if it addresses the points
or not.

Thank you!
Kathleen

-- 

Best regards,
Kathleen

---

From: Ted Lemon <[email-masked]>
Date: Thu, 19 Nov 2015 04:14:28 +0000

> meetings (Battlemesh, IETF, CCC, FOSDEM), in short, making HNCP familiar

Sure, that's fair enough.

> to implement, optional to use, but you're not allowed to #ifdef it away".)

Just to clarify, mandatory to implement doesn't mean you have to write the code.   It means the functionality has to be present in the deployed implementation so that two communicating partners can be configured to use it.   Mandatory to use means that the functionality has to be used at all times.

---

From: Mark Townsley <[email-masked]>
Date: Thu, 19 Nov 2015 07:46:35 +0100

> On Nov 19, 2015, at 05:14, Ted Lemon <[email-masked]> wrote:
> 
> Just to clarify, mandatory to implement doesn't mean you have to write the code.

s/write/run ?

- Mark

>   It means the functionality has to be present in the deployed implementation so that two communicating partners can be configured to use it.   Mandatory to use means that the functionality has to be used at all times.
> 
> 
> --
> _______________________________________________
> homenet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/homenet

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 19 Nov 2015 19:49:00 +1300

On 19/11/2015 17:14, Ted Lemon wrote:
> Just to clarify, mandatory to implement doesn't mean you have to write the code.   It means the functionality has to be present in the deployed implementation so that two communicating partners can be configured to use it.   

Um, where is that defined? Is there a BCP that says that?

I don't think a protocol spec can say that feature X cannot be ifdeffed.
It can say that a protocol must be capable of X and that implementations
must therefore be capable of X. But if you tell implementors that they can't
ifdef unused stuff when building images for highly constrained nodes, I
don't think they will take you seriously.

   Brian

Mandatory to use means that the functionality has to be used at all times.

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 19 Nov 2015 08:02:57 +0100

> don't think they will take you seriously.

Maybe slightly off-topic for homenet, but +1000 for constrained node
networks.

Grüße, Carsten

---

From: Ted Lemon <[email-masked]>
Date: Thu, 19 Nov 2015 17:08:16 +0000

>> Just to clarify, mandatory to implement doesn't mean you have to write the code.

No, that's not the point I was making (apparently I'm not very good at clarifying).   What I mean is that MTI means that an implementation of what is specified will be able to use the thing that's MTI when it's called for.   So it can't be #ifdef'd out and still be an implementation of the specification.   The mere fact that the code is there and could be compiled in does not mean the implementation conforms to the specification.   It has to actually be compiled in and operable.

As a general practice, ifdeffing out code that you've written tends not to be the right thing, because then it doesn't get tested and maintained.   c.f. "technical debt."

---

From: Ted Lemon <[email-masked]>
Date: Thu, 19 Nov 2015 17:12:19 +0000

> Um, where is that defined? Is there a BCP that says that?

It's not codified into law, but what else could it mean?   Why would we specify something as mandatory to implement if an expression of that implementation in running code did not actually contain the implementation?

> don't think they will take you seriously.

The protocol spec would just say MUST implement.   If the implementor wants to conditionalize the compilation of the code, we can't stop them from doing that, but then they don't have an implementation of the specification, and they shouldn't say "supports RFC XXX".   "supports RFC XXX" means that anything that is specified in the RFC is asserted to be functional in the implementation.

They can perfectly well say "supports a subset of RFC XXX," and I can't imagine that anybody would object to that.

---

From: Mark Andrews <[email-masked]>
Date: Fri, 20 Nov 2015 09:56:02 +1100

In message <[email-masked]>, Ted Lemon writ
es:
> >> Just to clarify, mandatory to implement doesn't mean you have to write
> >> the code.   It means the functionality has to be present in the deployed
> >> implementation so that two communicating partners can be configured to
> >> use it.
> >
> It's not codified into law, but what else could it mean?   Why would we
> specify something as mandatory to implement if an expression of that
> implementation in running code did not actually contain the
> implementation?
>
> The protocol spec would just say MUST implement.   If the implementor
> wants to conditionalize the compilation of the code, we can't stop them
> from doing that, but then they don't have an implementation of the
> specification, and they shouldn't say "supports RFC XXX".   "supports RFC
> XXX" means that anything that is specified in the RFC is asserted to be
> functional in the implementation.
>
> They can perfectly well say "supports a subset of RFC XXX," and I can't
> imagine that anybody would object to that.

Unless they say what the subset they support / don't support, then
I object.  "partial support" is meaningless unless it is qualified.

> My PGP key: https://keys.whiteout.io/mellon@fugue.=
> com
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Markus Stenberg <[email-masked]>
Date: Fri, 20 Nov 2015 16:21:29 +0200

On 18.11.2015, at 16.56, Ted Lemon <[email-masked]> wrote:
> Which possible applications of HNCP don't require security?   The problem we have with HNCP is that we have no basis for establishing trust, not that we don’t need security.

Most home networks in my honest opinion. Let us enumerate the threats:

- If the devices communicate using the wires in the home, if you have a breach there, someone can e.g. do nasty things to devices themselves anyway (for example, likelihood of someone doing on-wire tapping of my home ethernet infrastructure is less than someone actually stealing the Mac Pro, servers and other hardware the ethernet is attached to if they get the access) => physical security wins.

- If the devices communicate using wireless in the home, if you have a breach there, someone can e.g. do nasty things to other devices anyway => no wins in securing HNCP.

Securing HNCP will only make the attacks local, not global (in terms of the network). Someone can still spoof e.g. sending RAs on the local link, or do ARP/DHCPv4 in IPv4 land, and after that pretend to be router etc. Only if we have just point-to-point links (e.g. star topologies), with router as first hop for every node, then securing HNCP actually mitigates some threats. In practise I suspect typical homes will have relatively large number of devices in one or few wireless SSIDs and perhaps something on wires, but that does not imply star topology.

If we contrast that to the current full L2 bridges in homes, the situation is simply same; attacks can be mounted on any insecure link in home and it affects the whole home.

While improving the state of the art here would be nice, I do not really see it as a reason to say MUST to an unproven solution (in terms of deployment and adoption).

> The argument against DTLS that I think makes some sense is "we don't know how to key it, and therefore don't know if it will work if/when we figure out security," not "we don't need it."   I actually have a great deal of sympathy for Kathleen’s view here; if we make DTLS MTI, then at least we’ll have an encryption/authentication mechanism when we figure out how we want to do that.

But we will have no implementations that actually do that. I consider that just harmful code bloat until some distant day in the future in which we have feasible bootstrapping scheme AND implementations in place to use it. 

> I think there's a pretty strong case to be made that the security mechanism will require public key cryptography.   If that's the case, then DTLS will work as an encryption/authentication layer.   The fact that the current draft refers to DTLS and makes it mandatory to use when transmitting pre-shared keys means that we’ve already got consensus that DTLS is a necessary option for encryption/authentication.

Possibly. The jury is still out on what is actually deployable. I am very leery of mandating anything without actual deployment experience.

For example, the current open source DTLS implementations that do non-PSK are woefully small in number, and mostly derive from same, huge, and not so good codebase (naming no names to be polite).

There’s another (much more lightweight) scheme on how to (less well, psk-only) secure DNCP stuff that I actually I use in my home; no draft, as I did not want to muddle the waters, but it is essentially few lines of Python[1] as opposed to half million lines of C that certain unnamed SSL/TLS/DTLS implementation. Obviously it cannot be bootstrapped but neither can be the most common type of DTLS - PSK-based.

As the routing protocol choice was left up in the air for homenet, I consider this to be much more thorny issue, and just saying ‘DTLS+$FOO’ seems dangerous. Especially as none of the current solutions seem that appealing (PSK = practically no go in terms of real deployment, consensus = unproven new stuff, perhaps we want in-home CA?).

> That being the case, I actually don't see any argument against making DTLS mandatory to implement.   You didn't give a reason for your opinion that we should not.   If you do have a reason for thin…

It is question of threats <-> risks  <-> mitigation analysis. Only thing HNCP security really brings is _in case of insecure L2_ _some_ security for routing/psk state. If we assume every other protocol is secured (e.g. SEND, DHCPv6 ’secure mode’) it may be actually worthwhile, but as long as e.g. DHCPv4 is not secure (and it will never be I suspect), the amount of threats you actually take out of the picture by forcing ’securing’ HNCP alone is not really significant.

To sum it up: I recommend still SHOULD MTI, MUST MTU _if and only if_ L2, but at least _my_ home does not _have_ any insecure L2, or at least insecure in a sense that HNCP running there would be my greatest worry.

Cheers,

-Markus

[1] https://github.com/fingon/pysyma/blob/master/pysyma/shsp.py

---

From: Kathleen Moriarty <[email-masked]>
Date: Fri, 20 Nov 2015 09:47:50 -0500

> To sum it up: I recommend still SHOULD MTI, MUST MTU _if and only if_ L2, but at least _my_ home does not _have_ any insecure L2, or at least insecure in a sense that HNCP running there would be my…

If MTI is not a MUST, how can you MUST the MTU?

I think my question on what is "secure mode" and request for a
reference is still outstanding.

Thank you,
Kathleen

-- 

Best regards,
Kathleen

---

From: Markus Stenberg <[email-masked]>
Date: Fri, 20 Nov 2015 17:07:19 +0200

> If MTI is not a MUST, how can you MUST the MTU?

The MUST MTU here is only for (relatively small) subset of U cases. Therefore, if a product (or a network) does not see those cases happening, broad MTI/MTU causes extra bloat without any benefit (like my home network case I mentioned).

For example, given Markus’ Home Network product does not support insecure (L2-wise) network, having MTI DTLS/TLS causes bloat and solves nothing and makes product harder to ship.

> reference is still outstanding.

Ah, sorry, simply too much mail backlog. ’secure mode’ in that context should be probably just secure _transport_ enabled on that particular link/for a particular remote endpoint, that is,  the {TLS,DTLS} based one described in the rest of the text.

I wonder if we should edit dncp too, I don’t think that term appears anywhere elsewhere in the document.

Cheers,

-Markus

---

From: Kathleen Moriarty <[email-masked]>
Date: Fri, 20 Nov 2015 10:17:31 -0500

Hi Markus,

Thanks for your quick response, inline,

> The MUST MTU here is only for (relatively small) subset of U cases. Therefore, if a product (or a network) does not see those cases happening, broad MTI/MTU causes extra bloat without any benefit (…

Can you propose text that clearly describes this for developers and
implementors to replace the current text and we'll see where we are
at?  If it makes enough sense, I may be okay with that.  Stephen also
supported my discuss, so both of us may need to review and possibly
tweak it.  The current text isn't clear enough to convey what's been
described int his thread.

> Ah, sorry, simply too much mail backlog. ’secure mode’ in that context should be probably just secure _transport_ enabled on that particular link/for a particular remote endpoint, that is,  the {TL…

OK, then for the text where this shows up in this draft, please do
replace it with what is meant exactly.

> I wonder if we should edit dncp too, I don’t think that term appears anywhere elsewhere in the document.

Yes, please.  Since it isn't defined anywhere, just stating what was
intended would be much better.

Thank you,
Kathleen

-- 

Best regards,
Kathleen

---

From: Markus Stenberg <[email-masked]>
Date: Fri, 20 Nov 2015 17:51:27 +0200

> On 20.11.2015, at 17.17, Kathleen Moriarty <[email-masked]> wrote:
> 
> Hi Markus,
> 

I am not really a wordsmith, and as I am completely happy with the ’security of unicast traffic’ (given the delta in [1]), I am not really sure what is to be done about that. Perhaps Steven can come up with something.

The text currently looks as follows:

12.2.  Security of Unicast Traffic

   Once the homenet border has been established there are several ways
   to secure HNCP against internal threats like manipulation or
   eavesdropping by compromised devices on a link which is enabled for
   HNCP traffic.  If left unsecured, attackers may perform arbitrary
   traffic redirection, eavesdropping, spoofing or denial of service
   attacks on HNCP services such as address assignment or service
   discovery, and the protocols secured using HNCP-derived keys such as
   routing protocols.

   Detailed interface categories like "leaf" or "guest" can be used to
   integrate not fully trusted devices to various degrees into the
   homenet by not exposing them to HNCP traffic or by using firewall
   rules to prevent them from reaching homenet-internal resources.

   On links where this is not practical and lower layers do not provide
   adequate protection from attackers, DTLS-based secure unicast
   transport MUST be used to secure traffic.

Can you and Stephen come up with requirements on what exactly you want in this subsection?

> intended would be much better.

Staged [1] for both dncp(-13) and hncp(-10) that removes ‘secure mode’ references. I suspect it is remainder of some much older text where we used the term more :) Good catch, thanks.

Cheers,

-Markus

[1] https://github.com/fingon/ietf-drafts/commit/363bd9b02108b4f05c03eaa68181a0f972de8c6c

---

From: Kathleen Moriarty <[email-masked]>
Date: Fri, 20 Nov 2015 11:44:42 -0500

Hi Markus,

> Can you and Stephen come up with requirements on what exactly you want in this subsection?

I think this new wording helps a lot.  I don't consider WPA adequate,
but if you are stating encryption at other layers that are ok without
listing the specific solutions, then I think we are good.  In this
thread, WPA was mentioned and as pointed out by others, it's not
adequate, but WEP2 is a lot better.  And by ok - I mean provide the
necessary security properties of confidentiality and integrity that
are not subject to attacks (MiTM, etc.).  WPA is not mentioned in the
draft, so we may be ok on this with the updated text.  Thanks for the
quick turn-around!

> Staged [1] for both dncp(-13) and hncp(-10) that removes ‘secure mode’ references. I suspect it is remainder of some much older text where we used the term more :) Good catch, thanks.

Excellent, thank you!
Kathleen

-- 

Best regards,
Kathleen

---

From: Ted Lemon <[email-masked]>
Date: Fri, 20 Nov 2015 18:22:43 +0000

> I don't think DTLS with PSK is much better than WPA2 with PSK...

I bought this argument when I first saw it, but when reading Stephen's comment just now (arguing that PSK should be MTI) I realized that I was wrong.  The PSK in the case of HNCP is being shared amongst infrastructure devices, _not_ amongst end users, unlike the WPA2 PSK, which everybody using the network must know.

So while it is certainly _possible_ for the PSK to be vulnerable in the way you describe, it is not _necessary_ for it to be vulnerable in that way, and therefore even the DTLS/PSK mode of secure HNCP is preferable to no security at all.