I assume that the trust verdicts would be distributed by hncp, but the
documenet doesn't seem to say so.
Yes, they are. The idea was too limit them in some way since neutral
verdicts can be created by (unusuccessful) external connection attempts
and thus it must be avoided that established nod
section 6.3.3 contemplates sending out verdicts for a period of time
until a decision can be rendered, giving up after 10 minutes.
I think, that since hncp is using trickle, it can just rely on trickle saying
that we haven't got any new information, so just don't say anything.
I assume that the
On 10/22/14, 12:46 PM, Brian E Carpenter wrote:
On 22/10/2014 23:54, Ray Bellis wrote:
On 22 Oct 2014, at 02:02, Brian E Carpenter wrote:
Up one more level: the charter looks pretty out of date in general.
Hi Brian,
The charter itself still reflects our primary focus. I believe it still
On 22/10/2014 23:54, Ray Bellis wrote:
> On 22 Oct 2014, at 02:02, Brian E Carpenter
> wrote:
>
>> Up one more level: the charter looks pretty out of date in general.
>
> Hi Brian,
>
> The charter itself still reflects our primary focus. I believe it still
> accurately reflects the constrain
On 22 Oct 2014, at 02:02, Brian E Carpenter wrote:
> Up one more level: the charter looks pretty out of date in general.
Hi Brian,
The charter itself still reflects our primary focus. I believe it still
accurately reflects the constraints on our scope.
The milestones are admittedly completel
> I agree with whoever it was that said there is not enough explanation
> of the threat model in this draft. The result is that I really can't
> evaluate whether the proposed solution is complete or adequate.
>From my point of view there are two vectors through which you can attack
HNCP - as mentio
Hi,
I agree with whoever it was that said there is not enough explanation
of the threat model in this draft. The result is that I really can't
evaluate whether the proposed solution is complete or adequate.
The other thing that bothers me is that we need a secure homenet, not
just a secure HNCP.
.
http://tools.ietf.org/html/draft-barth-homenet-hncp-security-trust-01
Most notable changes:
* Some clarifications to the consensus based trust scheme
* PSK-management now supports key-derivation for different protocols
(IGPs, ...)
* Underlying crypto scheme changed to DTLS for now
* Some
I just pushed a new revision of the draft.
http://tools.ietf.org/html/draft-barth-homenet-hncp-security-trust-01
Most notable changes:
* Some clarifications to the consensus based trust scheme
* PSK-management now supports key-derivation for different protocols
(IGPs, ...)
* Underlying crypto
Hi Mikael,
thanks for your feedback.
Being a crypto novice, let me write some text and please tell me if it
makes sense in the context of your draft (thanks for writing it, it
looks like a good summary).
I do not consider myself to be a crypto expert either which is one of
the reasons I'd tr
On Fri, 3 Oct 2014, Steven Barth wrote:
Please note that this draft is in a very early stage so please help to
make additions, provide feedback and point out mistakes.
Being a crypto novice, let me write some text and please tell me if it
makes sense in the context of your draft (thanks for w
Hi everyone,
I took the last few days to gather some thoughts about threats, security
and trust management
in the context of HNCP and wrote it up under
http://tools.ietf.org/html/draft-barth-homenet-hncp-security-trust-00
Quick overview over the topics:
* Homenet Border
* HNCP Payload
Markus Stenberg writes:
> > I have no idea what littleconf-TOFU setup looks like, so cannot
> > comment..
>
> Guess I’ll come over and discuss this at some point (not sure how
> much you have followed the 100+ message thread here).
I have skimmed through some of the emails, but not that well, s
On 29.9.2014, at 14.57, Tero Kivinen wrote:
> Markus Stenberg writes:
>>
>>> If homenet needs multicast support then it might be good idea to push
>>> that document forward.
>> How does this solution work with e.g. link-local-only
>> littleconf-TOFU setup?
>
> I have no idea what littleconf-TOF
Ted Lemon wrote:
>> If, OTOH, you can say that you would in fact also require origin
>> authentication, then that is also of interest. (It'd mean that your
>> use case could not be met by the initially chartered work for DICE,
>> and that factoid could be helpful in figuring out h
On 09/29/2014 06:24 AM, Ted Lemon wrote:
On Sep 29, 2014, at 9:16 AM, Stephen Farrell wrote:
If, OTOH, you can say that you would in fact also require
origin authentication, then that is also of interest. (It'd
mean that your use case could not be met by the initially
chartered work for DICE, a
On Sep 29, 2014, at 9:16 AM, Stephen Farrell wrote:
> If, OTOH, you can say that you would in fact also require
> origin authentication, then that is also of interest. (It'd
> mean that your use case could not be met by the initially
> chartered work for DICE, and that factoid could be helpful
> i
On 29/09/14 13:58, Ted Lemon wrote:
> On Sep 29, 2014, at 3:50 AM, Stephen Farrell
> wrote:
>> Sooner would be much better than later for that as the DICE WG are
>> right now in the process of (re-)considering whether they can in
>> fact meet their chartered goals on this topic.
>
> Unfortunate
On Sep 29, 2014, at 3:50 AM, Stephen Farrell wrote:
> Sooner would be much better than later for that as the DICE
> WG are right now in the process of (re-)considering whether
> they can in fact meet their chartered goals on this topic.
Unfortunately I think at this point we are distracted by a d
Markus Stenberg writes:
> > There is also ikev2 version of group key management
> > (draft-yeung-g-ikev2), but the draft seems to have expired some time
> > ago. I still think it was supposed to be published.
>
> Ah, interesting, did not know about that. Thanks ;)
>
> > If homenet needs multicast
Hiya,
I've not really been following this discussion sufficient
to comment in general, but just on this part...
On 29/09/14 08:39, Markus Stenberg wrote:
> DTLS has rather sad multicast story too
The DICE WG [1] have also been discussing potential issues
with DTLS and multicast. That discussio
On 25.9.2014, at 14.19, Tero Kivinen wrote:
> Markus Stenberg writes:
>>> Is there something else that’ll work as transport layer security
>>> for multicast, or should we send a request for the IETF leadership
>>> to investigate if this is something that needs to be developed?
>>
>> There is not
Michael Thomas wrote:
>> So what about the other way around? To what degrees should my
>> homenet trust ISP-maintained CPE?
> Sorry, I was talking about the upstream aggregation router, not the
> in-home router. That is, if I treat the ISP CPE the same way that I
> treat my
Markus Stenberg writes:
> > Is there something else that’ll work as transport layer security
> > for multicast, or should we send a request for the IETF leadership
> > to investigate if this is something that needs to be developed?
>
> There is not that I know of.
>
> I believe msec work is some
On 9/24/14, 7:46 AM, Michael Richardson wrote:
Michael Thomas wrote:
>> Michael Thomas wrote:
>> >> 2) ISP-provided router has to be willing to trust retail purchased
router,
>> >> or nothing works.
>>
>> > So what about the other way around? To what degrees should my
Michael Thomas wrote:
>> Michael Thomas wrote:
>> >> 2) ISP-provided router has to be willing to trust retail purchased
router,
>> >> or nothing works.
>>
>> > So what about the other way around? To what degrees should my homenet
trust
>> > ISP-maintained CPE?
>>
On Sep 24, 2014, at 10:00 AM, Steven Barth wrote:
> Maybe adding that we should try to use an existing and well-tested mechanism
> unless there is a very good reason not to.
I don't think there is one, but if you think there is you should tell us! :)
__
Thank you for all of the discussion on this important topic.
Without declaring consensus on how far we should go scope-wise in
terms of overall homenet security just yet, I'd like to know if, in
terms of HNCP itself from a bits-on-the-wire protocol perspective, can
we adopt this proposal prop
Mark Townsley wrote:
> Without declaring consensus on how far we should go scope-wise in terms
> of overall homenet security just yet, I'd like to know if, in terms of
> HNCP itself from a bits-on-the-wire protocol perspective, can we adopt
> this proposal proposal from Mikael? If
On 09/24/2014 05:01 AM, Mark Townsley wrote:
Thank you for all of the discussion on this important topic.
Without declaring consensus on how far we should go scope-wise in
terms of overall homenet security just yet, I'd like to know if, in
terms of HNCP itself from a bits-on-the-wire protocol
Thank you for all of the discussion on this important topic.
Without declaring consensus on how far we should go scope-wise in terms of
overall homenet security just yet, I'd like to know if, in terms of HNCP itself
from a bits-on-the-wire protocol perspective, can we adopt this proposal
prop
> On Sep 23, 2014, at 7:22 PM, Michael Richardson wrote:
>
>
> Mark Townsley wrote:
>> My own experience attempting to use IPsec as an add-on security
>> solution (a.k.a. "pixie dust) for a protocol isn't all that
>> positive. We tried that with L2TP, and in the process failed to kill
>> off P
On 24.9.2014, at 12.07, Mikael Abrahamsson wrote:
> On Wed, 24 Sep 2014, Markus Stenberg wrote:
>> Big problem with IPsec + ‘any protocol’ is that it does not work _that_ well
>> with multicast. Certainly, you can use manually keyed (static) IPsec SAs
>> (although in case of Linux, out of the bo
On Wed, 24 Sep 2014, Markus Stenberg wrote:
Big problem with IPsec + ‘any protocol’ is that it does not work _that_
well with multicast. Certainly, you can use manually keyed (static)
IPsec SAs (although in case of Linux, out of the box, it does not work
either but is easy to patch), but they
On 24.9.2014, at 8.56, Mikael Abrahamsson wrote:
> On paper it still seems IPSEC should be able to do this (I mean, isn't this
> what Microsoft does with Direct Access, ie run IPSEC and have keys handled by
> AD? From a theoretical level, it seems bad that we can't implement generic
> security
On Fri, 19 Sep 2014, Mark Townsley wrote:
My own experience attempting to use IPsec as an add-on security solution
(a.k.a. "pixie dust) for a protocol isn't all that positive. We tried
that with L2TP, and in the process failed to kill off PPTP on windows
clients. I can't tell you how many time
On Sep 23, 2014, at 7:57 PM, Douglas Otis wrote:
> Actually, it is better to assume there is a long list of vulnerable home
> routers being p0wned by entities beyond their ISP.
This is to some extent true, but not something we can really address in homenet.
_
On Sep 23, 2014, at 3:39 PM, Michael Thomas wrote:
>
> On 9/23/14, 1:07 PM, Michael Richardson wrote:
>> Michael Thomas wrote:
>> >> 2) ISP-provided router has to be willing to trust retail purchased
>> router,
>> >> or nothing works.
>>
>> > So what about the other way around? T
On 9/23/14, 1:07 PM, Michael Richardson wrote:
Michael Thomas wrote:
>> 2) ISP-provided router has to be willing to trust retail purchased
router,
>> or nothing works.
> So what about the other way around? To what degrees should my homenet
trust
> ISP-maintained CPE?
Tha
Michael Thomas wrote:
>> 2) ISP-provided router has to be willing to trust retail purchased
router,
>> or nothing works.
> So what about the other way around? To what degrees should my homenet
trust
> ISP-maintained CPE?
That's up to you. Seriously.
Your ISP-maintained CPE to
STARK, BARBARA H wrote:
> If the concern is with a man-in-the-middle attack on HNCP messages,
> then point-to-point security, using encryption with any key that the 2
The concern is man-in-the-middle "attacks" on HNCP messages by an outsider,
not another member of the household. Or, mor
On 9/23/14, 10:59 AM, Michael Richardson wrote:
2) ISP-provided router has to be willing to trust retail purchased router,
or nothing works.
So what about the other way around? To what degrees should my homenet trust
ISP-maintained CPE?
Or more succinctly, what are the things the ISP and
Randy Turner wrote:
> Are we assuming that the home router is purchased retail, and not
> "fulfilled" or provided by an ISP? The method to establish trust
> relationships would hinge on the answer
1) if there only one home router from the ISP, then there is no problem.
2) ISP-provide
> >> I further suggest that if two routers have wireless that they might
> well
> >> have a WPA2/PSK available to them, and that they can and SHOULD use
> something
> >> derived from that key to authenticate each other. Could be over IKEv2,
> yes.
>
> > I _think_ we have to assu
On Sep 23, 2014, at 1:23 PM, Michael Richardson wrote:
> With respect, if you leave the trust scheme out of scope, what you are
> really doing is leaving all of the security out of scope, because it won't be
> deployable.
+1
___
homenet mailing list
h
Steven Barth wrote:
>> And it's extremely unlikely that
>> DTLS will be a one-sentence "solution" even if it gets adopted because
>> DTLS, IPsec, etc say nothing
>> about enrollment and authorization. Those are by far the hard problems
with
>> homenent security.
> I woul
Mark Townsley wrote:
> My own experience attempting to use IPsec as an add-on security
> solution (a.k.a. "pixie dust) for a protocol isn't all that
> positive. We tried that with L2TP, and in the process failed to kill
> off PPTP on windows clients. I can't tell you how many time
Markus Stenberg wrote:
markus> 1) Can we assume secure L2 and/or appropriate device
markus> configuration by the manufacturer/ISP(/user)? (This is what I can
markus> assume in my own home.)
>> I think that we can assume that wired links are secure.
>> The only time we care if
I agree with this direction. This will also let the work HCNP and Security
Threats/Requirements to go on in parallel. Of course, HCNP security may
need to be revisited once the latter is agreed upon.
Thanks,
Acee
On 9/21/14, 3:22 PM, "Mark Baugher" wrote:
>
>On Sep 20, 2014, at 12:57 AM, Steven
On Sep 20, 2014, at 12:57 AM, Steven Barth wrote:
>
> Am 20.09.2014 um 09:17 schrieb Tim Chown:
>> I think it would be useful to do, and needn't hold up progress. It would
>> give us a common understanding - hopefully - of which threats are being
>> covered and which are not. And which are ha
Am 20.09.2014 um 09:17 schrieb Tim Chown:
I think it would be useful to do, and needn't hold up progress. It would give
us a common understanding - hopefully - of which threats are being covered and
which are not. And which are handled by layers/protocols outside the scope of
homenet's charte
> On 19 Sep 2014, at 21:59, Ted Lemon wrote:
>
>> On Sep 19, 2014, at 4:54 PM, Michael Thomas wrote:
>> I guess that's kind of what I've been getting at: should we capture all of
>> this in a threats document?
>> I'm a little uncomfortable with the formality, but I'm even more
>> uncomfortable
On Sep 19, 2014, at 4:54 PM, Michael Thomas wrote:
> I guess that's kind of what I've been getting at: should we capture all of
> this in a threats document?
> I'm a little uncomfortable with the formality, but I'm even more
> uncomfortable with the seeming desire
> by some to sweep this all und
On 9/19/14, 3:28 AM, Ted Lemon wrote:
On Sep 18, 2014, at 6:04 PM, Mark Baugher wrote:
As someone on this thread has asked: Has any of this been written down?
Requirements, use cases, threat analysis should all help to inform our decision
about what format to use.
This discussion to some e
On 20/09/2014 08:05, Michael Thomas wrote:
>
> On 9/19/14, 12:38 PM, Ted Lemon wrote:
>> On Sep 19, 2014, at 1:22 PM, Mark Baugher wrote:
>>> AFAICT, we've been discussing key format or DLTS vs IPsec. That
>>> discussion presumes that you have some way for a CPE from ISP-a to
>>> securely accept
On 9/19/14, 12:38 PM, Ted Lemon wrote:
On Sep 19, 2014, at 1:22 PM, Mark Baugher wrote:
AFAICT, we've been discussing key format or DLTS vs IPsec. That discussion
presumes that you have some way for a CPE from ISP-a to securely accept HNCP
from ISP-b, or the user's new AP/router, and so for
On Sep 19, 2014, at 1:22 PM, Mark Baugher wrote:
> AFAICT, we've been discussing key format or DLTS vs IPsec. That discussion
> presumes that you have some way for a CPE from ISP-a to securely accept HNCP
> from ISP-b, or the user's new AP/router, and so forth. How does that happen?
Michael R
On Sep 19, 2014, at 9:37 AM, Ted Lemon wrote:
> On Sep 19, 2014, at 11:59 AM, Mark Baugher wrote:
>> How could it happen?
>
> Isn't that what we've been discussing?
AFAICT, we've been discussing key format or DLTS vs IPsec. That discussion
presumes that you have some way for a CPE from ISP-
supplicant
knows the private key.
Randy
From: Michael Thomas
Date: Thursday, September 18, 2014 at 3:06 PM
To: David R Oran , Rene Struik
Cc: , Markus Stenberg
Subject: Re: [homenet] HNCP security?
On 9/18/14, 8:57 AM, David R Oran wrote:
>
> On Sep 18, 2014, at 11:46 AM
On Sep 19, 2014, at 7:17 AM, Steven Barth wrote:
> Am 19.09.2014 um 16:00 schrieb Michael Thomas:
>> And it's extremely unlikely that
>> DTLS will be a one-sentence "solution" even if it gets adopted because DTLS,
>> IPsec, etc say nothing
>> about enrollment and authorization. Those are by far
On Sep 19, 2014, at 11:59 AM, Mark Baugher wrote:
> How could it happen?
Isn't that what we've been discussing?
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
On Sep 19, 2014, at 8:54 AM, Ted Lemon wrote:
> On Sep 19, 2014, at 10:52 AM, Steven Barth wrote:
>> That was not my point. I'm totally happy with having a standardized way of
>> doing this but I don't think that HNCP is the place where it should be
>> defined since we will probably not be th
On Sep 19, 2014, at 10:52 AM, Steven Barth wrote:
> That was not my point. I'm totally happy with having a standardized way of
> doing this but I don't think that HNCP is the place where it should be
> defined since we will probably not be the only user.
HNCP won't be the only user, but given t
On 09/19/2014 07:52 AM, Steven Barth wrote:
Am 19.09.2014 um 16:29 schrieb Michael Thomas:
Punting on one of the hardest problems would be a travesty. There are
plenty of people in IETF that are
plenty smart about this subject; we will never get an opportunity to
do the right thing again if we
Am 19.09.2014 um 16:29 schrieb Michael Thomas:
Punting on one of the hardest problems would be a travesty. There are
plenty of people in IETF that are
plenty smart about this subject; we will never get an opportunity to
do the right thing again if we loose
this into the wild and say "figure it o
On 09/19/2014 07:17 AM, Steven Barth wrote:
Am 19.09.2014 um 16:00 schrieb Michael Thomas:
And it's extremely unlikely that
DTLS will be a one-sentence "solution" even if it gets adopted
because DTLS, IPsec, etc say nothing
about enrollment and authorization. Those are by far the hard
problems
Am 19.09.2014 um 16:00 schrieb Michael Thomas:
And it's extremely unlikely that
DTLS will be a one-sentence "solution" even if it gets adopted because
DTLS, IPsec, etc say nothing
about enrollment and authorization. Those are by far the hard problems
with homenent security.
I wouldn't really wa
On 09/19/2014 02:06 AM, Markus Stenberg wrote:
On 19.9.2014, at 11.18, Mark Townsley wrote:
My own experience attempting to use IPsec as an add-on security solution (a.k.a.
"pixie dust) for a protocol isn't all that positive. We tried that with L2TP,
and in the process failed to kill off PPTP
On 09/19/2014 01:18 AM, Mark Townsley wrote:
Another lesson learned was exposing two passwords to the user vs. one.
In a retail/wholesale LAC/LNS deployment model, it made perfect sense
for the L2TP tunnel to have a password separate from the PPP user
password (and L2TP fully supplanted L2F
On Sep 19, 2014, at 3:25 AM, Ted Lemon wrote:
> On Sep 18, 2014, at 6:46 PM, Mark Baugher wrote:
>> The retail model works here. I can imagine a compliant CPE might allow the
>> use to "take ownership" of an interior HNCP interface. That's only if the
>> provider of that CPE wanted to be com
On Sep 18, 2014, at 6:04 PM, Mark Baugher wrote:
> As someone on this thread has asked: Has any of this been written down?
> Requirements, use cases, threat analysis should all help to inform our
> decision about what format to use.
This discussion to some extent made it into the homenet arch
On Sep 18, 2014, at 6:46 PM, Mark Baugher wrote:
> The retail model works here. I can imagine a compliant CPE might allow the
> use to "take ownership" of an interior HNCP interface. That's only if the
> provider of that CPE wanted to be compliant to a future HNCP security
> standard.
So to b
On 19.9.2014, at 11.18, Mark Townsley wrote:
> My own experience attempting to use IPsec as an add-on security solution
> (a.k.a. "pixie dust) for a protocol isn't all that positive. We tried that
> with L2TP, and in the process failed to kill off PPTP on windows clients. I
> can't tell you how
On Sep 18, 2014, at 12:34 PM, Ted Lemon wrote:
> On Sep 18, 2014, at 4:27 AM, STARK, BARBARA H wrote:
>> UPnP Device Protection uses X.509 certificates (which can be self-signed,
>> and in order not to assume a WAN connection, really should be self-signed)
>> and TLS.
>
> I think that someth
smartphone
Original message
From: "STARK, BARBARA H"
Date:09/18/2014 5:02 PM (GMT-06:00)
To: Randy Turner , Michael Thomas ,
homenet@ietf.org
Cc:
Subject: RE: [homenet] HNCP security?
> How do you bootstrap trust relationships without an initial certificat
On 9/18/14, 3:43 PM, Randy Turner wrote:
Are we assuming that the home router is purchased retail, and not
"fulfilled" or provided by an ISP? The method to establish trust
relationships would hinge on the answer
I should be able prepurpose an old PC with linux running homenet
software. We
k Baugher
> Date:09/18/2014 5:12 PM (GMT-06:00)
> To: Randy Turner
> Cc: "homenet@ietf.org Group"
> Subject: Re: [homenet] HNCP security?
>
>
> On Sep 18, 2014, at 2:37 PM, Randy Turner wrote:
>
> > How do you bootstrap trust relationships without a
On 9/18/14, 3:39 PM, Brian E Carpenter wrote:
Yes, I agree and that's why self-signed and/or manufacturer certs are of
no help.
Surely they are of help for secure *identification* of devices?
No more so than the naked public key.
Authorisation is a separate step.
Yes.
There is no beli
ndy Turner
Cc: "homenet@ietf.org Group"
Subject: Re: [homenet] HNCP security?
On Sep 18, 2014, at 2:37 PM, Randy Turner wrote:
> How do you bootstrap trust relationships without an initial certificate
> (whether installed at manufacturing or during a customer fulfillment stag
On 19/09/2014 09:17, Michael Thomas wrote:
>
> On 9/18/14, 2:10 PM, STARK, BARBARA H wrote:
>>> Self-signed certs bring only confusion, IMO: they are nothing more
>>> than a
>>> raw key with an unsubstantiated claim to another name, along with a
>>> whole
>>> lot more ASN.1 baggage beyond what is
re's been some talk about using web of trust,
but I don't understand how that would work.
Mark
>
>
>
> Original message
> From: Michael Thomas
> Date:09/18/2014 4:17 PM (GMT-06:00)
> To: homenet@ietf.org
> Cc:
> Subject: Re: [homenet]
And all of this was covered in the design for UPnP Device Protection that you
referred to earlier and its progenitor UPnP Device Security. I consider HNCP
security to be a small subset of the UPnP device requirements.
Mark
On Sep 18, 2014, at 2:10 PM, STARK, BARBARA H wrote:
>> Self-signed ce
On Sep 18, 2014, at 8:57 AM, David R Oran wrote:
>
> On Sep 18, 2014, at 11:46 AM, Rene Struik wrote:
>
>> It seems that the cryptographic literature needs to be rewritten now ...
>>
>> ==
>> Anything you can do with a cert, you can do with raw public keys, and you
>> don't need CA's. See R
in the network). I
really see no way to enable security without some user involvement. And as long
as the user has the choice to run without security, I see no problem in
requiring it.
Barbara
Original message
From: Michael Thomas
Date:09/18/2014 4:17 PM (GMT-06:00)
To: homenet@ie
: [homenet] HNCP security?
On 9/18/14, 2:10 PM, STARK, BARBARA H wrote:
>> Self-signed certs bring only confusion, IMO: they are nothing more than a
>> raw key with an unsubstantiated claim to another name, along with a whole
>> lot more ASN.1 baggage beyond what is needed to pa
On 9/18/14, 2:10 PM, STARK, BARBARA H wrote:
Self-signed certs bring only confusion, IMO: they are nothing more than a
raw key with an unsubstantiated claim to another name, along with a whole
lot more ASN.1 baggage beyond what is needed to parse the modulo and
exponent.
And you don't get usage
> Self-signed certs bring only confusion, IMO: they are nothing more than a
> raw key with an unsubstantiated claim to another name, along with a whole
> lot more ASN.1 baggage beyond what is needed to parse the modulo and
> exponent.
>
> And you don't get usage or policy restrictions without a CA
On 9/18/14, 8:57 AM, David R Oran wrote:
On Sep 18, 2014, at 11:46 AM, Rene Struik wrote:
It seems that the cryptographic literature needs to be rewritten now ...
==
Anything you can do with a cert, you can do with raw public keys, and you don't
need CA's. See RFC4871 for an example.
I wou
On 09/18/2014 08:57 AM, David R Oran wrote:
On Sep 18, 2014, at 11:46 AM, Rene Struik wrote:
It seems that the cryptographic literature needs to be rewritten now ...
==
Anything you can do with a cert, you can do with raw public keys, and you don't
need CA's. See RFC4871 for an example.
I w
On Sep 18, 2014, at 11:46 AM, Rene Struik wrote:
> It seems that the cryptographic literature needs to be rewritten now ...
>
> ==
> Anything you can do with a cert, you can do with raw public keys, and you
> don't need CA's. See RFC4871 for an example.
I would have thought it was the opposite
It seems that the cryptographic literature needs to be rewritten now ...
==
Anything you can do with a cert, you can do with raw public keys, and
you don't need CA's. See RFC4871 for an example.
On 9/18/2014 11:36 AM, Michael Thomas wrote:
On 09/18/2014 08:31 AM, Markus Stenberg wrote:
whethe
On 09/18/2014 08:31 AM, Markus Stenberg wrote:
whether your authorization policy is leap of faithy, or strict ’these are the
authorized CAs/individual certs’, there is no way to express same things with
raw public keys (or you wind up with new X509, which is in nobody’s best
interest).
Anyt
On 09/18/2014 08:24 AM, Markus Stenberg wrote:
With device certificates, you still have the original authz problem. That is,
just because I can identify you
reliably tells me nothing about whether I want to participate with routing
updates with you. So in that
way, they not any more useful th
Whether or not you do leap of faith, certificates _do_ provide extra value.
- you can produce them/validate via (local / cloudy) CA (which may also imply
authorization in addition to authentication, or not)
- you can have them from hardware (which makes producing spurious ones much
harder, assu
On 18.9.2014, at 18.17, Michael Thomas wrote:
> On 09/18/2014 06:49 AM, Markus Stenberg wrote:
>> On 18.9.2014, at 16.05, Ted Lemon wrote:
>>> On Sep 18, 2014, at 7:38 AM, STARK, BARBARA H wrote:
X.509 certificates can be self-signed. That is, the device acts as its own
CA. In fact, t
On 09/18/2014 06:49 AM, Markus Stenberg wrote:
On 18.9.2014, at 16.05, Ted Lemon wrote:
On Sep 18, 2014, at 7:38 AM, STARK, BARBARA H wrote:
X.509 certificates can be self-signed. That is, the device acts as its own CA.
In fact, this is the recommended approach.
Of course. But if there is
One advantage of using X.509 certs is that the code to support them is widely
available with multiple implementations.
I guess then you could go all the way and use the whole DTLS for HNCP
unicast traffic (and keep MC unencrypted since its more or less a
signaling channel for UC and doesn't c
On 18.9.2014, at 16.05, Ted Lemon wrote:
> On Sep 18, 2014, at 7:38 AM, STARK, BARBARA H wrote:
>> X.509 certificates can be self-signed. That is, the device acts as its own
>> CA. In fact, this is the recommended approach.
> Of course. But if there is never going to be a CA-signed key, there
On Sep 18, 2014, at 7:38 AM, STARK, BARBARA H wrote:
> X.509 certificates can be self-signed. That is, the device acts as its own
> CA. In fact, this is the recommended approach.
Of course. But if there is never going to be a CA-signed key, there is no
reason to have a cert at all. Self-sig
On 09/18/2014 04:50 AM, Michael Sweet wrote:
One advantage of using X.509 certs is that the code to support them is widely
available with multiple implementations.
Another is that the same cert can be used for TLS negotiation in embedded web
services, etc. to each device.
And of course if the
1 - 100 of 141 matches
Mail list logo
