Re: [homenet] Kathleen Moriarty's Discuss on draft-ietf-homenet-hncp-09: (with DISCUSS)
Wednesday, Nov 18, 2015 11:04 AM Henning Rogge wrote: > On Wed, Nov 18, 2015 at 4:46 PM, Ted Lemon wrote: >> 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. > > 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. -- Sent from Whiteout Mail - https://whiteout.io My PGP key: https://keys.whiteout.io/mel...@fugue.com pgpeA8ULKEAoW.pgp Description: PGP signature ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Kathleen Moriarty's Discuss on draft-ietf-homenet-hncp-09: (with DISCUSS)
Hi Markus,
On Fri, Nov 20, 2015 at 10:51 AM, Markus Stenberg
wrote:
>
>> On 20.11.2015, at 17.17, Kathleen Moriarty
>> wrote:
>>
>> Hi Markus,
>>
>> Thanks for your quick response, inline,
>>
>> On Fri, Nov 20, 2015 at 10:07 AM, Markus Stenberg
>> wrote:
>>> On 20.11.2015, at 16.47, Kathleen Moriarty
>>> wrote:
> 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.
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).
>> 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.
>
> 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?
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!
>
>>> 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.
>> 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.
>
> 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
>
> Cheers,
>
> -Markus
>
> [1]
> https://github.com/fingon/ietf-drafts/commit/363bd9b02108b4f05c03eaa68181a0f972de8c6c
>
--
Best regards,
Kathleen
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Kathleen Moriarty's Discuss on draft-ietf-homenet-hncp-09: (with DISCUSS)
> On 20.11.2015, at 17.17, Kathleen Moriarty
> wrote:
>
> Hi Markus,
>
> Thanks for your quick response, inline,
>
> On Fri, Nov 20, 2015 at 10:07 AM, Markus Stenberg
> wrote:
>> On 20.11.2015, at 16.47, Kathleen Moriarty
>> wrote:
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.
>>> 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).
> 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.
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?
>> 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.
> 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.
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
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Kathleen Moriarty's Discuss on draft-ietf-homenet-hncp-09: (with DISCUSS)
Hi Markus,
Thanks for your quick response, inline,
On Fri, Nov 20, 2015 at 10:07 AM, Markus Stenberg
wrote:
> On 20.11.2015, at 16.47, Kathleen Moriarty
> wrote:
>>> 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.
>> 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).
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.
>
> 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.
>
>> I think my question on what is "secure mode" and request for a
>> 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.
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
>
> Cheers,
>
> -Markus
>
--
Best regards,
Kathleen
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Kathleen Moriarty's Discuss on draft-ietf-homenet-hncp-09: (with DISCUSS)
On 20.11.2015, at 16.47, Kathleen Moriarty
wrote:
>> 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.
> 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.
> I think my question on what is "secure mode" and request for a
> 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
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Kathleen Moriarty's Discuss on draft-ietf-homenet-hncp-09: (with DISCUSS)
On Fri, Nov 20, 2015 at 9:21 AM, Markus Stenberg wrote: > On 18.11.2015, at 16.56, Ted Lemon wrote: >> Wednesday, Nov 18, 2015 8:24 AM Juliusz Chroboczek wrote: >>> 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. >> 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 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
Re: [homenet] Kathleen Moriarty's Discuss on draft-ietf-homenet-hncp-09: (with DISCUSS)
On 18.11.2015, at 16.56, Ted Lemon wrote: > Wednesday, Nov 18, 2015 8:24 AM Juliusz Chroboczek wrote: >> 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. > 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 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. It is ques
Re: [homenet] Kathleen Moriarty's Discuss on draft-ietf-homenet-hncp-09: (with DISCUSS)
In message <1447953139625-fadd659d-49861c14-8098f...@fugue.com>, Ted Lemon writ es: > > Thursday, Nov 19, 2015 1:49 AM Brian E Carpenter 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? > > 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? > > > 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. > > 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. > -- > Sent from Whiteout Mail - https://whiteout.io > > 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: ma...@isc.org ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Kathleen Moriarty's Discuss on draft-ietf-homenet-hncp-09: (with DISCUSS)
Thursday, Nov 19, 2015 1:49 AM Brian E Carpenter 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? 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? > 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. 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. -- Sent from Whiteout Mail - https://whiteout.io My PGP key: https://keys.whiteout.io/mel...@fugue.com pgpAN9O3NxVoR.pgp Description: PGP signature ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Kathleen Moriarty's Discuss on draft-ietf-homenet-hncp-09: (with DISCUSS)
Thursday, Nov 19, 2015 1:46 AM Mark Townsley wrote: >> Just to clarify, mandatory to implement doesn't mean you have to write the >> code. > > s/write/run ? 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." -- Sent from Whiteout Mail - https://whiteout.io My PGP key: https://keys.whiteout.io/mel...@fugue.com pgpw2yewMXlrx.pgp Description: PGP signature ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Kathleen Moriarty's Discuss on draft-ietf-homenet-hncp-09: (with DISCUSS)
Brian E Carpenter 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. Maybe slightly off-topic for homenet, but +1000 for constrained node networks. Grüße, Carsten ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Kathleen Moriarty's Discuss on draft-ietf-homenet-hncp-09: (with DISCUSS)
On 19/11/2015 17:14, Ted Lemon wrote: > Wednesday, Nov 18, 2015 6:49 PM Juliusz Chroboczek wrote: >> 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. > > Sure, that's fair enough. > >> (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".) > > 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. > > > -- > Sent from Whiteout Mail - https://whiteout.io > > My PGP key: https://keys.whiteout.io/mel...@fugue.com > > > > ___ > 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] Kathleen Moriarty's Discuss on draft-ietf-homenet-hncp-09: (with DISCUSS)
> On Nov 19, 2015, at 05:14, Ted Lemon wrote: > > Wednesday, Nov 18, 2015 6:49 PM Juliusz Chroboczek wrote: >> 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. > > Sure, that's fair enough. > >> (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".) > > 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. > > > -- > Sent from Whiteout Mail - https://whiteout.io > > My PGP key: https://keys.whiteout.io/mel...@fugue.com > ___ > 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] Kathleen Moriarty's Discuss on draft-ietf-homenet-hncp-09: (with DISCUSS)
Wednesday, Nov 18, 2015 6:49 PM Juliusz Chroboczek wrote: > 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. Sure, that's fair enough. > (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".) 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. -- Sent from Whiteout Mail - https://whiteout.io My PGP key: https://keys.whiteout.io/mel...@fugue.com pgpfoxsWeI4Te.pgp Description: PGP signature ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Kathleen Moriarty's Discuss on draft-ietf-homenet-hncp-09: (with DISCUSS)
On Wed, Nov 18, 2015 at 1:39 PM, Kathleen Moriarty wrote: > Hi Steven, > > Thanks for your response and text suggestions. Inline. > > Sent from my iPhone > >> On Nov 18, 2015, at 9:20 AM, Steven Barth wrote: >> >> Hello Kathleen, >> >> thanks for the review. >> >>> 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? >> >> I have staged this text now: >> >> HNCP nodes MUST use the leading 64 bits of the > target="RFC1321">MD5 message digest 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. >> > > This does help, thank you! >> >>> 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)? >> >> 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. > > 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. 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 >> >> 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? >> > > More later. Thanks again! > Kathleen >> >>> >>> Could you add a reference to RFC7525 to help with configuration and >>> cipher suite recommendations? This could be in section 12, security >>> considerations. >> >> Staged for next revision. >> >> >> >> Cheers, >> >> Steven -- Best regards, Kathleen ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Kathleen Moriarty's Discuss on draft-ietf-homenet-hncp-09: (with DISCUSS)
>> 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. > 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 ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Kathleen Moriarty's Discuss on draft-ietf-homenet-hncp-09: (with DISCUSS)
Wednesday, Nov 18, 2015 12:23 PM Brian E Carpenter wrote: >> 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. That's why I said MTI, not MTU! But MTI means not #ifdef. -- Sent from Whiteout Mail - https://whiteout.io My PGP key: https://keys.whiteout.io/mel...@fugue.com pgp1m0Tk51mCt.pgp Description: PGP signature ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Kathleen Moriarty's Discuss on draft-ietf-homenet-hncp-09: (with DISCUSS)
Wednesday, Nov 18, 2015 11:28 AM Juliusz Chroboczek wrote: >> 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. 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. >> There is a reason why the IETF seems slow. > > 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. > 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". 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... ;) -- Sent from Whiteout Mail - https://whiteout.io My PGP key: https://keys.whiteout.io/mel...@fugue.com pgpPofihiBuuk.pgp Description: PGP signature ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Kathleen Moriarty's Discuss on draft-ietf-homenet-hncp-09: (with DISCUSS)
Hi Steven, Thanks for your response and text suggestions. Inline. Sent from my iPhone > On Nov 18, 2015, at 9:20 AM, Steven Barth wrote: > > Hello Kathleen, > > thanks for the review. > >> 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? > > I have staged this text now: > > HNCP nodes MUST use the leading 64 bits of the target="RFC1321">MD5 message digest 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. > This does help, thank you! > >> 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)? > > 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. 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. > > 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? > More later. Thanks again! Kathleen > >> >> Could you add a reference to RFC7525 to help with configuration and >> cipher suite recommendations? This could be in section 12, security >> considerations. > > Staged for next revision. > > > > Cheers, > > Steven ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Kathleen Moriarty's Discuss on draft-ietf-homenet-hncp-09: (with DISCUSS)
Sent from my iPhone > On Nov 18, 2015, at 12:23 PM, Brian E Carpenter > wrote: > > 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. 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 > > Regards > Brian > ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Kathleen Moriarty's Discuss on draft-ietf-homenet-hncp-09: (with DISCUSS)
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 ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Kathleen Moriarty's Discuss on draft-ietf-homenet-hncp-09: (with DISCUSS)
> 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 ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Kathleen Moriarty's Discuss on draft-ietf-homenet-hncp-09: (with DISCUSS)
Wednesday, Nov 18, 2015 11:04 AM Henning Rogge wrote: > 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! -- Sent from Whiteout Mail - https://whiteout.io My PGP key: https://keys.whiteout.io/mel...@fugue.com pgpH2trkQegRS.pgp Description: PGP signature ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Kathleen Moriarty's Discuss on draft-ietf-homenet-hncp-09: (with DISCUSS)
Wednesday, Nov 18, 2015 10:57 AM Juliusz Chroboczek wrote: >> 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/87fv09u7uq.wl-...@pps.univ-paris-diderot.fr > > 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. 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. -- Sent from Whiteout Mail - https://whiteout.io My PGP key: https://keys.whiteout.io/mel...@fugue.com pgpMt5Bmriixp.pgp Description: PGP signature ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Kathleen Moriarty's Discuss on draft-ietf-homenet-hncp-09: (with DISCUSS)
On Wed, Nov 18, 2015 at 4:46 PM, Ted Lemon wrote: > Wednesday, Nov 18, 2015 9:20 AM Steven Barth wrote: >> 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. > > 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. I don't think DTLS with PSK is much better than WPA2 with PSK... Henning Rogge ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Kathleen Moriarty's Discuss on draft-ietf-homenet-hncp-09: (with DISCUSS)
>> 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. > 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/87fv09u7uq.wl-...@pps.univ-paris-diderot.fr 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 ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Kathleen Moriarty's Discuss on draft-ietf-homenet-hncp-09: (with DISCUSS)
Wednesday, Nov 18, 2015 9:20 AM Steven Barth wrote: > 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. 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. > 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. So doesn't that make DTLS MTI already? If so, maybe we should just say so explicitly. -- Sent from Whiteout Mail - https://whiteout.io My PGP key: https://keys.whiteout.io/mel...@fugue.com pgphF76pcEmvv.pgp Description: PGP signature ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Kathleen Moriarty's Discuss on draft-ietf-homenet-hncp-09: (with DISCUSS)
Wednesday, Nov 18, 2015 8:24 AM Juliusz Chroboczek wrote: > 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. 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/mel...@fugue.com pgpebceVopOW5.pgp Description: PGP signature ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Kathleen Moriarty's Discuss on draft-ietf-homenet-hncp-09: (with DISCUSS)
Hello Kathleen, thanks for the review. > 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? I have staged this text now: HNCP nodes MUST use the leading 64 bits of the MD5 message digest 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. > 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)? 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? > > Could you add a reference to RFC7525 to help with configuration and > cipher suite recommendations? This could be in section 12, security > considerations. Staged for next revision. Cheers, Steven ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Kathleen Moriarty's Discuss on draft-ietf-homenet-hncp-09: (with DISCUSS)
Dear Kathleen, > 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)? 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 ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
