Re: [Anima] Benjamin Kaduk's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT)

[Michael Richardson <[e-mail]>]

https://tinyurl.com/y2skc9xz

Benjamin Kaduk <[e-mail]> wrote:
    >> 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)

got them all now.

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

I have revised section 7.2.
My use of normative language seems inconsistent at this point.  I need to
distinguish between "X is possible" from "when doing X you MUST Y" better.

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

We have removed "ASCII, English), and left this as "UTF-8", with the
expectation that the message may be localized.  Emphasis is on human readable.

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

Changed.

--
Michael Richardson <[e-mail]>, Sandelman Software Works
 -= IPv6 IoT consulting =-