On Tue, Jul 16, 2019 at 06:14:37PM -0400, Michael Richardson wrote: > > I have responded to DISCUSSes from: > Alissa Cooper: > https://mailarchive.ietf.org/arch/msg/anima/QZn8UnsNxtE3MCHm_gPVBl5uSrU > Roman Danyli: > https://mailarchive.ietf.org/arch/msg/anima/mff9ZyGBk4EflTqYS6fENWOFRpI > Alexey Melnikov > https://mailarchive.ietf.org/arch/msg/anima/Ul0yfnf4UlQhoI0UtlJVZ9otY7M > Adam Roach: > https://mailarchive.ietf.org/arch/msg/anima/6AAD9mwsKEsbIUmXRVOAV0N83yA > Eric Vyncke: > https://mailarchive.ietf.org/arch/msg/anima/O860UBbY4p3iNOZUdEYF_iNKMvs > > plus comments: > Mirja Kühlewind > https://mailarchive.ietf.org/arch/msg/anima/jFuz6ugS-_1bf0HG46vMjf3UNaw > Magnus Westlund: > https://mailarchive.ietf.org/arch/msg/anima/g1c17bHiBUMuhCmw4RDoHoN_1zE > and noted comments from Barry and Warren. > > and this is for Ben Kaduk's DISCUSS, which got buried, and I think is the > last.
(You can always consult the datatracker page, too: https://datatracker.ietf.org/doc/draft-ietf-anima-bootstrapping-keyinfra/ballot/ I guess there's a couple No Objection with COMMENT that aren't mentioned above but maybe not that need replies.) > I'm going to use this email to deal with Ben's comments which I think we > already dealt with other edits, then I'll deal with low-hanging fruit, and > then decide how to deal with the desire for a high-level security analysis. > > Benjamin Kaduk via Datatracker <nore...@ietf.org> wrote: > > (5) RFC7951 is cited for the audit log response, but I cannot find the > > underlying YANG module that is JSON-encoded using the RFC 7951 > > procedures. Furthermore, I don't think the "nonce" handling (with > > explicit "NULL" string where base64-encoded binary data might be > > expected) would be consistent with the 7951 rules. > > We did not resort to a YANG data model for the auditlog responses, so I spent > a few minutes mystified by your complaint... then: > We referenced 7951 (YANG->JSON), but we should have just referenced RFC7159 > (JSON)! Oh! That would make a lot more sense... (but 7159 is obsoleted by 8259, of course) > (Those numbers are annoyingly similar. And we actually made this mistake > before, I wonder if this was collatoral damage from a global search and > replace) > > > (6) In Section 7.2: > > > The pledge can choose to accept vouchers using less secure methods. > > These methods enable offline and emergency (touch based) deployment use > > cases: > > > 1. The pledge MUST accept nonceless vouchers. This allows for a > > use > > > It's very unclear to me what this "MUST" means, especially so given > > that the entire section 7 is declared to be non-normative. Is it that > > the client "can choose" whether it "MUST accept nonceless vouchers"? > > That would seem to make the MUST basically ineffective. > > > > > > More broadly, if the entire Section 6 is non-normative, why is there > > any normative language in it? > > First, I think you mean section 7? I think you're right and that was a typo; sorry. > If so, the reason for normative language is because, we want to say, "if you > do X, then you MUST do it this way". > > Second, we have referenced some pieces of section 7.2 from section 9. > We think that there are significant security issues by accepting nonceless > vouchers, which we discuss in 11.1. A variation of the protocol is when > the manufacturer programs the pledge to ALWAYS accept nonceless vouchers. > There could otherwise be some more complex (proprietary, or documented later > on) evaluation of whether to accept a nonceless voucher. For instance, the > MASA could sign them with a different key, perhaps one stored in an HSM. Okay, so it is that the client (well, manufacturer?) chooses whether or not to accept nonceless vouchers. So we could change the introduction to the enumerated list to be saying that this is a list of exclusive candidate behaviors that could be chosen independently of each other, and not a collection of behaviors all of which are expected to be implemented. > A key point is that the Manufacturer/MASA knows exactly the rules that the > Pledge has been coded to, and we don't need to agree on all these rules to > get interoperability. Originally, we didn't even think we needed to > standardize the voucher, just the voucher-request; but it was the desire to > audit them on the Registrar that changed our mind. > > > (7) the new /enrollstatus and /voucher_status well-known EST endpoints > > are not registered in Section 8.1 > > Good catch, we have since been told by the .well-known designated expert that > either we create a new registry, or we just ask IANA to point the "est" > definition at RFC7030 and this document. Most .well-known entries do not > have registries. > > I haven't heard a clear opinion as to which we should do. I haven't, either, but if we do need an explicit list, we can remebmer to include these as well. > > (7.1) I think we also need to register the > > "urn:ietf:params:xml:ns:yang:ietf-mud-brski-masa" XML namespace. > > added. > > > (8) The versioning mechanism for Pledge BRSKI Status Telemetry is > > underspecified, including the interaction with new registered values. > > This was updated based upon comments from Adam. > > > (9) The versioning mechainsm for the MASA audit log response is > > underspecified, including whether a registry of field names is > > appropriate. > > This was updated based upon comments from Adam. (I didn't get to read the other ballot positions before submitting mine, so this is great to see.) > > (10) The term PKIX seems to be incorrectly used a few times; it refers > > to the Internet PKI, and so things like a private PKI internal to a > > manufacturer would probably not be best described as such. Such > > private PKIs can of course still reuse the protocols and mechanisms > > developed for PKIX, and it's accurate to describe them as such. > > I would never call the Internet PKI "PKIX". > I'd call it WebPKI, or CAB. > PKIX is the set of IETF specifications that made X509v3 useful. > (And why I try never to use "X509"...) > > I couldn't find a reference to private PKI, so maybe I mis-understand. This document details protocols and messages to answer the above questions. It uses a TLS connection and an PKIX (X.509v3) certificate (an IEEE 802.1AR [IDevID] LDevID) of the pledge to answer points 1 and 2. It uses a new artifact called a "voucher" that the [...] Pledge authentication and pledge voucher-request signing is via a PKIX certificate installed during the manufacturing process. This is The comment about private PKI was me making an assumption; I could be wrong. But I don't really expect all manufacturers that do this to have their IDevID signing CA be part of the Internet PKI; I expect them to be standalone CAs with the root baked into hardware and nothing else that uses that root. Does that help clarify? > > (11) In a few places we describe the voucher-request in terms of its > > YANG structure but do not say that it has to be wrapped in a signed CMS > > object as is done for the RFC 8366 voucher. > > I will review this; previous versions (prior to ~20) provided for both signed > and unsigned voucher requests, and we removed this feature. > I added some phrases to sentences in section 3: > > <t> > - A pledge forms the "pledge voucher-request" and submits it to the > - registrar. > + A pledge forms the "pledge voucher-request", signs it with it's > + IDevID and submits it to the registrar. > </t> > > <t> > - The registrar in turn forms the "registrar voucher-request", and > - submits it to the MASA. > + The registrar in turn forms the "registrar voucher-request", > + signs it with it's Registrar keypair and submits it to the MASA. > </t> Thanks. I was actually really confused about this for a while until I went back to look at 8366. > > (12) Maybe this is a "discuss discuss", but why do we need SHA-1 in the > > domainID calculation? > > What we really want is a hash of the registrar's key/cert. > We don't want to list it literally in the auditlog as it divulges too much. > We just want the RFC5280 Subject Key Identifier (4.2.1.2), but since both > the Registrar and the MASA need to calculate this value, we had to be > specific as to how it is done. If there is a better reference with better > agility, please let us know. > If the Registrar could be depended upon to always provide the extension, then > we could use the extension contents directly. It sounds like you don't want to try to require that the registrar do so, though (which would probably be fine from my point of view). I note that 5280 says "other methods of generating unique numbers are also acceptable"; even replacing SHA-1 with SHA-256 in that construction would be an improvement, from my point of view. Do we think that retaining consistency with the 5280 algorithm would (e.g.) help facilitate implementation or some other concrete benefit? I don't think that just compatibility for the sake of compatibility is a strong justification for using SHA-1 at this point. > > (13) In Section 5.5.1: > > > As described in [RFC8366] vouchers are normally short lived to avoid > > revocation issues. If the request is for a previous (expired) voucher > > using the same registrar then the request for a renewed voucher SHOULD > > be automatically authorized. The MASA has sufficient > > > I don't understand what "for a previous (expired) voucher" means. Is > > it something like "containing the same content as a previous voucher > > request for which a voucher was issued", with the presumption that the > > voucher expired before the pledge could successfully imprint, so it > > needs to try again? Or does this extend to longer timescales, like a > > device that gets deployed for a couple years and is then reset to > > factory settings and has to rebootstrap but is still by the same > > registrar? > > It is intended for both uses. > Either to be able to easily extend a short-lived voucher, or to get another > one years later. The MASA does not need to actually use the included > history; it can ignore it completely and make an entirely new decision. Hmm, okay. I still think that the grammar just doesn't like up about a "request for" a "previous voucher" means, so hopefully you can come up with some different text. I don't think I have a good enough picture to do so myself, unfortunately. > > (14) In Section 5.6: > > > The server MUST answer with a suitable 4xx > > or 5xx HTTP [RFC2616] error code when a problem occurs. In this case, > > the response data from the MASA MUST be a plaintext human- readable > > (ASCII, English) error message containing explanatory information > > describing why the request was rejected. > > > It seems hard to support this stance on internationalization in 2019. > > We don't believe that this response will go anywhere other than logs, > for software suppliers to evaluate. Localizing these error message causes > more problems in my experience than benefit. 90% of the information is in > the 4xx/5xx code. I should probably defer to my ART-area colleagues here. But you're saying that mandating English is better than allowing UTF-8 and otherwise leaving it as implementation defined? > > (15) In Section 5.9.4: > > > To indicate successful enrollment the client SHOULD re-negotiate the > > EST TLS session using the newly obtained credentials. This occurs by > > the client initiating a new TLS ClientHello message on the existing TLS > > connection. The client MAY simply close the old TLS session and start > > a new one. The server MUST support either model. > > > Is this supposed to be sending a new TLS ClientHello in the application > > data channel or as a new handshake message (aka "renegotiation")? The > > latter is not possible in TLS 1.3 and is generally disrecommended > > anyways even in TLS 1.2. I would strongly suggest to remove the > > "renegotiation" option and just leave "close the connection and start a > > new connection/handshake". > > Okay, fixed to say: > > <t>To indicate successful enrollment the client SHOULD re-negotiate > the EST TLS session using the newly obtained credentials. This > - occurs by the client initiating a new TLS ClientHello message on > the > - existing TLS connection. The client MAY simply close the old TLS > - session and start a new one. The server MUST support either > + occurs by the client closing the existing TLS connection, and > + starting a new one. The server MUST support either > model.</t> I'd prefer to s/re-negotiate/re-establish/ as well, but this is probably good enough to clear the discuss. > > Appendix C > > > I don't know how important file "ietf-mud-extens...@2018-02-14.yang" > > is, but it seems a tad generic. > > I changed ietf-mud-extension to ietf-mud-brski-masaurl-extension. > > > Appendix D > > > [Just checking that Michael wants sandelman.ca embedded in the final > > RFC] > > I don't have a problem with it. There is an error: > 3726:d=9 hl=2 l= 55 prim: UTF8STRING :#<SystemVariable:0x00000 > > where a variable name rather than it's value went into a certificate, and I > will probably re-run it again before AUTH48. We haven't gotten 100% > interoperability proven yet inside FairHair Alliance, so I can't be sure it's > all correct. Okay, that sounds fine to me. > I'll stop here, and continue in a new email. Sure; more smaller mails is probably easier all around. -Ben _______________________________________________ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
