I've been told to resend this message due to a mailing list glitch. Please see below.
--- Begin Message ---Ben, Barring any objections to the below I will issue a new draft with edits tomorrow. Now please see below. On 04.06.18 17:40, Benjamin Kaduk wrote: > Hi Eliot, > > On Sat, Jun 02, 2018 at 03:40:34PM +0200, Eliot Lear wrote: >> This update contains only the following changes: >> >> * A correction (signature -> certificate) >> * Slightly change language to make clear that the certificate subject >> must be the sameas the id-pe-mudsigner >> * Updated dates on the YANG files >> >> At this point, I really hope we're done. Eric, Ben? > I think we're basically done -- I have just one quibble which > hopefully is not problematic, and also noted a handful of editorial > things you can deal with at your leisure. Thanks for going through > the multiple rounds of changes addressing our concerns -- the > document really is much better for it! > > At the start of the Security Considerations, we say: > > Based on how a MUD URL is emitted, a Thing may be able to lie about > what it is, thus gaining additional network access. This happens > when a device emits a MUD URL using DHCP or LLDP, and is either > inappropriately admitted to a class such as "same-manufacturer" or > given access to a device such as "my-controller", where such access > would otherwise be disallowed. > > To me, "[t]his happens when" indicates that the subsequent > enumeration is an exhaustive list. I don't really think we've got > enough experience with this stuff to be able to make such a claim, > and the list should instead be treated as illustrative. I think > that there was some text emailed around that did this nicely, > something like: > > % Based on how a MUD URL is emitted, a Thing may be able to lie about > % what it is, thus gaining additional network access. This can happen > % in a number of ways when a device emits a MUD URL using DHCP or > % LLDP, such as being inappropriately admitted to a class such as > % "same-manufacturer", given access to a device such as > % "my-controller", or being permitted access to an Internet resource, > % where such access would otherwise be disallowed. I think that's fine. > > > And, here's the editorial stuff. > > Section 1.5 > > o A DHCP option[RFC2131],[RFC3315] that the DHCP client uses to > inform the DHCP server. The DHCP server may take further actions, > such as act as the MUD manager or otherwise pass it along to the > MUD manager. > > nit: We lost the immediately previous "URL" that "it" referred to, so we > may want to specifically say "pass the MUD URL along". > > Section 13.2 > > Prior to processing the rest of a MUD file, the MUD manager MUST > retrieve the MUD signature file by retrieving the value of "mud- > signature" and validating the signature across the MUD file. The Key > Usage Extension in the signing certificate MUST have the bit > digitalSignature(0) set. > > nit: do we need to go with "MUST be present and have the bit > digitalsignature(0) set"? That is fine. > > The subject of this certificate MUST be > equal to that of the value of id-pe-mudsigner when that extension is > present in the device certificate. If these conditions are not met, > or if it cannot validate the chain of trust to a known trust anchor, > the MUD manager MUST cease processing the MUD file until an > administrator has given approval. > > nit-level as well, I guess: I might wordsmith this differently. > > NEW: > > When the id-pe-mudsigner extension is present in a device's X.509 > certificate, the MUD signature file MUST have been generated by > a certificate whose subject matches the contents of that > id-pe-mudsigner extension. If these conditions are not met, > or if it cannot validate the chain of trust to a known trust anchor, > the MUD manager MUST cease processing the MUD file until an > administrator has given approval. Ok. > > I might also consider adding something like the following (though > hopefully it would be obvious and thus not necessary to say): > > Before the signature has been validated, both the MUD file and > the resource retrived from the "mud-signature" URL are unverified > and should be treated as untrusted input. In particular, MUD > managers can impose a cap on the number of bytes they retrieve > from a "mud-signature" URL, to avoid DoS attacks involving > presenting a large (invalid) signature file or similar scenarios. I would rather leave this out for the very reasons you state. The draft is already quite wordy. > > Section 16 > > Implementations SHOULD be configurable to > disallow additive access for devices using MUD-URLs that not emitted > in a secure fashion such as in a certificate. > > nit: "that are not emitted". Ok > > When certificates are not present, Things claiming to be of a certain > manufacturer SHOULD NOT be included in that manufacturer grouping > without additional validation of some form. This will be relevant > when it makes use of primitives such as "manufacturer" for the > purpose of accessing Things of a particular type. > > What is "it" that makes use of primitives such as "manufacturer"? the MUD manager. > > [...] If the actual MUD file has changed, the MUD > manager MAY check the WHOIS database to see if registration ownership > of a domain has changed. > > Do we need a reference for WHOIS? I don't think so. RFC Editor will sort if so. > > Appendix C > > In this sample extension we augment the core MUD model to indicate > whether the device implements DETNET. If a device claims not to use > NETNET, but then later attempts to do so, a notification or exception > > That's also supposed to be 'D'ETNET, right? Indeed. Thanks. Eliot
signature.asc
Description: OpenPGP digital signature
--- End Message ---
signature.asc
Description: OpenPGP digital signature
_______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
