Re: [Ace] edhoc section 4: N_U/N_V question

[John Mattsson]

N_U serves as a session identifier. That is the reason it is bounced back in 
message_2.

Both N_U and N_V is not needed in message_3. In the updated version on  Github 
only a single session identifier is used in message_3

Sent from my Cray-1

> On 24 Feb 2017, at 15:07, Göran Selander  wrote:
> 
> Michael, 
> 
> This has already been updated in the latest version on the Github:
> https://ericssonresearch.github.io/EDHOC/
> 
> 
> As I mentioned we will submit to the IETF a new version next week, pending
> some expected review comments.
> 
> Göran
> 
> 
>> On 2017-02-24 14:15, "Michael Richardson"  wrote:
>> 
>> 
>> N_U, N_V, E_V, Alg_V, Enc(K_VE; ID_V, Sig(V; Mac(K_VM; prot_2)))|
>>   | <---+
>>   | message_2
>> |
>>   |
>> |
>>   | |
>>   |N_U, N_V, Enc(K_UE; ID_U, Sig(U; Mac(K_UM; prot_3)))
>> 
>> Why is N_U echoed back to U in message 2?
>> Why are N_U and N_V included in message 3?
>> 
>> If the nonce acts as a defense against off-path attacks, then at least
>> N_U does not need to be in message 3.  Including N_U in message 2 defends
>> an off-path attacker racing V to reply to message_1, which seems unlikely.
>> 
>> 
>> --
>> Michael Richardson , Sandelman Software Works
>> -= IPv6 IoT consulting =-
>> 
>> 
>> 
> 

___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

[Ace] Coordinated effort to produce updated profiles for the use of crypto algorithms in IoT

[John Mattsson]

I strongly support Carsten’s suggestion to have a coordinated effort to produce 
updated profiles for the use of crypto algorithms in IoT. I think the work 
should include at least TLS, DTLS, COSE, and X.509 and take into consideration 
the hardware acceleration available in (future) devices. Should also look if 
there is a need to update X.509 profile in RFC 7925, any new IoT profile should 
be applicable to both TLS and COSE.

How do we get this started in a way that applies to all IETF groups using 
crypto? I would be happy to help with this work.

Some quick thoughts:

- Curve25519 is already implemented a lot, but needs to be differentiated from 
Ed25519 which is not implemented as much (yet) and may require CA support for 
certificate based deployments. Curve25519 and Ed25519 has a strong potential to 
lower latency, storage, memory, and battery consumptions in IoT devices. There 
was earlier vendors stating that curves with a cofactor caused problems for 
older hardware. My understanding is that this has now changed, at least the 
UICC vendors in 3GPP has stated that curve25519 works on their current hardware.

- ChaCha20-Poly1305 is only standardized with 128-bit tags and therefore not 
very well suited for IoT. Like GCM, Poly1305 is not very well suited for 
truncated tags. AES_128_OCB_8 only requires half the amount of AES operations, 
but AES is not drawing much power compared to transmitting, listening, and 
receiving radio, so any update from AES_128_CCM_8 might not be worth it. I 
think 64 bit tags is a good compromised between overhead and security for IoT.

-  PRF. TLS 1.3 used HMAC with SHA-256, RFC8247 specifies PRF_AES128_XCBC for 
devices not having SHA.

- Hash algorithms, Ed25519 is as far as I known standardized with SHA-512/256. 
IoT deployments of TLS and DTLS typically use SHA-256.

Cheers,
John
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] New Version Notification for draft-selander-ace-cose-ecdhe-10.txt

[John Mattsson]

Hi,

We just submitted version 10 of EDHOC, the new version adds quite a lot of 
clarifications and examples and adds some new optimizations. In particular:

- The introduction has been expanded to better describe the security properties 
of EDHOC, the motivation behind it, and the structure of the document.
- The key derivation is described in terms of a function 
EDHOC-Key-Derivation(AlgorithmID, keyDataLength, other) and an Exporter 
interface EDHOC-Exporter(label, length). Appendix C and D now uses the exporter 
interface.
- More information and examples on different ways to identify public keys. More 
security details regarding identities as suggested by University of Copenhagen.
- Updated CCDL definitions with .cbor and .cborseq
- Changes aad_i and exchange_hash definitions to make implementations more 
optimized
- The algorithm arrays are now defined as algs = alg / [ 2* alg ], an idea 
borrowed from draft-schaad-cose-x509
- Renamed session IDs to connection IDs to make the purpose clearer.
- More explanation and clarification on how error messages work and how they 
interact with lower layers as requested by Jim Schaad.
- Modified the error handling to allow truncation of the list of supported 
algoritms.
- IANA section to register a Content-Format
- Added an appendix shortly explaining CBOR, CDDL, and COSE to developers of 
EDHOC (as suggested by Klaus Hartke)
- Significantly expanded security considerations section, now divided in 
subsections.
- Expanded the message size appendix to also cover PSK and certificate. 
Compared to the TLS 1.3 handshake with TLS 1.3 the number of bytes in EDHOC is 
less than 1/3 when PSKauthentication is used and less than 1/2 when RPK 
authentication is used

 PSK   RPK   x5t x5chain
    
   message_1  47444444  
   message_2  49   125   131   121 + Certificate chain  
   message_3  12869282 + Certificate chain  
    
   Total 108   255   267   247 + Certificate chains 

 Figure : Typical message sizes in bytes

Cheers,
John

On 2018-09-18, 13:15, "internet-dra...@ietf.org"  
wrote:


A new version of I-D, draft-selander-ace-cose-ecdhe-10.txt
has been successfully submitted by John Mattsson and posted to the
IETF repository.

Name:   draft-selander-ace-cose-ecdhe
Revision:   10
Title:  Ephemeral Diffie-Hellman Over COSE (EDHOC)
Document date:  2018-09-18
Group:  Individual Submission
Pages:  44
URL:
https://www.ietf.org/internet-drafts/draft-selander-ace-cose-ecdhe-10.txt
Status: https://datatracker.ietf.org/doc/draft-selander-ace-cose-ecdhe/
Htmlized:   https://tools.ietf.org/html/draft-selander-ace-cose-ecdhe-10
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-selander-ace-cose-ecdhe
Diff:   
https://www.ietf.org/rfcdiff?url2=draft-selander-ace-cose-ecdhe-10

Abstract:
   This document specifies Ephemeral Diffie-Hellman Over COSE (EDHOC), a
   very compact, and lightweight authenticated Diffie-Hellman key
   exchange with ephemeral keys that can be used over any layer.  EDHOC
   provides mutual authentication, perfect forward secrecy, and identity
   protection.  EDHOC uses CBOR and COSE, allowing reuse of existing
   libraries.


  


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat


___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

[Ace] Minimizing overhead of certificates in constrained IoT

[John Mattsson]

Hi,

We recently submitted 
https://tools.ietf.org/html/draft-raza-ace-cbor-certificates-00, which build on 
research done by Research Institutes of Sweden, Royal Institute of Technology 
in Stockholm, and Nexus:

https://kth.diva-portal.org/smash/get/diva2:1153958/FULLTEXT01.pdf
https://doi.org/10.1007/978-3-319-93797-7_14

The mechanism in the draft aims to reduce message overhead with the approach to 
start with a heavily profiled X.509 certificate and encode it to CBOR, 
resulting in around 50% savings in message overhead and storage. A major reason 
for submitting this early draft is to start a discussion on how to minimize the 
overhead (message size, code size, memory, storage, processing, etc.) caused by 
certificates in IoT deployments.

Current X.509 certificates are demanding in several ways (message, code size, 
memory, processing, etc. and are not designed for constrained IoT environments. 
The quite large sizes of even well profiled X.509 certificates mean that they 
take up a large part of the total number of bytes when used in protocols. 
Transmitting, receiving, or even listening for radio is relatively expensive in 
terms of power consumption and as the radio resources are often constrained, 
large messages lead to interference and therefore more latency than just the 
message sizes would infer.

That fact that certificates are sent encrypted in new protocols (TLS 1.3, DTLS 
1.3, EDHOC) means that compression in intermediaries will not work in the 
future. TLS 1.3 and DTLS 1.3 are currently looking at certificate compression, 
but these mechanisms are not optimal for constrained IoT. The use of general 
lossless compression algorithms are quite heavy, and they do not compress 
things optimally.

With the submission of raft-raza-ace-cbor-certificates we would like to start a 
discussion on how to minimize the overhead caused by certificates.

- Which aspects do the community prioritise the most? i.e. message size, code 
size, memory, processing, etc. And how should trade-offs between these aspects 
look like?

- For how long time is people planning to use older protocols that do not 
encrypt certificates? Is it worth specifying gateway type of compression for 
these protocols?

draft-raza-ace-cbor-certificates does currently take the approached to start 
with a heavily profiled X.509 certificate and encode it to CBOR. Another 
approach is to not start with X.509 and do certificates in CBOR directly. This 
can be even more optimal from a theoretical point of view but may never 
deployed. Previous attempts to introduce new certificate types seem to have 
failed. On the other hand the current mechanism increases code size and 
processing for the part verifying the certificate.

- How should new IoT CBOR certificates be introduced in protocols? As a new 
type of certificate or a new compression/encoding algorithm for certificates? 
Is compression/encoding done inside the protocol or outside of the protocol?

- Is CBOR the correct choice if a new encoding is specified? We certainly think 
so.

- What are peoples’ opinions on general lossless compression algorithms?

- Which protocols would the IoT community want to use with new 
certificates/encoding/compression?

I think that a good place to start a discussion about these topics would be in 
T2TRG. If people find this interesting, I suggest having a quick introduction 
on the Friday plenary session and then further discussions in the security 
breakout.

Cheers,
John

___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] EDHOC standardization

[John Mattsson]

Hi Salvador, Michael,

Regarding your comments on negotiation and out-of-band. We have gotten similar 
comments from Klaus Hartke regarding cipher suites and out-of-band. I added 
your comments to the open issue on GitHub

https://github.com/EricssonResearch/EDHOC/issues/57

We agree with you both, this can and should be optimized, but some kind of 
negotiation is still needed. The current plan for the next version is to 
introduce cipher suites and to let the cipher suite with value 0 indicate that 
algorithms have been negotiated out-of-band. For the constrained deployments 
targeted by EDHOC, I think this might be the best trade-off between 
negotiation, overhead, and simplicity. While I think TLS 1.3 did the right 
thing to split up the cipher suites, I agree that for most constrained IoT 
deployments, the implemented algorithm(s) will often be the same for all nodes 
and fixed for long periods of time. As you stated Salvador, this would be an an 
important optimization. The message sizes would look as follows:

 PSK   RPK   x5t x5chain
   
   message_1  43383838
   message_2  47   121   127   117 + Certificate chain
   message_3  12869282 + Certificate chain
   
   Total 102   245   257   237 + Certificate chains

 Figure 6: Typical message sizes in bytes

Cheers,
John

Michael Richardson wrote:

> we have implemented a previous version of EDHOC
> (draft-selander-ace-cose-ecdhe) and want to share some experiences.

That's very cool.
Some questions for you!

> Our work so far has focused on implementation and evaluation of version
> -08 of EDHOC over CoAP using real IoT hardware. The obtained results
> show a significant performance improvement compared to other key
> establishment protocols, such as DTLS handshake (version 1.2),
> especially with respect to length and number of exchanged messages.

What did you use for authentication?  RSA? ECDSA? EDDSA? PSK?
Were they raw public keys, or was it in a certificate?
Did you try a certificate in one direction and a raw public key in the other?
Did you offer more than 1 algorithm when you negotiated?

> We have reviewed version -10 and noted the reduction of message
> length. Based on our experience, we propose that also removing the
> overhead due to security parameter negotiation could be an important
> optimization, and relevant in many use cases where these parameters are
> available through an out-of-band process.

If the list of valid algorithms is available securely by out-of-band
processes, then couldn't use this mechanism to do key agreement instead,
saving 100% of the bytes on the wire?  :-)

We need to do security parameter negotiation in order to be agile against
future algorithm attacks, and there will be algorithm attacks in the 20 to
40 year lifespans that we expect... and we need to leave space for replacing
the DH process with some QMDH process.  The CBOR encoding is really really
very nice for this, and I wish we had CBOR when we did IKEv2.

> Accordingly and taking into account that EDHOC provides a basic
> security functionality for any context where security needs to be
> enabled, we are currently considering the application of this protocol
> in different IoT deployments, such as LoRaWAN networks, OSCORE-enabled
> scenarios or its integration with capabilities. We therefore would like
> to see the progress of EDHOC in standardization.

I don't see how LORaWAN has enough bytes available for even EDHOC.
I think that LoRaWAN needs a key agreement protocol that can be run once
while the sensor is attached to the installer's smartphone.  The important
thing is that one is able to use the key agrement protocol over IPs A<->B,
in order to setup a context that can be used between IPs C<-->D.

___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] EDHOC standardization

[John Mattsson]

Hi Benjamin, Salvador

While DTLS 1.3 have done a very good job of lowering the overhead of the record 
layer when application data is sent (see e.g. 
https://tools.ietf.org/html/draft-ietf-lwig-security-protocol-comparison-01 for 
a comparison between different protocols), I do not think the handshake 
protocol is much leaner (is it leaner at all?).

