Subject: [ieee-ietf-coord] Fwd: [802.1 - 11898] Proposed PAR: P802.1AR: Standard for Local and metropolitan area networks - Secure Device Identity

From: Dan Romascanu <[email-masked]>
Date: Wed, 5 Oct 2016 12:48:58 +0300

Please see below the proposed PAR of IEEE 802.1AR. If there are any
questions, comments, or concerns from the IETF participants, please make
sure that Glenn Parsons sees them.

Thanks and Regards,

Dan

---------- Forwarded message ----------
From: Glenn Parsons <[email-masked]>
Date: Wed, Oct 5, 2016 at 8:25 AM
Subject: [802.1 - 11898] Proposed PAR: P802.1AR: Standard for Local and
metropolitan area networks - Secure Device Identity
To: [email-masked]

Ballots due October 23: P802.1Qcc/D1.1, P802.1Xck D0.8
  Due October 24: P802c/D1.2
For particulars see
  www.ieee802.org/1/email-pages/ballots.html
This list strips out HTML. For  more format and size rules, see "Sending"
at
802.1 list help: www.ieee802.org/1/email-pages/zmqw1113.html
-----

Colleagues
This is a PAR  for a revision -- P802.1AR:  Standard for Local and
metropolitan area networks - Secure Device Identity -- for pre-submission
to the EC for approval in November.
The September 802.1 interim meeting was authorized to discuss this and
produced this PAR:
http://ieee802.org/1/files/public/docs2016/ar-seaman-rev-
draft-par-0916-v02.pdf
As well as the accompanying CSD:
http://ieee802.org/1/files/public/docs2016/ar-seaman-rev-
draft-csd-0916-v02.pdf
I would request that this be considered for review by all WGs at the
November plenary, and also be considered for approval by the EC.
Please let me know if you have any comments or questions.
Cheers,
Glenn.

--
Glenn Parsons - Chair, IEEE 802.1
[email-masked]<mailto:[email-masked]>
+1-613-963-8141

===
Unsubscribe link: mailto:[email-masked]
IEEE. Fostering technological innovation and excellence for the benefit of
humanity.

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 5 Oct 2016 11:22:03 +0100

Hiya,

> sure that Glenn Parsons sees them.

I had a quick look at the PDFs included there and have a
couple of questions:

1) Wouldn't it be a fine plan to include consideration of
the privacy aspects of (new) long-lived identifiers in
this work? Given that IEEE are rightly considering things
like MAC address randomisation, the same issues that cause
us to be interested in that will cause us to want to try
be privacy sensitive when introducing any new long-lived
identifiers. The upshot of that might not be any change
to protocol, but could e.g. be a recommendation for the
kind(s) of nodes for which these new long-lived identifiers
are (un)suitable. Equally however, there could be protocol
features that would be more or less privacy-friendly so
explicitly considering that seems to me like it'd be a
good plan.

2) The PAR refers to NIST curves which is fine. In the IETF
context there is also a lot of interest in use of the
"cfrg curves" (Curve25519 and Curve448) which have some
properties that are desirable from a performance and
security POV. Similarly, deterministic signatures (i.e.
not requiring a good random number for each signature)
have significant security benefits. I wondered if these
kinds of issue would be in scope? (FWIW I think it'd be
a good plan if they were also considered.)

Cheers,
S.

> _______________________________________________
> ieee-ietf-coord mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ieee-ietf-coord
>

---

From: Mick Seaman <[email-masked]>
Date: Wed, 5 Oct 2016 11:14:05 -0700

Hi Stephen,

This proposed revision PAR for the existing IEEE Std 802.1AR-2009 will 
replace the amendment PAR P802.1ARce which just added P-384 SHA-384.

It turned out during the course of that work that the original 802.1AR 
was not constructed in a way that made extensions to new curves easy. It 
had started life very focused on RSA and ECC curves were shoehorned in 
late in the day. Basically taking the form "X is done like this but if 
you are using ECC then ..".

This resulted in a much longer project than desirable given the pressing 
need for P-384 SHA-384, and much more of a shake up to the document that 
could be justified under an amendment PAR - hence the revision PAR which 
will then be followed by withdrawal of the amendment PAR. That having 
been done it should now be much easier to add new curves (the starting 
point of this project is not a blank sheet or even the existing standard 
but a much updated amendment of the latter). However it would be sad if 
the emergence of new curves further delayed P-384 SHA-384. Having got 
the structured sorted out new curves can be added by an amendment, and 
the process of completing the Revision (as currently) scoped plus the 
addition of a further curve by amendment should not take any longer than 
holding the revision open to add a new curve. It is always quicker to 
take things in bite sized chunks.

