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

From: Benjamin Kaduk <[email-masked]>
Date: Sun, 1 Sep 2019 15:43:40 -0500

I'll try to respond to Peter and Jim in one go.

On Fri, Aug 30, 2019 at 01:12:46PM +0200, Peter van der Stok wrote:
> HI Jim and Ben,
> 
> Ben, many thanks for a nice and elaborate  review of the draft.
> 
> beginning next week I will provide partial answers to the review.
> Some small remarks below to the much appreciated explanations by Jim.
> 
> An initial answer to the first point precedes the answers by Jim.
> 
> cheerio,
> 
> Peter
> _____________________________________________________________
> 
> Section 2
> 
>    This document also profiles the use of EST to only support
>    certificate-based client authentication.  HTTP Basic or Digest
>    authentication (as described in Section 3.2.3 of [RFC7030]) are not
>    supported.
> 
> Is the intent just to exclude HTTP-layer authentication, or to
> specifically prefer client certificate authentication?  7030 does allow
> for non-certificate TLS-layer authentication (e.g., TLS-SRP), which
> would be compatible with DTLS just fine.  There's also recurrent talk of
> getting modern PAKE(s) integrated with TLS, which might also be an
> option in the constrained space.
> [There are subsequent parts of the document that continue to assume
> only-certificates, so I'm mostly assuming that the intent is
> specifically to prefer client certificates, and have not made specific
> notes at those other places in the document.]
> 
> <pvds>
> client certificate authentication is preferred based on the following
> history:
> est_coaps was initially written as extension to anima BRSKI for small
> devices.
> In that context the only reasonable use case is client certificate
> authentication.
> In a later stage a wider audience of the document was identified beyond
> BRSKI also with a certificate authentication use case.
> The draft is limited to the certificate authentication, other
> authentications are not considered.
> I am not sure if this falls under preference of certificate
> authentication or exclusion of http layer authentication.
> If http layer authentication is wanted, my suggestion is that another
> document specifies this. This draft does not forbid the use of http
> layer authentication.
> Did I interpret your remark as you intended?
> </pvds>

Thanks for the extra background; it seems that there's reasonable
justification for the preference for certificate authentication; if a
TLS-layer password-based use case does arise, it should be possible to
write a companion document.

> Jim Schaad schreef op 2019-08-30 01:15:
> 
> > A couple of answers from my own perspective
> > 
> > -----Original Message-----
> > From: Ace <[email-masked]> On Behalf Of Benjamin Kaduk
> > Sent: Wednesday, August 28, 2019 4:37 PM
> > To: [email-masked]
> > Cc: [email-masked]
> > 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.
> > 
> > <pvds> I am happy with an update to LAMPS </pvds>

I don't think we'd want to do it in ACE, so LAMPS is a likely home (note
that I haven't checked with Roman).

> > 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.
> > <pvds> agree; new text will look much like repetition of text in other documents </pvds>

Okay, that's good to know.  I should probably read up on it a bit more...

> > 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.)
> > <pvds> finding the other ct's means parsing the CBOR content</pvds>

Agreed on all counts.

> > 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.
> > <pvds> I would prefer my co-authors to react to this aspect </pvds>

(To be clear, I'm asking for a bit of email discussion here, and not
necessarily any changes to the text.  Hearing Jim's thoughts is helpful,
but should not preclude others from chiming in as well.)

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

Okay.  (And thank you for having spent the time trying!)

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

Ah, it is supposed to be a "SHOULD do it this way", not "SHOULD check"; I
may have misread it.  I don't have any alternative phrasings that aren't
more words, so it's unclear if we want to make a change.  ("When a client
uses the Implicit TA database for certificate validation, she needs to know
whether the server is acting as an RA; she SHOULD confirm this by checking
for the presence of the id-kp-cmcRA EKU [RFC6402] in the server
certificate" would be one such longer alternative.)

Thanks,

Ben

---

From: Peter van der Stok <[email-masked]>
Date: Mon, 02 Sep 2019 14:47:10 +0200

Hi Ben,

Below some additional reactions to your review.
In some parts the term "suggest" is used, meaning that I am not sure of
the correctness of my reaction.
A confirmation/denial would be appreciated in those cases.
My co-authors can always improve my changes.

To-morrow I hope to do the follow-up.

many thanks,

peter

________________________________________________________________

Section 4

   As per sections 3.3 and 4.4 of [RFC7925], the mandatory cipher suite

nit: I do see RFC 7925 in the subject heading, but the lead-in here is
still a bit jarring.  Without some statement in this document to that
effect, RFC 7925 is not binding on the protocol specified in this
document, so I think it's better to say something like "In accordance
with", or even to flat out state that "this document conforms to the
DTLS 1.2 profile specified in RFC 7925". 

<pvds> done, used: In accordance with sections …  </pvds>

   DTLS 1.2 implementations must use the Supported Elliptic Curves and
   Supported Point Formats Extensions in [RFC8422].  Uncompressed point
   format must also be supported.  DTLS 1.3 [I-D.ietf-tls-dtls13]
   implementations differ from DTLS 1.2 because they do not support
   point format negotiation in favor of a single point format for each
   curve.  Thus, support for DTLS 1.3 does not mandate point format
   extensions and negotiation.

DTLS 1.3 uses the "supported_groups" extension in contrast to Supported
Elliptic Curves for 1.2; we should mention that disparity as well. 

<pvds> added at the end of the paragraph </pvds> 

   o  a previously issued client certificate (e.g., an existing
      certificate issued by the EST CA); this could be a common case for
      simple re-enrollment of clients.

Is "re-enrollment" intended to cover renewal operations? 

<pvds>RFC7030 states: "An EST client can renew/rekey its existing client
certificate by 

submitting a re-enrollment request to an EST server."

Do you want that emphasized more in the draft?
</pvds>

   o  a previously installed certificate (e.g., manufacturer IDevID
      [ieee802.1ar] or a certificate issued by some other party); the
      server is expected to trust that certificate.  IDevID's are

"trust" can cover a lot of things, many of which we don't really need
here; would "expected to be able to validate" suffice? 

<pvds> s/is expected to trust that certificate/ can use the certificate
for DTLS client Authentication/
</pvds>

   As described in Section 2.1 of [RFC5272] proof-of-identity refers to
   a value that can be used to prove that the private key corresponding
   to the public key is in the possession of and can be used by an end-
   entity or client.  Additionally, channel-binding information can link

nit: "the certified public key", I think, since the certificate is what
binds the identity to the public key.
Also, this sentence is a bit awkward, though I don't have any concrete
rewording suggestions at present. 

<pvds>s/public key/certified public key/ 

Suggestion, is this better?: "a client provides proof of identity by
proving that it possesses the private key corresponding with the
certified public key" 

   Given that after a successful enrollment, it is more likely that a
   new EST transaction will take place after a significant amount of
   time, the DTLS connections SHOULD only be kept alive for EST messages
   that are relatively close to each other.  In some cases, like NAT
   rebinding, keeping the state of a connection is not possible when
   devices sleep for extended periods of time.  In such occasions,
   [I-D.ietf-tls-dtls-connection-id] negotiates a connection ID that can
   eliminate the need for new handshake and its additional cost.

Do we also want to mention DTLS 1.3 session resumption here as less
expensive than a full handshake?  It's not as cheap as "just keep using
the same connection ID", of course, but has somewhat different other
properties. 

<pvds> thanks, added: 

"additional cost; or DTLS 1.3 session resumption provides a less costly
alternative than re-doing a full DTLS handshake."
</pvds>

Section 5

   o  Simple enroll and re-enroll for a CA to sign public client
      identity key.

nit(?): is this "public client identity key" or "client identity public
key" or something else? 

<pvds>by reducing the txt's target, I suggest: 

s/public client identity key/client certificate/ 

</pvds>

   o  Certificate Signing Request (CSR) attribute messages that inform
      the client of the fields to include in a CSR.

nit: "informs" 

<pvds> yep, thanks </pvds>

   o  Server-side key generation messages to provide a private client
      identity key when the client choses so.

(similar nit(?) as above) 

<pvds>also reducing the text's target: 

s/provide a private client identity key/provide the client with a new
private key/ 

</pvds>

Section 5.1

With the current text, I expect us to get several IESG questions about
"why do you have both discovery and well-known URIs?".  I think we need
to treat this more prominently in the first few paragraphs of the
section, perhaps just after we discuss the short-est strings, so we
could tie into the constrained nature of things and how some devices may
need to hardcode assumptions about the endpoint location. 

<pvds> I suggest the following starting text: 

"EST-coaps is targeted for low-resource networks with small packets. Two
types of installations are possible (1)rigid ones where the address and
the supported functions of the EST server(s) are known, and (2) flexible
one where the EST server and it supported functions need to be
discovered. 

For both types of installations, saving header space….."