We tried to make an fair comparison between EDHOC and TLS 1.3 in the 
presentation at IETF 101 (see 
https://datatracker.ietf.org/meeting/101/materials/slides-101-ace-key-exchange-w-oscore-00).
 Since then, we have significantly optimized the encoding in EDHOC and the 
upcoming version (-11) is expected to have the following message sizes.

   Auth.   PSK   RPK   x5t x5chain
   
   EDHOC message_1  43383838
   EDHOC message_2  47   121   127   117 + Certificate chain
   EDHOC message_3  12869282 + Certificate chain
   
   Total   102   245   257   237 + Certificate chains

As Salvador writes, the handshakes in TLS 1.3 and DTLS 1.3 are basically the 
same, so the numbers presented at IETF 101 should be a good estimate also for 
DTLS 1.3.

   Auth.PSK   RPK
   
   (D)TLS message_1 142   107
   (D)TLS message_2 135   264
   (D)TLS message_3  51   167
   
   Total328   538

The numbers above include ECDHE. For handshake messages, my understanding is 
that the DTLS 1.3 and TLS 1.3 record layer have exactly the same size.

Cheers,
John

> Salvador Pérez wrote:

Hi Benjamin,

our results are included in a paper, which is under review for its 
publication.

Regarding the comparison between EDHOC and DTLS, we have employed the tinydtls 
library [1] since it is widely used to deploy DTLS in different IoT scenarios. 
Note that, at the moment in which the paper was written, such library did not 
offer support for version 1.3. Anyway, DTLS 1.3 is essentially using the same 
handshake as TLS 1.3 ("DTLS 1.3 re-uses the TLS 1.3 handshake messages and 
flows” [2]). Moreover, authors of EDHOC state that the message overhead of TLS 
1.3 is much higher than EDHOC ("Compared to the TLS 1.3 handshake with ECDH, 
the number of bytes in EDHOC is less than 1/3 when PSK authentication is used 
and less than 1/2 when RPK authentication is used, see Appendix E” [3-4]). 
Accordingly, we can claim that it is expected that DTLS 1.3 performs worse than 
EDHOC (at least, regarding message overhead) for the type of constrained 
implementations we are looking at.

[1] https://projects.eclipse.org/projects/iot.tinydtls 

[2] https://tools.ietf.org/html/draft-ietf-tls-dtls13-29#section-5 

[3] https://tools.ietf.org/html/draft-selander-ace-cose-ecdhe-10#section-1 

[4] https://tools.ietf.org/html/draft-selander-ace-cose-ecdhe-10#appendix-E.4 


Kind regards,


Salvador Pérez
PhD student in "Future Internet Networks: Infrastructure and Security”
Faculty of Computer Science - University of Murcia
Email: salvador@um.es
Skype: salva.pf

> On 31 Oct 2018, at 16:43, Benjamin Kaduk ; wrote:
> 
> Hi Salvador,
> 
> On Wed, Oct 31, 2018 at 10:12:54AM +0100, Salvador Pérez wrote:
>> Hello authors of EDHOC,
>> 
>>  we have implemented a previous version of EDHOC 
>> (draft-selander-ace-cose-ecdhe) and want to share some experiences.
>> 
>> Our work so far has focused on implementation and evaluation of version -08 
>> of EDHOC over CoAP using real IoT hardware. The obtained results show a 
>> significant performance improvement compared to other key establishment 
>> protocols, such as DTLS handshake (version 1.2), especially with respect to 
>> length and number of exchanged messages.
> 
> Are your results written up anywhere?  It would be great to see more
> details of the comparison and the actual numbers.
> Unfortunately, I don't think that DTLS 1.2 is the best comparison -- DTLS
> 1.3 should be seen as the current "state of the art" for DTLS, and is
> expected to itself be leaner than DTLS 1.2, which might wash out some of
> the results you've seen here.
> 
> Thanks,
> 
> Ben
> 
>> We have reviewed version -10 and noted the reduction of message length. 
>> Based on our experience, we propose that also removing the overhead due to 
>> security parameter negotiation could be an important optimization, and 
>> relevant in many use cases where these parameters are a

Re: [Ace] EDHOC standardization

[John Mattsson]

Hi Owen,

In constrained radio deployments where throughput is the limiting factor, the 
number of bytes in the bootstrapping can make a huge difference.

The number of bytes is directly related to the minimum number of frames (in 
6tisch each frame can typically carry around 80 bytes of payload) and therefore 
the number of round-trips and the time taken to bootstrap a new device.

If you have multiple devices bootstrapping at the same time, which is often the 
case, the relation between the number of bytes, the number of devices, and the 
bootstrapping time for the whole system is non-linear and even with a moderate 
number of devices, you quickly start to see bootstrapping taking forever or not 
finishing at all.

Cheers,
John

-Original Message-
From: "Owen Friel (ofriel)" 
Date: Monday, 5 November 2018 at 18:07
To: John Mattsson , "salvador@um.es" 
, "ka...@mit.edu" , "ace@ietf.org" 

Subject: RE: [Ace] EDHOC standardization

Hi John, Salvador,
As EDHOC is used purely for key derivation with key exporting to the 
application for ciphertext exchange, does the lower byte count overhead of the 
EDHOC handshake vs DTLS1.3 really matter that much?  Of course that depends on 
the amount of application ciphertext, but if there is a sufficient number of 
ciphertext bytes to be exchanged in one session, then DTLS + key exporting may 
make more sense than EDHOC + key exporting.
Owen

-Original Message-----
From: Ace  On Behalf Of John Mattsson
Sent: Friday 2 November 2018 14:56
To: salvador@um.es; ka...@mit.edu; ace@ietf.org
Subject: Re: [Ace] EDHOC standardization

Hi Benjamin, Salvador

While DTLS 1.3 have done a very good job of lowering the overhead of the record 
layer when application data is sent (see e.g. 
https://tools.ietf.org/html/draft-ietf-lwig-security-protocol-comparison-01 for 
a comparison between different protocols), I do not think the handshake 
protocol is much leaner (is it leaner at all?).

We tried to make an fair comparison between EDHOC and TLS 1.3 in the 
presentation at IETF 101 (see 
https://datatracker.ietf.org/meeting/101/materials/slides-101-ace-key-exchange-w-oscore-00).
 Since then, we have significantly optimized the encoding in EDHOC and the 
upcoming version (-11) is expected to have the following message sizes.

   Auth.   PSK   RPK   x5t x5chain
   
   EDHOC message_1  43383838
   EDHOC message_2  47   121   127   117 + Certificate chain
   EDHOC message_3  12869282 + Certificate chain
   
   Total   102   245   257   237 + Certificate chains

As Salvador writes, the handshakes in TLS 1.3 and DTLS 1.3 are basically the 
same, so the numbers presented at IETF 101 should be a good estimate also for 
DTLS 1.3.

   Auth.PSK   RPK
   
   (D)TLS message_1 142   107
   (D)TLS message_2 135   264
   (D)TLS message_3  51   167
   
   Total328   538

The numbers above include ECDHE. For handshake messages, my understanding is 
that the DTLS 1.3 and TLS 1.3 record layer have exactly the same size.

Cheers,
John

> Salvador Pérez wrote:

Hi Benjamin,

our results are included in a paper, which is under review for its 
publication.

Regarding the comparison between EDHOC and DTLS, we have employed the tinydtls 
library [1] since it is widely used to deploy DTLS in different IoT scenarios. 
Note that, at the moment in which the paper was written, such library did not 
offer support for version 1.3. Anyway, DTLS 1.3 is essentially using the same 
handshake as TLS 1.3 ("DTLS 1.3 re-uses the TLS 1.3 handshake messages and 
flows” [2]). Moreover, authors of EDHOC state that the message overhead of TLS 
1.3 is much higher than EDHOC ("Compared to the TLS 1.3 handshake with ECDH, 
the number of bytes in EDHOC is less than 1/3 when PSK authentication is used 
and less than 1/2 when RPK authentication is used, see Appendix E” [3-4]). 
Accordingly, we can claim that it is expected that DTLS 1.3 performs worse than 
EDHOC (at least, regarding message overhead) for the type of constrained 
implementations we are looking at.

[1] https://projects.eclipse.org/projects/iot.tinydtls 
<https://projects.eclipse.org/projects/iot.tinydtls>
[2] https://tools.ietf.org/html/draft-ietf-tls-dtls13-29#section-5 
<https://tools.ietf.org/html/draft-ietf-tls-dtls13-29#section-5>
[3] https://tools.ietf.org/html/draft-selander-ace-cose-ecdhe-10#section-1 
<https://tools.ietf.org/html/draft-selander-ace-cose-ecdhe-10#section-1>
[4] https://tools.ietf.org/html/draft-sela

Re: [Ace] EDHOC standardization

[John Mattsson]

ion
-

0x30 // Sequence
0x59 // Size 89

0x30 // Sequence
0x13 // Size 19
0x06 0x07 0x2A 0x86 0x48 0xCE 0x3D 0x02 0x01. // OID 1.2.840.10045.2.1 
(ecPublicKey)
0x06 0x08 0x2A 0x86 0x48 0xCE 0x3D 0x03 0x01 0x07 // OID 1.2.840.10045.3.1.7 
(secp256r1)

0x03 // Bit string
0x42 // Size 66
0x00 // Unused bits 0
0x04 // Uncompressed
.. 64 bytes X and Y

Total of 91 bytes

SubjectPublicKeyInfo with point compression
-

0x30 // Sequence
0x59 // Size 89

0x30 // Sequence
0x13 // Size 19
0x06 0x07 0x2A 0x86 0x48 0xCE 0x3D 0x02 0x01. // OID 1.2.840.10045.2.1 
(ecPublicKey)
0x06 0x08 0x2A 0x86 0x48 0xCE 0x3D 0x03 0x01 0x07 // OID 1.2.840.10045.3.1.7 
(secp256r1)

0x03 // Bit string
0x42 // Size 66
0x00 // Unused bits 0
0x03 // Compressed
.. 32 bytes X

Total of 59 bytes


==
Helpful Sources of Information
==

In addition to relevant RFCs and the estimates done by Jim, the following
references were helpful:

Every Byte Explained: The Illustrated TLS 1.3 Connection
https://tls13.ulfheim.net/

Digital Certificates for the Internet of Things
https://kth.diva-portal.org/smash/get/diva2:1153958/FULLTEXT01.pdf

/John




-Original Message-
From: Benjamin Kaduk 
Date: Saturday, 3 November 2018 at 15:59
To: John Mattsson 
Cc: "salvador@um.es" , "ace@ietf.org" 
Subject: Re: [Ace] EDHOC standardization

On Fri, Nov 02, 2018 at 02:55:54PM +, John Mattsson wrote:
> Hi Benjamin, Salvador
> 
> While DTLS 1.3 have done a very good job of lowering the overhead of the 
> record layer when application data is sent (see e.g. 
> https://tools.ietf.org/html/draft-ietf-lwig-security-protocol-comparison-01 
> for a comparison between different protocols), I do not think the handshake 
> protocol is much leaner (is it leaner at all?).

(There are some handshake messages that are removed entirely.)

> We tried to make an fair comparison between EDHOC and TLS 1.3 in the 
> presentation at IETF 101 (see 
> https://datatracker.ietf.org/meeting/101/materials/slides-101-ace-key-exchange-w-oscore-00).
>  Since then, we have significantly optimized the encoding in EDHOC and the 
> upcoming version (-11) is expected to have the following message sizes.
> 
>Auth.   PSK   RPK   x5t x5chain
>
>EDHOC message_1  43383838
>EDHOC message_2  47   121   127   117 + Certificate chain
>EDHOC message_3  12869282 + Certificate chain
>
>Total   102   245   257   237 + Certificate chains
> 
> As Salvador writes, the handshakes in TLS 1.3 and DTLS 1.3 are basically the 
> same, so the numbers presented at IETF 101 should be a good estimate also for 
> DTLS 1.3.
> 
>Auth.PSK   RPK
>
>(D)TLS message_1 142   107
>(D)TLS message_2 135   264
>(D)TLS message_3  51   167
>
>Total328   538

Thanks for the numbers!

> The numbers above include ECDHE. For handshake messages, my understanding is 
> that the DTLS 1.3 and TLS 1.3 record layer have exactly the same size.

The DTLS 1.3 ones will be worse, due to the epoch and sequence number
fields.

-Ben

___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] EDHOC standardization

[John Mattsson]

Hi Hannes,

Good point, detailed data for EDHOC is available in Appendix E of 
draft-selander-ace-cose-ecdhe-10.

https://tools.ietf.org/html/draft-selander-ace-cose-ecdhe-10#page-40

The assumptions there are the same:
- Minimum number of algorithms and cipher suites offered
- Curve25519, AES-CCM_8, SHA-256, EdDSA (same signature size as ECDSA)
- Length of key identifiers: 4 bytes
- Connection identifiers: 1 byte

draft-selander-ace-cose-ecdhe-11 will contain similar information but with 
cipher suites.

Cheers,
John

-Original Message-
From: Hannes Tschofenig 
Date: Wednesday, 21 November 2018 at 16:22
To: John Mattsson , "ace@ietf.org" , 
"l...@ietf.org" 
Cc: Benjamin Kaduk , "salvador@um.es" 
Subject: RE: [Ace] EDHOC standardization

John, could you also add the detailed data for EDHOC as well?
(And thanks for the details regarding the DTLS numbers.)

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 SS 00 00 00 LL LL LL

Legacy Version (2 bytes)
fe fd

Client Random (32 bytes)
00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13 14 15 16 17 18 19 
1a 1b 1c 1d 1e 1f

Legacy Session ID (1 bytes)
00

Cipher Suites (TLS_AES_128_CCM_8_SHA256) (4 bytes)
00 02 13 05

Compression Methods (null) (2 bytes)
01 00

Extensions Length (2 bytes)
LL LL

Extension - Supported Groups (x25519) (8 bytes)
00 0a 00 04 00 02 00 1d

Extension - Signature Algorithms (ecdsa_secp256r1_sha256) (8 bytes)
00 0d 00 04 00 02 08 07

Extension - Key Share (42 bytes)
00 33 00 26 00 24 00 1d 00 20
00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13 14 15 16 17 18 19 
1a 1b 1c 1d 1e 1f

Extension - Supported Versions (1.3) (7 bytes)
00 2b 00 03 02 03 04

Extension - Client Certificate Type (Raw Public Key) (6 bytes)
00 13 00 01 01 02

Extension - Server Certificate Type (Raw Public Key) (6 bytes)
00 14 00 01 01 02

Extension - Connection Identifier (43) (6 bytes)
XX XX 00 02 01 42

13 + 10 + 2 + 32 + 1 + 4 + 2 + 2 + 8 + 8 + 42 + 7 + 6 + 6 + 6 = 149 bytes

--
DTLS 1.3 Flight #1 PSK + ECDHE
--

Differences compared to RPK 

Re: [Ace] EDHOC standardization

[John Mattsson]

 #3 RPK + ECDHE
==

Record Header - TLSCiphertext (5 bytes)
17 03 03 LL LL

Handshake Header - Certificate (4 bytes)
0b LL LL LL

Request Context (1 bytes)
00

Certificate List Length (3 bytes)
LL LL LL

Certificate Length (3 bytes)
LL LL LL

Certificate (59 bytes) // Point compression


Certificate Extensions (2 bytes)
00 00

Handshake Header - Certificate Verify (4 bytes) 
0f LL LL LL

Signature  (68 bytes)
04 03 LL LL //ecdsa_secp256r1_sha256
00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13 14 
15 16 17 18 19 1a 1b 1c 1d 1e 1f
00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13 14 
15 16 17 18 19 1a 1b 1c 1d 1e 1f

Handshake Header - Finished (4 bytes)
14 LL LL LL

Verify Data (32 bytes) // SHA-256
00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13 14 
15 16 17 18 19 1a 1b 1c 1d 1e 1f

Record Type (1 byte)
16

Auth Tag (8 bytes) // AES-CCM_8
00 01 02 03 04 05 06 07

5 + 72 + 72 + 36 + 1 + 8 = 194 bytes

--
TLS 1.3 Flight #3 PSK + ECDHE
-

Differences compared to RPK + ECDHE

- Handshake Message Certificate (72 bytes)

- Handshake Message Certificate Verify (72 bytes)

194 - 72 - 72 = 50 bytes

--
TLS 1.3 Flight #3 PSK
-

Differences compared to PSK + ECDHE

None

50 bytes


-Original Message-
From: Jim Schaad 
Date: Wednesday, 21 November 2018 at 16:25
To: John Mattsson , "ace@ietf.org" , 
"l...@ietf.org" 
Cc: 'Benjamin Kaduk' , "salvador@um.es" 
Subject: RE: [Ace] EDHOC standardization

John,

In the analysis that I did I very deliberately used TLS not DTLS.  The main 
reason for using DTLS is because one is operating in the UDP environment and 
one cannot have reliable in order delivery.  Since EDHOC is being built on top 
of CoAP, one can use CoAP to create reliable in order delivery.  Thus the extra 
bytes that DTLS has to deal with this are not needed.

Jim


> -Original Message-
> From: Ace  On Behalf Of John Mattsson
> Sent: Wednesday, November 21, 2018 7:03 AM
> 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 th

Re: [Ace] [Lwip] (protocol flows) Re: EDHOC standardization

[John Mattsson]

Hi Rene,

These are interesting ideas. As you say, EDHOC is currently optimized for a 
minimum number of messages and bytes. Spreading out the bytes and computations 
could be beneficial in some applications. EDHOC is currently based on SIGMA-I. 
The four-message variant would be based on SIGMA-R with basically the same 
security properties. The difference would be that SIGMA-I protects the 
initiator identity against active attackers and the non-initiator identity 
against passive attackers. SIGMA-R does the opposite. I think protection models 
are needed in practice, but could also be solved by letting the initiator 
telling the other party to start SIGMA-I.

Party U   Party V
|  C_U, CIPHER_SUITEs_U, CIPHER_SUITE_U, X_U|
+-->|
| message_1 |
|   |
|   C_U, C_V, X_V   |
|<--+
| message_2 |
|   |
|  C_V, AE(K_3; ID_CRED_U, Sig(U; CRED_U, aad_3) )  |
+-->|
| message_3 |
|   |
|  C_U, AE(K_4; ID_CRED_V, Sig(V; CRED_V, aad_4) )  |
|<--+
| message_4 |

I get the following message sizes for EDHOC when I apply SIGMA-R to
version -11 of EDHOC.


Flight#1  #2 #3 #4 Total

DTLS 1.3 RPK + ECDHE 150 373213  736
DTLS 1.3 PSK + ECDHE 187 190 57  434
DTLS 1.3 PSK 137 150 57  344

EDHOC RPK + ECDHE (SIGMA-I)   39 120 85  244
EDHOC RPK + ECDHE (SIGMA-R)   39  37 85 84   245
EDHOC PSK + ECDHE 44  46 11  101


Regarding computations, I guess the main difference when it comes to 
asymmetrical crypto computations would be that Party V can compute a shared 
secret in between flight #2 and flight #3. Or are the any additional benefits?

SIGMA-I:

Party U   Party V

generate a key pair
+---#1->|
  generate a key pair (can be done before #1)
  compute a shared secret
 sign
|<--#2--+
compute a shared secret
verify
sign
+---#3->|
   verify

SIGMA-R:

Party U   Party V

generate a key pair
+---#1->|
  generate a key pair (can be done before #1)
  compute a shared secret (can be done between #2 and #3)
|<--#2--+
compute a shared secret
sign
+---#3->|
   verify
 sign
|<--#4--+
verify

The optimization to split up the ECDSA Signature (R, S) and send R in the 
beginning is interesting, but as far as I understand, this only works for ECDSA 
and there is no similar trick for Ed25519 as both R and S depends on the 
message M.

SIGMA-I:

Party U   Party V
|   C_U, CIPHER_SUITEs_U, CIPHER_SUITE_U, X_U, R_U  |
+-->|
| message_1 |
|   |
|  C_U, C_V, X

Re: [Ace] EDHOC standardization

[John Mattsson]

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

[Ace] FW: New Version Notification for draft-selander-ace-cose-ecdhe-12.txt

[John Mattsson]

The new version contains some editorial changes and corrections, and more 
descriptions on transport and error handling.

-   Some editorial changes and corrections.
-   More description on transport based on the comments from Valery 
Smyslov. Transport appendix moved to the main body of the document. Made it 
clearer already in the introduction that CoAP is the main intended transport.
-   Corrected DLTS numbers (legacy_cookie was missing) and added more info 
on how the size comparison was done (variable lengths, #offered algorithms, 
etc.).
-   More description and examples on error handling
-   Some variable changes and updated figures based on a review by Karl 
Norrman.
-   More rationale and security considerations

Cheers,
John

-Original Message-
From: "internet-dra...@ietf.org" 
Date: Monday, 25 February 2019 at 14:31
To: Göran Selander , Göran Selander 
, John Mattsson , 
Francesca Palombini 
Subject: New Version Notification for draft-selander-ace-cose-ecdhe-12.txt


A new version of I-D, draft-selander-ace-cose-ecdhe-12.txt
has been successfully submitted by John Mattsson and posted to the
IETF repository.

Name:   draft-selander-ace-cose-ecdhe
Revision:   12
Title:  Ephemeral Diffie-Hellman Over COSE (EDHOC)
Document date:  2019-02-25
Group:  Individual Submission
Pages:  44
URL:
https://www.ietf.org/internet-drafts/draft-selander-ace-cose-ecdhe-12.txt
Status: https://datatracker.ietf.org/doc/draft-selander-ace-cose-ecdhe/
Htmlized:   https://tools.ietf.org/html/draft-selander-ace-cose-ecdhe-12
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-selander-ace-cose-ecdhe
Diff:   
https://www.ietf.org/rfcdiff?url2=draft-selander-ace-cose-ecdhe-12

Abstract:
   This document specifies Ephemeral Diffie-Hellman Over COSE (EDHOC), a
   very compact, and lightweight authenticated Diffie-Hellman key
   exchange with ephemeral keys.  EDHOC provides mutual authentication,
   perfect forward secrecy, and identity protection.  A main use case
   for EDHOC is to establish an OSCORE security context.  EDHOC uses
   COSE for cryptography, CBOR for encoding, and CoAP for transport.  By
   reusing existing libraries, the additional code footprint can be kept
   very low.


  


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat


___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] [Secdispatch] FW: [secdir] EDHOC and Transports

[John Mattsson]

Richard Barnes ; wrote:

>This is the part that worries me.  It would be helpful to be very crisp
>about what assumptions are being changed here, and why it's OK for them to
>be changed.  Especially given that the Bruni et al. paper seems to have
>found flaws.

As explained in Stanislav's CFRG crypto review:

"The concerns of [1] (namely, section 2.3 of [1]) has been addressed."
https://mailarchive.ietf.org/arch/msg/cfrg/6WN2C2RYGTIAInE2jIUco6L9pO8

As the concerns were about the ability of end users to understand the security 
properties of early application data, I think similar concerns could be made 
regarding (D)TLS 1.3. 

Regarding differences between EDHOC and TLS 1.3, EDHOC is closer to the deeply 
analyzed SIGMA-I protocol. Many of the additions TLS 1.3 do to SIGMA-I are as 
far as I know done to support additional features:

- Nonces enable TLS 1.3 to work with 0-RTT data, to support PSK mode without 
PFS, to work with static Diffie-Hellman keys in older versions of TLS, and to 
look like TLS to middleboxes and applications that expect TLS to look a certain 
way.

- A MAC in TLS flight #1 enables 0-RTT data.

- The split into handshake and record layer means that TLS flight #2 and #3 
contain two MACs

Most of the additions EDHOC made to SIGMA-I are summarized in Stanislav's CFRG 
review:

"The EDHOC protocol looks well-designed. Particularly, the reviewer would
like to mention such solutions as CRED_x under signature, which is good to
prevent DSKS-type attacks; a downgrade protection based on sending both a
list of supported suites and a selected one with aad2 and aad3 messages
being hashes from all previous messages (binding the communications
together); KCI-attacks are inapplicable due to SIGMA-like ephemeral keys
usage."

(Similar additions are done in TLS 1.3 as well, but EDHOC aims for very simple 
solutions that keep the code and memory complexity as low as possible).

- Other differences are mainly in encoding and different design requirements, 
TLS supports a large number of additional extensions and options and it also 
has to interop with older versions. DTLS adds a lot of transport related things 
that EDHOC relies on CoAP for. TLS was designed with web servers as the main 
use case. EDHOC is not trying to replace TLS, I love TLS 1.3, and I advise 
Ericsson products and SDOs to use TLS as much as possible. But the TLS 
handshake was certainly not designed with constrained IoT as the main use case. 
We are trying to bring SIGMA-I level end-to-end protection to constrained IoT 
systems where TLS is impractical.

Cheers,
John

___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

[Ace] CFRG Crypto Review Panel reviews of draft-selander-ace-cose-ecdhe-12

[John Mattsson]

For those of you that are not following the CFRG list. The CFRG Crypto Review 
Panel has recently provided two reviews of draft-selander-ace-cose-ecdhe-12

Russ Housley:
https://mailarchive.ietf.org/arch/msg/cfrg/6WN2C2RYGTIAInE2jIUco6L9pO8

Stanislav V. Smyshlyaev:
https://mailarchive.ietf.org/arch/msg/cfrg/2OY2om1FjhNNBmUzwYJroHv7eWQ

Main comments were that more text on compromises was needed in security 
considerations and that the optimization to omit the connection identifier may 
not be worth the added complexity, but please read the reviews yourself.

As announced here 
https://mailarchive.ietf.org/arch/msg/cfrg/7O-UnZP59LO1YY0_tToZgdEirt0 the 
comments from Russ and Stanislav have already been addressed in the GitHub 
version of the draft. Other comments/suggestions have been added to GitHub 
issues for discussion.

https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-selander-ace-cose-ecdhe.txt&url2=https://EricssonResearch.github.io/EDHOC/draft-selander-ace-cose-ecdhe.txt

Cheers,
John

___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

[Ace] FW: New Version Notification for draft-selander-ace-cose-ecdhe-14.txt

[John Mattsson]

Hi,

We have submitted a new version 14 of EDHOC. Most of the changes are based on 
comments from people implementing version 13 of EDHOC.

- The major change in version 14 is the inclusion of test vectors for both RPK 
and PSK authentication. Since the last submission, there has been two new 
implementations of EHDOC (-13) as well as a limited script that generates test 
vectors. The included test vectors has been verified by an independent 
implementation done by Martin Disch from University of Fribourg.

- With actual test vectors, the appendix with example messages is not needed 
and has been removed.

- Based on comments from developers, the appendix explaining parts of COSE has 
been integrated in the body of document.

- Text has been added to the IANA sections for cipher suite and method 
registries including expert review considerations.

- New security consideration on Party U and Party V sending message_1 in 
parallel to each other. The new considerations also mitigates so called 
reflection attacks when PSK authentication is used.

- EDHOC now use COSEs HMAC algorithms in cipher suites, this should make it 
easier for developers to understand and enables use of more algorithms. EDHOC 
can now e.g. be made compliant with the CNSA suite.

- The error message now includes a connection identifier so that the receiving 
endpoint can always map the error message to the correct protocol run.

- EDHOC now specifies an exact encoding of the COSE_Keys when they are included 
in the signatures, this was missing in earlier versions.

- Based on implementation comments, a lot of smaller changes has been made to 
text describing encoding, especially regarding byte string (non-CBOR byte 
strings vs. encodings of CBOR byte string where the encoding itself is a byte 
string). The goal has been to make the specification correct and easier to 
understand.

Future plans:

- While the EDHOC message encoding is quite optimized there are some more bytes 
that could be shaved off based on the known lengths of CoAP payload, plaintext, 
PSK ciphertext, signature, ephemeral keys, etc. The plan is to analyze how many 
bytes could be saved and if changes would complicate implementations. 

- We think it is worth investigating the use of OPTLS-style authentication in 
EDHOC, i.e. authentication provided by a MAC computed from an ephemeral-static 
ECDH shared secret. Instead of signature authentication keys, U and V would 
have Diffie-Hellman authentication keys G_U and G_V, respectively.  This type 
of authentication keys could easily be used with RPK and would provide 
significant reductions in message sizes as the 64 bytes signature would be 
replaced by an 8 bytes MAC. While the OPTLS proposal by Krawczyk et.al was not 
chosen for TLS 1.3, there are currently two different individual drafts in the 
TLS working group suggesting use of this type of authentication. Version 14 of 
the draft already includes an appendix a high level description.

Cheers,
John

-Original Message-
From: "internet-dra...@ietf.org" 
Date: Wednesday, 11 September 2019 at 15:46
To: Göran Selander , Göran Selander 
, John Mattsson , 
Francesca Palombini 
Subject: New Version Notification for draft-selander-ace-cose-ecdhe-14.txt


A new version of I-D, draft-selander-ace-cose-ecdhe-14.txt
has been successfully submitted by John Mattsson and posted to the
IETF repository.

Name:   draft-selander-ace-cose-ecdhe
Revision:   14
Title:  Ephemeral Diffie-Hellman Over COSE (EDHOC)
Document date:  2019-09-11
Group:  Individual Submission
Pages:  71
URL:
https://www.ietf.org/internet-drafts/draft-selander-ace-cose-ecdhe-14.txt
Status: 
https://datatracker.ietf.org/doc/draft-selander-ace-cose-ecdhe/
Htmlized:   https://tools.ietf.org/html/draft-selander-ace-cose-ecdhe-14
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-selander-ace-cose-ecdhe
Diff:   
https://www.ietf.org/rfcdiff?url2=draft-selander-ace-cose-ecdhe-14

Abstract:
   This document specifies Ephemeral Diffie-Hellman Over COSE (EDHOC), a
   very compact, and lightweight authenticated Diffie-Hellman key
   exchange with ephemeral keys.  EDHOC provides mutual authentication,
   perfect forward secrecy, and identity protection.  EDHOC is intended
   for usage in constrained scenarios and a main use case is to
   establish an OSCORE security context.  By reusing COSE for
   cryptography, CBOR for encoding, and CoAP for transport, the
   additional code footprint can be kept very low.


  


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF S

[Ace] FW: New Version Notification for draft-raza-ace-cbor-certificates-04.txt

[John Mattsson]

Hi,

We have submitted a new version of the CBOR certificate draft.

https://tools.ietf.org/html/draft-raza-ace-cbor-certificates-04

The changes are:

- The profiling section has been removed; the profiling now relies completely 
on RFC 7925. The aim is to be compatible with all RFC 7925 profiled 
certificates.
- The encoding has been modified to increase compression and some missing 
pieces have been filled in.
- Example DER encoded RFC 7925 certificate with corresponding CBOR encoding. 
The example certificate is compressed from 314 to 136 bytes, a compression rate 
of 57%.

General purpose compression algorithms (without dictionary) seems not able to 
compress RFC 7925 profiles certificates. zlib compressed the example cert 9%, 
but other certificates and compression algorithms did in many cases increase 
the size.

We have submitted two drafts that use draft-raza-ace-cbor-certificates to 
compress X.509 certificates in TLS 1.3 and COSE.

https://tools.ietf.org/html/draft-mattsson-tls-cbor-cert-compress-00
https://tools.ietf.org/html/draft-mattsson-cose-cbor-cert-compress-00

Cheers,
John

-Original Message-
From: "internet-dra...@ietf.org" 
Date: Monday, 9 March 2020 at 18:41
To: Joel Hoglund , Göran Selander 
, Martin Furuhed , 
John Mattsson , Shahid Raza , 
Joel Höglund , John Mattsson , 
Göran Selander 
Subject: New Version Notification for draft-raza-ace-cbor-certificates-04.txt


A new version of I-D, draft-raza-ace-cbor-certificates-04.txt
has been successfully submitted by =?utf-8?q?John_Preu=C3=9F_Mattsson?= and 
posted to the
IETF repository.

Name:   draft-raza-ace-cbor-certificates
Revision:   04
Title:  CBOR Profile of X.509 Certificates
Document date:  2020-03-09
Group:  Individual Submission
Pages:  16
URL:
https://www.ietf.org/internet-drafts/draft-raza-ace-cbor-certificates-04.txt
Status: 
https://datatracker.ietf.org/doc/draft-raza-ace-cbor-certificates/
Htmlized:   
https://tools.ietf.org/html/draft-raza-ace-cbor-certificates-04
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-raza-ace-cbor-certificates
Diff:   
https://www.ietf.org/rfcdiff?url2=draft-raza-ace-cbor-certificates-04

Abstract:
   This document specifies a CBOR encoding and profiling of X.509 public
   key certificate suitable for Internet of Things (IoT) deployments.
   The full X.509 public key certificate format and commonly used ASN.1
   DER encoding is overly verbose for constrained IoT environments.
   Profiling together with CBOR encoding reduces the certificate size
   significantly with associated known performance benefits.

   The CBOR certificates are compatible with the existing X.509
   standard, enabling the use of profiled and compressed X.509
   certificates without modifications in the existing X.509 standard.


  


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat




___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

[Ace] Review of draft-ietf-ace-oscore-profile

[John Mattsson]

Hi,

I have reviewed the latest GitHub version of draft-ietf-ace-oscore-profile
https://ace-wg.github.io/ace-oscore-profile/draft-ietf-ace-oscore-profile.html

In general this draft looks very good. I have one major comments, and several 
more minor comments.

Major comment
---

- Asignment of OSCORE Sender and Recipient IDs

I think the specified mechanism where the AS dictates the OSCORE connection 
parameters is unfortunate. It introduces several current and future 
limitations. The current assignment mechanisms only works without problems in 
close systems where the RS does not have any other non-AS OSCORE connections, 
where the CoAP client and CoAP server roles are fixed and cannot be switched, 
and where only draft-ietf-ace-oscore-profile is used. In systems where the 
OSCORE nodes can switch between CoAP client and CoAP server (a feature 
explicitly supported by OSCORE) the current mechanism is likely to lead to 
RecipientID collisions. Also in future systems where the AS also supports a 
more modern key management with PFS using e.g. a future 
draft-ace-edhoc-oscore-profile, the mechanism would not work together in an 
efficient way. My understanding is that the authors would like the solution to 
work with both role switching and EDHOC.

How to negotiate these type of connection identifiers (in this case OSCORE 
Sender and Recipient IDs) have been studied and specified several times in e.g. 
draft-selander-lake-edhoc, draft-ietf-tls-dtls-connection-id. A solution where 
each party choses its OSCORE recipient ID for the connection always work 
without collisions. Such a negotiation could quite easily be added to the 
roundtrip with the nonces N1 and N2. My feeling is that it would be worthwhile 
to do such a change. This would also require a new identifier for the 
OSCORE_Security_Context Object, either a new objectID or a hash of the object 
could be used. I think this would be a good change as the current "hack" of 
using the ACE client sender Id and and ID context to identify the object might 
lead to other future limitations.

The suggested changes would lead quite equal message sizes and storage 
requirements, they might even lead to some small improvements.

Minor comments
---

- "server authentication"

My understanding is that server authentication with this draft requires two 
additional things. That C trusts AS and that RS sends an OSCORE response back. 
The draft should point this out similarly to the way it points out that a 
OSCORE request is required for proof-of-possession. As C trust in AS, and RS 
sending an OSCORE response back are both optional, I would recommend to maybe 
remove "server authentication" from the abstract and intro.

- "The nonces are encoded as CBOR bstr if CBOR is used, and as Base64 string if 
JSON is used"

Would be good to define exactly how the Master salt is created when JSON is 
used. I.e. is the Base64 encoded strings used, or are the byte strings after 
Base64 decoding used.

- "the authz-info endpoint is not a protected resource, so there is no 
cryptographic protection to this request."

I do not think this follows from the OAuth ACE term “protected resource”. Most 
resources on the web are not protected resources, but use cryptographic 
protection (https:// HTTPS)

- "An OSCORE_Security_Context is an object that represents part or all of an 
OSCORE Security Context"

The object cannot represent all of an RFC 8613 OSCORE Security Context as 
sequence number, replay window, and Master salt are missing. I would also 
strongly recommend removing "context" from the name of the object so that it is 
not confused with an RFC 8613 context. Maybe OSCORE input keying material or 
something similar.

- "CBOR type"

The types listed are CDDL types. Should at least mention CDDL or change to 
actual CBOR types.

- "Security Context identified by "kid""

This message has two different "kid", one on the ACE level and one on the 
OSCORE level, would be good to clarify which "kid" this refers to.

- "client" "server"

I think the draft should have a sentence saying that the terms "client" 
"server" when used without specification refer to the ACE client C and the ACE 
resource server RS. There is another server in the ACE architecture, and on the 
CoAP level the nodes can switch roles.

- "input salt"

input salt is not defined when it is used in section 2.

- "clientID", "serverID", "contextID"

I am not fond of these new abbreviations for the OSCORE parameters for several 
reasons. The draft uses the term "clientID" for "ACE client sender ID" = "ACE 
resource server recipient ID", the term "serverID" for "ACE client recipient 
ID" = "ACE resource server sender ID", and the term "contextID" for "ID 
context". "clientID" and "contextID" is also together used as an identifier for 
the "OSCORE_Security_Context Object".

The problems I have with these terms are that "client ID" and "serverID" give 
the impression that they are identifiers 

[Ace] AS discovery in draft-ietf-ace-oauth-authz-35

[John Mattsson]

 Hi,

I just reviewed draft-ietf-ace-oscore-profile. This made me wonder about the AS 
discovery mechanism in the ACE framework. Why is this particular discovery 
mechanism given so much attention? Of all possible discovery mechanisms, this 
seems like one of the worst as:

1.  It requires a round-trip over the C-RS path which is typically the most 
constrained path in the architecture.
2.  The response would in many cases be unprotected, which means C does not 
know if the response comes from RS or an attacker.

A discovery mechanism using a non-contrained path (e.g. DNS, but could be any 
type of look up service) would in many cases be much more efficient and should 
be recommended. Such a mechanism might also be protected in more cases and 
therefore rule out the possibility that the response came from an attacker.

I understand that the ACE framework draft does not want to specify any other AS 
discovery mechanism, but at a minimum the severe limitations of the current 
mechanism should be detailed. I my view the current mechanism should be not 
recommended and only used as an error message when the client in good faith try 
to access a resource believing that it might have the right to access it.

Cheers,
John

___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] AS discovery in draft-ietf-ace-oauth-authz-35

[John Mattsson]

Hi Ludwig,

The problem I have is that the current mechanism is presented as a generic 
discovery mechanism and that none of the disadvantages are mentioned in section 
5.1.

"A generic procedure is described in Section 5.1"

The mechanism is not presented as an error message when the client in good 
faith tries to access a resource. It is presented as something C do 
intentionally to dicsover the AS. In the description in the draft, C is clearly 
aware that the request is unauthorized.

Section 6.4 describes the security properties quite well. But I cannot see any 
discusion about the inefficiency of doing discovery over the C-RS path, which 
in many cases is contrained.

The current presentation is:

   5.1 generic procedure to discover AS

   6.4 BTW this mechanism has some security limitation

My view would be that is should be more like:

   5.1 Error message with AS address

   X.X BTW the error message could be used for AS discovery but has limited 
effeciency and security and is not recommended.

Cheers,
John

-Original Message-
From: Seitz Ludwig 
Date: Monday, 7 September 2020 at 08:28
To: John Mattsson , "ace@ietf.org" 
Subject: RE: AS discovery in draft-ietf-ace-oauth-authz-35

Hi John,

Replies inline

/Ludwig

> -Original Message-
> From: Ace  On Behalf Of John Mattsson
> Sent: den 5 september 2020 14:53
> To: ace@ietf.org
> Subject: [Ace] AS discovery in draft-ietf-ace-oauth-authz-35
> 
>  Hi,
> 
> I just reviewed draft-ietf-ace-oscore-profile. This made me wonder about
> the AS discovery mechanism in the ACE framework. Why is this particular
> discovery mechanism given so much attention? Of all possible discovery
> mechanisms, this seems like one of the worst as:
> 
> 1.It requires a round-trip over the C-RS path which is typically the most
> constrained path in the architecture.
> 2.The response would in many cases be unprotected, which means C
> does not know if the response comes from RS or an attacker.
> 
> A discovery mechanism using a non-contrained path (e.g. DNS, but could be
> any type of look up service) would in many cases be much more efficient and
> should be recommended. Such a mechanism might also be protected in
> more cases and therefore rule out the possibility that the response came
> from an attacker.
> 
> I understand that the ACE framework draft does not want to specify any
> other AS discovery mechanism, but at a minimum the severe limitations of
> the current mechanism should be detailed. 

The limitations of this mechanism are detailed in section 6.4, do you think 
that there is some consideration missing from that section?

> I my view the current mechanism
> should be not recommended and only used as an error message when the
> client in good faith try to access a resource believing that it might have the
> right to access it.
> 
It is indeed intended as an error message when the client in good faith tries 
to access a resource believing it might have the right to access it.


___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] AS discovery in draft-ietf-ace-oauth-authz-35

[John Mattsson]

Hi,

Rereading Section 6.4 again I think the discussion on Denial-of-Service / 
amplification attacks in Section 6.4 clearly needs more work.

- "However a compromised RS may use this to perform a denial of service against 
a specific AS"

Any attacker (not just a compromised RS) on the path beween C and RS can easily 
trick C into contacting any node S (not just an ACE AS). Such a forged message 
would be a denial-of-service attack on both C and N, not only on N.

- "It is therefore advisable to provide C with a (possibly hard-coded) list of 
trustworthy authorization servers"

The list would need to be allowlist to have any effect. My understanding is 
that C could contact an AS it does not trust. Having an allowlist in C does not 
help in general. Even if C have a list stating that AS1, AS2, and AS3 is 
allowed, an attacker can impersonate RS3 (belonging to AS3) and fool C to 
contact AS1 or AS2. The attacker may even be able to get C to alternate between 
contacting AS1 and AS2.

Possible DDoS attacks in the IoT space is very serious. Recently, the lagest 
DDoS attacks have all been using IoT devices. New protocols should mitigate 
amlification and DDoS attacks.

Cheers,
John

-Original Message-
From: John Mattsson 
Date: Monday, 7 September 2020 at 12:45
To: Seitz Ludwig , "ace@ietf.org" 
Subject: Re: AS discovery in draft-ietf-ace-oauth-authz-35

Hi Ludwig,

The problem I have is that the current mechanism is presented as a generic 
discovery mechanism and that none of the disadvantages are mentioned in section 
5.1.

"A generic procedure is described in Section 5.1"

The mechanism is not presented as an error message when the client in good 
faith tries to access a resource. It is presented as something C do 
intentionally to dicsover the AS. In the description in the draft, C is clearly 
aware that the request is unauthorized.

Section 6.4 describes the security properties quite well. But I cannot see any 
discusion about the inefficiency of doing discovery over the C-RS path, which 
in many cases is contrained.

The current presentation is:

   5.1 generic procedure to discover AS

   6.4 BTW this mechanism has some security limitation

My view would be that is should be more like:

   5.1 Error message with AS address

   X.X BTW the error message could be used for AS discovery but has limited 
effeciency and security and is not recommended.

Cheers,
John

-Original Message-
From: Seitz Ludwig 
Date: Monday, 7 September 2020 at 08:28
To: John Mattsson , "ace@ietf.org" 
Subject: RE: AS discovery in draft-ietf-ace-oauth-authz-35

Hi John,

Replies inline

/Ludwig

> -Original Message-
> From: Ace  On Behalf Of John Mattsson
> Sent: den 5 september 2020 14:53
> To: ace@ietf.org
> Subject: [Ace] AS discovery in draft-ietf-ace-oauth-authz-35
> 
>  Hi,
> 
> I just reviewed draft-ietf-ace-oscore-profile. This made me wonder about
> the AS discovery mechanism in the ACE framework. Why is this particular
> discovery mechanism given so much attention? Of all possible discovery
> mechanisms, this seems like one of the worst as:
> 
> 1.It requires a round-trip over the C-RS path which is typically the most
> constrained path in the architecture.
> 2.The response would in many cases be unprotected, which means C
> does not know if the response comes from RS or an attacker.
> 
> A discovery mechanism using a non-contrained path (e.g. DNS, but could be
> any type of look up service) would in many cases be much more efficient and
> should be recommended. Such a mechanism might also be protected in
> more cases and therefore rule out the possibility that the response came
> from an attacker.
> 
> I understand that the ACE framework draft does not want to specify any
> other AS discovery mechanism, but at a minimum the severe limitations of
> the current mechanism should be detailed. 

The limitations of this mechanism are detailed in section 6.4, do you think 
that there is some consideration missing from that section?

> I my view the current mechanism
> should be not recommended and only used as an error message when the
> client in good faith try to access a resource believing that it might have the
> right to access it.
> 
It is indeed intended as an error message when the client in good faith tries 
to access a resource believing it might have the right to access it.



___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] Assignment of OSCORE Sender and Recipient IDS - was RE: Review of draft-ietf-ace-oscore-profile

[John Mattsson]

Hi Jim,

I agree with most of what you say. Below are some additional comments on some 
of the bullets.

[JLS]  I'll start with what I said on the mailing list - this problem was 
discussed previously on the mailing list and in person and it was decided that 
it did not need to be fixed.

[JM] My understanding from Francesca and Göran is that neither migration path 
to e.g. EDHOC nor systems where the nodes change roles have been discussed 
before. Both have additional collision probems. How important the use cases are 
and how bad the collision problem would be can be discussed.

[JLS] 1) The use of the same token on multiple RS has security problems on its 
own that cannot be overlooked.  It is possible that we need to say that this 
just should not be done.  If you are using symmetric keys all around, then RS1 
an impersonate C to RS2 because it has all of the necessary keying material to 
post the token and setup a security context.  RS1 can go farther and 
potentially impersonate the AS to RS2 gaining additional privileges when it 
impersonates C if the AS is using symmetric keys to validate tokens to RS1 and 
RS2.  This indicates that generally one does not want to use the same token 
with multiple devices.

[JM] Yes, using symmetric keys for authentication in groups is in general a 
very bad idea. Forbidding use of the token to several servers would forbid the 
use of multiple resource servers for redundancy. Alternatively several RS 
accepting the same token could be allowed in certain circumstances.

[JLS] 3) You seem to be ignoring the most practical solution to the problem, 
use the context identifier for name space separation.  If you have five 
different ASs, then simply assign a one byte context to each of them and you 
now have no problems with name collisions unless somebody is going to be 
knowingly difficult.  Similarly, you  assign each of the group key managers a 
one byte value which is used as the prefix to the contexts assigned by that key 
manager for all of the groups it manages.  I would have to look to see if one 
can specify a context for LAKE, but being able to do so would provide a 
separation for that space as well.

