Re: [Ace] AD review of draft-ietf-ace-coap-est-12 part 2

[Michael Richardson <[e-mail]>]

Peter van der Stok <[e-mail]> wrote:
    > ..... if the SignedData is not the outermost container, then we don't
    > care what the relevant Content-Format for it is; we only care about the
    > Content-Format for the EnvelopedData.

    > <pvds>

    > s/ SignedData is signed/SignedData, placed in the outermost container,
    > is signed/

    > s/ The SignedData is further protected by placing it inside of a CMS
    > EnvelopedData/

    > SignedData placed within the Enveloped Data does not need additional
    > signing/

    > </pvds>

    > Also, did we explicitly consider and reject AuthEnvelopedData?

    > <pvds>

    > Not sure about this

Jim Schaad <[e-mail]> wrote:
    > [JLS] As a CMS person, I would consider the use of EnvelopedData and
    > AuthEnvelopedData to be equivalent.  Which of these is used is totally
    > dependent on what algorithm is used for encryption.  If one requires
    > the use of AES-GCM or AES-CCM then one has no choice but to use
    > AuthEnvelopedData.  If one wants to use AES-CCM ten one has no choice
    > but to use EnvelopedData.  Everybody is slowly moving from
    > EnvelopedData to AuthEnvelopedData just because everybody is changing
    > algorithms.  I do not remember any discussions about this, but
    > AuthEnvelopeData is generally going to be the more correct value here.
    > I will also note that there is a space between Enveloped and Data which
    > is not CMS.
    > </pvds>

So, on a constrained device, I'd like to know what to expect (what to code
for).  While I do'nt particularly care for server-generated keys, it should
probably be specified correctly.  I see that the complexity of sorting this
means that I think that Content-Format 284 (unprotected) will get used most
often.

Is there a good reference that would let us rip out more of this paragraph?

    > This carefully says nothing about recommendations for use, only for
    > software support.  Are we letting 7030's recommendation for use of
    > encryption stand?  It's probably worth being explicit, either way.

Server-side key generation is optional, but when used, I agree that the
question of which mechanism the server should use to return the key is
completely open.   The client can indicate what it supports via CoAP Accept
"header".  https://datatracker.ietf.org/doc/draft-amsuess-core-accept-any/
might be useful here.

    > <pvds> I did not find any recommendation for use in RFC7030 apart the
    > responsibility of the server for generating random numbers. The
    > recommendations at the top of section 5.8 of the draft seem adequate in
    > my opinion. The alternative is classifying the applications; unless you
    > see a better way to do this.

    > </pvds>

    > Why OPTIONAL?  (Also, nit: OPTIONALLY isn't a 2119 keyword; only
    > OPTIONAL.)

    >    client.  For example, it could be configured to accept POP linking
    > information that does not match the current TLS session because the
    > authenticated EST client Registrar has verified this information when
    > acting as an EST server.

    > This is close enough to a literal quote that we might think about
    > actually quoting and using quotation marks.  nit: s/POP/PoP/ if we
    > don't do the literal quote.

    > <pvds>

    > Hope my co-authors will react to this

    > [JLS] I would disagree with the nit.

    > [JLS] I would agree with the nit on OPTIONALLY being wrong, but I think
    > that it ought to be at least a SHOULD if not a MUST for the use of
    > COAPS as it is terminating the connection.  The only exception would be
    > in there is internal authentication for the EST request.

    > </pvds>


Okay, I'm seeing three things here.
1) tls-unique can't be used across the proxy, and we need additional
   configuration.  I don't think we should quote literally, I think the
   point is to hammer the point home.

2) You are saying that we should replace tls-unique (RFC5929) with a TLS
   Exporter. But RFC7030 didn't reference RFC5705.
   You are suggesting that we update ourselves to use RFC5705.
   That would seem to require that we change some PKIX things in CSR.

3) I'm wondering if we need to have a clear response/error code for the case
   where the tls-unique does not match.  At least, from the HTTPS-EST
   server to the COAPS-EST "proxy" that might be valuable, even if the
   code it not sent back to the client.

    > Section 9.1

    > I think we probably need this document as a reference for all the
    > allocations; as the document effectuating the registration, we are
    > still of interest even if most details of content encoding lie
    > elsewhere.

    > [JLS] No response from Peter?

