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

[Stephen Farrell <[e-mail]>]

Hiya,

On 05/10/16 19:14, Mick Seaman wrote:
> 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 ..".

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.

> 
> This resulted in a much longer project than desirable given the pressing
> 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
> 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'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;-)

> 
> 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.

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.



> 
> Mick Seaman
> 
> Chair, IEEE 802.1 Security Task Group
> 
> 
> On 10/5/2016 3:22 AM, Stephen Farrell wrote:
>> Hiya,
>>
>> On 05/10/16 10:48, Dan Romascanu wrote:
>>> 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.
>> 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.
>>
>>
>>> Thanks and Regards,
>>>
>>> Dan
>>>
>>> ---------- Forwarded message ----------
>>> From: Glenn Parsons <[e-mail]>
>>> 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: [e-mail]
>>>
>>>
>>> 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
>>> [e-mail]<mailto:[e-mail]>
>>> [phone]
>>>
>>>
>>>
>>> ===
>>> Unsubscribe link: mailto:[e-mail]
>>> IEEE. Fostering technological innovation and excellence for the
>>> benefit of
>>> humanity.
>>>
>>>
>>>
>>> _______________________________________________
>>> ieee-ietf-coord mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/ieee-ietf-coord
>>>
> 
> _______________________________________________
> ieee-ietf-coord mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ieee-ietf-coord