[JM] Yes, that is definitely a solution, but I don't think it matters if you 
use ID context or longer Sender IDs, it's the sum of the lengths that matter 
for the collision probability. I agree that you can definitely solve the 
collision problem by randomly assigning longer ID Context + Sender ID, 
potentially combined with a mechanism (as you mentioned during the interim) 
where the client rejects tokens that lead to collisions. This solves collision 
problems on with the cost of additional roundtrips and/or larger OSCORE message 
sizes. Both could be acceptable, but unfortunate as collision free and optimal 
(in terms of message size) are well-known and there seems to be no benefits of 
the AS dictating Sender and Recipient IDs. Both RFC 7252 and RFC 8613 is very 
careful to not waste a single byte.

/John

-Original Message-
From: Jim Schaad 
Date: Monday, 7 September 2020 at 22:14
To: John Mattsson , "ace@ietf.org" 
Subject: Assignment of OSCORE Sender and Recipient IDS - was RE: [Ace] Review 
of draft-ietf-ace-oscore-profile



-Original Message-
From: Ace  On Behalf Of John Mattsson
Sent: Saturday, September 5, 2020 5:51 AM
To: ace@ietf.org
Subject: [Ace] Review of draft-ietf-ace-oscore-profile


Major comment
---

- Asignment of OSCORE Sender and Recipient IDs