I should clarify further than these are not new long lived identifiers. 
They are X.509 certs (and the information around those to support/use 
them in particular ways). They are referenced by (and the way they were 
intended to be used fits with)  RFC 7030 Enrollment over Secure 
Transport (Standards Track), as well as by the informational internet 
draft draft-pritikin-bootstrapping-keyinfrastructures-1 Bootstrapping 
Key Infrastructures. The development of IEEE Std 802.1AR-2009 preceded 
and informed that IETF work with participants attending both groups.

A section on "Privacy considerations" already appears in the P802.1ARce 
draft (related material was already in 802.1AR-2009 but renaming that to 
fit the mood of the times is appropriate) . The "Scope" statement in the 
PAR matches exactly that of the existing IEEE Std 802.1AR.

Mick Seaman

Chair, IEEE 802.1 Security Task Group

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 5 Oct 2016 21:21:17 +0100

Hiya,

> you are using ECC then ..".

Yeah, we've seen that with IETF protocols too and ended up
re-structuring how we handle ECC in a number of cases. It
was well worth doing as some initial data structures were
far too over-general in ways that encouraged some weaknesses.

> need for P-384 SHA-384, 

I'm surprised about a pressing need? Unless it's some kind
of suite-B special thing that is. Many folks don't seem to
consider stronger than 128-bit equivalent that interesting
for ECC other than for window dressing (IMO the reason why
we ended up adding Curve448 was just for window dressing as
we knew someone would demand "stronger than that";-)

> and much more of a shake up to the document that

I'm totally not following the IEEE minutiae there, but that's ok.