</pvds>

   Figure 5 in Section 3.2.2 of [RFC7030] enumerates the operations and
   corresponding paths which are supported by EST.  Table 1 provides the
   mapping from the EST URI path to the shorter EST-coaps URI path.

Our table has the entries in a different order than 7030's table. 

<pvds> correct, has been modified </pvds> 

We also don't say anything about the (lack of the) fullcmc endpoint. 

<pvds>/fullcmc is added in the table with "n.a." as short value </pvds> 

The serverkeygen endpoints could perhaps have some notation to indicate
that the private key is always returned, in addition to the PKCS#7 vs.
pkix-cert question that distinguishes skg and skc. 

<pvds>after "…..an /skc request.", the following text is added: 

"In both cases a private key MUST be returned." 

</pvds>

   The /skg message is the EST /serverkeygen equivalent where the client
   requests for a certificate in PKCS#7 format and a private key.  If

nit: s/requests for a/requests a/ 

<pvds>done</pvds>

   Clients and servers MUST support the short resource EST-coaps URIs.

Are they expected to also support the long EST URIs over CoAP? 

<pvds> It was undecided whether we should add: 

"The corresponding longer URIs from <xref target="RFC7030"/> MAY be
supported." 

</pvds> 

  The first three lines of the discovery response above MUST be
   returned if the server supports resource discovery.  The last three