I think the specified mechanism where the AS dictates the OSCORE connection 
parameters is unfortunate. It introduces several current and future 
limitations. The current assignment mechanisms only works without problems in 
close systems where the RS does not have any other non-AS OSCORE connections, 
where the CoAP client and CoAP server roles are fixed and cannot be switched, 
and where only draft-ietf-ace-oscore-profile is used. In systems where the 
OSCORE nodes can switch between CoAP client and CoAP server (a feature 
explicitly supported by OSCORE) the current mechanism is likely to lead to 
RecipientID collisions. Also in future systems where the AS also supports a 
more modern key management with PFS using e.g. a future 
draft-ace-edhoc-oscore-profile, the mechanism would not work together in an 
efficient way. My understanding is that the authors would like the solution to 
work with both role switching and EDHOC.

How to negotiate these type of connection identifiers (in this case OSCORE 
Sender and Recipient IDs) have been studied and specified several times in e.g. 
draft-selander-lake-edhoc, draft-ietf-tls-dtls-connection-id. A solution where 
each party choses its OSCORE recipient ID for the connection always work 
without collisions. Such a negotiation could quite easily be added to the 
roundtrip with the nonces N1 and N2. My feeling is that it would be worthwhile 
to do such a change. This would also require

Re: [Ace] Review of draft-ietf-ace-oscore-profile

