Subject: [OPSAWG] Fwd: New Version Notification for draft-lear-ietf-netmod-mud-02.txt

From: Eliot Lear <[email-masked]>
Date: Tue, 7 Jun 2016 10:36:23 +0200

Hi everyone,

There is a new version of draft-ietf-lear-netmod-mud out there.  In
discussions with various WG chairs it seems like the best approach is to
(a) consolidate the drafts a bit and (b) proceed in opsawg with this
work.  That is what this draft does.  Both the PKIX constraint and the
DHCP options are rolled in here.  In addition, several other changes
have been made, a full list of which can be found in the appendix.  Here
are few of the bigger ones (apart from the merge):

  * This version changes the serialization from XML to JSON.  Tooling is
    definitely going in the direction of JSON.  The initial reason for
    XML is that it is commonly used by routers.  We're pretty sure that
    on the whole, this stuff won't be directly consumed by routers, and
    those who do consume it can learn JSON ;-).  Thanks to Cullen
    Jennings for nudging in this direction.
  * We now include a signature mechanism for the MUD files.  It was
    always the plan to do this.  There were two choices: CMS/PKCS#7 or
    JWS.  Again for tooling's sake, so that people don't need to roll
    their own, especially for anything security related, we've gone with
    CMS and a detached signature at that.  Thanks to John Bashinsky and
    others for their advice on this.  This area in particular could
    stand close scrutiny.
  * Per a suggestion from Mark Nottingham, we are now registering a MIME
    application type.  That registration is included in the IANA
    considerations.
  * The constraint X.509 specification specification has changed
    somewhat based on advice from Tom Gindin.
  * We've included a small number of additional elements in the model,
    mostly around flow/packet directionality.

Comments and edits are very welcome!

Eliot

Subject: New Version Notification for draft-lear-ietf-netmod-mud-02.txt
From: <[email-masked]>
To: Eliot Lear <[email-masked]>, Ralph Droms <[email-masked]>
Date: Tue, 7 Jun 2016 01:25:00 -0700

A new version of I-D, draft-lear-ietf-netmod-mud-02.txt
has been successfully submitted by Eliot Lear and posted to the
IETF repository.

Name:		draft-lear-ietf-netmod-mud
Revision:	02
Title:		Manufacturer Usage Description Specification
Document date:	2016-06-07
Group:		Individual Submission
Pages:		21
URL:            https://www.ietf.org/internet-drafts/draft-lear-ietf-netmod-mud-02.txt
Status:         https://datatracker.ietf.org/doc/draft-lear-ietf-netmod-mud/
Htmlized:       https://tools.ietf.org/html/draft-lear-ietf-netmod-mud-02
Diff:           https://www.ietf.org/rfcdiff?url2=draft-lear-ietf-netmod-mud-02

Abstract:
   This memo specifies the necessary components to implement
   manufacturer usage descriptions (MUD).  This includes a YANG model,
   IPv4 and IPv6 DHCP options, a URL suffix specification, an X.509
   certificate extension and a means to sign and verify the
   descriptions.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Tue, 7 Jun 2016 17:32:18 +0000

> * We now include a signature mechanism for the MUD files.  It was always the
> plan to do this.  There were two choices: CMS/PKCS#7 or JWS.  Again for
> tooling's sake, so that people don't need to roll their own, especially for
> anything security related, we've gone with CMS and a detached signature at
> that.  Thanks to John Bashinsky and others for their advice on this.  This
> area in particular could stand close scrutiny.
Wouldn’t CMS still require serialization/canonicalization?

Tooling-wise, OpenSSL is indeed prevalent (and seems to do CMS quite well) –
but  JWS tools are around, so you wouldn’t need to roll your own if you
decided to go that way.

Do I need the ability to tell whether a MUD file was not signed or its
signature was deleted?

> Comments and edits are very welcome!

Have to settle for questions for now. :-)

---

From: Eliot Lear <[email-masked]>
Date: Tue, 7 Jun 2016 19:42:38 +0200

Hi Uri,

On 6/7/16 7:32 PM, Blumenthal, Uri - 0553 - MITLL wrote:
>
>       * We now include a signature mechanism for the MUD files.  It
>         was always the plan to do this.  There were two choices:
>         CMS/PKCS#7 or JWS.  Again for tooling's sake, so that people
>         don't need to roll their own, especially for anything security
>         related, we've gone with CMS and a detached signature at
>         that.  Thanks to John Bashinsky and others for their advice on
>         this.  This area in particular could stand close scrutiny.
>
Yes/No, depending on what you mean.  Currently we're treating the MUD
file as binary precisely to avoid canonicalization.  The transport for
all of this is HTTPS and UTF-8.
>
> Tooling-wise, OpenSSL is indeed prevalent (and seems to do CMS quite
> well) – but  JWS tools are around, so you wouldn’t need to roll your
> own if you decided to go that way.

I'm not saying there are no tools around, but I personally found slim
pickings in the form of various libraries.  If people think we should go
in a different direction...  The key here though is not whether I would
want to roll my own but whether others would be able to do the same. 
This is a pretty large uplift for some, and one goal is to make that as
painless as possible.

> Do I need the ability to tell whether a MUD file was not signed or its

The spec requires that all files be signed and that the signatures be
verified prior to processing.

And thanks for again for the comments.

Eliot