Re: [Lake] PRs on encoding clarification and invalid test vectors

[Göran Selander <[e-mail]>]

Hi Paul, LAKE chairs, and all,

We missed to follow up the instructions in the mail below.

> Create a PR, notify the list. Then after a few days send email to the RFC Editor and CC: me (as AD). I guess these two requests to the RFC Editor should be folded into one request though.

This part, when to abort invalid messages, is included in the same PR #446 as addressing item 2, and has been out for some time. I just made a minor wording update today.

https://github.com/lake-wg/edhoc/pull/446

The contents are as described by John in a previous mail in this thread.

Do we need more time or should I now send to RFC Editor (and CC AD)?

Göran


(PR#442 was already merged in before sending -traces to RFC Editor.)



From: Lake <[e-mail]> on behalf of Paul Wouters <paul.wouters=[e-mail]>
Date: Monday, 11 September 2023 at 22:02
To: John Mattsson <john.mattsson=[e-mail]>
Cc: John Mattsson <[e-mail]>, [e-mail] <[e-mail]>
Subject: Re: [Lake] PRs on encoding clarification and invalid test vectors

On Sat, Sep 9, 2023 at 2:30 AM John Mattsson <john.mattsson=[e-mail]<mailto:[e-mail]>> wrote:
Hi Paul,

https://github.com/lake-wg/edhoc/pull/442<https://protect2.fireeye.com/v1/url?k=31323334-501cfaf3-313273af-454445554331-8503a20fe11575b8&q=1&e=adbcd16f-7172-4a15-a7d2-2b3560914e58&u=https%3A%2F%2Fgithub.com%2Flake-wg%2Fedhoc%2Fpull%2F442>

Is a PR to the traces draft with invalid test vectors. The work before focused more or less only on valid test vectors. I wish we had looked at this earlier, but I think it very good that we did now.

For the traces draft, just submit a new draft please. It has not yet entered the RFC Editor queue.

https://github.com/lake-wg/edhoc/pull/446<https://protect2.fireeye.com/v1/url?k=31323334-501cfaf3-313273af-454445554331-428ad5d0452896f6&q=1&e=adbcd16f-7172-4a15-a7d2-2b3560914e58&u=https%3A%2F%2Fgithub.com%2Flake-wg%2Fedhoc%2Fpull%2F446>

Is my collection of things that are not optimal in the EDHOC draft. These were found during the work on invalid traces. The PR contains two things:

1. Sender side and wire format: Minor clarifications and corrections on encoding. These are editorial thing that I intend to bring up in my AUTH48 review. I just did this part of my AUTH48 review early.

2. Receiver side: Some suggested changes to what a receiver does with various types of invalid encoding. This would involve changes to RFC2119 words and therefore goes beyond clarification and corrections and I therefore send it to the WG. I think the topic of what to do with different types of invalid messages was ignored a bit. These changes do not change the requirements on the sender or the wire format at all.

Please send an email with instructions to the RFC Editor ([e-mail]<mailto:[e-mail]>) now, and CC: me (as AD). Please do not wait for AUTH48.

 I think the current text on when to abort invalid messages is not optimal. On the otherhand it is things that are 100% in the receiver implementations and does not affect the sender or the wire format. While changes would be good it is not 100% essential, a receiver implementation can do this anyway. I don't know what "pause the publication process" would mean. These changes would clearly need consensus in the WG, but I don’t know what the exact process would be. I assume that is partly up to the AD.

Create a PR, notify the list. Then after a few days send email to the RFC Editor and CC: me (as AD). I guess these two requests to the RFC Editor should be folded into one request though.

Paul



Cheers,
John
From: Lake <[e-mail]<mailto:[e-mail]>> on behalf of Paul Wouters <paul.wouters=[e-mail]<mailto:[e-mail]>>
Date: Friday, 8 September 2023 at 15:59
To: John Mattsson <john.mattsson=[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Subject: Re: [Lake] PRs on encoding clarification and invalid test vectors
On Sep 8, 2023, at 04:52, John Mattsson <john.mattsson=[e-mail]<mailto:[e-mail]>> wrote:


The plan is to:
- include the traces PR in the next version of the draft.
- include the EDHOC PR duing AUTH48.

No PRs should be merged during AUTH48.

Are you talking about the edhoc draft or the edhoc-traces draft ?

We can pause the publication process if needed.

Paul