[John Mattsson]

Hi,

Just want to say that I don't have any strong opinions on how to proceed. I 
just wanted to point out the collision problems with the draft are more severe 
that the group have discussed. Ignoring collisions seems like a mistake, and to 
my understanding there seems to be no benefits of the AS dictating Sender and 
Recipient IDs.

I think Jim has a good point in that the solution with symmetric key 
authentication comes with a lot of limitations anyway.

/John 

-Original Message-
From: Göran Selander 
Date: Monday, 7 September 2020 at 17:05
To: John Mattsson , "ace@ietf.org" 
Subject: Re: [Ace] Review of draft-ietf-ace-oscore-profile

Hi,

Just want to acknowledge, as was discussed in the WG meeting today, that the 
major comment below is alternatively a possible -bis update. I think this is 
good functionality, and even though related problem statements have been 
discussed before, this solution has not. And although the change is small it 
comes at a late stage. But if it doesn't make it for this version then let's 
make it in an update soon. 

Göran


On 2020-09-05, 14:51, "Ace on behalf of John Mattsson"  wrote:

Hi,

I have reviewed the latest GitHub version of draft-ietf-ace-oscore-profile

https://protect2.fireeye.com/v1/url?k=cd0dd5df-93bc0ebf-cd0d9544-86e2237f51fb-51fc8fb4bf065a0f&q=1&e=5ecc1a37-faa1-4082-857b-150aa2dc3b9a&u=https%3A%2F%2Face-wg.github.io%2Face-oscore-profile%2Fdraft-ietf-ace-oscore-profile.html

In general this draft looks very good. I have one major comments, and 
several more minor comments.

Major comment
---

- Asignment of OSCORE Sender and Recipient IDs

I think the specified mechanism where the AS dictates the OSCORE connection 
parameters is unfortunate. It introduces several current and future 
limitations. The current assignment mechanisms only works without problems in 
close systems where the RS does not have any other non-AS OSCORE connections, 
where the CoAP client and CoAP server roles are fixed and cannot be switched, 
and where only draft-ietf-ace-oscore-profile is used. In systems where the 
OSCORE nodes can switch between CoAP client and CoAP server (a feature 
explicitly supported by OSCORE) the current mechanism is likely to lead to 
RecipientID collisions. Also in future systems where the AS also supports a 
more modern key management with PFS using e.g. a future 
draft-ace-edhoc-oscore-profile, the mechanism would not work together in an 
efficient way. My understanding is that the authors would like the solution to 
work with both role switching and EDHOC.

How to negotiate these type of connection identifiers (in this case OSCORE 
Sender and Recipient IDs) have been studied and specified several times in e.g. 
draft-selander-lake-edhoc, draft-ietf-tls-dtls-connection-id. A solution where 
each party choses its OSCORE recipient ID for the connection always work 
without collisions. Such a negotiation could quite easily be added to the 
roundtrip with the nonces N1 and N2. My feeling is that it would be worthwhile 
to do such a change. This would also require a new identifier for the 
OSCORE_Security_Context Object, either a new objectID or a hash of the object 
could be used. I think this would be a good change as the current "hack" of 
using the ACE client sender Id and and ID context to identify the object might 
lead to other future limitations.

The suggested changes would lead quite equal message sizes and storage 
requirements, they might even lead to some small improvements.

Minor comments
---

- "server authentication"

My understanding is that server authentication with this draft requires two 
additional things. That C trusts AS and that RS sends an OSCORE response back. 
The draft should point this out similarly to the way it points out that a 
OSCORE request is required for proof-of-possession. As C trust in AS, and RS 
sending an OSCORE response back are both optional, I would recommend to maybe 
remove "server authentication" from the abstract and intro.

- "The nonces are encoded as CBOR bstr if CBOR is used, and as Base64 
string if JSON is used"

Would be good to define exactly how the Master salt is created when JSON is 
used. I.e. is the Base64 encoded strings used, or are the byte strings after 
Base64 decoding used.

- "the authz-info endpoint is not a protected resource, so there is no 
cryptographic protection to this request."

I do not think this follows from the OAuth ACE term “protected resource”. 
Most resources on the web are not protected resources, but use cryptographic 
protection (https:// HTTPS)

- "An OSCORE_Security_Context is an object that represents part or all of 
an OSCORE Security Context"

The object cannot represent all of an RFC 8613 OSCORE Security Context as 
sequence numbe

Re: [Ace] AS discovery in draft-ietf-ace-oauth-authz-35

[John Mattsson]

Hi Stephanie,

Regarding the section that you quoted: "the client MUST be able to determine 
whether an AS has the authority to issue access tokens for a certain RS. This 
can for example be done through pre-configured lists, or through an online 
lookup mechanism that in turn also must be secured."

Assuming C has access to a function M letting it determine whether an AS has 
the authority to issue access tokens for a certain RS, this would certainly 
partly mitigate DoS attacks. The attack would be a DoS attack on C and M, but 
the attacker could not choose M.

The problem is that:
- if C has access to such a function M that can provide a link between AS and 
RS, the whole mechanism with sending the AS address in an error message seems 
completely redundant.
- If C does not have access to such a function M, the mechanism with sending an 
address in a spoofable error message seems like a very dangerous attack vector 
for DDoS attacks.

The only implementation of M that would make use of an error message would be 
if the error message contained something like sign(AS, RS), but this is 
something that is not discussed in the draft.

Cheers,
John

___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] Review of draft-ietf-ace-oscore-profile

[John Mattsson]

The question in my view is if this draft should create collisions. All other 
drafts that have ever been discussed in the IETF takes efforts to not create 
any collisions in the first place

https://tools.ietf.org/html/draft-selander-lake-edhoc-01
https://tools.ietf.org/html/draft-mattsson-ace-tls-oscore-00
https://tools.ietf.org/html/draft-friel-tls-atls-04

All these assignment mechanism can be used together collision-free without ID 
Context and with minimal length Sender ID / Recipient ID. So I don’t think the 
statement that “Collisions are going to be a common problem across all of these 
different ways of getting OSCORE contexts established.” is correct.

Group OSCORE is a different story, there the assignment mechanism have to 
handle collisions with ID Contexts (unless the deployment is strictly local, 
e.g. when used only over a local radio technology). 

One option is that this draft recommends the use of an ID context and that a 
bis version of the draft makes the simple changes to not get collisions in the 
first place.

It would as you say have been very good if RFC 8613 discussed how to negotiate 
Sender ID / Recipient ID. If there is ever a bis version, this should definitly 
be added. 

John

-Original Message-
From: Jim Schaad 
Date: Tuesday, 8 September 2020 at 21:14
To: John Mattsson , Göran Selander 
, "ace@ietf.org" 
Subject: RE: [Ace] Review of draft-ietf-ace-oscore-profile

John,

I am wondering if this is really the document that should be dealing with this 
collision problem.   A number of the collisions that might occur are going to 
be out of the ACE scope and a more general discussion of the problem should 
probably occur in a BIS version of the CoRE OSCORE document itself.   Memory 
says that the document does not claim to deal with how names are assigned to 
contexts, but I think that having a centralized location that LAKE, ACE (AS, 
Groupcomm and pub-sub) and perhaps other methods that we don’t currently have 
in our radar.  Collisions are going to be a common problem across all of these 
different ways of getting OSCORE contexts established.

Jim


-Original Message-
From: Ace  On Behalf Of John Mattsson
Sent: Tuesday, September 8, 2020 12:40 AM
To: Göran Selander ; ace@ietf.org
Subject: Re: [Ace] Review of draft-ietf-ace-oscore-profile

Hi,

Just want to say that I don't have any strong opinions on how to proceed. I 
just wanted to point out the collision problems with the draft are more severe 
that the group have discussed. Ignoring collisions seems like a mistake, and to 
my understanding there seems to be no benefits of the AS dictating Sender and 
Recipient IDs.

I think Jim has a good point in that the solution with symmetric key 
authentication comes with a lot of limitations anyway.

/John 

-Original Message-
From: Göran Selander 
Date: Monday, 7 September 2020 at 17:05
To: John Mattsson , "ace@ietf.org" 
Subject: Re: [Ace] Review of draft-ietf-ace-oscore-profile

Hi,

Just want to acknowledge, as was discussed in the WG meeting today, that the 
major comment below is alternatively a possible -bis update. I think this is 
good functionality, and even though related problem statements have been 
discussed before, this solution has not. And although the change is small it 
comes at a late stage. But if it doesn't make it for this version then let's 
make it in an update soon. 

Göran


On 2020-09-05, 14:51, "Ace on behalf of John Mattsson"  wrote:

Hi,

I have reviewed the latest GitHub version of draft-ietf-ace-oscore-profile

https://protect2.fireeye.com/v1/url?k=cd0dd5df-93bc0ebf-cd0d9544-86e2237f51fb-51fc8fb4bf065a0f&q=1&e=5ecc1a37-faa1-4082-857b-150aa2dc3b9a&u=https%3A%2F%2Face-wg.github.io%2Face-oscore-profile%2Fdraft-ietf-ace-oscore-profile.html

In general this draft looks very good. I have one major comments, and 
several more minor comments.

Major comment
---

- Asignment of OSCORE Sender and Recipient IDs

I think the specified mechanism where the AS dictates the OSCORE connection 
parameters is unfortunate. It introduces several current and future 
limitations. The current assignment mechanisms only works without problems in 
close systems where the RS does not have any other non-AS OSCORE connections, 
where the CoAP client and CoAP server roles are fixed and cannot be switched, 
and where only draft-ietf-ace-oscore-profile is used. In systems where the 
OSCORE nodes can switch between CoAP client and CoAP server (a feature 
explicitly supported by OSCORE) the current mechanism is likely to lead to 
RecipientID collisions. Also in future systems where the AS also supports a 
more modern key management with PFS using e.g. a future 
draft-ace-edhoc-oscore-profile, the mechanism would not work together in an 
efficient way. My understanding is that the authors would like the solution to 
work with both role switching 

Re: [Ace] Review of draft-ietf-ace-oscore-profile

[John Mattsson]

The question in my view is if this draft should create collisions. All other 
drafts assigning identities to RFC 8613 that have ever been discussed in the 
IETF takes efforts to not create any collisions in the first place

https://tools.ietf.org/html/draft-selander-lake-edhoc-01
https://tools.ietf.org/html/draft-mattsson-ace-tls-oscore-00
https://tools.ietf.org/html/draft-friel-tls-atls-04

All these assignment mechanism can be used together collision-free without ID 
Context and with minimal length Sender ID / Recipient ID. So I don’t think the 
statement that “Collisions are going to be a common problem across all of these 
different ways of getting OSCORE contexts established.” is correct.

