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

["Brian Weis (bew)" <[e-mail]>]

Hi Stephen,

> On Oct 5, 2016, at 2:05 PM, Stephen Farrell <[e-mail]> wrote:
> 
> 
> 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.

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

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

-- 
Brian Weis
Security, CSG, Cisco Systems
Telephone: [phone]
Email: [e-mail]