You didn't get to deterministic signatures. That's probably more
of a deal than new curves for 802 devices I'd say given how bad
we know folks are at finding good randomness. (That said, if the
main justification here is suite-B then you've no freedom to
improve there anyway so it doesn't matter.)

Anyway, if this is a suite-B thing, it'd be better to explicitly
say that. If not, then I'd really strongly recommend deterministic
signatures and then also adding in new curves into the mix explicitly.
(EDDSA as used in IETF protocols only does things deterministically.)

And just for those who might not follow all the fun of ECDSA, if
you ever sign twice with the same supposed-to-be-but-not-random
value (or a random output that repeats because it's not long enough
or your PRNG isn't good enough) then you give the world your private
key value. And that has been seen in the wild. I assume in this case
that'd mean that the attacker could enter the enterprise network
which is precisely the thing that signing was intended to prevent.

(Apologies if that's already handled in 802-land;-)

> PAR matches exactly that of the existing IEEE Std 802.

Sure, and I don't know what implementers tend to add this kind of
thing. I can say that I'd prefer to not have it in kit in my home
at all, (or fully turned off if the code is there) but can see why
enterprises would like to use it. If those kinds of consideration
are going to be covered well, then that's great. If not, then I'd
worry a bit that we end up disimproving privacy yet again because
we didn't think enough about it. (And the "we" there isn't meant to
mean IEEE or IETF but all of us;-)

Cheers,
S.

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 5 Oct 2016 22:05:08 +0100

Hiya,

On 05/10/16 21:57, Mick Seaman wrote:
> Hi Stephen,
> 
> Given that we already have already approved P-384 SHA-384 project and
> those that wanted that still want it now, I don't think it would be fair
> play to take a ballot comment from the P802.1ARce Task Group ballot that
> said "turn this from an amendment into a revision for technical editing
> reasons" and come back with a response "yes, and delay this already
> approved  project". And yes, Suite B (I believe), but I don't think we
> need to go reargue the fact that we are adding P-384 SHA-384.

So if this is to meet the requirements of those with customers
who need Suite-B then just saying so would be much clearer and
would avoid folks (like me:-) commenting.

> 
> I agree with the sentiment on new curves and deterministic and RNGs, but
> that can be in an amendment.

Again, I'd argue deterministic should be included (and be the
default) unless "meets Suite-B needs" is more important than
security, in which case being explicit about that is wise really.
Either position can be reasonable but those who do not need
Suite-B would I'm sure appreciate knowing what's what if they
are encouraged to support this.

> Should be fairly easy for someone to look
> at our existing draft and come up with the couple of pages to add the
> required text and a proposal to do that and argue that specific case.
> Where I do not want to be with this project is refereeing a three
> cornered fight between the proponents of adding various other curves,
> those that want to minimize the number of curves for interoperability,
> and those still waiting for  the initial amendment to complete. There
> was a fair amount of proposed hostage taking first time round. Each
> specific curve proposal should stand or fall purely on its own merits,
> and that means taking them as separate items of projects and ruling out
> on-going horse-trading.

Yeah, CFRG had all the your-curve/my-curve fun a couple of years
back. But at least for IETF purposes I think that's all sorted
now and 25519 and 448 plus the legacy NIST curves are the ones,
and only ones, folks are looking at afaik. (Well, there's one
organisation who may still be holding out for other curves that
I can think of, but only one organisation.)

S.

> 
> Mick
> 
> 
> On 10/5/2016 1:21 PM, Stephen Farrell wrote:
>> Hiya,
>>
>>>>> Unsubscribe link:
>>>>> mailto:[email-masked]

---

From: "Brian Weis (bew)" <[email-masked]>
Date: Wed, 5 Oct 2016 22:02:21 +0000

Hi Stephen,

> On Oct 5, 2016, at 2:05 PM, Stephen Farrell <[email-masked]> wrote:
> 
> 
> Hiya,
> 

That is in fact the case.

There’s a fair resistance in IEEE 802.1 for optimistically adding support for cryptographic algorithms that are not actually likely to be implemented. This is due to the h/w cost of a device potentially having to implement each algorithm, which is a consideration we don’t often make when defining IANA namespaces for IETF protocols.  In the case of IEEE 802.1AR, we’re also expecting an uptick in support for device types used in multi-vendor environments. For example, see the ANIMA Bootstrapping (“BRSKI”) protocol, <https://tools.ietf.org/html/draft-ietf-anima-bootstrapping-keyinfra-03>), which is a zero-touch method enabling authorizing devices with an IEEE 802.1AR DevID sourced from a variety of manufacturers. One would not like to require a small single purpose device using this protocol to support a large set of public key validation methods in h/w because IEEE 802.1AR supported a large variety of algorithms. That would be a worry for this working group.

As I think was noted earlier in this threat, the current draft of P802.1ARce does make it easier to add new signature “cipher suites”, so at such time as there is a constituency needing 25519 (or other) curve the process for adding it should be straightforward.

Hope that helps,
Brian

-- 
Brian Weis
Security, CSG, Cisco Systems
Telephone: +1 408 526 4796
Email: [email-masked]

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 5 Oct 2016 23:11:30 +0100

Hi Brian,

> That is in fact the case.

Thanks - that makes the project sound reasonable. (Not ideal,
but quite reasonable:-)

S.

---

From: Pat Thaler <[email-masked]>
Date: Wed, 5 Oct 2016 15:29:31 -0700

The PAR does indicate that the need is adding SHA-384 and the P-384
elliptic curve plus general maintenance. See the Need for Project
description. Also, the Additional notes item covers the history that Mick
described. So I believe that the intent of the revision is adequately
described in the PAR.

It was my comment that initiated converting the project from an amendment
to a revision. I agree with Mick that there shouldn't be more change piled
on. We should finish bringing the base standard up to date and adding what
we chartered in the original amendment PAR given that it has a fairly
mature draft. Then any additional work can be considered for future
amendments.

Regards,
Pat

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 5 Oct 2016 23:40:05 +0100

On 05/10/16 23:38, Mick Seaman wrote:
> I think what is important here (given Stephen's last comment) is that
> the PAR does already explicitly mention Suite B under "5.5 Need for the
> Project".

Oh - sorry, I missed that! If I'd seen it I'd not have bothered
us all;-)

S.

> 
> Mick
> 
> 
> 
> On 10/5/2016 3:29 PM, Pat Thaler wrote:
>> description. Also, the Additional notes item covers the history that
>> Mick described. So I believe that the intent of the revision is
>> adequately described in the PAR.
>>
>> It was my comment that initiated converting the project from an
>> amendment to a revision. I agree with Mick that there shouldn't be
>> more change piled on. We should finish bringing the base standard up
>> to date and adding what we chartered in the original amendment PAR
>> given that it has a fairly mature draft. Then any additional work can
>> be considered for future amendments.
>>
>> Regards,
>> Pat
>>
>> On Wed, Oct 5, 2016 at 3:11 PM, Stephen Farrell
>> <[email-masked] <mailto:[email-masked]>> wrote:
>>
>>
>>     Hi Brian,
>>
>>     [email-masked] <mailto:[email-masked]>
>>     <https://www.ietf.org/mailman/listinfo/ieee-ietf-coord>
>>
>>
> 
>