Group OSCORE is a different story, there the assignment mechanism have to 
handle collisions with ID Contexts (unless the deployment is strictly local, 
e.g. when used only over a local radio technology). 

One option is that this draft recommends the use of an ID context unless the 
draft is uses in a local closed system, and that a bis version of the draft 
makes the simple changes to not get collisions in the first place.

It would as you say have been very good if RFC 8613 discussed how to negotiate 
Sender ID / Recipient ID. If there is ever a bis version, this should definitly 
be added. 

John

-Original Message-
From: Jim Schaad 
Date: Tuesday, 8 September 2020 at 21:14
To: John Mattsson , Göran Selander 
, "ace@ietf.org" 
Subject: RE: [Ace] Review of draft-ietf-ace-oscore-profile

John,

I am wondering if this is really the document that should be dealing with this 
collision problem.   A number of the collisions that might occur are going to 
be out of the ACE scope and a more general discussion of the problem should 
probably occur in a BIS version of the CoRE OSCORE document itself.   Memory 
says that the document does not claim to deal with how names are assigned to 
contexts, but I think that having a centralized location that LAKE, ACE (AS, 
Groupcomm and pub-sub) and perhaps other methods that we don’t currently have 
in our radar.  Collisions are going to be a common problem across all of these 
different ways of getting OSCORE contexts established.

Jim


-Original Message-
From: Ace  On Behalf Of John Mattsson
Sent: Tuesday, September 8, 2020 12:40 AM
To: Göran Selander ; ace@ietf.org
Subject: Re: [Ace] Review of draft-ietf-ace-oscore-profile

Hi,

Just want to say that I don't have any strong opinions on how to proceed. I 
just wanted to point out the collision problems with the draft are more severe 
that the group have discussed. Ignoring collisions seems like a mistake, and to 
my understanding there seems to be no benefits of the AS dictating Sender and 
Recipient IDs.

I think Jim has a good point in that the solution with symmetric key 
authentication comes with a lot of limitations anyway.

/John 

-Original Message-
From: Göran Selander 
Date: Monday, 7 September 2020 at 17:05
To: John Mattsson , "ace@ietf.org" 
Subject: Re: [Ace] Review of draft-ietf-ace-oscore-profile

Hi,

Just want to acknowledge, as was discussed in the WG meeting today, that the 
major comment below is alternatively a possible -bis update. I think this is 
good functionality, and even though related problem statements have been 
discussed before, this solution has not. And although the change is small it 
comes at a late stage. But if it doesn't make it for this version then let's 
make it in an update soon. 

Göran


On 2020-09-05, 14:51, "Ace on behalf of John Mattsson"  wrote:

Hi,

I have reviewed the latest GitHub version of draft-ietf-ace-oscore-profile

https://protect2.fireeye.com/v1/url?k=cd0dd5df-93bc0ebf-cd0d9544-86e2237f51fb-51fc8fb4bf065a0f&q=1&e=5ecc1a37-faa1-4082-857b-150aa2dc3b9a&u=https%3A%2F%2Face-wg.github.io%2Face-oscore-profile%2Fdraft-ietf-ace-oscore-profile.html

In general this draft looks very good. I have one major comments, and 
several more minor comments.

Major comment
---

- Asignment of OSCORE Sender and Recipient IDs

I think the specified mechanism where the AS dictates the OSCORE connection 
parameters is unfortunate. It introduces several current and future 
limitations. The current assignment mechanisms only works without problems in 
close systems where the RS does not have any other non-AS OSCORE connections, 
where the CoAP client and CoAP server roles are fixed and cannot be switched, 
and where only draft-ietf-ace-oscore-profile is used. In systems where the 
OSCORE nodes can switch between CoAP client and CoAP server (a feature 
explicitly supported by OSCORE) the current mechanism is likely to lead to 
RecipientID collisions. Also in future systems where the AS also supports a 
more modern key management with PFS using e.g. a future 
draft-ace-edhoc-oscore-profile, the mechanism would not work together in an 
efficient way. My understanding 

[Ace] draft-ietf-ace-oauth-authz-35 - unauthorized AS address, DoS, and privacy

[John Mattsson]

Hi,

Summarizing my thoughts and opinion on this issue. Changing the title to 
highlight the issues better.

As currently specified in draft-ietf-ace-oauth-authz-35, the RS will happily 
send the AS address to any node that asks. This causes two problems.

- If C acts on the unauthorized information, this is an attack vector for DoS 
attacks as an attacker on the C-RS path can make C contact a chosen node on the 
Internet. 

- That RS shares the AS address with anybody that asks can be a severe privacy 
problem. If RS is a medical device, the AS address can reveal sensitive 
information. If RS is a blood pressure sensor it could e.g. be “AS address = 
coaps://as.hopkinsmedicine.org/kimmel_cancer_center/”

The requirement "the client MUST be able to determine whether an AS has the 
authority to issue access tokens for a certain RS. This can for example be done 
through pre-configured lists, or through an online lookup mechanism that in 
turn also must be secured." indicates that C is required to have another 
mechanism to determine the AS for a specific RS and that the unauthorized AS 
address is completely redundant.

The draft does not discuss the privacy issues of unauthorized AS addresses at 
all and the draft is diminishing the DoS issues by only talking about 
compromised RS and attacking an AS. This indicates that none of these issues 
has been discussed enough. 

I currently have a strong opinion that Unauthorized AS address should be 
removed from the specification.

Cheers,
John

___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] Assignment of OSCORE Sender and Recipient IDS - was RE: Review of draft-ietf-ace-oscore-profile

[John Mattsson]

I agree very much with you Jim regarding the use on symmetric keys, and I think 
this is something IETF needs to work with in the future. I think a lot of IETF 
groups and drafts are using way too much symmetric keys for authentication and 
key exchange. There seems to be a belief that symmetric keys are needed for 
constrained IoT, which is not the case. Asymmetric authentication and key 
exchange can be achieved in similar message sizes to PSK authentication. E.g.

- method type 3 (static DH Key + static DH Key) in 
https://tools.ietf.org/html/draft-ietf-lake-edhoc-01

- static-static Diffie-Hellman shared secret in 
https://tools.ietf.org/html/draft-ietf-core-oscore-groupcomm-09

There are also very efficient ECC implementations taking up just a few kB.

Two-party authentication with symmetric keys comes with privacy problems, and 
symmetric groups keys does not provide authentication of the peer, just group 
membership. Symmetric key exchange does not provide PFS. Symmetric keys also 
comes with severe deployment problems.

While there are cases where asymmetric cryptography requires too much storage, 
memory, message sizes, or processing (latency), these are exceptions and should 
not be the default.

I see a limited need for symmetric authentication or key exchange in new 
systems, and I think the use should be clearly motivated. The main reason to 
use symmetric keys is in my view legacy interop.

John

-Original Message-
From: Jim Schaad 
Date: Wednesday, 9 September 2020 at 00:48
To: John Mattsson , "ace@ietf.org" 
Subject: RE: Assignment of OSCORE Sender and Recipient IDS - was RE: [Ace] 
Review of draft-ietf-ace-oscore-profile

Hey John, comments in line commented with JLS2

-Original Message-----
From: John Mattsson  
Sent: Tuesday, September 8, 2020 12:34 AM
To: Jim Schaad ; ace@ietf.org
Subject: Re: Assignment of OSCORE Sender and Recipient IDS - was RE: [Ace] 
Review of draft-ietf-ace-oscore-profile

Hi Jim,

I agree with most of what you say. Below are some additional comments on some 
of the bullets.

[JLS]  I'll start with what I said on the mailing list - this problem was 
discussed previously on the mailing list and in person and it was decided that 
it did not need to be fixed.

[JM] My understanding from Francesca and Göran is that neither migration path 
to e.g. EDHOC nor systems where the nodes change roles have been discussed 
before. Both have additional collision probems. How important the use cases are 
and how bad the collision problem would be can be discussed.

[JLS2] This may be a case of people not hearing things that they don't think 
are of immediate importance.  I spent a couple of years arguing about much of 
this.  I did not deal with the reversing situation because I am not sure that 
this really makes a great deal of sense for ACE in general.  The one exception 
would be things like revocation, but that is always going to be a single RS.


[JLS] 3) You seem to be ignoring the most practical solution to the problem, 
use the context identifier for name space separation.  If you have five 
different ASs, then simply assign a one byte context to each of them and you 
now have no problems with name collisions unless somebody is going to be 
knowingly difficult.  Similarly, you  assign each of the group key managers a 
one byte value which is used as the prefix to the contexts assigned by that key 
manager for all of the groups it manages.  I would have to look to see if one 
can specify a context for LAKE, but being able to do so would provide a 
separation for that space as well.

[JM] Yes, that is definitely a solution, but I don't think it matters if you 
use ID context or longer Sender IDs, it's the sum of the lengths that matter 
for the collision probability. I agree that you can definitely solve the 
collision problem by randomly assigning longer ID Context + Sender ID, 
potentially combined with a mechanism (as you mentioned during the interim) 
where the client rejects tokens that lead to collisions. This solves collision 
problems on with the cost of additional roundtrips and/or larger OSCORE message 
sizes. Both could be acceptable, but unfortunate as collision free and optimal 
(in terms of message size) are well-known and there seems to be no benefits of 
the AS dictating Sender and Recipient IDs. Both RFC 7252 and RFC 8613 is very 
careful to not waste a single byte.

[JLS2] Please re-read what I outlined.  I was suggesting the use of very short 
ID contexts which are assigned in a non-random method.  This means that the 
collision probability can be highly controlled and you are not using longer 
sender IDs that you would otherwise.  

[JLS2] One of the big advantages of the AS assigning client ids is that updated 
tokens will have the same client IDs so that you don't end up with having to 
change these because you do not recognize that it should be the same security 
conversation.  There are also advant

Re: [Ace] draft-ietf-ace-oauth-authz-35 - unauthorized AS address, DoS, and privacy

[John Mattsson]

Hi Olof,

Your reasoning does seem to be anchored in the draft. See inline.

The current state of the draft is not acceptable.

Grüße,
John Preuß Mattsson

-Original Message-
From: Olaf Bergmann 
Date: Wednesday, 9 September 2020 at 10:20
To: John Mattsson 
Cc: "ace@ietf.org" , "draft-ietf-ace-oauth-authz@ietf.org" 

Subject: Re: [Ace] draft-ietf-ace-oauth-authz-35 - unauthorized AS address, 
DoS, and privacy

Hello John,

Thank you for condensing this discussion thread. See inline for my
reasoning why I think that this issue is less severe than one would
expect at first:

John Mattsson  writes:

>> Summarizing my thoughts and opinion on this issue. Changing the title
>> to highlight the issues better.
>>
>> As currently specified in draft-ietf-ace-oauth-authz-35, the RS will
>> happily send the AS address to any node that asks. This causes two
>> problems.
>>
>> - If C acts on the unauthorized information, this is an attack vector
>> for DoS attacks as an attacker on the C-RS path can make C contact a
>> chosen node on the Internet.
>
>The important part here is the "If". A proper client MUST NOT act on
>unauthorized information at any time. The workaround is the list of
>known AS'es in the draft. (In the current architecture, a client would
>not and cannot communicate with an unknown AS anyway as it has no way to
>establish a secure communication.)

I cannot find anything in the draft stating that “A proper client MUST NOT act 
on unauthorized information at any time”. This also raises the question why the 
unauthorized information is needed in the first place.

>> - That RS shares the AS address with anybody that asks can be a severe
>> privacy problem. If RS is a medical device, the AS address can reveal
>> sensitive information. If RS is a blood pressure sensor it could
>> e.g. be “AS address =
>> coaps://as.hopkinsmedicine.org/kimmel_cancer_center/”
>
>This is a valid concern. However, I would argue that the Uri-Path in
>this URI should not be constructed to reveal this information in the
>first place. All discussions so far assumed that the authorization
>information endpoint on the AS would be named more descriptively as,
>e.g., /autz-info. This could at least mitigate the issue.

I don’t find anything in the draft stating that “the Uri-Path in this URI 
should not be constructed to reveal this information”, or how such a 
construction would look like. This is not trivial.

>> The requirement "the client MUST be able to determine whether an AS
>> has the authority to issue access tokens for a certain RS. This can
>> for example be done through pre-configured lists, or through an online
>> lookup mechanism that in turn also must be secured." indicates that C
>> is required to have another mechanism to determine the AS for a
>> specific RS and that the unauthorized AS address is completely
>> redundant.
>
>No. This indicates that before contacting an AS (in order to retrieve an
>access token for its communication with RS), the client must be sure
>that it trusts the AS to provide this access token. This is something
>that the client always needs to do, independent of the discovery
>mechanism.

I don’t find anything in the draft stating that “the client must be sure that 
it trusts the AS”. The draft states that “It is therefore advisable to provide 
C with a (possibly hard-coded) list of trustworthy authorization servers”. 
“Advisable” is not the same as “must”, “trustworthy” is not the same as “trust, 
and “C trust in AS” is completely different than “whether an AS has the 
authority to issue access tokens for a certain RS”

>> The draft does not discuss the privacy issues of unauthorized AS
>> addresses at all and the draft is diminishing the DoS issues by only
>> talking about compromised RS and attacking an AS. This indicates that
>> none of these issues has been discussed enough.
>>
>> I currently have a strong opinion that Unauthorized AS address should
>> be removed from the specification.
>
>I still think that due to the lack of a secure discovery mechanism for
>authorized AS'es, this mechanism is the best we have. Otherwise, the
>specification would leave the reader completely in the dark on how to
>guess to which AS the RS has delegated its authorization tasks. (A
>natural way would be to include it in /.well-known/core but I fail to
>see a difference except for an additional roundtrip in case the client
>is not aware a priori that the requested resource is protected.)

Your reasoning seems to indicate that the mechanism "the client MUST be able to 
determine whether an AS has the authority to issue access tokens for a certain 
RS” is just an imaginary requirement, and not something you believe will be 
possible in practice.

Grüße
Olaf

___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] Review of draft-ietf-ace-oscore-profile

[John Mattsson]

about any specific AS 
discovery mechnism.
 
-

 





Editorial suggestions:

-

- "bound to a key" -> "bound to a symmetric key"
 
-
 
- "This situation might occur " -> "two-time pad might otherwise occur"
 
-

- Figure 1.
 
I think it would be very good if you added a little bit more text in the Figure 
to show when proof-of-possession achieved.
 
/Sec Context /Sec Context|
   Derivation/  Derivation/   |
   || |
   |  OSCORE Request -> | |
 
proof-of-possession
context storage
   || |
   | <--- OSCORE Response - | |
 
proof-of-possession
context storage
   || |
   |  OSCORE Request -> | |
   |    | |
   | <--- OSCORE Response - | |
   |   ...  | |
 