It may be worth listing out ace.est.crts, ace.est.sen, and ace.est.sren
explicitly for clarity (especially since line breaks are "only for
readability") 

<pvds> after "the first three lines" added 

",describing ace.est.crts, ace.est.sen, and ace.est.sren,"
</pvds>

   lines are only included if the corresponding EST functions are
   implemented.  The Content-Formats in the response allow the client to
   request one that is supported by the server.  These are the values
   that would be sent in the client request with an Accept option.

It seems that these specific values (or a subset thereof) are mandatory;
a forward reference might be in order. 

<pvds> "Added : "(see table 2)"

Section 5.2

Did we consider merging this table with Table 1? 

<pvds> 

The functions of the tables are different. It fits the progress of the
text. Merging will probably mean more forward references. Unless two
tables are too boring, I suggest to leave as is. 

</pvds>

Section 5.2

   While [RFC7030] permits a number of these functions to be used
   without authentication, this specification requires that the client
   MUST be authenticated for all functions.

Perhaps this divergence from 7030 should be noted more prominently,
perhaps in the section title or a dedicated "Differences from RFC 7030"
section? 

<pvds> 

Suggestion to move this phrase to section 5 just before section 5.1? 

</pvds>

Section 5.3

   EST-coaps is designed for low-resource devices and hence does not
   need to send Base64-encoded data.  Simple binary is more efficient
   (30% smaller payload) and well supported by CoAP.  Thus, the payload
   for a given Media-Type follows the ASN.1 structure of the Media-Type
   and is transported in binary format.

This last sentence is only true when scoped to this document, for which
all the content we're handling is specified using ASN.1.  I don't know
whether we want to tweak the wording to reflect that or not, though.
Also, we probably should say DER-encoded ASN.1 structure (or BER?  I'd
have to check what the requirements are) since ASN.1 is just the
abstract syntax and not the encoding rules. 

<pvds> 

s/payload/payload for DER-encoded ASN.1/
</pvds>

   When the client makes an /skc request the certificate returned with
   the private key is a single X.509 certificate (not a PKCS#7
   container) with Content-Format identifier TBD287 (0x011F) instead of
   281.  In cases where the private key is encrypted with CMS (as
   explained in Section 5.8) the Content-Format identifier is 280
   (0x0118) instead of 284.  The key and certificate representations are
   ASN.1 encoded in binary format.  An example is shown in Appendix A.3.

I think these relationships might be more clear in tabular form; I
dind't really understand the scheme at this point in the document, and
needed to get a ways further in before it really "clicked". 

<pvds> the following table is added. Is that sufficient?

             +----------+-----------------+-----------------+ 

             | Function | Response part 1 | Response part 2 | 

             +----------+-----------------+-----------------+ 

             | /skg       | 284                 | 281                | 

             | /skc       | 280                 | TBD287          | 

             +----------+-----------------+-----------------+ 

             Table 3: response content formats for skg and skc 

</pvds>

Section 5.4

   o  EST-coaps servers sometimes need to provide delayed responses
      which are conveyed with an empty ACK or an ACK containing response
      code 5.03 as explained in Section 5.7.  Thus, it is RECOMMENDED

nit: the response itself (delayed or not) is not in the ACK, so maybe
"the need for which is conveyed". 

<pvds> 

s/responses which are conveyed with an/which are preceded by an
immediately returned/ 

Section 5.6

   layer.  In addition, invokers residing on a 6LoWPAN over IEEE
   802.15.4 [ieee802.15.4] network should attempt to size CoAP messages
   such that each DTLS record will fit within one or two IEEE 802.15.4
   frames.

Is this intended to be a normative SHOULD?  If not, it feels like we
need a reference or justification. 

<pvds> 

s/should attempt/are recommended/ 

</pvds>

Section 5.7

   certificate to the client after a short delay.  If the certificate
   response is large, the server will need more than one Block2 blocks
   to transfer it.

nit: "Block2 block" singular 

<pvds> thanks, done </pvds>

POST [2001:db8::2:1]:61616/est/sen (CON)(1:0/1/256) {CSR (frag# 1)} -->
   <-- (ACK) (1:0/1/256) (2.31 Continue)

Where is this notation documented?  (Is Appendix B.1 of this document
the
first place it's introduced?)  We need some kind of reference on first
usage. 

<pvds> Just before figure 2 the following phrase is added: 

"The notation of figure 2 is explained in section B.1" 

</pvds> 

   If the server is very slow (i.e. minutes) in providing the response
   (i.e. when a manual intervention is needed), he SHOULD respond with

nit: RFC style puts commas after (and before) "i.e." and "e.g.". 

<pvds>done everywhere </pvds>

   the identical CSR to the server.  As long as the server responds with
   response code 5.03 (Service Unavailable) with a Max-Age Option, the
   client SHOULD keep resending the enrollment request until the server
   responds with the certificate or the client abandons for other
   reasons.

nit: the transitive verb "abandons" has no direct object 

<pvds>abandons the request </pvds>

   response.  Note that the server asks for a decrease in the block size
   when acknowledging the first Block2.

nit: From the trace, it looks like the server is the first one to use
a 128-byte block size, and it does happen in an ack message, but that
ack is not acking a block2 (though it contains one).  (That ack message
also happens to contain part of the response.) 

<pvds> Ai, that confuses a lot. 

Should read: Note that the client asks again for a decrease
</pvds>

POST [2001:db8::2:1]:61616/est/sen(CON)(1:N1/0/256){CSR (frag# 1)}-->
  <-- (ACK) (1:0/1/256) (2.31 Continue)
POST [2001:db8::2:1]:61616/est/sen (CON)(1:1/1/256) {CSR (frag# 2)}  -->
  <-- (ACK) (1:1/1/256) (2.31 Continue)

The first line doesn't seem to match up -- doesn't the "N1" mean
"fragment N1+1" but the descriptive text at the end say "frag# 1"?
Or is this supposed to be 1:0/1/256? 

<pvds> Difficult to be terse and get it right: 

CSR (frag# n) means fragment n of the request 

Cert resp(frag# m) means fragment m of the response 

Like in figure 2, in figure 3, the line 

"... Immediate response when certificate is ready ...", 

Is added to separate the request sending from the response reception 

</pvds>

Also, it surprised me somewhat that the client has to re-send the whole
request (i.e., all fragments thereof) after the Max-Age interval when
the server says it's ready, since that feels wasteful of bandwidth, but
I assume that's just how CoAP works and not relevant for this document. 

<pvds>We did not see any other mechanism; but we are talking about many
minutes, the relative bandwidth loss is not too high.
This way, there is no need to keep much state, especially when many
simultaneous requests are treated.</pvds>

Section 5.8

   In scenarios where it is desirable that the server generates the
   private key, server-side key generation should be used.  Such

nit: suggest s/should be used/is available/ to avoid the appearance of
tautology. 

<pvds>done</pvds>

---

From: Peter van der Stok <[email-masked]>
Date: Tue, 03 Sep 2019 14:18:22 +0200

Hi Ben,

the last part of the responses to your thorough review.
Apart from nits you found some "nice" mistakes.

the openssl example make me worry a bit.

See below.

Peter
_______________________________________________________________________

   When requesting server-side key generation, the client asks for the
   server or proxy to generate the private key and the certificate which
   are transferred back to the client in the server-side key generation
   response.  In all respects, the server SHOULD treat the CSR as it
   would treat any enroll or re-enroll CSR; the only distinction here is
   that the server MUST ignore the public key values and signature in
   the CSR.  These are included in the request only to allow re-use of
   existing codebases for generating and parsing such requests.

We need to reword this; the SHOULD is in conflict with the MUST. 

<pvds> 

Removed the SHOULD -> "…the server treats the CSR …" 

</pvds>

   certificate and a private key.  The private key Content-Format
   requested by the client is depicted in the PKCS#10 CSR request.  If

nit: I suggest s/depicted/indicated/ 

<pvds>done </pvds>

   (Section 5.3) .  The two representations (each consisting of two CBOR
   array items) do not have to be in a particular order since each

<pvds> 

s/do not have to be in a particular order since each representation is/ 

are/ 

</pvds>
[side note: core-multipart-ct is looking to land on "multipart/mixed"
semantics to resolve my outstanding Discuss point; RFC 2046 is pretty
clear about the component parts "need[ing] to be in a particular order",
which this is in conflict with]

   representation is preceded by its Content-Format ID.  The private key
   can be in unprotected PKCS#8 [RFC5958] format (Content-Format 284) or
   protected inside of CMS SignedData (Content-Format 280).  The

Phrasing it like this makes it soun like the server can just
spontaneously decide that it wants to sign the key content, as opposed
to having it be dependant on the CSR's contents.  Also... 

<pvds> 

/The private key/ 

Dependent on the contents of the CSR, the private key/ 

</pvds>

   SignedData is signed by the party that generated the private key,
   which may be the EST server or the EST CA.  The SignedData is further
   protected by placing it inside of a CMS EnvelopedData as explained in
   Section 4.4.2 of [RFC7030].  In summary, the symmetrically encrypted

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

</pvds>

   key is included in the encryptedKey attribute in a KEKRecipientInfo
   structure.  In the case where the asymmetric encryption key is
   suitable for transport key operations the generated private key is
   encrypted with a symmetric key which is encrypted by the client
   defined (in the CSR) asymmetric public key and is carried in an

nit: hyphenate "client-defined" 

<pvds> done </pvds>

   encryptedKey attribute in a KeyTransRecipientInfo structure.
   Finally, if the asymmetric encryption key is suitable for key
   agreement, the generated private key is encrypted with a symmetric
   key which is encrypted by the client defined (in the CSR) asymmetric

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. 

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

</pvds>

   public key and is carried in an recipientEncryptedKeys attribute in a
   KeyAgreeRecipientInfo.

   [RFC7030] recommends the use of additional encryption of the returned
   private key.  For the context of this specification, clients and
   servers that choose to support server-side key generation MUST
   support unprotected (PKCS#8) private keys (Content-Format 284).
   Symmetric or asymmetric encryption of the private key (CMS
   EnvelopedData, Content-Format 280) SHOULD be supported for
   deployments where end-to-end encryption needs to be provided between
   the client and a server.  Such cases could include architectures
   where an entity between the client and the CA terminates the DTLS
   connection (Registrar in Figure 4).

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. 

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

Section 6

   The EST-coaps-to-HTTPS Registrar MUST terminate EST-coaps downstream
   and initiate EST connections over TLS upstream.  The Registrar MUST
   authenticate and OPTIONALLY authorize the clients and it MUST be 

<pvds> 

Suggestion: 

s/ authenticate and OPTIONALLY authorize the clients and/ 

authenticate and authorize client request, while/ 

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

</pvds>

   For some use cases, clients that leverage server-side key generation
   might prefer for the enrolled keys to be generated by the Registrar
   if the CA does not support server-side key generation.  Such
   Registrar is responsible for generating a new CSR signed by a new key
   which will be returned to the client along with the certificate from

nit: "Such a Registrar" 

<pvds> done </pvds>

   the CA.  In these cases, the Registrar MUST support random number
   generation using proper entropy.

Not just support -- use! 

<pvds>done </pvds>

   Additionally, a conversion from CBOR major type 2 to Base64 encoding
   MUST take place at the Registrar when server-side key generation is
   supported.  [...]

Not always? 

<pvds> IMO always; removed the when…. 

</pvds>

   key, the encrypted CMS EnvelopedData blob MUST be converted to binary
   in CBOR type 2 downstream to the client.

I think we should reword this -- my first reading of "downstream to the
client" is "after the client in the processing path", which doesn't
actually help the client.  Presumably we mean at the registrar, in the
downstream direction, towards the client. 

<pvds> 

s/ MUST be converted to binary in CBOR type 2 downstream to the client./

MUST be converted at the Registrar to binary CBOR type 2 downstream to
the client./ 

</pvds>

   The EST-coaps-to-HTTP Registrar MUST support resource discovery
   according to the rules in Section 5.1.  Section 5.1. 

<pvds> 

Second section 5.1 is removed 

</pvds>

Do we need to say anything about translation of discovered URIs? 

<pvds> I don't think so; 

The Registrar discovers the EST server, while the TLS client discovers
the registrar. I don't see the client discovering the EST server through
the Registrar 

</pvds>

Section 7

   This section addresses transmission parameters described in sections
   4.7 and 4.8 of [RFC7252].  EST does not impose any unique values on
   the CoAP parameters in [RFC7252], but the EST parameter values need
   to be tuned to the CoAP parameter values.

I don't understand what "but the EST parameter values need to be tuned
to the CoAP parameter values" means. 

<pvds> 

s/ but the EST parameter values need to be tuned to the CoAP parameter
values/ 

but the setting of the CoAP parameter values may have consequences for
the setting of the EST parameter values/ 

</pvds>.

   It is recommended, based on experiments, to follow the default CoAP
   configuration parameters ([RFC7252]).  However, depending on the
   implementation scenario, retransmissions and timeouts can also occur
   on other networking layers, governed by other configuration
   parameters.  A change in a server parameter MUST ensure the adjusted
   value is also available to all the endpoints with which these
   adjusted values are to be used to communicate.

I don't understand who this is a normative requirement upon.  Is it the
network operator's, to propagate configuration changes?  Or is there
supposed to be some automated protocol that makes adjusted values
available? 

<pvds> 

It is meant as reminder to anyone doing the configuration of a given
installation; you want to suppress the text? 

</pvds>

   o  NSTART: A parameter that controls the number of simultaneous
      outstanding interactions that a client maintains to a given
      server.  An EST-coaps client is not expected to interact with more
      than one servers at the same time, which is the default NSTART
      value defined in [RFC7252].

nit: there's a mismatch between "to a given server" and "more than one
servers at the same time".  (Also, s/one servers/one server/.) 

<pvds> 

s/ not expected to interact with more than one servers at the same time/

/is expected to control at most one interaction with a given server,/ 

</pvds>

   o  PROBING_RATE: A parameter which specifies the rate of re-sending
      non-confirmable messages.  The EST messages are defined to be sent
      as CoAP confirmable messages, hence this setting is not
      applicable.

Section 5.4 only has it as RECOMMENDED to send requests in CON messages,
so we should still say something here. 

<pvds> 

s/ The EST messages are defined to be sent as CoAP confirmable messages,
hence this setting is not applicable./ 

In the rare situations that non-confirmable messages are used, the
default PROBING_RATE value defined in RFC7252 applies./ 

</pvds>

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.

Section 9.2

The grammar for these entries is a bit stilted, though the existing
registrations are not so far off.

nit: should ace.est.att include the word "get" like ace.est.crts does? 

<pvds> added get </pvds>

Section 10.1

   The security considerations of Section 6 of [RFC7030] are only
   partially valid for the purposes of this document.  As HTTP Basic
   Authentication is not supported, the considerations expressed for
   using passwords do not apply.

It may be worth explicitly stating that "the other portions of the
security considerations of RFC 7030 continue to apply". 

<pvds>added </pvds>

   Modern security protocols require random numbers to be available
   during the protocol run, for example for nonces, ephemeral (EC)
   Diffie-Hellman key generation.  This capability to generate random

nit: the comma expects a 3+ element list but we only have two elements.
Just "and" suffices? 

<pvds>absolutely right </pvds>

   Analysis SHOULD be done to establish whether server-side key
   generation increases or decreases the probability of digital identity
   theft.

In the abstract sense, this seems like a non-normative "should".  But if
we make it apply specifically to those deploying server-side key
generation then it is appropriately normative. 

<pvds> 

Preceded by: For those deploying server-side key generation, 

</pvds>

   It is important to note that sources contributing to the randomness
   pool used to generate random numbers on laptops or desktop PCs are
   not available on many constrained devices, such as mouse movement,
   timing of keystrokes, air turbulence on the movement of hard drive
   heads, as pointed out in [PsQs].  Other sources have to be used or

nit: need an "and" (or "or") to close the list. 

<pvds>repaired with or</pvds>

   It is also RECOMMENDED that the Implicit Trust Anchor database used
   for EST server authentication is carefully managed to reduce the
   chance of a third-party CA with poor certification practices
   jeopardizing authentication.  Disabling the Implicit Trust Anchor

We may want to call out that since the implicit database is used for the
initial /crts request, that single jeporadized exchange could cause all
subsequent exchanges from that client to be compromised as well. 

<pvds> before Disabling: 

"Remark that the initial /crts request uses the implicit database, and
that a compromised implicit database has as consequence that all
subsequent exchanges from that client are jeopardized." 

</pvds>

   database after successfully receiving the Distribution of CA
   certificates response (Section 4.1.3 of [RFC7030]) limits any risk to
   the first DTLS exchange.  Alternatively, in a case where a /sen
   request immediately follows a /crts, a client MAY choose to keep the
   connection authenticated by the Implicit TA open for efficiency
   reasons (Section 4).  A client that pipelines EST-coaps /crts request

nit: is "pipelines" the right word here, given that HTTP pipelining is a
thing and CoAP pipelining (probably?) isn't, and the former isn't what
we're doing anyway? 

<pvds> suggestion: 

s/pipelines/interleaves/ 

<pvds> 

   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>

   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>

It might be worth splitting the triple-handshake bits (including open
question) into a separate subsection so that we can make a forward
reference to it from earlier in the document.

   value generated from an exporter would break backwards compatibility.
   Thus, in this specification we still depend on the tls-unique
   mechanism defined in [RFC5929], especially since a 3SHAKE attack does
   not expose messages exchanged with EST-coaps.

I suppose that new endpoint names would be one way to work through the
backwards-compatibility break, though it's not entirely clear that we
need to say so in this document.  We probably do want to say that even
though EST-coaps looks like a new protocol that could get away with
changing the default, we want to preserve the ability for the RA to
proxy through to a "classic" EST HTTPS server, so we are in fact
constrained to use the compatible choice.

   Regarding the Certificate Signing Request (CSR), an EST-coaps server
   is expected to be able to recover from improper CSR requests.

What does "recover" mean?  Is it just "not crash" or is it expected to
somehow still be able to issue a certificate?  (If the former, that
might be implicit in an RFC 3552 threat model, though saying it
explicitly probably doesn't hurt.)

Section 10.2

   The Registrar proposed in Section 6 must be deployed with care, and
   only when the recommended connections are impossible.  When POP

Do we actually explicitly say that the direct connection is recommended
anywhere?  If not, we should. 

<pvds> 

Added at the end of the first paragraph of section 6: 

When not explicitly needed, it is RECOMMENDED to use direct connections
between EST server and client 

</pvds> 

   linking is used the Registrar terminating the TLS connection
   establishes a new one with the upstream CA.  Thus, it is impossible

I think technically it terminates DTLS and esablishes a new TLS
connection. 

<pvds> 

s/ terminating the TLS connection establishes a new one/ 

terminating the DTLS connection establishes a new TLS connection/ 

</pvds>

   for POP linking to be enforced end-to-end for the EST transaction.
   The EST server could be configured to accept POP linking information
   that does not match the current TLS session because the authenticated
   EST Registrar client has verified this information when acting as an
   EST server.

I think we need to say that the EST server "assumes" or "trusts" that
the registrar has verified this information -- it is to some extent a
leap of faith. 

<pvds> Suggestion: 

s/ client has verified this information when acting as an EST server / 

acting as an EST-server, assumes that the client has verified this
information/ 

</pvds>

   The introduction of an EST-coaps-to-HTTP Registrar assumes the client
   can trust the registrar using its implicit or explicit TA database.

I'm not entirely sold on "trust" as the best word here (vs., e.g.,
validate), but don't object to it.

<pvds> leave as is, have no better word </pvds> 

   generating the key.  In such cases, the existence of a Registrar
   requires the client to put its trust on the registrar doing the right
   thing if it is generating the private key.

This is true, though it (probably correctly, for our purposes) does not
give any indication of what "the right thing" is intended to be :) 

<pvds> 

Remove: "doing the right thing" 

s/if/when/ 

</pvds>

Section 11.2

I think draft-ietf-lamps-rfc5751-bis, RFC 5958, RFC 8075, and RFC 8422
should be normative references. 

<pvds>done; </pvds>

If we're going to say that this spec requires conformance to RFC 7925's
DTLS profile (which we currently don't, but I suggest above that we do),
it will need to be a normative reference as well. 

<pvds> 

In section 4, 

/fits into/conforms to/ 

</pvds>

I don't understand why RFC 7231 is in the 'reference' column for
application/csrattrs in Table 4; its presence there would normally
suggest that it should be a normative reference.  

<pvds> 

Removed RFC7231, it is not mentioned in RFC7030 

</pvds>

RFC 5929 is interesting, as it is of course a normative reference for
RFC 7030, which we use normatively, but we may not need to cite it
directly as a normative reference from this document. 

<pvds> 

Continue to do so 

</pvds>

It may be worth citing RFC 7525 as BCP 195 where it appears. 

<pvds>To be done </pvds>

Appendix A

   transported in hex, but in binary.  The payloads are shown
   unencrypted.  In practice the message content would be transferred
   over an encrypted DTLS tunnel.

I expect a tsvart reviewer to complain about the use of the word
"tunnel" here, and suggest "channel" as an alternative. 

<pvds>done </pvds>

   The certificate responses included in the examples contain Content-
   Format 281 (application/pkcs7).  If the client had requested Content-
   Format TBD287 (application/pkix-cert) by querying /est/skc, the
   server would respond with a single DER binary certificate.

Just to check my own understanding: this will always appear within a
multipart-core container, right? 

<pvds> 

Added: in the multipart-core container 

</pvds>

Appendix A.1

     Option (Uri-Port)
        Option Delta = 0x4  (option# 3+4=7)
        Option Length = 0x4
        Option Value = 9085
      Option (Uri-Path)
        Option Delta = 0x4   (option# 7+4=11)
        Option Length = 0x5
        Option Value = "est"

This is more for my own edification than the document's sake, so thank
you for your time, but what accounts for the "extra" length here?  The
"est" is three bytes, and what makes up for the other two?  Also, I
assume that the port value of 9805 is the decimal value, which gets
CBOR encoded into two bytes  of integer encoding plus the byte with
additional information 25 to indicate the two-byte integer, and another
byte that I need help accounting for. 

<pvds> 

Many thanks; an old misreading of an example in 7252. 

For the option length of URI-Path we included the quotations as well;
That is WRONG. 

Repaired it everywhere. 

Options are not CBOR encoded. 

</pvds>

Appendix A.2

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>

Appendix A.3

I'm having trouble validating the private key in the PKCS#8 component:
asn1parse says: 

<pvds> 

As input I used recently a hex dump of Wt1234.key.der: 

308187020100301306072a8648ce3d020106082a8648ce3d030107046d30
6b020101042061336a86ac6e7af4a96f632830ad4e6aa0837679206094d7
679a01ca8c6f0c37a14403420004c8b421f11c25e47e3ac57123bf2d9fdc
494f028bc351cc80c03f150bf50cff958d75419d81a6a245dffae790be95
cf75f602f9152618f816a2b23b5638e59fd9 

I used openssl pkey -in Wt1234.key.der -text -noout -inform der\ 

-passin pass:watnietweet 

The password is may be prohibitive? 

Resulting in:
Private-Key: (256 bit)
priv:
    61:33:6a:86:ac:6e:7a:f4:a9:6f:63:28:30:ad:4e:
    6a:a0:83:76:79:20:60:94:d7:67:9a:01:ca:8c:6f:
    0c:37
pub: 
    04:c8:b4:21:f1:1c:25:e4:7e:3a:c5:71:23:bf:2d:
    9f:dc:49:4f:02:8b:c3:51:cc:80:c0:3f:15:0b:f5:
    0c:ff:95:8d:75:41:9d:81:a6:a2:45:df:fa:e7:90:
    be:95:cf:75:f6:02:f9:15:26:18:f8:16:a2:b2:3b:
    56:38:e5:9f:d9
ASN1 OID: prime256v1
NIST CURVE: P-256

$ unhex|openssl asn1parse -inform der
   308187020100301306072a8648ce3d020106082a8648ce3d030107046d30
   6b02010104200b9a67785b65e07360b6d28cfc1d3f3925c0755799deeca7
   45372b01697bd8a6a144034200041bb8c1117896f98e4506c03d70efbe82
   0d8e38ea97e9d65d52c8460c5852c51dd89a61370a2843760fc859799d78
   cd33f3c1846e304f1717f8123f1a284cc99f
    0:d=0  hl=3 l= 135 cons: SEQUENCE          
    3:d=1  hl=2 l=   1 prim: INTEGER           :00
    6:d=1  hl=2 l=  19 cons: SEQUENCE          
    8:d=2  hl=2 l=   7 prim: OBJECT            :id-ecPublicKey
   17:d=2  hl=2 l=   8 prim: OBJECT            :prime256v1
   27:d=1  hl=2 l= 109 prim: OCTET STRING      [HEX
DUMP]:306B02010104200B9A67785B65E07360B6D28CFC1D3F3925C0755799DEECA745372B01697BD8A6A144034200041BB8C1117896F98E4506C03D70EFBE820D8E38EA97E9D65D52C8460C5852C51DD89A61370A2843760FC859799D78CD33F3C1846E304F1717F8123F1A284CC99F

which doesn't look like an RFC5208 PrivateKeyInfo:

      PrivateKeyInfo ::= SEQUENCE {
        version                   Version,
        privateKeyAlgorithm       PrivateKeyAlgorithmIdentifier,
        privateKey                PrivateKey,
        attributes           [0]  IMPLICIT Attributes OPTIONAL }

      Version ::= INTEGER

      PrivateKeyAlgorithmIdentifier ::= AlgorithmIdentifier

      PrivateKey ::= OCTET STRING

      Attributes ::= SET OF Attribute

due to the lack of OID for privateKeyAlgorithm, etc.
(`openssl pkcs8` also chokes on it, but I don't have a working example
and
can't rule out user error there.)

Even that giant OCTET STRING 27 bytes in doesn't seem to match a
PrivateKeyInfo:

$ unhex|openssl asn1parse -inform der -strparse 27
   308187020100301306072a8648ce3d020106082a8648ce3d030107046d30
   6b02010104200b9a67785b65e07360b6d28cfc1d3f3925c0755799deeca7
   45372b01697bd8a6a144034200041bb8c1117896f98e4506c03d70efbe82
   0d8e38ea97e9d65d52c8460c5852c51dd89a61370a2843760fc859799d78
   cd33f3c1846e304f1717f8123f1a284cc99f
    0:d=0  hl=2 l= 107 cons: SEQUENCE          
    2:d=1  hl=2 l=   1 prim: INTEGER           :01
    5:d=1  hl=2 l=  32 prim: OCTET STRING      [HEX
DUMP]:0B9A67785B65E07360B6D28CFC1D3F3925C0755799DEECA745372B01697BD8A6
   39:d=1  hl=2 l=  68 cons: cont [ 1 ]        
   41:d=2  hl=2 l=  66 prim: BIT STRING        

though the OCTET STRING does have the private key and the BIT STRING has
the public key's contents as depicted in C.3 (details of that too boring
to show).

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

Section A.4

I'm not sure how useful repeating the RFC 7030 csrattrs is: do we expect
(e.g.) brainpoolP384r1 to be relevant for our readers? 

<pvds> 

It was added for completeness sake; nothing more. 

Suppressing it may provoke other questions like: Why is it not there? 

</pvds>

Appendix B.1

   and BLOCK option Block2.  The minimum PMTU is 1280 bytes, which is
   the example value assumed for the DTLS datagram size.  The example

I'm not seeing how this relates to the rest of the section. 

<pvds> 

I see. We do not use it anymore.; suppressed it. 

</pvds>

                                  The CoAP message adds around 10 bytes,
   the DTLS record 29 bytes.  To avoid IP fragmentation, the CoAP Block

The DTLS overhead can also vary based on cipher suite, padding, etc., so
a bit more qualification ("we assume", "around", etc.) might be in
order. 

<pvds> 

Added: "in this example" 

</pvds>

   tenth packet of 63 bytes.  The client sends an IPv6 packet containing
   the UDP datagram with the DTLS record that encapsulates the CoAP
   request 10 times.  The server returns an IPv6 packet containing the
   UDP datagram with the DTLS record that encapsulates the CoAP
   response.  The CoAP request-response exchange with block option is

The definite vs. indefinite articles here don't seem quite right, and
each of the 10 datagrams do not encapsulate the entire CoAP request. 

<pvds> 

I don't understand your meaning. 

</pvds>

   with exponent (2**(SZX+4)) separated by slashes.  The Length 64 is
   used with SZX=2 to avoid IP fragmentation.  The CoAP Request is sent

We just said "to avoid IP fragmentation" ten lines ago.

<pvds> 

Removed 

</pvds> 

Should we be using the same Token value in two different exchanges in
this document? 

<pvds> 

No opinion 

</pvds>

Appendix B.2

   In this example, the requested Block2 size of 256 bytes, required by
   the client, is transferred to the server in the very first request
   message.  The block size 256=(2**(SZX+4)) which gives SZX=4.  The

I don't see a Block2 size in the first request message, just Block1: 

<pvds> 

Thanks. Block1 it is 

</pvds>

   POST [2001:db8::2:321]:61616/est/sen (CON)(1:0/1/256) {CSR req} -->
          <-- (ACK) (1:0/1/256) (2.31 Continue)

Also, we seem to have stopped using the "{CSR req frag#2}" notation that
we had in the main body text. 

<pvds>That is an oversight; adapted 

</pvds>

Appendix C.2

[I mentioned otherName's non-decoding earlier]

Appendix C.3

I find it kind of amusing that we have a "Netscape Comment" in the
generated cert :) 

<pvds> 

This was the result of a lengthy openssl struggle. 

Any suggestions for improvement are very welcome indeed. 

</pvds>

_

---

From: Jim Schaad <[email-masked]>
Date: Tue, 3 Sep 2019 11:48:52 -0700

I have pruned and tossed in  a few [JLS] comments.

Jim

From: Peter van der Stok <[email-masked]> 
Sent: Tuesday, September 3, 2019 5:18 AM
To: Benjamin Kaduk <[email-masked]>
Cc: Jim Schaad <[email-masked]>; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Ace] AD review of draft-ietf-ace-coap-est-12 part 2

Hi Ben,

See below.

Peter

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

<pvds>

Not sure about this

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

<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

asymmetric key.

I don’t know what to do here; probably insert the 7030 text.

[JLS] Ben, you do not have the correct view of the key-agreement case.  It does a key agreement -> KDF -> KeyWrap -> Content.  There is always a key wrap step between the key agreement and the content encryption key.

</pvds>

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

<pvds>

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

Section 9.1

[JLS] No response from Peter?

Appendix A.3

<pvds>

-passin pass:watnietweet

[JLS] I would lose the password on the key if possible.

Resulting in:
Private-Key: (256 bit)
priv:

   27:d=1  hl=2 l= 109 prim: OCTET STRING      [HEX DUMP]:306B02010104200B9A67785B65E07360B6D28CFC1D3F3925C0755799DEECA745372B01697BD8A6A144034200041BB8C1117896F98E4506C03D70EFBE820D8E38EA97E9D65D52C8460C5852C51DD89A61370A2843760FC859799D78CD33F3C1846E304F1717F8123F1A284CC99F

      Version ::= INTEGER

due to the lack of OID for privateKeyAlgorithm, etc.
(`openssl pkcs8` also chokes on it, but I don't have a working example and
can't rule out user error there.)

    5:d=1  hl=2 l=  32 prim: OCTET STRING      [HEX DUMP]:0B9A67785B65E07360B6D28CFC1D3F3925C0755799DEECA745372B01697BD8A6

Appendix B.1

<pvds>

No opinion

[JLS] As long as the Token values are not in the same exchange, this makes no difference.  Tokens are reused after an amount of time in CoAP.

</pvds>

---

From: Peter van der Stok <[email-masked]>
Date: Wed, 04 Sep 2019 09:02:06 +0200

I concluded on the pruned .

Peter
Jim Schaad schreef op 2019-09-03 20:48:

> FROM: Peter van der Stok <[email-masked]> 
> SENT: Tuesday, September 3, 2019 5:18 AM
> TO: Benjamin Kaduk <[email-masked]>
> CC: Jim Schaad <[email-masked]>; [email-masked]; [email-masked]; [email-masked]
> SUBJECT: Re: [Ace] AD review of draft-ietf-ace-coap-est-12 part 2 
> 
> Hi Ben,
> 
> <pvds2>
> I don't do anything here
> </pvds2> 
> <pvds2>
> Also here I see no room for improvement then.
> <pvds2> 
> 
> </pvds>
> 
> <pvds2>
> Suggest to use SHOULD and not distinguish between terminating or not.
> <pvds2> 
> 
> </pvds>
> 
> Section 9.1
> 
> <pvds2>
> Sorry, misunderstood. Will add <thisdocument>
> </pvds2> 
> 
> Appendix A.3
> 
> <pvds2>
> Right, It means changing the whole chain of certificates. and redoing the examples.
> But I understand the reason, being confronted with the disassembly failure.
> </pvds2> 
> 
> <pvds2>
> No extra text, I gather
> </pvds2>

---

From: Jim Schaad <[email-masked]>
Date: Wed, 4 Sep 2019 11:02:31 -0700

Let me draw back and re-address the comment from Ben about the private key in appendix A.3

If I take 

and decode it I get (with comments from me)

SEQUENCE (3 elem)    -- OneAsymmetricKey (replacement of PKCS #8)

  INTEGER 0   -- Version = v1

  SEQUENCE (2 elem)  -- privateKeyAlgorithm

    OBJECT IDENTIFIER 1.2.840.10045.2.1 ecPublicKey (ANSI X9.62 public key type)  -- Alg ID

    OBJECT IDENTIFIER 1.2.840.10045.3.1.7 prime256v1 (ANSI X9.62 named elliptic curve) – Parameters == P256

  OCTET STRING (1 elem) – Private Key

    SEQUENCE (3 elem) – ECPrivate Key  [RFC 5915]

      INTEGER 1 – Version – ecPrivkeyVer1

      OCTET STRING (32 byte) 0B9A67785B65E07360B6D28CFC1D3F3925C0755799DEECA745372B01697BD8A6 – Private Key value

      [1] (1 elem) – Public key value

        BIT STRING (520 bit) 0000010000011011101110001100000100010001011110001001011011111001100011…

This looks correct to me.

Jim

 

From: Peter van der Stok <[email-masked]> 
Sent: Wednesday, September 4, 2019 12:02 AM
To: Jim Schaad <[email-masked]>
Cc: [email-masked]; 'Benjamin Kaduk' <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [Ace] AD review of draft-ietf-ace-coap-est-12 part 2

Peter

Jim

From: Peter van der Stok <[email-masked] <mailto:[email-masked]> > 
Sent: Tuesday, September 3, 2019 5:18 AM
To: Benjamin Kaduk <[email-masked] <mailto:[email-masked]> >
Cc: Jim Schaad <[email-masked] <mailto:[email-masked]> >; [email-masked] <mailto:[email-masked]> ; [email-masked] <mailto:[email-masked]> ; [email-masked] <mailto:[email-masked]> 
Subject: Re: [Ace] AD review of draft-ietf-ace-coap-est-12 part 2

Hi Ben,

See below.

Peter

<pvds>

</pvds>

<pvds>

Not sure about this

<pvds2>
I don't do anything here
</pvds2>

</pvds>

<pvds>

asymmetric key.

</pvds>

</pvds>

<pvds>

</pvds>

Section 9.1

Appendix A.3

<pvds>

-passin pass:watnietweet

<pvds2>

Resulting in:
Private-Key: (256 bit)
priv:

      Version ::= INTEGER

Appendix B.1

<pvds>

No opinion

<pvds2>
No extra text, I gather
</pvds2>

</pvds>

---

From: Peter van der Stok <[email-masked]>
Date: Thu, 05 Sep 2019 08:40:14 +0200

Hi Jim,

I removed the passwd from the example, and did the disassembly as Ben
proposed.
That seems to work correctly for me.

Peter
Jim Schaad schreef op 2019-09-04 20:02:

> OBJECT IDENTIFIER 1.2.840.10045.3.1.7 prime256v1 (ANSI X9.62 named elliptic curve) - Parameters == P256 
> 
> OCTET STRING (1 elem) - Private Key 
> 
> SEQUENCE (3 elem) - ECPrivate Key  [RFC 5915] 
> 
> INTEGER 1 - Version - ecPrivkeyVer1 
> 
> OCTET STRING (32 byte) 0B9A67785B65E07360B6D28CFC1D3F3925C0755799DEECA745372B01697BD8A6 - Private Key value 
> 
> [1] (1 elem) - Public key value 
> 
> BIT STRING (520 bit) 0000010000011011101110001100000100010001011110001001011011111001100011... 
> 
> SENT: Wednesday, September 4, 2019 12:02 AM
> TO: Jim Schaad <[email-masked]>
> CC: [email-masked]; 'Benjamin Kaduk' <[email-masked]>; [email-masked]; [email-masked]
> _______________________________________________
> Ace mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ace

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 6 Sep 2019 18:09:22 -0500

Hi Jim,

Thanks for taking a closer look.  It's been a long week, so I'm not sure if
you're saying that I was doing the decoding wrong, expecting the wrong
structure, or both.

-Ben

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 6 Sep 2019 18:17:31 -0500

> > the openssl example make me worry a bit.

I was reading Jim as suggesting to make a change here (though exactly what
change, I'm not sure).

> > Suggest to use SHOULD and not distinguish between terminating or not.

I'm not 100% sure I understand the proposal, but if I do, it seems okay.
I'll just have to look at the new rev when it comes out, I suppose.

-Ben

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 6 Sep 2019 19:29:17 -0500

[trimming]
> see a better way to do this. 

I think the 7030 text I was thinking of is this:

   It is strongly RECOMMENDED that the clients request that the returned
   private key be afforded the additional security of the Cryptographic
   Message Syntax (CMS) EnvelopedData in addition to the TLS-provided
   security to protect against unauthorized disclosure.

> </pvds>
[...]
> installation; you want to suppress the text? 

I don't want to suppress it, no.

Maybe "A configuration change in a server parameter MUST be coordinated
with all the endpoints with which these adjusted values are to be used to
communicate"?  Though I guess "coordinate" does not necessarily force the
other endpoint to be using the identical value, just to know about it.

> </pvds>
[...]
> Options are not CBOR encoded. 

Well, now I'm glad I asked -- thanks!

> What do you suggest for IDevID? 

If we were going to add something (which remains unclear to me), it could
be after the sentence "[...] the CSR contains a ChallengePassword which is
used for POP linking (Section 4).", and be something like "This CSR also
contains an RFC 7299 id-on-hardwareModuleName hardware identifier to
customize the returned certificate to the requesting device."
(The actual identifier here is the same one mentioned in
https://www.mail-archive.com/[email-masked]/msg00938.html, from Bob
Moskowitz's OID arc.)

> Will be happy to learn about otherName 

otherName is an OID-indexed generic name container for the cert; it's a
form of subjectAltName.  What I did here was:

~$ unhex|openssl asn1parse -inform der
   3082018b30820131020100305c310b3009060355040613025553310b3009
   06035504080c024341310b300906035504070c024c413114301206035504
   0a0c0b6578616d706c6520496e63310c300a060355040b0c03496f54310f
   300d060355040513065774313233343059301306072a8648ce3d02010608
   2a8648ce3d03010703420004c8b421f11c25e47e3ac57123bf2d9fdc494f
   028bc351cc80c03f150bf50cff958d75419d81a6a245dffae790be95cf75
   f602f9152618f816a2b23b5638e59fd9a073303406092a864886f70d0109
   0731270c2576437630292a264a4b4a3bc3a2c280c2992f3e3c2e2c3d6b6e
   7634332323403d204e787e60303b06092a864886f70d01090e312e302c30
   2a0603551d1104233021a01f06082b06010505070804a013301106092b06
   010401b43b0a01040401020304300a06082a8648ce3d0403020348003045
   02210092563a546463bd9ecff170d0fd1f2ef0d3d012160e5ee90cffedab
   ec9b9a38920220179f10a3436109051abad17590a09bc87c4dce5453a6fc
   1135a1e84eed754377
    0:d=0  hl=4 l= 395 cons: SEQUENCE          
  [...]
  271:d=7  hl=2 l=   3 prim: OBJECT            :X509v3 Subject Alternative
Name
  276:d=7  hl=2 l=  35 prim: OCTET STRING      [HEX
DUMP]:3021A01F06082B06010505070804A013301106092B06010401B43B0A01040401020304
  313:d=1  hl=2 l=  10 cons: SEQUENCE          
  315:d=2  hl=2 l=   8 prim: OBJECT            :ecdsa-with-SHA256
  325:d=1  hl=2 l=  72 prim: BIT STRING        

to note that there's a SAN that's not decoded automatically, and then

~$ unhex|openssl asn1parse -inform der -strparse 276
   3082018b30820131020100305c310b3009060355040613025553310b3009
   [...]
   1135a1e84eed754377
    0:d=0  hl=2 l=  33 cons: SEQUENCE          
    2:d=1  hl=2 l=  31 cons: cont [ 0 ]        
    4:d=2  hl=2 l=   8 prim: OBJECT            :1.3.6.1.5.5.7.8.4
   14:d=2  hl=2 l=  19 cons: cont [ 0 ]        
   16:d=3  hl=2 l=  17 cons: SEQUENCE          
   18:d=4  hl=2 l=   9 prim: OBJECT            :1.3.6.1.4.1.6715.10.1
   29:d=4  hl=2 l=   4 prim: OCTET STRING      [HEX DUMP]:01020304

to look at the contents.  1.3.6.1.5.5.7.8.4 (with the symbolic name in my
suggested text) is the type of the otherName, here.

I'm pretty sure there's not a more-"automatic" way to get openssl to peek
inside otherName.

> </pvds>
[...]
> Suppressing it may provoke other questions like: Why is it not there? 

Okay.

> </pvds>
[...]
> I don't understand your meaning. 

I'm complaining that the "an"s and "the"s don't match up.
I think I also misunderstood the sense of what was happening, so my "do not
encapsualte the entire CoAP request" is not quite right.

NEW:

   tenth packet of 63 bytes.  The client sends an IPv6 packet containing
   a UDP datagram with DTLS record protection that encapsulates a block
   of the CoAP request 10 times (one packet per block).  The server returns
   an IPv6 packet containing the UDP datagram with the DTLS record that
   encapsulates the CoAP response.  The CoAP request-response exchange
   with block option is [...]

> </pvds>
[...]
> [I mentioned otherName's non-decoding earlier]

Specifically, in crypto/x509/v3_alt.c:

STACK_OF(CONF_VALUE) *i2v_GENERAL_NAME(X509V3_EXT_METHOD *method,
                                       GENERAL_NAME *gen,
                                       STACK_OF(CONF_VALUE) *ret)
{
    [...]
    switch (gen->type) {
    case GEN_OTHERNAME:
        if (!X509V3_add_value("othername", "<unsupported>", &ret))
            return NULL;

So openssl is explicitly just punting on all otherNames.

> Any suggestions for improvement are very welcome indeed. 

Do you have a line with a "nsComment" in any config file (e.g., openssl.cfg)
floating around (i.e., the -config <filename> argument to openssl req)?  It
*sounds* from the documentation like this is not supposed to be added by
default (though many of the apps/ and demos/ config files in the tree do
include it).

-Ben

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 6 Sep 2019 20:05:04 -0500

> A confirmation/denial would be appreciated in those cases.

Okay, I'll try to remark at those locations, and sorry for not trimming
stuff without comments.

> To-morrow I hope to do the follow-up.

I don't think it's necessary; thanks for finding the right 7030 quote to
quiet me up.

> s/public client identity key/client certificate/ 

That seems to work.

> s/provide a private client identity key/provide the client with a new

Thanks

> For both types of installations, saving header space….."

That looks great; thank you!

> <pvds> correct, has been modified </pvds> 

(It may be ever so slightly easier for readers that have both documents
open, if we keep the ordering the same for the entries that are common to
both documents.)

> "In both cases a private key MUST be returned." 

I was thinking we could have something in the table, though we may be too
short on horizontal space for that to actually work.

> "The corresponding longer URIs from <xref target="RFC7030"/> MAY be

I have no strong preference here, but would not be surprised if we got a
question on it from the IESG.  (Which I guess means a weak preference for
adding the above text.)

> <pvds> "Added : "(see table 2)"

Hmm, I think I was not very clear about what I meant: for the given
resources, the only defined content types for that resource are the ones
listed in the example request.  If a server tries to advertise anything
else, it seems like that would be out of spec (and maybe a client should
bail on seeing it?).  But maybe I'm misinterpreting things and we should
leave open space for future expansions to other content formats.

> tables are too boring, I suggest to leave as is. 

Okay.  Thank you for the explanation!

> Suggestion to move this phrase to section 5 just before section 5.1? 

That would be a big help, thanks..

> <pvds> the following table is added. Is that sufficient?

I think so.  Just splitting out and naming "part 1" and "part 2" for the
comparison helps the clarity.

> s/responses which are conveyed with an/which are preceded by an

That should work (but please check that the final text still has "delayed
responses", the expression here would have dropped the "responses" part)

> Is added to separate the request sending from the response reception 

Thanks for adding that line, but I think you were looking at one chunk
later than I was looking at.  I was looking at:

(1:N1/0/256){CSR (frag# 1)}

and seeing that the "N1" in "N1/0/256" should correspond to "fragment
N1+1", but the parenthetical at the end says "frag# 1".

Thanks,

Ben

---

From: Michael Richardson <[email-masked]>
Date: Mon, 09 Sep 2019 12:54:12 +0100

Peter van der Stok <[email-masked]> 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

Jim Schaad <[email-masked]> 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?

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

    > actually quoting and using quotation marks.  nit: s/POP/PoP/ if we
    > don't do the literal quote.

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

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

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

    > to inject himself between a client and server even when channel binding
    > is in use.  The attack was possible because of certain (D)TLS

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

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

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  [ 
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 9 Sep 2019 09:42:33 -0500

> means that I think that Content-Format 284 (unprotected) will get used most

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.

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

We seem to have dropped enough quoting that there's not any paragraph here
that's in the current document :)

> "header".  https://datatracker.ietf.org/doc/draft-amsuess-core-accept-any/

That seems like a good point.

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

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

> Is Ben suggesting that the table should say:

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

> I not understand the question here.

I think this was about relating the strength of the symmetric encryption
key to the strength of the ephemeral asymmetric share; 7030 has some text
here (quoted above, I think) but we currently do not.  So Peter is
proposing to just crib the text from 7030.

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

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

-Ben

---

From: Michael Richardson <[email-masked]>
Date: Mon, 09 Sep 2019 17:38:23 +0100

Benjamin Kaduk <[email-masked]> 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.

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

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

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

    >> | 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'd rather have both classic-EST and coap-EST benefit than just

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

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 9 Sep 2019 11:42:40 -0500

> Updates: 7030 and this document.

Right.

-Ben

---

From: Jim Schaad <[email-masked]>
Date: Mon, 9 Sep 2019 13:17:27 -0700

-----Original Message-----
From: Michael Richardson <[email-masked]> 
Sent: Monday, September 9, 2019 9:38 AM
To: Benjamin Kaduk <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: Re: [Ace] AD review of draft-ietf-ace-coap-est-12 part 2

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

[JLS] This is the function of section 4.4.1.1 in RFC 7030 which says that
the DecryptKeyIdentifier must be present.  This will provide the EST server
a method to identify the correct key and the correct symmetric encryption
algorithm.

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

---

From: Jim Schaad <[email-masked]>
Date: Mon, 9 Sep 2019 20:34:01 -0700

Authors,

Are we ready to produce a new draft that addresses most, if not all, of
Ben's comments?  Do we have a pull request to deal with this that we can
point to?

Jim

-----Original Message-----
From: Jim Schaad <[email-masked]> 
Sent: Monday, September 9, 2019 1:17 PM
To: 'Michael Richardson' <[email-masked]>; 'Benjamin Kaduk'
<[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: RE: [Ace] AD review of draft-ietf-ace-coap-est-12 part 2

---

From: "Panos Kampanakis (pkampana)" <[email-masked]>
Date: Tue, 10 Sep 2019 04:18:01 +0000

Hi Jim,

We are tracking all of Ben's feedback here https://github.com/SanKumar2015/EST-coaps/issues/150 

The fixes that have gone in the draft so far are after each comment. There are still some that we still need to update after the threads converged. 

Panos

-----Original Message-----
From: Ace <[email-masked]> On Behalf Of Jim Schaad
Sent: Monday, September 09, 2019 11:34 PM
To: 'Michael Richardson' <[email-masked]>
Cc: [email-masked]; 'Benjamin Kaduk' <[email-masked]>; [email-masked]
Subject: Re: [Ace] AD review of draft-ietf-ace-coap-est-12 part 2

Authors,

Are we ready to produce a new draft that addresses most, if not all, of Ben's comments?  Do we have a pull request to deal with this that we can point to?

Jim

-----Original Message-----
From: Jim Schaad <[email-masked]>
Sent: Monday, September 9, 2019 1:17 PM
To: 'Michael Richardson' <[email-masked]>; 'Benjamin Kaduk'
<[email-masked]>

---

From: Peter van der Stok <[email-masked]>
Date: Tue, 10 Sep 2019 10:35:02 +0200

>> Hi all,
>> 
>> below are comments to a subset of not yet concluded review exchanges.
>> 
>> Peter
>> _______________________________________________________
>> 
>> <pvds>after ".....an /skc request.", the following text is added: 
>> 
>> <pvds3>
>> The tables seem to be full, so I left them as they were
>> </pvds3>
>> 
> <pvds3>
> slightly preferred text has been added 
> </pvds3>
> 
> <pvds3>
> I added the text:
> "This approach allows future servers to incorporate currently not specified content-formats and resources."
> 
>> Section 5.2
>> 
>> <pvds3>
>> done
>> </pvds3>

---

From: "Panos Kampanakis (pkampana)" <[email-masked]>
Date: Mon, 16 Sep 2019 17:38:59 +0000

Hi Ben,

I think we have now addressed all your feedback from the AD review. A big chunk of the changes were agreed upon in the list emails threads. 

The iteration that we are planning to upload that includes all the changes is at https://github.com/SanKumar2015/EST-coaps/blob/master/draft-ietf-ace-coap-est.txt 

The summary of all your comments and what went into the text is in the git issue https://github.com/SanKumar2015/EST-coaps/issues/150 To break it down 
- https://github.com/SanKumar2015/EST-coaps/issues/150#issue-489289217 has most of the changes agreed on the list.
-  https://github.com/SanKumar2015/EST-coaps/issues/150#issuecomment-528001807 has an answer to your question about addressing the tls-unique issue in a new draft. 
- https://github.com/SanKumar2015/EST-coaps/issues/150#issuecomment-531853281 has the last changes in response to your feedback that went into the draft after Peter uploade the -13 iteration. 

Two places to pay attention to is that I removed the 
>   security to protect against unauthorized disclosure."
and the 
>   The corresponding longer URIs from [RFC7030] MAY be supported."
The rationale behind that is in the git issue. 

Please have a look and let us know if there is anything missing. Otherwise we will upload at the end of the week. 

Rgs,
Panos

-----Original Message-----
From: Ace <[email-masked]> On Behalf Of Panos Kampanakis (pkampana)
Sent: Tuesday, September 10, 2019 12:18 AM
To: Jim Schaad <[email-masked]>; 'Michael Richardson' <[email-masked]>
Cc: [email-masked]; 'Benjamin Kaduk' <[email-masked]>; [email-masked]
Subject: Re: [Ace] AD review of draft-ietf-ace-coap-est-12 part 2

Hi Jim,

Panos

-----Original Message-----
From: Ace <[email-masked]> On Behalf Of Jim Schaad
Sent: Monday, September 09, 2019 11:34 PM
To: 'Michael Richardson' <[email-masked]>
Cc: [email-masked]; 'Benjamin Kaduk' <[email-masked]>; [email-masked]
Subject: Re: [Ace] AD review of draft-ietf-ace-coap-est-12 part 2

Authors,

Jim

-----Original Message-----
From: Jim Schaad <[email-masked]>
Sent: Monday, September 9, 2019 1:17 PM
To: 'Michael Richardson' <[email-masked]>; 'Benjamin Kaduk'
<[email-masked]>

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 23 Sep 2019 15:48:28 -0700

Hi Panos,

Sorry for the slow response here -- I was in telechat-prep mode last week.

This is in pretty good shape, and I wanted to especially thank you for the
presentation in the github issue -- that format was extremely helpful for
me.

I think we will probably need to upload one more minor revision before I
initiate the IETF LC; please seem my comments below.

In Section 4, I think we need to put the "for" back in "requests for a
trusted certificate list".

Also, refresh my memory: did we decide that there's no need to
explicitly mandate the use of the "extended_master_secret" TLS
extension?

I'd also change the note about supported_groups vs. Supported Elliptic
Curves to read "In addition, in DTLS 1.3 the Supported Elliptic Curves
extension has been renamed to Supported Groups."

I think we can move /csrattrs to the bottom of Table 2 (thank you for
changing Table 1!).

With the changes to the example in Figure 3, can you walk me through the
block-size negotiation?  Quoting:

    POST [2001:db8::2:1]:61616/est/sen(CON)(1:N1/0/256){CSR (frag# N1+1)}-->
		      |
       ... Immediate response when certificate is ready ...
		      |
      <-- (ACK) (1:N1/0/256) (2:0/1/256) (2.04 Changed){Cert resp (frag# 1)}
    POST [2001:db8::2:1]:61616/est/sen (CON)(2:1/0/128)           -->
      <-- (ACK) (2:1/1/128) (2.04 Changed) {Cert resp (frag# 2)}

So the ACK to the final fragment of the POST includes (2:0/1/256), or
the first fragment of a 256-byte-fragmented version of the response.
The client then goes and asks for (2:1/0/128), which is the second
fragment of a 128-byte-fragmented version of the response.  Is that just
going to be the last 128 bytes of the thing it already got from the
server?  If so, is that something it would actually do (e.g., if it had
to drop part of the server's response due to a buffer-size limitation)
or is it not possible to only have part of a fragment (so it would need
to either ask for (2:0/0/128) or (2:2/0/128)?

It looks like you removed the text about "[the two representations] do
not have to be in a particular order since each representation is
preceded by its Content-Format ID" based on my remark about
core-multipart-ct; that document has since been approved by the IESG and
is explicitly confirming that there is no specific ordering requirement
(in contrast to multipart/mixed), so we could put that clause back in
this document if desired.

I consider it more likely than not that a directorate reviewer will want
to tweak the added language at the end of Section 5.8 explaining our
divergence from RFC 7030; if you want to preemptively reword, my
suggestion would be "Although [RFC7030] strongly recommends that clients
request the use of CMS encryption on top of the TLS channel's
protection, this document does not make such a recommendation; CMS
encryption can still be used when mandated by the use case."

Thanks!

-Ben

---

From: "Panos Kampanakis (pkampana)" <[email-masked]>
Date: Wed, 25 Sep 2019 16:56:56 +0000

Hi Ben,

Thank you again for the additional feedback. 

The changes are summarized in the git issue https://github.com/SanKumar2015/EST-coaps/issues/150#issuecomment-535065314 I mostly made all the suggested text changes, summarized our discussion about extended-master-secret. I also made a change in Fig 2 and Fig 3 to address the issue you caught with the /128 blocks. 

The diff is here https://github.com/SanKumar2015/EST-coaps/commit/d16c53d3360430b5587021dc1a2d31f668c0c0fe . And a minor nit fix in https://github.com/SanKumar2015/EST-coaps/commit/ff5b303781231e34571352cb07fb895d5ecab791 

I will reupload early next week. Please check out the issue in case you have further comments. 

Panos

-----Original Message-----
From: Ace <[email-masked]> On Behalf Of Benjamin Kaduk
Sent: Monday, September 23, 2019 6:48 PM
To: Panos Kampanakis (pkampana) <[email-masked]>
Cc: Peter van der Stok <[email-masked]>; Jim Schaad <[email-masked]>; [email-masked]; Michael Richardson <[email-masked]>; [email-masked]
Subject: Re: [Ace] AD review of draft-ietf-ace-coap-est-12 part 2

Hi Panos,

This is in pretty good shape, and I wanted to especially thank you for the presentation in the github issue -- that format was extremely helpful for me.

I think we will probably need to upload one more minor revision before I initiate the IETF LC; please seem my comments below.

In Section 4, I think we need to put the "for" back in "requests for a trusted certificate list".

Also, refresh my memory: did we decide that there's no need to explicitly mandate the use of the "extended_master_secret" TLS extension?

I'd also change the note about supported_groups vs. Supported Elliptic Curves to read "In addition, in DTLS 1.3 the Supported Elliptic Curves extension has been renamed to Supported Groups."

I think we can move /csrattrs to the bottom of Table 2 (thank you for changing Table 1!).

With the changes to the example in Figure 3, can you walk me through the block-size negotiation?  Quoting:

So the ACK to the final fragment of the POST includes (2:0/1/256), or the first fragment of a 256-byte-fragmented version of the response.
The client then goes and asks for (2:1/0/128), which is the second fragment of a 128-byte-fragmented version of the response.  Is that just going to be the last 128 bytes of the thing it already got from the server?  If so, is that something it would actually do (e.g., if it had to drop part of the server's response due to a buffer-size limitation) or is it not possible to only have part of a fragment (so it would need to either ask for (2:0/0/128) or (2:2/0/128)?

It looks like you removed the text about "[the two representations] do not have to be in a particular order since each representation is preceded by its Content-Format ID" based on my remark about core-multipart-ct; that document has since been approved by the IESG and is explicitly confirming that there is no specific ordering requirement (in contrast to multipart/mixed), so we could put that clause back in this document if desired.

I consider it more likely than not that a directorate reviewer will want to tweak the added language at the end of Section 5.8 explaining our divergence from RFC 7030; if you want to preemptively reword, my suggestion would be "Although [RFC7030] strongly recommends that clients request the use of CMS encryption on top of the TLS channel's protection, this document does not make such a recommendation; CMS encryption can still be used when mandated by the use case."

Thanks!

-Ben

On Mon, Sep 16, 2019 at 05:38:59PM +0000, Panos Kampanakis (pkampana) wrote:
> The iteration that we are planning to upload that includes all the 
> changes is at 
> https://github.com/SanKumar2015/EST-coaps/blob/master/draft-ietf-ace-c
> oap-est.txt
> 
> The summary of all your comments and what went into the text is in the 
> git issue https://github.com/SanKumar2015/EST-coaps/issues/150 To 
> break it down
> We are tracking all of Ben's feedback here 
> https://github.com/SanKumar2015/EST-coaps/issues/150
> 
> 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.
> 
> [JLS] This is the function of section 4.4.1.1 in RFC 7030 which says 
> that the DecryptKeyIdentifier must be present.  This will provide the 
> EST server a method to identify the correct key and the correct 
> symmetric encryption algorithm.
>