On Mon, Jun 04, 2018 at 07:50:47PM +0200, Eliot Lear wrote: > Ben, > > Barring any objections to the below I will issue a new draft with edits > tomorrow. Now please see below.
Okay, thanks. (I'm okay with leaving out the extra text about the file+signature being untrusted input until the signature is verifeid.) -Benjamin > 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: PGP signature
_______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
