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

[Jim Schaad <[e-mail]>]

A couple of answers from my own perspective

-----Original Message-----
From: Ace <[e-mail]> On Behalf Of Benjamin Kaduk
Sent: Wednesday, August 28, 2019 4:37 PM
To: [e-mail]
Cc: [e-mail]
Subject: [Ace] AD review of draft-ietf-ace-coap-est-12

Hi all,

A good number of comments here, though many are just nits.  We may need some
more in-depth discussion about only using certificates for client
authentication (immediately below) and how we discuss server-keygen.

Thanks,

Ben

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%


   When proof-of-possession is desired, a set of actions are required
   regarding the use of tls-unique, described in Section 3.5 in
   [RFC7030].  The tls-unique information consists of the contents of

I see the note in the shepherd writeup about converting EST to use TLS
exporters rather than tls-unique in a separate update document.  Where is
that work happening?  The discussion in Section 10.1 is helpful (and we
could do well to reference it from here) but does not inspire great
confidence in the reader that such work will come to fruition.
I think we also need to at least mandate extended-master-secret to be used
on the underlying DTLS connection.  (That is, assuming that we don't want to
lock down to specific, non-vulnerable, ciphersuites -- RFC 7925 only has
TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 as MTI, not MTU.)

[JLS]  If this work is going to happen it needs to be done as an update to
the EST RFC.  I don't know if it would be better to do that in LAMPS rather
than here.  Currently I do not know of anybody who is going to do this.
This is my issue and I am willing to let it slide for the time being.


   In the context of CoAP, the presence and location of (path to) the
   EST resources are discovered by sending a GET request to "/.well-
   known/core" including a resource type (RT) parameter with the value
   "ace.est*" [RFC6690].  The example below shows the discovery over

Is that a literal asterisk, for ace dot est star?
(1) Why?
(2) It probably merits a mention in the text to confirm it for the reader.

[JLS] This is standard CoAP searching with the "rt" parameter.  The start is
a) literal and b) means a wild chard with the expected meaning.  I don't
think that this needs any additional text.

It's a little unfortunate that we can only indicate ct=62 for the last two,
and there's no way to indicate what content types we expect within that
container.

[JLS] This was a big topic of discussion both in ace and more importantly in
core for the multipart content type.  If this is solved it should be solved
in CoRE and not here.  (I recognize from the text that you don't expect it
to be solved in this document.)


I can (grudgingly) accept that people are going to do server-side key
generation, so I do not propose to remove it from the document.  The policy
case is a clear example of why the feature needs to be available, but I'm
not 100% sure that I believe that server-keygen could be "more secure" given
that the client needs to be able to produce secure random numbers for DTLS
(though I do accept that some people will believe it to be so!).  It seems
likely to only be possible in some intermediate situation where the
client-generated random numbers could be attacked but at substantial
expense, such that paying that expense for a single handshake is "too much"
for the attacker to bear, but doing it for the key generation that would
give the attacker all transactions would make the expense worthwhile; this
intermediate situation seems to also be transitory, since attacks only get
better/cheaper.
For the other case, if we were doing RSA keygen, then going from random
numbers to prime generation could be enough incremental expense that
offloading to the server would make sense, but I didn't think the elliptic
curve stuff had the same kind of issues, so I'd like to hear more about the
resource-consumption aspect as well.

[JLS] I would disagree that there is any requirement for a client using
DTLS to have any type of secure random numbers to still get a secure
channel.  If you do PSK authentication, then it is not required.  The
"random numbers" in the protocol are not really random, this is really true
because they are public numbers, you would like them to be non-predictable
but I do not know that this is even a requirement.  The only question is how
much you want to avoid some type of static-ephemeral key agreement state
which looses the PFS but is still potentially not horrid to have.

   with other requests in the same DTLS connection SHOULD revalidate the
   server certificate chain against the updated Explicit TA from the
   /crts response before proceeding with the subsequent requests.  If
   the server certificate chain does not authenticate against the
   database, the client SHOULD close the connection without completing
   the rest of the requests.  The updated Explicit TA MUST continue to
   be used in new DTLS connections.

I'm not going to say you shouldn't do this check, but it seems pretty easy
for an attacker that knows it's servicing a /crts request to supply a
response that includes a (potentially bogus) trust anchor that can certify
the certificate it used for the current connection.  So it's not clear how
much protection this really provides.

[JLS] Right, of course the attacker that is going to do this needs to have
gotten a trusted channel set up initially to provide that (potentially
bogus) trust anchor over.  If you can do that then there is no longer any
trust in the system at all.

   As described in CMC, Section 6.7 of [RFC5272], "For keys that can be
   used as signature keys, signing the certification request with the
   private key serves as a POP on that key pair".  The inclusion of tls-
   unique in the certificate request links the proof-of-possession to
   the TLS proof-of-identity.  This implies but does not prove that only
   the authenticated client currently has access to the private key.

Do we want to further clarify that this means the PoP is weaker than it
could be?  ("no" is a fine answer, as always.)

[JLS] My response would be no.  I have spent hours describing the issues
that arise here without it always being clear that I have succeeded.  Trying
to do this in text and get the corner cases well described is extremely
difficult.


   It also assumes the Registrar has a trust relationship with the
   upstream EST server in order to act on behalf of the clients.  When a
   client uses the Implicit TA database for certificate validation, she
   SHOULD confirm if the server is acting as an RA by the presence of
   the id-kp-cmcRA EKU [RFC6402] in the server certificate.

Why is this only a SHOULD?

[JLS] Because it could be done by a different method.


Jim

_______________________________________________
Ace mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ace