-

Cheers,
John

-Original Message-
From: John Mattsson 
Date: Saturday, 5 September 2020 at 14:51
To: "ace@ietf.org" 
Subject: Review of draft-ietf-ace-oscore-profile

Hi,

I have reviewed the latest GitHub version of draft-ietf-ace-oscore-profile
https://ace-wg.github.io/ace-oscore-profile/draft-ietf-ace-oscore-profile.html

In general this draft looks very good. I have one major comments, and several 
more minor comments.

Major comment
---

- Asignment of OSCORE Sender and Recipient IDs

I think the specified mechanism where the AS dictates the OSCORE connection 
parameters is unfortunate. It introduces several current and future 
limitations. The current assignment mechanisms only works without problems in 
close systems where the RS does not have any other non-AS OSCORE connections, 
where the CoAP client and CoAP server roles are fixed and cannot be switched, 
and where only draft-ietf-ace-oscore-profile is used. In systems where the 
OSCORE nodes can switch between CoAP client and CoAP server (a feature 
explicitly supported by OSCORE) the current mechanism is likely to lead to 
RecipientID collisions. Also in future systems where the AS also supports a 
more modern key management with PFS using e.g. a future 
draft-ace-edhoc-oscore-profile, the mechanism would not work together in an 
efficient way. My understanding is that the authors would like the solution to 
work with both role switching and EDHOC.

How to negotiate these type of connection identifiers (in this case OSCORE 
Sender and Recipient IDs) have been studied and specified several times in e.g. 
draft-selander-lake-edhoc, draft-ietf-tls-dtls-connection-id. A solution where 
each party choses its OSCORE recipient ID for the connection always work 
without collisions. Such a negotiation could quite easily be added to the 
roundtrip with the nonces N1 and N2. My feeling is that it would be worthwhile 
to do such a change. This would also require a new identifier for the 
OSCORE_Security_Context Object, either a new objectID or a hash of the object 
could be used. I think this would be a good change as the current "hack" of 
using the ACE client sender Id and and ID context to identify the object might 
lead to other future limitations.

The suggested changes would lead quite equal message sizes and storage 
requirements, they might even lead to some small improvements.

Minor comments
---

- "server authentication"

My understanding is that server authentication with this draft requires two 
additional things. That C trusts AS and that RS sends an OSCORE response back. 
The draft should point this out similarly to the way it points out that a 
OSCORE request is required for proof-of-possession. As C trust in AS, and RS 
sending an OSCORE response back are both optional, I would recommend to maybe 
remove "server authentication" from the abstract and intro.

- "The nonces are encoded as CBOR bstr if CBOR is used, and as Base64 string if 
JSON is used"

Would be good to define exactly how the Master salt is created when JSON is 
used. I.e. is the Base64 encoded strings used, or are the byte strings after 
Base64 decoding used.

- "the authz-info endpoint is not a protected resource, so there is no 
cryptographic protection to this request."

I do not think this follows from the OAuth ACE term “protected resource”. Most 
resources on the web are not protected resources, but use cryptographic 
protection (https:// HTTPS)

- "An OSCORE_Security_Context is an object that represents part or all of an 
OSCORE Security Context"

The object ca

Re: [Ace] [Emu] New Version Notification for draft-ietf-ace-wg-coap-eap-04.txt

[John Mattsson]

Thanks,

I think this is a very useful mechanism and a well written draft. Some quick 
comments.

- "ciphersuite"
Note that both TLS and EDHOC spells this with space "cipher suite"

- Section 2. I don't understand what "SM" in Figure 1 is an abbrevation for.

- Section 2. "UDP/TCP/Websockets" Why is the Websocket protocol in plural?

- Section 3. "EAP method that exports cryptographic material"

  This can probably be reformulated in terms of MSK, EMSK or "Key derivation" 
which
  is the property that RFC 3748 uses.

- "EAP-MD5 cannot be used since it does not export key material"

   MD5 should really not be used at all for security resons. Highlighting it 
like this might
   be the idea that it would be ok if EAP-MD5 had the "Key derivation" property.

- "The required key, the Master Session Key (MSK), will be available once the
   EAP authentication is successful."

   Does this belong in step 2?

- In Figure 2. I do not think you have to wait until EAP-SUCCES to make MSK 
available.
  The authentication can be successful before EAP-SUCCES.

- In section 3.3. it might be good to state that "Reauthentication" might be 
needed to rekey MSK/EMSK and to increase protection against key leakage.

(An important mitigation of pervasive monitoring is to force attackers to do 
dynamic key exfiltration instead of static key exfiltration. Dynamic key 
exfiltration increases the risk of discovery for the attacker [RFC7624]. While 
OSCORE will soon be augmented with a rekeying mechanism with forward secrecy, 
attackers can still get away with doing static key exfiltration. This is 
similar to TLS 1.3 with KeyUpdate, after leakage of 
application_traffic_secret_N, a passive attacker can passively eavesdrop on all 
future application data sent on the connection including application data 
encrypted with application_traffic_secret_N+1, application_traffic_secret_N+2, 
etc.)

- "4.  The values from 65000 to 65535 are reserved for experimentation"

   what does "The values" refer to? Lifetime? In that case it would fit better 
under 3.

- In addition to AES-CCM-16-64-128, only ciphersuites only cipher suites with 
AES-GCM is included. My feeling was that most IoT people are more interested in 
ChaCha20-Poly1305 than AES-GCM. I don't have a strong personal opinion.

- "which is considered fresh key material"

   “considered fresh”? Maybe "uniformally random"?

- With normal use of DTLS, Appendix A violates “The CoAP-EAP operation is 
intended to be compatible with the use of intermediary entities between the IoT 
device and the Controller”. This limitation should be clearly stated.

- Probably good if the labels have “CoAP-EAP” in all the labels to guarantee 
that they do not collide with anything else.

Cheers,
John

From: Emu  on behalf of Dan Garcia Carrillo 

Date: Monday, 25 October 2021 at 13:27
To: ace@ietf.org , EMU WG 
Subject: Re: [Emu] New Version Notification for 
draft-ietf-ace-wg-coap-eap-04.txt
Dear ACE and EMU WG,

We have submitted a new version of the draft (draft-ietf-ace-wg-coap-eap)

This version provides information on the different comments, from the
reviews and interim meetings.

Best Regards.


El 10/25/2021 a las 1:23 PM, internet-dra...@ietf.org escribió:
> A new version of I-D, draft-ietf-ace-wg-coap-eap-04.txt
> has been successfully submitted by Dan Garcia-Carrillo and posted to the
> IETF repository.
>
> Name: draft-ietf-ace-wg-coap-eap
> Revision: 04
> Title:EAP-based Authentication Service for CoAP
> Document date:2021-10-25
> Group:ace
> Pages:29
> URL:
> https://www.ietf.org/archive/id/draft-ietf-ace-wg-coap-eap-04.txt
> Status: https://datatracker.ietf.org/doc/draft-ietf-ace-wg-coap-eap/
> Htmlized:   
> https://datatracker.ietf.org/doc/html/draft-ietf-ace-wg-coap-eap
> Diff:   
> https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-wg-coap-eap-04
>
> Abstract:
> This document specifies an authentication service that uses the
> Extensible Authentication Protocol (EAP) transported employing
> Constrained Application Protocol (CoAP) messages.  As such, it
> defines an EAP lower layer based on CoAP called CoAP-EAP.  One of the
> primer goals is to authenticate a CoAP-enabled IoT device (EAP peer)
> that intends to join a security domain managed by a Controller (EAP
> authenticator).  Secondly, it allows deriving key material to protect
> CoAP messages exchanged between them based on Object Security for
> Constrained RESTful Environments (OSCORE), enabling the establishment
> of a security association between them.
>
>
>
>
> The IETF Secretariat
>
>

___
Emu mailing list
e...@ietf.org
https://www.ietf.org/mailman/listinfo/emu
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] I-D Action: draft-ietf-ace-oscore-profile-19.txt

[John Mattsson]

Hi,

I think it would be good if the draft added a sentence to clarify that the 
profile works with all transports that CoAP can be transported over. This is 
already the case, but it is not mentioned. The default choice for most 
deployments will probably be UDP, but sometimes UDP is blocked, and the client 
has to fall back to TCP to reach the RS.

Cheers,
John
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] Protocol Action: 'Datagram Transport Layer Security (DTLS) Profile for Authentication and Authorization for Constrained Environments (ACE)' to Proposed Standard (draft-ietf-ace-dtls-authoriz

[John Mattsson]

Thanks to the IESG for stepping in and adding DTLS 1.3. Very much appreciated!

I think IESG should send any (D)TLS 1.2 only drafts back to the WGs from now 
on. A lot of SDOs and industries are working hard on updating all (D)TLS 
applications to work also with 1.3. The last thing the world needs is more 1.2 
only standards.

I was surprised already in 2017 that the draft was 1.2 only.
https://datatracker.ietf.org/meeting/98/materials/minutes-98-ace-00

Cheers,
John
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] Protocol Action: 'Datagram Transport Layer Security (DTLS) Profile for Authentication and Authorization for Constrained Environments (ACE)' to Proposed Standard (draft-ietf-ace-dtls-authoriz

[John Mattsson]

The -17 and -18 versions clearly states that it can be used with DTLS 1.3. The 
GitHub version, which I assume will be the basis for the RFC also explains the 
psk identity differences between 1.2 and 1.3, which is great. I don’t think 
there is a need to do anything more.

Regarding DTLS 1.3 support, I don’t think there is any need for a -bis version, 
DTLS 1.3 is to my understanding already supported by the current document 
thanks to IESG.

John

From: Carsten Bormann 
Date: Thursday, 4 November 2021 at 16:14
To: John Mattsson 
Cc: ace@ietf.org 
Subject: Re: [Ace] Protocol Action: 'Datagram Transport Layer Security (DTLS) 
Profile for Authentication and Authorization for Constrained Environments 
(ACE)' to Proposed Standard (draft-ietf-ace-dtls-authorize-18.txt)
On 2021-11-04, at 15:08, John Mattsson 
 wrote:
>
> I think IESG should send any (D)TLS 1.2 only drafts back to the WGs from now 
> on.

Since you made this comment on an approved document (which the IESG no longer 
gets to “send back”), I’m not sure I understand what you are trying to say, but 
I don’t agree with any of the possible interpretations.

> A lot of SDOs and industries are working hard on updating all (D)TLS 
> applications to work also with 1.3. The last thing the world needs is more 
> 1.2 only standards.

I don’t think we need to form a queue behind the completion of DTLS 1.3.
This apparently will take some more time:
https://protect2.fireeye.com/v1/url?k=8ed7d76d-d14cee6d-8ed797f6-86fc6812c361-b378f81d3777bcda&q=1&e=5985dba9-7ace-4fe4-9ace-256b8615b396&u=https%3A%2F%2Fwww.rfc-editor.org%2Fauth48%2FC321
2021-10-18:  Received email from Eric Rescorla that an open technical issue is 
ongoing.

However, we should already have been working on a -bis for the DTLS profile 
that also supports DTLS 1.3; I can certainly agree with that.

Grüße, Carsten
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] WG Adoption Call for bergmann-ace-extend-dtls-authorize

[John Mattsson]

As a author I obviously support adoption.

The whole content of the document is 164 words. If anybody has been looking for 
a really short document to review, now’s your chance :)

Cheers,
John
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] New Version Notification for draft-ietf-ace-extend-dtls-authorize-05.txt

[John Mattsson]

Hi,

We have submitted a new version intended to address all the comments in the AD 
Review. Thanks, Roman for the good comments.

https://mailarchive.ietf.org/arch/msg/ace/LECjW-g5p1tU4ZawHfgNK0j243w/

Cheers,
John


From: internet-dra...@ietf.org 
Date: Tuesday, 10 January 2023 at 15:26
To: Göran Selander , John Mattsson 
, Göran Selander , 
John Mattsson , Olaf Bergmann 
Subject: New Version Notification for 
draft-ietf-ace-extend-dtls-authorize-05.txt

A new version of I-D, draft-ietf-ace-extend-dtls-authorize-05.txt
has been successfully submitted by John Preuß Mattsson and posted to the
IETF repository.

Name:   draft-ietf-ace-extend-dtls-authorize
Revision:   05
Title:  Extension of the CoAP-DTLS Profile for ACE to TLS
Document date:  2023-01-10
Group:  ace
Pages:  6
URL:
https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-45444731-e849d03664c09ec7&q=1&e=47924d15-d8a3-4c40-877f-f25a3af83c66&u=https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-ietf-ace-extend-dtls-authorize-05.txt
Status: 
https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-45444731-39bca9f47cffaa8e&q=1&e=47924d15-d8a3-4c40-877f-f25a3af83c66&u=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-ace-extend-dtls-authorize%2F
Html:   
https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-45444731-af0d4630d1575140&q=1&e=47924d15-d8a3-4c40-877f-f25a3af83c66&u=https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-ietf-ace-extend-dtls-authorize-05.html
Htmlized:   
https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-45444731-a166d4b391f7992a&q=1&e=47924d15-d8a3-4c40-877f-f25a3af83c66&u=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-ace-extend-dtls-authorize
Diff:   
https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-45444731-f8e1c51777156947&q=1&e=47924d15-d8a3-4c40-877f-f25a3af83c66&u=https%3A%2F%2Fauthor-tools.ietf.org%2Fiddiff%3Furl2%3Ddraft-ietf-ace-extend-dtls-authorize-05

Abstract:
   This document updates the CoAP-DTLS profile for ACE described in RFC
   9202 by specifying that the profile applies to TLS as well as DTLS.




The IETF Secretariat
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] Secdir last call review of draft-ietf-ace-extend-dtls-authorize

[John Mattsson]

Hi Tirumaleswar,

Thanks for your review and the good comments. See inline. We will update the 
document accordingly.

Cheers,
John

From: tirumal reddy 
Date: Friday, 13 January 2023 at 07:32
To: sec...@ietf.org , last-c...@ietf.org , 
ace@ietf.org , draft-ietf-ace-extend-dtls-authorize@ietf.org 

Subject: Secdir last call review of draft-ietf-ace-extend-dtls-authorize
Reviewer: Tirumaleswar Reddy
Review result: Ready with Nits

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of the
security area directors.  Document editors and WG chairs should treat
these comments just like any other last call comments.

This document updates the CoAP-DTLS profile for ACE by specifying
that the profile applies to TLS as well as DTLS.

Comments below:

1) In case the ace_profile parameter indicates the
use of the DTLS profile for ACE as defined in [RFC9202],
the Client MAY try to connect to the Resource Server via TLS, or try TLS and 
DTLS in parallel
to accelerate the connection setup. It is up to the implementation to handle 
the case where the RS reponds to both connection requests.

