Re: [Ace] [T2TRG] Constrained Node/Network Cluster @ IETF104: DRAFT AGENDA
On Feb 23, 2019, at 05:59, Carsten Bormann wrote: > > > Here is my usual eclectic condensed agenda based on the DRAFT AGENDA > for IETF104. Remember that there is still quite some potential for > changes. And how could I forget: FRIDAY, March 22, 2019 — Fri 0930–1800 T2TRG Work Meeting — Room TBD Grüße, Carsten ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] WGLC for draft-ietf-ace-coap-est
Hi Klaus,
Thanks for the thorough review.
All your issues identified are tracked here
https://github.com/SanKumar2015/EST-coaps/issues?utf8=%E2%9C%93=is%3Aissue+%22Klaus+WGLC%22
. We tried to address all of them. The fixes we are putting in are spelled out
in the github issues themselves. The actual latest version of the draft is
https://github.com/SanKumar2015/EST-coaps/blob/master/draft-ietf-ace-coap-est.txt
After proof reading the draft one more time we will upload early next week.
Below I am answering some of the questions you asked in your review.
> 4. -- Is this section about the generated certificates or the DTLS connection
> between the client and the server? If the latter, this section is weird,
> because RFC 7252 already does define MTI cipher suites and extensions, and I
> see no reason why an application layered on top of CoAP needs to restate all
> of that.
This section describes how the (D)TLS profile defined in RFC7925 is used by
EST-coaps. It was asked by the original ACE co-chair to show conformance with
ACE profiles. It touches on the client server authentication, the tunnel
ciphersuites. It explains how the EST-coaps data exchange is secured thereby
preventing eavesdropping, tampering, and message forgery. We wanted to spell
out for implementers which parts of RFC7925 they should take into consideration
instead of just pointing them to RFC7925 or RFC7252 etc.
> 4. "The authentication of the EST-coaps client MUST be with a client
> certificate in the DTLS handshake." -- Why? Why can't a client communicate
> with a server using any other secure mechanism with client authentication? Or
> is this just the MTI mechansim?
The issue is that EST mandates HTTP Basic or Digest Auth and/or client cert
auth. HTTP Auth is not defined for COAP application as far as we know. So, for
EST-coaps, the only viable authentication method is mutual cert auth. Other
client auth methods could be defined, but are outside the scope of this draft.
> 5.1. "Arbitrary Labels are usually defined and used by EST CAs in order to
> route client requests to the appropriate certificate profile." -- I assume
> that a client needs to construct URIs from the well-known path
> "/.well-known/est", the Arbitrary Label and one of the suffixes. How does a
> client determine which Arbitrary Label to use?
That is configured on the client out of band depending on the CA that generates
the certs. It is outside the scope of EST or EST-coaps.
> 5.1. "The EST-coaps server URIs, obtained through discovery of the EST-coaps
> root resource(s) as shown below, are of the form:" -- If a client discovers
> the URIs from "/.well-known/core" (annotated with "ace.est.crts",
> "ace.est.sen", etc.), is this table 1 still needed? If not, I would recommend
> that only the 'rt' values are standardized ("ace.est.crts", "ace.est.sen",
> etc.) and all paths are left to the implementation, in accordance with BCP
> 190.
We intend to require /.well-known URIs so that resource discovery is not
mandatory for pre-configured client deployments. Discovery is optional when
non-default URIs are needed to save URI space. Feel free to check the text in
https://github.com/SanKumar2015/EST-coaps/issues/123 where I edited the
resource discovery text to make it clearer.
> 5.1. "Discoverable port numbers MAY be returned in the of the payload
> [I-D.ietf-core-resource-directory]." -- What does this mean?
> And what does Resource Directory have to do with EST?
We needed a way to be able tell the client that the resource is hosted on
another port but the reference to I-D.ietf-core-resource-directory is removed
after Jim last WGLC We no longer use anchors, just an href in the payload.
Check out https://github.com/SanKumar2015/EST-coaps/issues/136
> 5.2. "Table 2 specifies the mandatory-to-implement or optional implementation
> of the est-coaps functions." -- How does a client discover which functions
> are implemented?
Client pre-configuration or optionally resource discovery. We added a reference
to the discovery section.
> 5.3. "Content-Format TBD287 can be used in place of 281" -- It's a bit
> difficult to see what TBD287 and 281 mean without scrolling all the way down
> and scrolling back up. Maybe include the table here to make the section
> easier to read?
I don't think that is necessary as we are stating that TBD287 and 281 "to carry
a single certificate instead of a PKCS#7 container in a /crts, /sen, /sren or
/skg response ". Also there is a reference to the IANA section in the paragraph
above.
> 5.7. "After a delay of Max-Age, the client SHOULD resend the identical CSR to
> the server." -- Just for my understanding: Does the submission of a specific
> CSR always lead to the same output, or can it happen (e.g., if the client
> submits an identical CSR weeks or months later) that the client would get a
> different output?
Submitting the same CSR will likely give the client a
Re: [Ace] Embedded Content Types
> -Original Message- > From: Michael Richardson > Sent: Friday, February 22, 2019 8:46 AM > To: Carsten Bormann > Cc: Jim Schaad ; Panos Kampanakis (pkampana) > ; ace ; Klaus Hartke > ; draft-ietf-ace-coap-...@ietf.org > Subject: Re: [Ace] Embedded Content Types > > > Carsten Bormann wrote: > >> I am thinking of two different URLs, that is not do the difference by > >> a query parameter but by changing the URI. > > > Note that the query parameters are part of the URI, so fundamentally > > there is no difference between putting the info there or in the path > > part of the URI. > > Really? Aren't there caching differences? > (Not that these things should ever be cached) Not in CoAP, for CoAP options are part of the cache key. I don't know for sure about HTTP but normally it says only GETs and use the URI. That would say that options are part of the cache key. Jim > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] Embedded Content Types
Carsten Bormann wrote: >> I am thinking of two different URLs, that is not do the difference by >> a query parameter but by changing the URI. > Note that the query parameters are part of the URI, so fundamentally > there is no difference between putting the info there or in the path > part of the URI. Really? Aren't there caching differences? (Not that these things should ever be cached) -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] EDHOC standardization
Hi Hannes, No wonder that ECDHE-PSK is not widely used in (D)TLS when the relevant ECDHE-PSK cipher suites TLS_ECDHE_PSK_WITH_AES_128_CCM_8_SHA256 for TLS 1.2 (and similarly ECDHE + PSK + TLS_AES_128_CCM_8_SHA256 for TLS 1.3) were standardized just a few months ago (RFC 8442 and RFC 8446). Luckily most, if not all TLS 1.3 implementations are likely to support ECDHE + PSK + TLS_AES_128_CCM_8_SHA256. Similarly, PRK (RFC 7250) is not supported in many TLS implementations (e.g. it is not supported in mbed TLS). The main use case for RPK and self-signed certificates are not as a replacement for PKI, it's a replacement for symmetrical group keys. My experience is that almost all IoT devices are capable of doing ECDH and doing so is very important as a way to get PFS. As required by RFC 725, IEFT protocols need to mitigate pervasive monitoring and one very effective way is to use PFS. Looking at a lot of currently deployed IoT systems makes me sad, if security is used at all, it is often hop-by-hop and often not over the full path. The systems seldom provide PFS and in many cases use symmetrical group keys where they should not. A common reason that systems do not use PFS is because they think it’s an easy way to enable intercept. IETF has a role to educate and guide people on what to use. I think that IETF should strongly recommend PFS in all use cases and recommend using RPK/ self-signed certificates instead of group keys where possible. A pre-requisite for doing so is to provide protocols that can be used even in very constrained systems. Cheers, John -Original Message- From: Hannes Tschofenig Date: Wednesday, 21 November 2018 at 16:16 To: John Mattsson , "ace@ietf.org" , "l...@ietf.org" Cc: Benjamin Kaduk , "salvador@um.es" Subject: RE: [Ace] EDHOC standardization Hi John, From our experience neither PSK+ECDHE nor RPK usage is common in IoT deployments among the bigger IoT providers. Today, most companies use certificate-based authentication in almost all cases. In some cases plain PSK is used for those cases where devices are particularly constraint. Ciao Hannes -Original Message- From: Ace On Behalf Of John Mattsson Sent: Wednesday, November 21, 2018 4:03 PM To: ace@ietf.org; l...@ietf.org Cc: Benjamin Kaduk ; salvador@um.es Subject: Re: [Ace] EDHOC standardization Hi all, Inspired by the discussion in this thread, I did more detailed calculations of the number of bytes when DTLS 1.3 is used for typical IoT use cases (PSK, RPK, Connection ID). The plan is to add this information to draft-ietf-lwig-security-protocol-comparison as this has been requested by several people. I think some bytes were missing in the earlier estimates for TLS 1.3, and as Ben commented, DTLS 1.3 adds some bytes compared to TLS 1.3. == Flight#1 #2#3 Total -- DTLS 1.3 RPK + ECDHE 149373 213735 DTLS 1.3 PSK + ECDHE 18619057433 DTLS 1.3 PSK 13615057343 -- EDHOCRPK + ECDHE 3812186245 EDHOCPSK + ECDHE 43 4712102 == Number of bytes Assumptions: - Minimum number of algorithms and cipher suites offered - Curve25519, ECDSA with P-256, AES-CCM_8, SHA-256 - Length of key identifiers: 4 bytes - Connection identifiers: 1 byte - The DTLS RPKs use point compression (saves 32 bytes) - No DTLS handshake message fragmentation - Only mandatory DTLS extentions, except for connection ID - Version 30 https://tools.ietf.org/html/draft-ietf-tls-dtls13-30 (EDHOC numbers are for the soon to be published -11 version with cipher suites) I hope this information is useful for people. Please comment if I missed something or if you have any suggestion of things to add or how to present things. I do not know currently how these numbers compare to DTLS 1.2. Below is detailed information about where the byte in different flights as well as the RPKs (SubjectPublicKeyInfo). Most of the bytes should have the correct value, but most of the length fields are just written as LL LL LL. Below is also information about how resumption, cached information [RFC 7924], and not using Connection ID affects the number of bytes. == DTLS 1.3 Flight #1 RPK + ECDHE == Record Header - DTLSPlaintext (13 bytes) 16 fe fd EE EE SS SS SS SS SS SS LL LL Handshake Header - Client Hello (10 bytes) 01 LL LL LL SS
