Saturday, November 11, 2017< ^ >
ynir has set the subject to: ACE meeting - IETF 98 - Room Zurich C -
Room Configuration
Room Occupants

[02:36:36] jimsch1 joins the room
[02:36:50] Christian joins the room
[02:37:05] francesca joins the room
[02:37:14] <Christian> good morning francesca
[02:37:22] <francesca> Hi Christian!
[02:37:30] <francesca> Sorry for being late
[02:38:21] <Christian> no problem, jim and i already got our first messages with the new draft version exchanged
[02:38:46] <francesca> great :)
[02:39:39] <Christian> jimsch1 ad test 5: please hang on a moment, i'm trying the test with my own client
[02:41:44] <jimsch1> Just to be clear - I think that I receaved an ACK w/ no headers follwed by a compressed form w/ a header.  HOwever since it has the observer option - I always run the observe path (I think)
[02:42:36] <Christian> i'll try to verify that once i find out why both my server and my client locally pass their test suites but my client can't execute test 5 against my server
[02:44:26] <jimsch1> I take that back - it looks like I always key on the presence of the partialIV and don't look at an observe option on receipt.  Only do the other on send of response.
[02:45:36] <Christian> mh, there's something broken in my code (and the test suite is broken too so i didn't catch it) :-(
[02:49:52] <Christian> oook... i see roughly where my bug is:
[02:50:10] <Christian> it's still the handling of the sequence number 0 to be encoded as h'00' not as h''
[02:50:29] <Christian> i've temporarily set my server to start with sequence number 1, can you retry please?
[02:50:42] <jimsch1> just 5 ?
[02:50:51] <Christian> as you like
[02:51:26] <jimsch1> I got back two messages - '1' and 'Zwei'
[02:51:32] <Christian> great :-)
[02:52:28] <Christian> we'll need to come back to that test once i've found where i'm left-trimming or not left-trimming the partial iv
[02:53:04] <jimsch1> I only seem to be setup to run the first 7 tests.  Need to look at the test set.
[02:53:57] <Christian> 8 and 9 seem trivial oscoap-wise, 10ff are the hard ones with incorrect oscoap use
[02:54:20] <Christian> i'll use that time to look into the seqno-zero issue
[02:55:24] <jimsch1> Ok - I just got a replay protection failure - I should have a PIV of 10
[02:56:26] <Christian> which test were you executing?
[02:57:05] <Christian> shall i reset the replay protection?
[02:58:35] <jimsch1> I was running test 8
[02:59:54] <jimsch1> I would love to know why you are giving me a failed hit test because I don't think I have used that IV yet.  Are you expecting things to be in order?
[03:00:17] <Christian> no, i'm just sifting through the logs
[03:02:04] <Christian> yes, that's odd -- i haven't seen that IV before
[03:02:08] <Christian> yet the server refused it
[03:02:17] <Christian> adding more logging there...
[03:03:55] <Christian> debugging in place, can you run the full sequence again?
[03:04:01] <jimsch1> oiok
[03:04:02] <jimsch1> will do
[03:04:40] <jimsch1> I just faile d0
[03:04:53] <jimsch1> now seems fine
[03:04:53] <Christian> that's odd, i received the request
[03:05:25] <Christian> but that could be a clue: can you check for package loss on the link to the server?
[03:06:04] <Christian> if there is, and you've seen spurious reuse failures: are you sending your retransmits on the same message IDs?
[03:07:07] <jimsch1> I should generate a new MID every message.  It would be very random for it to be the same twice in a row.
[03:07:48] <Christian> imo retransmits should have the same message ID, even if and especially if they're OSCORE
[03:07:57] <jimsch1> I just ran 8 and 9 and they both passed.
[03:08:08] <jimsch1> A retransmit will have the same MID.
[03:08:12] <Christian> ok
[03:08:57] <Christian> now i'm seeing reuse on sequence number 1
[03:09:17] <jimsch1> Odd - I thought I was using 20.  Must be an error in my code somewhere.
[03:10:39] <Christian> did you explicitly increase it to 20? because the last exchanges had sequence numbers up to and including 5
[03:11:39] <jimsch1> I thought I was doing an explicit jump.  Don't know why my code is not doing it correctly.
[03:11:52] <jimsch1> I see a 1 in the send log
[03:16:44] jimsch1 joins the room
[03:17:03] <jimsch1> I need to fix my ipv6 - so I juste switched so I have an IPv4 address -
[03:18:11] <jimsch1> Ok - I think my server is up
[03:18:20] <Christian> started tests, and 0 and 1 passed
[03:18:37] <Christian> 2, 3, 4 passed
[03:19:13] <Christian> 5 tells me it will be lunch time soon
[03:19:44] <jimsch1> I am not sure when lunch is being served here -
[03:20:51] <Christian> 6 passes (with comments: it seems to be giving hello/?first=1 rather than hello/6?first=1 as Location)
[03:21:20] <jimsch1> Ok - that is a bug in my code - I forgot which of the two variables I needed.
[03:22:53] <Christian> 7 passes (with comments: i expect Changed where i got Created, and didn't expect the ETag)
[03:23:08] <Christian> 8 and 9 pass
[03:24:10] <Christian> 10 and 11 pass
[03:24:46] <Christian> 12 passes
[03:25:30] <Christian> 13 failed (as usual -- your test server is configured not to do replay protection)
[03:27:35] <Christian> i don't have 14 and 15 implemented, but since i manually tried to access /hello/1 w/o protection, your server seems to have triggered a breakpoint
[03:28:49] <jimsch1> My code just crashed.  
[03:29:53] <Christian> the first message i didn't get a response to was an unprotected GET at /hello/1
[03:30:28] <jimsch1> somebody juste tried to send a secure message as an unsecure message.
[03:31:00] <jimsch1> I just restarted the server
[03:31:03] <Christian> that's basically test 15
[03:31:27] <Christian> shall i retry that test?
[03:31:45] <francesca> yes please
[03:32:38] jimsch1 leaves the room
[03:37:41] <jimsch1> I want to know if 15 is what is causing my crash
[03:37:48] <Christian> i think so, yes
[03:38:08] <jimsch1> re-send, I know how to fix it I just want to know that is the test
[03:38:16] <Christian> i ran test 0 (unprotected GET /hello/0) before
[03:38:29] <Christian> sorry, that was /hello/0 again
[03:38:49] <Christian> that's /hello/1 and your'e probably in the debugger again
[03:42:18] <Christian> i'll be working on the seqno-0 issue in my code, so please start clients at my server for the next time. i can still start test 15 to your server at any time.
[03:45:34] <jimsch1> Ok - I just fixed my error which was crashing so you should be fine.
[03:46:12] <jimsch1> Do you have any special tests you want to see?  I don't know that I have all of the failure tests setup to automatically run
[03:46:25] <Christian> so test 15 passed too
[03:47:09] <Christian> if it's all the same to you i'd take some minutes to fix the seqno-0 issue and then ask you to run test 5 to my server again
[03:47:43] <jimsch1> I seem to have gotten a 5.00 rather than a 4.01 on test 15.
[03:48:44] <jimsch1> never mind - my error on 15
[03:48:46] <Christian> what did you send?
[03:48:49] <Christian> ok
[03:51:33] <Christian> got ya...
[03:51:43] <Christian> please run test 5 again
[03:52:32] <jimsch1> like that?
[03:52:44] <Christian> *grumbles* stupid paraentheses error... (x, y.lstrip(b'\0')) or b'\0' is subtly different from (x, y.lstrip(b'\0') or b'\0')
[03:52:47] <jimsch1> Did you test 14?  I don't think either of our implementations would ever mat chat
[03:53:09] <Christian> yes, did that pass on your side?
[03:53:27] <jimsch1> I got the resource back.  The test says it should be a failure.
[03:53:44] <Christian> i mean test 5
[03:54:33] <jimsch1> I got back a 1 and a zwei and a 2.05?
[03:54:53] <jimsch1> I seem to have gotten a 2.05 rather than a 2.04 status code
[03:55:09] <jimsch1> sorry - typed that backwards.
[03:55:20] <Christian> yes, that's good (the test suite is a bit impresices to how that counter should be represented -- you count time, i count german)
[03:55:31] <jimsch1> I got a payload of 0 bytes somwhere as well
[03:56:00] <Christian> ad test 14: yes, that's why i say i don't implement it. my implementation (or the part i'm using for the test suite, library could do something different) always allows encrypted access to the unprotected resources as well
[03:56:13] <jimsch1> as do I for 14
[03:57:07] <Christian> the test should retrun 2.05 Content, and i think i do
[03:57:29] <jimsch1> For 14 yes - for 5 no
[03:57:35] <francesca> yes test 14 is to run on a server that does not implement OSCORE
[03:58:28] <Christian> wait, now i'm confused: what are the issues with test 5, and where do you get 0-byte payload?
[03:59:47] <jimsch1> I seem to have gotten a third observe message
[04:00:08] <jimsch1> the token is the same
[04:01:11] <Christian> the way i'm counting is
Content: 1
Content: Zwei
Content: Drei
Content: und aus!
followed by a 5.00 error, payload "server is bored with client"
so the test has a defined end
[04:02:15] <jimsch1> I do not have Drei
[04:03:17] <Christian> mh, i didn't verify that, and indeed my client only gets the first two messages as well :-/
so while we do get an observation established, my server seems to break it prematurely
[04:05:30] <Christian> aaah, better now; there's a mismatch in which components expect which other to set the observe option in my code, so it always ended the observation at Zwei
[04:07:20] <Christian> server is ready for another run of test 5
[04:10:00] <Christian> i just got nonce reuse, did you trigger that deliberately?
[04:11:14] <jimsch1> No, I seem to be in a situation where I retransmitted some messages
[04:14:01] <jimsch1> Ok - My code has a "helpful" feature in it that occassionally causes problems.  If a specific amount of time passes on an observe without it getting a response then I resend the original request to try and renew the observe relationship.
[04:15:20] <Christian> hmmm ... that basically brings us to that open issue about observation renewal
[04:16:16] <jimsch1> Yes it does, esp since I am not sure where in the stack I am doing that "funny code" and if I have all of the contexts that I need for security.
[04:17:02] <Christian> well it kind of looks like it's doing the right thing:
[04:17:54] <Christian> it seems it executes variant 2 of, and retansmits the message as-is with its original sequence number
[04:18:12] <Christian> which is consistent with how the underlying observation mechanism works
[04:19:10] <jimsch1> I acutally do an Observer 0 followed by an observer 1 on the resource, but I don't re-use the token
[04:19:29] <Christian> oh *checks specs*
[04:19:47] <jimsch1> I take that back - the token on the last two messagse is the same, but different from the orignal request
[04:20:38] <Christian> so your client tries to renew the observation on a different token, and then cancels that renewed observation?
[04:21:22] <jimsch1> No - it cancels on a different token, and then renews on the same token as the cancel
[04:22:04] <Christian> that sounds wrong (speaking as someone who hasn't implemented all of this correctly himself)
[04:25:52] <jimsch1> I don't think you need to use the same token on the cancel as on the original request. I agree that it is odd to use the same token on the second renewal as the cancel but I don't see anything that would say it is wrong.
[04:26:59] <Christian> you need to use the same token on the cancel:
   In this case, a client MAY explicitly deregister by issuing a GET
   request that has the Token field set to the token of the observation
   to be cancelled and includes an Observe Option with the value set to
   1 (deregister).
[04:27:09] <jimsch1> My code is wrong -
[04:27:12] <Christian> otherwise, how would the server know which observation to cancel?
[04:27:26] <jimsch1> It cancels it based on the souce address and resource
[04:27:46] <jimsch1> What happens if two separate clients use the same token?
[04:27:54] <Christian> tokens are scoped to source addresses
[04:28:12] <Christian> (or to address pairs, actually)
[04:28:19] <jimsch1> But would a single client have two different observers on the same resource?
[04:29:00] <Christian> we do that in oscore (admittedly with different fetch payloads, but still)
[04:29:49] <Christian> there's nothing in observation that has special treatment for Uri-Path
[04:29:55] <jimsch1> I look at the final decrypted URL in that case.
[04:30:21] <Christian> it still needs to be a working observation for proxies that can't do that
[04:30:51] <jimsch1> Yea - which means it also needs to include that option as part of the URL when canceling.
[04:31:35] <jimsch1> It is a mess and I need to get my code fixed.
[04:32:06] <Christian> it just means that an observation always has two addresses and a token to which it is keyed; it's on the request-response and not the rest sublayer
[04:41:19] <jimsch1> Ok - my code is messier than I thought.  I am doing a cancel on the oringal token, a cancel on a new token and an observer on the new token.  I am reusing the same partial IV on the last two messages which is causing the replay attack.
[04:49:42] <Christian> i'd like to re-run test 13 with your server (i still had the wrong response code in there)
[04:50:44] <jimsch1> go ahead - I have not changed anything though
[04:52:20] <Christian> ah, hit tests are enabled on your server now :-)
[04:52:58] <jimsch1> It is a switch that I can control on startup
[04:54:42] <Christian> that means that test 13 (which previously failed) can now be a almost-pass (you're returning 4.00 where current spec says 5.03 with Max-Age 0, but that's under discussion on the issue tracker anyway)
[04:55:13] <jimsch1> I think that I have several issues on what error codes are being returned.  I will need to look at that more closely
[05:03:06] <jimsch1> Doi we have anything else we need to test today?
[05:03:46] <Christian> my inner-block tests are not fully ready yet, so i'd come back to them later if you're still around for the hackathon
[05:07:57] jimsch1 joins the room
[05:08:07] <jimsch1> I will be here the whole time.  until about 3 tomorrow, although I will go to sleep sometime tonight.
[05:08:36] <Christian> great :-)
[05:08:50] <Christian> i'll send francesca the recording of my client's interaction with your server
[05:08:54] <jimsch1> ack
[05:09:02] <francesca> thanks
[05:17:45] jimsch1 leaves the room
[06:44:13] <Christian> when properly fixing the observation issues, i think i found the source of the 2.04/2.05 confusion:
[06:44:50] <Christian> when a server decides to end an observation (because the resource becomes unobservable, or the response code becomes 4.04), it sens a final non-observe response
[06:45:48] <Christian> my implementation sends that as 2.04 Changed (which has the nice side effect in the implementation of cancelling the observation), so the outer codes and options are FETCH+Obs, Content+Obs, Content+Obs, Changed.
[06:47:20] <Christian> it is kind of covered by the text ("For Observe messages, the Outer Code [...] SHALL be set to [...] 2.05 (Content)", and it's not an observe message any more.
[06:48:43] <Christian> i expect that implementations will not try to enforce their ideas as to which code comes along -- do you think we'll need to clarify anything here?
[07:28:06] <francesca> actually I was looking at observe and opened an issue on the spec since I didn't find anything in the observe rfc about forbidding 2.04 with observe
[07:28:27] <francesca> so in that case we should have 2.04 outer code all the time
[07:28:55] <francesca> but yes there was still an issue on the observe implementation
[07:29:30] <jimsch1> I dont think that is correct.  The document says
[07:29:32] <jimsch1> A 2.xx notification MUST include an Observe Option with a sequence    number as specified in Section 4.4 <> below; a non-2.xx notification    MUST NOT include an Observe Option.
[07:29:58] <jimsch1> which to me says you cannot return the 2.04 w/o observe
[07:31:05] <Christian> I think this was more about whether we can have a single return code for both POST and FETCH, and I think we can, and it can even be either code (i'd go with the most generic Content)
[07:34:14] <jimsch1> I think you should be able to do.  I was objecting to the sequence of values you were returning.
[08:01:13] <Christian> jimsch1, have you changed anything on your side of inner-blockwise compared to the short test we did in Prague?
[08:02:13] <Christian> i'm just trying to get a good direction to continue hacking in, and it appears that i'll have a cleaner inner-blockwise if i do coap-over-tcp next and then oscore-inner-blockwise
[08:03:47] <Christian> but if you have something new you'd like to test now, i'll try to make the current version work for that (more just for testing, because the future of the implementation is in the refactoring that follows from coap-over-reliable-transports (like coap-over-tcp) that oscore actually is)
[08:10:11] <jimsch1> No I have made no changes to any of the block code.
[08:11:02] <Christian> ok, then i'll proceed on the tcp side, and come back to inner blockwise when it has magically started to work
[09:42:53] jimsch1 leaves the room
[11:40:31] francesca leaves the room: Connection failed: ping_timeout
[11:40:52] francesca joins the room
[11:42:38] francesca leaves the room
Powered by ejabberd - robust, scalable and extensible XMPP server Powered by Erlang Valid XHTML 1.0 Transitional Valid CSS!