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

[Eliot Lear <[e-mail]>]

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
>