Is Ben suggesting that the table should say:

   +------------------------------+-------+----------------------------+
   | HTTP Media-Type              |    ID | Reference                  |
   +------------------------------+-------+----------------------------+
   | application/pkcs7-mime;      |   280 | [THISDOCUMENT]             |
   | smime-type=server-generated- |       |                            |
   | key                          |       |                            |
   | application/pkcs7-mime;      |   281 | [THISDOCUMENT]             |
   | smime-type=certs-only        |       |                            |
   | application/pkcs8            |   284 | [THISDOCUMENT]           - |
   |                              |       |                            |
   | application/csrattrs         |   285 | [THISDOCUMENT]             |
   | application/pkcs10           |   286 | [THISDOCUMENT]             |
   |                              |       |                            |
   | application/pkix-cert        | TBD28 | [THISDOCUMENT]             |
   |                              |     7 |                            |
   +------------------------------+-------+----------------------------+

And I guess rfc5751-bis is now RFC8551.

    > So I have to wonder if I'm messing something up, somewhere.

I see that Peter has posted new examples.

    > In the key-agreement case, the symmetric key-encryption key is the
    > result of the key-agreement operation, no?  In which case it is not
    > itself encrypted, but rather the server's ephemeral public value is
    > sent.

    > <pvds>

    > In RFC7030 the text says: the EnvelopedData content is encrypted using
    > a randomly

    > generated symmetric encryption key (that means ephemeral I assume). The
    > cryptographic strength of

    > the symmetric encryption key SHOULD be equivalent to the
    > clientspecified
    > asymmetric key.

    > However, I see no explicit relation with the ephemeral public value.

    pvds> I don't know what to do here; probably insert the 7030 text.

I not understand the question here.

    >    What's more, POP linking uses tls-unique as it is defined in
    > [RFC5929].  The 3SHAKE attack [tripleshake] poses a risk by allowing

    > nit: "such POP linking" or "the CMC POP linking"

    > <pvds>CMC POP </pvds>

    >    a man-in-the-middle to leverage session resumption and renegotiation
    > to inject himself between a client and server even when channel binding
    > is in use.  The attack was possible because of certain (D)TLS
    > implementation imperfections.  In the context of this specification,

    > I don't think we can solely blame the attacks on implementation
    > imperfections (though they were certainly compounding factors).  Does
    > this sentence really add any value to the current document?

    > <pvds>

    > Leave this to my co-authors

    > </pvds>

I think that 3SHAKE requires session resumption to be supported.
I'm not sure that using session resumption is the best thing in a constrained
client system.  I think that whenever we get to doing a new operation, that
we actually need a new session setup at that point anyway.

    >    binding mechanism.  Such a mechanism could include an updated tls-
    > unique value generation like the tls-unique-prf defined in
    > [I-D.josefsson-sasl-tls-cb] by using a TLS exporter [RFC5705] in TLS
    > 1.2 or TLS 1.3's updated exporter (Section 7.5 of [RFC8446]).  Such
    > mechanism has not been standardized yet.  Adopting a channel binding

    > We probably should be explicit about "using a TLS Exporter value in
    > place of the tls-unique value in the CSR", just from a writing clarity
    > perspective.

    > <pvds>

    > Leave to my co-authors from here to section 10.2

    > </pvds>

I think that we could go to TLS Exporter right now, but it would take some work.


    > Do we want to say anything about the IDevID in the CSR/cert?  I note
    > that the breakdown in Appendix C.2 (looks like openssl output) does not
    > decode the otherName (though asn1parse can be convinced to do so).

    > <pvds>

    > What do you suggest for IDevID?

    > Actually openssl was used extensively for generating the examples.

    > Will be happy to learn about otherName

    > </pvds>

there is a whole bunch of othername not supported.
asn1parse isn't terribly informative here, in my opinion.

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works        | network architect  [ 
]     [e-mail]  http://www.sandelman.ca/        |   ruby on rails    [