Re: [OPSAWG] Deb Cooley's Discuss on draft-ietf-opsawg-mud-acceptable-urls-11: (with DISCUSS and COMMENT)

[Deb Cooley <[e-mail]>]

Thanks for that.  I look forward to reading the revision.

RFC 8520, if only....  [I do get tired of people running up 'oh my, oh my,
oh my, our certificates have been exposed!!'.   My reply is usally 'so
what?']  It is a common mistake, and probably pedantic on my part.  But PKI
is complicated, and hard to understand.  LOL

Deb

On Sat, Apr 13, 2024 at 9:42 AM Eliot Lear <[e-mail]> wrote:

> Hi Deb,
>
> Taking both your messages into account, I agree that we should retitle
> Section 3 and make clear that we are discussing risks.  I also agree that
> we should clearly reference 802.1AR, and that we state it's limitations.
> In brief, 802.1AR specifies the form of the Subject, the crypto to be used,
> and which extensions are required.  These sorts of profiles for IOT are
> pretty common.  I also agree that we should take care to separate certs and
> keys in our language.  I wish you had been available to do the 8520 review
> ;-)
>
> Thanks,
>
>
>
> On 13.04.2024 15:26, Deb Cooley wrote:
>
> Thanks for the site config fix.
>
> 802.1AR you say?  No mention of 802.1 in the draft at all.  If the PKI
> rules are different in 802, seems like that would be good to at least
> mention.  At least distinguish whether we are talking about L2 or L3 (or
> app layer - wherever HTTPS lives)
>
> Deb
>
> On Thu, Apr 4, 2024 at 8:26 AM Eliot Lear <[e-mail]> wrote:
>
>> Hi Deb,
>>
>> On 04.04.2024 13:45, Deb Cooley via Datatracker wrote:
>> >
>> > Shepherd writeup:  It would be nice to enumerate the manufacturers that
>> have
>> > implemented this concept.  The link to 'https://mudmaker.org' causes
>> my browser
>> > to throw big flashy warning signs.  When I click through them, it tells
>> me to
>> > 'GO AWAY'.  fun...
>>
>> Hi Deb.  There was a config error on a server.  It's fixed. Thanks for
>> pointing it out.
>>
>>
>> > Section 3.1 upgrade causes vulnerabilities:  One would think that this
>> > situation should be avoided at all costs.  There could be a way for the
>> device
>> > to signal which version of F/W it is running, allowing the MUD file to
>> be
>> > tailored.
>>
>> This may or may not be possible.  It depends on how the MUD URL is
>> communicated.  If it's communicated in a certificate, then the cert
>> would have to change, and as 802.1AR makes clear, that's not supposed to
>> happen.  I hold out hope that SUIT will provide a better path here, but
>> these are still early days.
>>
>> I should point out that in the vast majority of cases, a MUD URL rarely
>> has to change because you can have a superset of access that won't be at
>> all harmful (a good example would be adding a new new endpoint that is
>> used by new versions).  The corner case is primarily about services
>> being turned off.
>>
>> >
>> > Section 3.2:  The same applies for this section as well.  False
>> positives can
>> > be just as dangerous (because they bury the real positives).
>> >
>> > Section 4:  Updating IDevID URLs can't be updated with a F/W update?
>> F/W
>> > updates are signed by the manufacturer's signing key, correct?
>>
>> See above.  Not permitted by 802.1AR.  But there may be a more SUITable
>> fix over time.
>>
>> I'll leave the the rest to Michael.
>>
>> Eliot
>>
>> >
>> > Section 4.2:  Just how hard would it be to specify the CA certificate
>> paired
>> > with a subject name (subject alt name, or CN)?  Seems like this is more
>> secure
>> > than your proposed methods.  Oddly enough, Section 5.1 proposes this.
>> >
>> > Section 5, last para:  Instead of subject names, SKI should be used
>> [RFC5280,
>> > section 4.2.1.2].  This can be easily checked in a certificate validate
>> that is
>> > presented.
>> >
>> > Section 5.2:  Can't this be used all the time?
>> >
>> > Section 5.3.3:  Classically to change a 'root' one signs the new with
>> the old
>> > and signs the old with the new.  If it is done this way, I suspect one
>> could
>> > change whatever names, CAs one needs to change.
>> >
>> > Section 7:  One might argue that the use of server authenticated TLS
>> might
>> > mitigate a bunch of concerns.
>> >
>> > Section 9.  This is confusing. Please seperate the before issues and
>> the after
>> > issues into seperate sections (at least). There are many potential
>> > vulnerabilities listed earlier in the draft.  Please consolidate those
>> here
>> > (possibly with draft section links to where the mitigation is
>> suggested).
>> >
>> >
>> > ----------------------------------------------------------------------
>> > COMMENT:
>> > ----------------------------------------------------------------------
>> >
>> >
>> > Nits:
>> > Section 1, para 6: change 'check the signatures, rejecting files whose
>> > signatures do not match' to '... whose signatures do not validate'.
>> Using
>> > language like 'match' leads to bad behavior, when the entity should be
>> taking a
>> > positive action to validate the signature.
>> >
>> > Section 9, last sentence:  jargon?  I'm not sure I know what this
>> means, and
>> > English is my (only) language.
>> >
>> >
>> >
>> > _______________________________________________
>> > OPSAWG mailing list
>> > [e-mail]
>> > https://www.ietf.org/mailman/listinfo/opsawg
>> >
>>
>