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

[Eliot Lear <[e-mail]>]

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