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

[Michael Richardson <[e-mail]>]

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

    > Your constrained device is probably only going to implement one cipher
    > [mode], too, right?  If it's an AEAD mode, you use AuthEnvelopedData;
    > otherwise, classic EnvelopedData.

Yes, but each constrained device type might have a different set, and the EST
server for such an installation has to figure out how to send the right thing.

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

    > From a crypto perspective, we should do that.  From a
    > protocol-specification perspective, we should retain parity with
    > classic EST and only update when it does.  So we should probably mostly
    > ignore this other than trying to kick off work on classic EST, and
    > mandating extended-master-secret.

okay, good.

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

    > [I didn't think much about whether this would give an attacker leverage
    > from which to execute new attacks]

An HTTPS-EST server that responses to the COAPS-EST with such an error is
probably mis-configured for that end point.  It probably does not believe
that the CoAPS-EST proxy is authorized to speak for the end point.
Both are already trusted.

The end point is probably already also trusted btw.  The major use case that
we had for server-generating keys is for updating keys for existing
installations.  Such as moving from 10yr old 1024RSA keys that were manually
deployed (at the factory) to 256bit ECDSA keys, etc.

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

    > No, I was thinking we should add "[THISDOCUMENT]" to the existing
    > entries, not replace them.

got it.

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

    > Hmm, but we perhaps cannot guarantee that this will hold universally
    > for all devices implementing coap-est.  I do think that we can mandate
    > other aspects that make 3SHAKE impossible (like
    > extended-master-secret), though.

okay.

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

    > I'd rather have both classic-EST and coap-EST benefit than just
    > coap-EST.

So you'd agree to deferring this to a document (maybe in LAMPS?) that would
Updates: 7030 and this document.

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