Comment> DTLS should be given higher precedence than TLS as CoAP over UDP is 
the first choice of implementation.

John: Yes, if the Client supports both DTLS and TLS, the first choice should be 
DTLS unless the Client has reason to believe that only TLS will work. We will 
add text describing this.


2) As resource-constrained devices are not expected to
support both transport layer security mechanisms, a Client
that implements either TLS or DTLS but not both might fail in establishing a 
secure communication channel with the Resource Server altogether.

Comment> If the IoT device cannot support both TLS and DTLS , is it mandatory 
for the device to support TLS ?
Otherwise, if a device supports DTLS only and a firewall blocks the 
communication channel over UDP with the RS, it will fail to function.

John: In general it should not be mandatory to support TLS, but a device 
implementing this document is supporting TLS. Most ACE clients will likely only 
support DTLS. Some will support both to do firewall traversal. Some will only 
support TLS. Yes in the case you describe the connection will fail. Things can 
fail to function even with TLS if the firewall only accepts connections from 
the other directions. We will add text with these considerations.


Cheers,
-Tiru
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] Meeting in Yokhohama ?

[John Mattsson]

I agree with earlier replies that ACE should meet at IETF 116 . ACE is now 
deployed in a number of industries and there is a lot of things to address, 
regarding both lacking security as well as functionality. As discussed by 
previous comments, meetings during the IETF week attract a lot of people that 
would otherwise not call into an interim, that typically includes me.

Cheers,
John
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] Gen-ART Last Call review of draft-ietf-ace-extend-dtls-authorize-05

[John Mattsson]

Hi Paul,

Thanks for you review.

I very much agree with you that this should have been part of the RFC 9202. In 
fact, I pointed out the need for TLS compatibility very early in the 
standardization process. The situation right now is that this was unfortunately 
not done, and that TLS/TCP is very much needed for the 3GPP use of RFC 9202. 
This should have been standardized yesterday, so any increased delay would not 
be good. 3GPP is waiting for this draft. A future update to RFC 9202 might be 
worth doing.

> But it fails to do the work of actually making those revisions. It leaves 
> that work to the  reader. It is hard to believe that all readers will infer 
> the identical set of changes.
I don’t see what is missing and what would be hard to infer, and I am not an 
author of RFC 9202. It would be more constructive if you could provide advice 
on how to improve draft-ietf-ace-extend-dtls-authorize.

> I suggest that this document's status be changed to an informational
I think it would be strange if DTLS transport is standards track and TLS is 
informal. Also Informational is not compatible with the current IANA actions. I 
would suggest not doing this.

Cheers,
John

From: Paul Kyzivat 
Date: Friday, 20 January 2023 at 18:32
To: draft-ietf-ace-extend-dtls-authorize@ietf.org 

Cc: General Area Review Team , last-c...@ietf.org 
, ace@ietf.org 
Subject: Gen-ART Last Call review of draft-ietf-ace-extend-dtls-authorize-05
I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

.

Document: draft-ietf-ace-extend-dtls-authorize-05
Reviewer: Paul Kyzivat
Review Date: 2023-01-20
IETF LC End Date: 2023-01-24
IESG Telechat date: ?

Summary:

This draft is on the right track but has open issues, described in the
review.

Issues: 1

1) ISSUE: Form and completeness of the document

This document reads as a good concept document proposing how RFC 9202
could be revised to allow use of both TLS and DTLS. But it fails to do
the work of actually making those revisions. It leaves that work to the
reader. It is hard to believe that all readers will infer the identical
set of changes.

I suggest that this document's status be changed to an informational,
and then work begin on an rfc9202bis document that incorporates the
proposed changes.
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

[Ace] FW: New Version Notification for draft-ietf-ace-extend-dtls-authorize-06.txt

[John Mattsson]

Hi,

We submitted -06 addressing the comments received during the IETF last call.

- Clarified that the Client typically first tries using DTLS to connect to the 
Resource Server. If this fails, the Client MAY try to connect to the Resource 
Server via TLS. Change based on a comment from Tirumaleswar Reddy.

- Added "Clients and Resource Servers SHOULD support DTLS and MAY support TLS." 
Change based on a comment from Tirumaleswar Reddy.

-  Added detailed information including a new section describing how the 
document updates RFC 9202. Change based on a comment from Paul Kyzivat.

We don't think a RFC9202bis document is realistic at this moment as that would 
cause significant delays and 3GPP TS 33.434 has a dependency on 
draft-ietf-ace-extend-dtls-authorize.

We have not changed the category to informal as that would hinder the currently 
suggested IANA actions.

Cheers,
John

From: internet-dra...@ietf.org 
Date: Wednesday, 25 January 2023 at 12:34
To: Göran Selander , John Mattsson 
, Göran Selander , 
John Mattsson , Olaf Bergmann 
Subject: New Version Notification for 
draft-ietf-ace-extend-dtls-authorize-06.txt

A new version of I-D, draft-ietf-ace-extend-dtls-authorize-06.txt
has been successfully submitted by John Preuß Mattsson and posted to the
IETF repository.

Name:   draft-ietf-ace-extend-dtls-authorize
Revision:   06
Title:  Extension of the CoAP-DTLS Profile for ACE to TLS
Document date:  2023-01-25
Group:  ace
Pages:  6
URL:
https://www.ietf.org/archive/id/draft-ietf-ace-extend-dtls-authorize-06.txt
Status: 
https://datatracker.ietf.org/doc/draft-ietf-ace-extend-dtls-authorize/
Html:   
https://www.ietf.org/archive/id/draft-ietf-ace-extend-dtls-authorize-06.html
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-ietf-ace-extend-dtls-authorize
Diff:   
https://author-tools.ietf.org/iddiff?url2=draft-ietf-ace-extend-dtls-authorize-06

Abstract:
   This document updates the CoAP-DTLS profile for ACE described in RFC
   9202 by specifying that the profile applies to TLS as well as DTLS.




The IETF Secretariat
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] Warren Kumari's No Record on draft-ietf-ace-extend-dtls-authorize-06: (with COMMENT)

[John Mattsson]

Hi,

We have submitted draft-ietf-ace-extend-dtls-authorize-07. This version 
addresses all comments received from OpsDir and IESG.

- Expanded the terms ACE, CoAP, TLS, DTLS, OSCORE, AS, RS as suggested by 
OpsDir and John Scudder.
- Added some info on the ACE framework (RFC9200) including the information that 
both the Client and the RS may be constrained. This addresses the comments from 
Paul Wouters, Zaheduzzaman Sarker, and John Scudder
- Explained what DTLS is used for. This addresses the comment from Lars Eggert.
- Removed the sentences "The client can try TLS and DTLS in parallel to 
accelerate the connection setup. It is up to the implementation to handle the 
case where the RS reponds to both connection requests." This addresses the 
comments from Erik Kline, Warren Kumari, and OpsDir.
- Added "Non-constrained Clients and Resource Servers SHOULD support both TLS 
and DTLS.". This addresses comments from Paul Wouters, Robert Wilton, and 
Zaheduzzaman Sarker.
- Fixed all nits found by IESG.

Diff:   
https://author-tools.ietf.org/iddiff?url2=draft-ietf-ace-extend-dtls-authorize-07

Cheers,
John

From: Warren Kumari via Datatracker 
Date: Wednesday, 15 February 2023 at 15:27
To: The IESG 
Cc: draft-ietf-ace-extend-dtls-author...@ietf.org 
, ace-cha...@ietf.org 
, ace@ietf.org , mglt.i...@gmail.com 
, mglt.i...@gmail.com , 
yingzhen.i...@gmail.com , ops...@ietf.org 

Subject: Warren Kumari's No Record on draft-ietf-ace-extend-dtls-authorize-06: 
(with COMMENT)
Warren Kumari has entered the following ballot position for
draft-ietf-ace-extend-dtls-authorize-06: No Record

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to 
https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-ace-extend-dtls-authorize/



--
COMMENT:
--

Thanks to Yingzhen Qu for the helpful OpsDir review:
https://datatracker.ietf.org/doc/review-ietf-ace-extend-dtls-authorize-06-opsdir-lc-qu-2023-02-09/

I encourage the authors to review this, and respond to the "In case both the
client and server support both TLS and DTLS, it says here “It is up to the
implementation to handle”. However it also says “the client typically first
tries using DTLS”, this seems to give priority to DTLS. Please clarify."

___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] call for adoption draft-selander-ace-coap-est-oscore

[John Mattsson]

I support adoption and will review.

Cheers,
John

___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

[Ace] I-D Action: draft-ietf-ace-coap-est-oscore-02.txt

[John Mattsson]

Review of draft-ietf-ace-coap-est-oscore-02

Hi,

Below is my review of draft-ietf-ace-coap-est-oscore-02. This does not seem 
ready yet.


  *   “EST-coaps ([RFC9148])”

This is in parathesis, other references are not.



  *   OLD “DTLS 
[RFC6347]
 
[RFC9147]”
NEW “DTLS 
[RFC6347]”

RFC 6347 is obsoleted. I think the rule is to not refer to obsolete RFC unless 
needed.


  *   ”instead of HTTP 
[RFC9110]
 
[RFC9112]
 and TLS 
[RFC8446]”

Any reason that this is referring to HTTP/1.1 only? HTTP/2 and HTTP/3 seems 
like much better more modern options.


  *   You seem to use the old BCP14 boilerplate. Use {::boilerplate bcp14} in md


  *   The trust anchor terminology from RFC 6024 ”used to verify digital 
Signatures” does not work with 3/4 of the EDHOC methods. Needs to be rewritten.



  *   ”is the SubjectPublicKeyInfo structure”
How does this work efficiently with EDHOC?


  *   A Trust Anchor database is always required, not just for certificates (I 
have not read RFC 7030). ” enabling the client to authenticate the server” is 
always required.



  *   ”Connection-based proof-of-possession”, I assume this means the client 
might not be authenticated (verify identity) in EDHOC. In that case this needs 
to be described and discussed.



  *   Should ”32 bytes” seems a bit much for something trying to be lightweight.


  *   Section 3.4 talks about ”certificates”. It is not clear which types of 
certificates this is about. EST-oscore use certificates on two layers (In EDHOC 
and on top of OSCORE).


-  Figure 1 does also not illustrate the use of 
I-D.ietf-core-oscore-edhoc



  *   Figures 1 and 2 would look much nicer with aasvg



  *   Figure 3 would look much nicer as a Table.


  *   I-D.ietf-cose-x509 has been published as RFC 9360



  *   EST with hop-by-hop protection over a proxy seems like a very bad 
security architecture. Unless RFC 9148 makes this NOT RECOMMENDED, I think this 
draft should update RFC 9148 and do that. Server generated private keys visible 
to proxies should be MUST NOT. I have not read RFC 9148.



  *   ”TBD: Compare with RFC9148”
Need to be fixed before any WGLC.



  *   OLD: Section 4 of 
[RFC6955]
NEW: Section 6 of 
[RFC6955]


  *   ”The EST client obtained the CA certs including the CA's DH certificate 
using the /crts function”
This seems very inefficient. Why not just use G_Y from EDHOC? The 
Client/Initiator can use the cipher suite to get the curve it wants. I think 
this should be added as on option.


  *   “As per [RFC8613], the HKDF MUST be one of the HMAC-based HKDF [RFC5869] 
algorithms defined for COSE [RFC9052].”

I would say that the quoted sentence is an erratum in OSCORE. I would suggest 
deleting that sentence. Should be one of the HMAC algorithms defined for COSE 
or one of the hash functions defined for COSE. COSE does not have any general 
HKDFs defined. They are “direct+HKDF-SHA-512” and only make sense if you use 
them in COSE and not in OSCORE. EDHOC specifies that the output to OSCORE can 
be HMAC-SHA-384.


  *   “External Authorization Data (EAD) fields of EDHOC are
intentionally not used to carry EST payloads because EDHOC needs not
be executed in the case of re-enrollment.”
This seems to me like the wrong decision. Using EAD would be much more 
efficient for the first enrollment. How common and important is re-enrollment? 
By using EDHOC efficiently I think the client might be able to send the CSR in 
message_3 and get the cert in message_4.


  *   “|UDP or TCP   |”

I suggest deleting this layer. Both CoAP and HTTP can be transported over other 
(or more)( or less) things. Having UDP and TCP in this figure do not add 
anything.



  *   The document makes heavy use of EDHOC and states that C509 might be use 
as an optimization. Other parts of the draft seems 100% ASN.1. EDHOC makes 
heavy use of CWT/CSS/C509. It would make sense to be able to request the server 
to issue C509 certificates. Currently that does not seem to be possible.


  *   This is probably handled by other drafts, but I think the draft should 
summarize some very basic high-level things in the introduction. Is the client 
assumed to have some form of credential before starting EST-oscore. In that 
case what kind of credential. The whole point of certificates is to bind a 
public key with an identity. How does the 

[Ace] RFC 9148 challengePassword byte string to text string encoding

[John Mattsson]

Hi,

The encoding of the challengePassword in RFC 9148 seems undefined, or?

My understanding is that the ANS.1 type for challengePassword is 
DirectoryString, which according to RFC 5280 is

   DirectoryString ::= CHOICE {
 teletexString   TeletexString (SIZE (1..MAX)),
 printableString PrintableString (SIZE (1..MAX)),
 universalString UniversalString (SIZE (1..MAX)),
 utf8String  UTF8String (SIZE (1..MAX)),
 bmpString   BMPString (SIZE (1..MAX)) }

RFC 9148 takes 32 bytes from the TLS exporter but does not seem to specify how 
to encode the 32 bytes as a ASN.1 text string.

Looking at one of the examples in RFC 9148, it seems like the challengePassword 
is a 37-byte UTF8String:

196 115: [0] {
198  52:   SEQUENCE {
200   9: OBJECT IDENTIFIER challengePassword (1 2 840 113549 1 9 7)
211  39: SET {
213  37:   UTF8String 'vCv0)*&JKJ;/><.,=knv43##@= Nx~`'
   :   }
   : }

I don't understand how this the 32 bytes gets encoded into the 37 byte UTF8 
text string. This is not Base64 or hex and general byte strings are not valid 
utf8.

Is the bytestring to textstring encoding specified in some other document or is 
is just undefined? Maybe it is ok that the encoding to be unspecified in this 
case as long the encoding is the same everytime it is used.

The reason I wonder is that we would like to make an optimal C509 encoding for 
this, but we cannot make that unless the encoding is specified and we 
understand it….

Cheers,
John
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] Call for adoption for draft-tiloca-ace-group-oscore-profile

[John Mattsson]

I support adoption
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] Call for adoption of draft-tiloca-ace-workflow-and-params

[John Mattsson]

I support adoption
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace