Browse Source

is-140 changes, updated ascii art

master
Kelly Bristol 1 year ago
parent
commit
06326cbcab
5 changed files with 3828 additions and 133 deletions
  1. +129
    -121
      pep-keysync/draft-pep-keysync.mkd
  2. +3696
    -0
      pep-keysync/review/draft-pep-keysync-01-pre20200525-krb.txt
  3. +1
    -4
      shared/ascii-arts/sync/join-device-group.atxt
  4. +1
    -4
      shared/ascii-arts/sync/join-device-group_cancel.atxt
  5. +1
    -4
      shared/ascii-arts/sync/join-device-group_reject.atxt

+ 129
- 121
pep-keysync/draft-pep-keysync.mkd View File

@ -91,7 +91,7 @@ Modern users of messaging systems typically have multiple devices for
communicating, and attempting to use encryption on all of these devices
often leads to situations where messages cannot be decrypted on a given
device due to missing private key data. Current approaches to resolve
key synchronicity issues are cumbersome and potentially unsecure.
key synchronicity issues are cumbersome and potentially insecure.
The pEp KeySync protocol is designed to facilitate this personal key
synchronization in a user-friendly manner.
@ -113,7 +113,7 @@ receive encrypted communications from any of their devices.
For pEp implementations, pEp KeySync is a critical part of the broader
pEp Sync protocol, which is designed to be extensible to allow for the
synchronization of additional user data, such as configuration
settings and peer trust status information across a user's devices.
settings and peer trust status information across a single user's devices.
This document will provide a general description of pEp KeySync,
including idealized use cases, diagrams, and examples of messages that
@ -550,10 +550,6 @@ Device Group.
1. During initialization of pEp KeySync, the new device sends a Beacon
message.
Note: In the diagram, all messages marked "1. Beacon" are a single
message, but drawn separately in order to convey that the message
is sent to all devices in the Device Group.
2. Upon receipt of a Beacon message from a device not part of a
Device Group, all Grouped Devices send a NegotiationRequestGrouped
message.
@ -566,7 +562,7 @@ Device Group.
Note 1: Only the first NegotiationRequestGrouped message is
processed. In this example message 2(w) (from "winner") is
processed, while message 2(l) (from "looser") will be ignored. The
processed, while message 2(l) (from "loser") will be ignored. The
result will be the same, no matter which NegotiationRequestGrouped
message is processed.
@ -577,12 +573,12 @@ Device Group.
4. The new device displays the Trustwords to the user.
5. Up on receipt of the NegotiationOpen message, the "winner" device
sends a GroupHandshake message to the "looser" device(s), to
sends a GroupHandshake message to the "loser" device(s), to
indicate that a new device wants to join the Device Group.
6. All Grouped Devices display the Trustwords to the user: the
"winner" device as a result of receiving the NegotiationOpen
message, the "looser" device(s) as result receiving GroupHandshake
message, the "loser" device(s) as result receiving GroupHandshake
message.
Note: Messages 6(w) and 6(l) are instances of the same action on
@ -629,7 +625,7 @@ Device Group.
along with its own original local key pairs (private and public
keys) to be synchronized.
Note: In the diagram, all messages marked "13. GroupKeysAndClsoe
Note: In the diagram, all messages marked "13. GroupKeysAndClose
(key data)" are a single message, but drawn separately in order to
convey that the message is sent to all devices in the Device
Group.
@ -678,13 +674,11 @@ R7. The user compares the Trustwords displayed on both devices. If
{::include ../shared/fence-line.mkd}
R8. Upon receipt of the 'Reject' event, the 'Active Device' sends
a CommitReject message to the new device and the 'Passive
Device(s)'
a CommitReject message to both the new device which attempted to
join, and the 'Passive Device(s)' in the Device Group.
Note: In the diagram, all messages marked "R8. CommitReject" are
a single message, but drawn separately in order to convey that
the message is sent to all devices participating in the
handshake.
Note: In the diagram, "R8. CommitReject" represents the message
that is sent to all devices participating in the handshake.
{::include ../shared/fence-line.mkd}
@ -726,9 +720,8 @@ C7. The user decides to discontinue the process and chooses the
C8. Upon receipt of the 'Reject' event, the 'Active Device' sends a
Rollback message to the new device and the 'Passive Device(s)'
Note: In the diagram, all messages marked "C8. Rollback" are a
single message, but drawn separately in order to convey that the
message is sent to all devices participating in the handshake.
Note: In the diagram, all messages marked "C8. Rollback" represents
the message that is sent to all devices participating in the handshake.
{::include ../shared/fence-line.mkd}
@ -785,7 +778,7 @@ A Sender Group Key is a Sender's signing key, which is used to update
the Device Group information. If it is reset, the Device Group breaks.
-->
<!--
<!--
The following figures are simplified excerpts of the implemented pEp
KeySync Finite-State Machine (FSM).
@ -986,7 +979,7 @@ On receipt of the 'Offerer' device's NegotiationOpen message, the
In this state, other events may also be processed, but these events do
not result in a transition to another state.
<!--
<!--
TODO Some actions (e.g. storeNegotiation) are not described above.
Also some parts should be described in more detail.
-->
@ -1011,8 +1004,9 @@ choose from the following options:
If the user selects one of the above options on the 'Requester'
device, the 'Requester' FSM sends a response to the 'Offerer' device.
When this response is received, the 'Offerer' FSM performs a
sameNegotiation conditional check to verify the session
integrity. If this conditional returns 'true', the FSM proceeds as
sameNegotiation conditional check on the current negotiation session to
verify that the current session has not been disrupted or compromised.
If this conditional returns 'true', the FSM proceeds as
follows, depending on the message received:
* CommitAcceptRequester: The 'Requester' FSM transitions to state
@ -1046,9 +1040,10 @@ choose from the following options:
If the user selects the 'Cancel' or the 'Reject' options on the
'Offerer' device, the 'Offerer' FSM sends a response to the
'Requester' device. When this response is received, the 'Requester'
FSM performs a sameNegotiation conditional check to verify the session
integrity. If this conditional returns 'true', the FSM proceeds as
follows, depending on the message received:
FSM performs a sameNegotiation conditional check on the current
negotiation session to verify that the current session has not been
disrupted or compromised. If this conditional returns 'true',
the FSM proceeds as follows, depending on the message received:
* CommitReject: pEp KeySync is disabled, and the FSM transitions to
state End.
@ -1064,8 +1059,9 @@ HandshakingOfferer state.
In this state the FSM awaits and processes the response from a
'Requester' device in state HandshakingRequester. When this response
is received, the 'Offerer' FSM performs a sameNegotiation conditional
check to verify the session integrity. If this conditional returns
'true', the FSM proceeds as follows, depending on the message
check on the current negotiation session to verify that the current
session has not been disrupted or compromised. If this conditional
returns 'true', the FSM proceeds as follows, depending on the message
received:
* CommitAcceptRequester: A CommitAcceptOfferer message is sent to the
@ -1087,9 +1083,10 @@ HandshakingRequester state.
In this state the FSM awaits and processes the response from an
'Offerer' device in state HandshakingOfferer or
HandshakingPhase2Offerer. When this response is received, the
'Requester' FSM performs a sameNegotiation conditional check to verify
the session integrity. If this conditional returns 'true', the FSM
proceeds as follows, depending on the message received:
'Requester' FSM performs a sameNegotiation conditional check on the
current negotiation session to verify that the current session has not
been disrupted or compromised. If this conditional returns 'true',
the FSM proceeds as follows, depending on the message received:
* CommitAcceptOfferer: The FSM prepares the Own Keys on the
'Requester' device for synchronization. The FSM then issues an
@ -1130,18 +1127,19 @@ HandshakingPhase1Offerer or HandshakingPhase2Offerer state.
On initialization, the FSM prepares the Own Keys on the 'Offerer'
device for synchronization and makes a backup of these Own Keys. Then
it wait for the OwnKeysRequester message from the 'Requester', which
it waits for the OwnKeysRequester message from the 'Requester', which
contains the Own Keys and the information about all Own Identities of
the 'Requester'.
When this message is received, the 'Offerer' FSM performs a
sameNegotiation conditional check to verify the session integrity. If
this conditional returns 'true', the FSM saves the 'Requester' keys
sameNegotiation conditional check on the current negotiation session to
verify that the current session has not been disrupted or compromised.
If this conditional returns 'true', the FSM saves the 'Requester' keys
combined with the 'Offerer' keys in a shared GroupKeys array
(saveGroupKeys) and the 'Requester' device keys are marked as default
for those respective identities (receivedKeysAreDefaultKeys). Then,
the FSM prepares the Own Keys on the 'Offerer' device for
synchronization. Because the Keys are already set to the ones of the
synchronization. Because the Keys are already set to those of the
'Requester' device, it is taking its former Own Keys and Own
Identities from the backup (cf. above). The Offerer sends the
OwnKeysOfferer message (with Key material of its Own Keys and Own
@ -1172,8 +1170,9 @@ from an 'Offerer' device in state HandshakingPhase1Offerer or
HandshakingPhase2Offerer.
When this message is received, the 'Requester' FSM performs a
sameNegotiation conditional check to verify the session integrity. If
this conditional returns 'true', the FSM saves
sameNegotiation conditional check on the current negotiation session to
verify that the current session has not been disrupted or compromised.
If this conditional returns 'true', the FSM saves
the 'Offerer' keys in a shared GroupKeys array (saveGroupKeys), and
prepares the device's Own Keys for synchronization. The 'Requester'
device keys are marked as default for those respective identities
@ -1186,7 +1185,7 @@ Rollback message is issued to the 'Offerer' device, and the FSM
transitions to state Sole.
Note: In case the 'Offerer' device has already transitioned to Grouped
state, this Rollback message will not processed by the 'Offerer'
state, this Rollback message will not be processed by the 'Offerer'
device.
In case a (delayed) Rollback message is received (which normally
@ -1227,7 +1226,7 @@ not result in a transition to another state.
This state can only be entered by a device in the Sole state that is
attempting to join an existing Device Group.
On initialization, it drives user interface options, including the
On initialization, this state drives user interface options, including the
Trustwords dialog for joining a Device Group. The user on the new
device is prompted to compare Trustwords and choose from the following
options:
@ -1243,11 +1242,12 @@ options:
* Cancel: A Rollback message is sent to the existing Device Group, and
the FSM transitions to state Sole.
If the user selects one of the above options on a device that it part
If the user selects one of the above options on a device that is part
of the existing Device Group, its FSM sends a response to the new
device. When this response is received, the FSM of the new device
performs a sameNegotiation conditional check to verify the session
integrity. If this conditional returns 'true', the FSM proceeds as
performs a sameNegotiation conditional check on the current negotiation
session to verify that the current session has not been disrupted or
compromised. If this conditional returns 'true', the FSM proceeds as
follows, depending on the message received:
* CommitAcceptForGroup: The FSM of the new device transitions to state
@ -1262,14 +1262,15 @@ follows, depending on the message received:
#### HandshakingToJoinPhase1
This state is entered by a new device only, i.e. a device that is not
yet part of a Device Group.
yet part of a Device Group.
In this state the FSM awaits and processes the response from a device
that it part of the existing Device Group. When this response is
that is part of the existing Device Group. When this response is
received, the FSM of the new device performs a sameNegotiation
conditional check to verify the session integrity. If this conditional
returns 'true', the FSM proceeds as follows, depending on the message
received:
conditional check on the current negotiation session to verify that
the current session has not been disrupted or compromised. If this
conditional returns 'true', the FSM proceeds as follows, depending on
the message received:
* CommitAcceptForGroup: A CommitAccept message is sent to the existing
Device Group, and the The FSM transitions to state JoiningGroup.
@ -1310,17 +1311,18 @@ This state is entered by a new device only, i.e. a device that is not
yet part of a Device Group.
On initialization, the FSM prepares the Own Keys on the new device for
synchronization and makes a backup of these Own Keys. Then it wait for
synchronization and makes a backup of these Own Keys. Then it waits for
the OwnKeysForNewMember message from the exiting Device Group, which
contains the Own Keys and the information about all Own Identities of
the existing Device Group.
When this message is received, the FSM of the new device performs a
sameNegotiationAndPartner conditional check to verify the session
integrity. If this conditional returns 'true', the FSM saves the
'Requester' keys combined with the keys of the existing group in a
shared GroupKeys array (saveGroupKeys) and the Device Group's keys are
marked as default for those respective identities
sameNegotiationAndPartner conditional check on the current negotiation
session to verify that both the current session and negotiation partner
have not been disrupted or compromised. If this conditional returns
'true', the FSM saves the 'Requester' keys combined with the keys of
the existing group in a shared GroupKeys array (saveGroupKeys) and the
Device Group's keys are marked as default for those respective identities
(receivedKeysAreDefaultKeys). Then, the FSM prepares the Own Keys on
the new device for synchronization. Because the Keys are already set
to the ones of the existing Device Group, it is taking its former Own
@ -1336,7 +1338,7 @@ transitions to state Grouped.
This state is entered by Grouped Devices only, i.e., devices that are
part of a Device Group.
On initialization, it drives user interface options, including the
On initialization, this state drives user interface options, including the
Trustwords dialog. The user is prompted to compare Trustwords, and
choose from the following options on any device belonging to the
existing Device Group:
@ -1353,8 +1355,9 @@ existing Device Group:
If the user selects the 'Cancel' or the 'Reject' options on the new
device, the new device's FSM sends a response to the existing Device
Group. When this response is received, the grouped devices FSM
performs a sameNegotiation conditional check to verify the session
integrity. If this conditional returns 'true', the FSM proceeds as
performs a sameNegotiation conditional check on the current negotiation
session to verify that the current session has not been disrupted or
compromised. If this conditional returns 'true', the FSM proceeds as
follows, depending on the message received:
* CommitReject: The FSM transitions to state Grouped.
@ -1377,7 +1380,7 @@ here.
#### HandshakingGroupedPhase1
This state is entered by Grouped Devices only, i.e., devices that are
already part of a Device Group.
already part of a Device Group.
On initialization a message GroupTrustThisKey is sent to the other
members of the Device Group and a message CommitAcceptForGroup is sent
@ -1386,8 +1389,9 @@ to the new device.
In this state the FSM awaits and processes the response from an new
device in state HandshakingToJoin or HandshakingToJoinPhase2. When
this response is received, the grouped device's FSM performs a
sameNegotiation conditional check to verify the session integrity. If
this conditional returns 'true', the FSM proceeds as follows,
sameNegotiation conditional check on the current negotiation session to
verify that the current session has not been disrupted or compromised.
If this conditional returns 'true', the FSM proceeds as follows,
depending on the message received:
* CommitAccept: The FSM prepares the Own Keys on the grouped device
@ -1405,7 +1409,7 @@ depending on the message received:
* Rollback: The 'Offerer' public key is mistrusted, and the FSM
transitions to state Grouped.
In case a GroupKeysAndClose message arrives from another group
member, the FSM transitions to state Grouped.
@ -1416,7 +1420,7 @@ result in a transition to another state.
#### GroupKeyResetElection
This state is entered by Grouped Devices only, i.e., devices that are
already part of a Device Group.
already part of a Device Group.
It is used to reset keys that have become invalid.
@ -1476,66 +1480,73 @@ form a new Device Group.
#### sameChallenge
The 'sameChallenge' conditional evaluates true if the Challenge of the
incoming Sync Message is identical to the Challenge of the Device. In
this case this was a Sync Message sent by the Device itself.
incoming Sync Message is identical to the Challenge of the Device, i.e.,
this is a Sync Message sent by the originating Device itself.
#### sameNegotiation
Similar as with 'sameChallenge', the 'sameNegotiation' conditional
evaluates true if the Negotiation of the incoming Sync Message is
identical to the Negotiation the Device is in. In this case the
incoming Sync Message is part of the same Negotiation.
The 'sameNegotiation' conditional is dependent upon the 'storeNegotiation'
function, which stores the active negotiation session while the KeySync
process is performed. This conditional evaluates true if the
'storeNegotiation' value of the incoming Sync Message is identical to
that of the 'storeNegotiation' value that the Device is in.
This serves as a session fidelity check. If this boolean evaluates
'true', it confirms that the pEp KeySync session in progress is the
same throughout.
#### sameNegotiationAndPartner
The 'sameNegotiationAndPartner' conditional evaluates true if the
Negotiation of the incoming Sync Message is identical to the
Negotiation the Device is in and the partner did not change. In this
case the incoming Sync Message is part of the same Negotiation coming
from the expected Device.
Similar to the 'sameNegotiation' conditional, the 'sameNegotiationAndPartner'
conditional is dependent upon the 'storeNegotiation' function, which
stores the active negotiation session while the KeySync
process is performed. The 'sameNegotiation' conditional evaluates true
if both 'storeNegotiation' value of the incoming Sync Message is identical
to that of the 'storeNegotiation' value that the Device is in, AND the
negotiation partner did not change.
This serves as a session fidelity check. If this boolean evaluates
'true', it confirms that the pEp KeySync session in progress is the
same throughout, and that the negotiation partner has not changed.
This conditional also serves as a session fidelity check. If this
boolean evaluates 'true', it confirms that the pEp KeySync session in
progress is the same throughout, and that the negotiation partner has
not changed.
#### sameResponse
The 'sameResponse' conditional evaluates true if the Response of the
incoming Sync Message is identical to the Response of the Device. In
this case the Response was correctly echoed.
this case the Response is correctly echoed.
#### weAreOfferer
The 'weAreOfferer' conditional evaluates true if the Challenge of the
incoming Sync Message is greater than the Challenge of the
Device. Otherwise we’re Requester.
Device. Otherwise we’re the Requester.
### Actions
Actions are unconditionally executing the code of their
implementation. All Actions may fail. In this case they’re bringing
the State Machine into an error state, and the State Machine will be
initialized.
Actions are unconditionally executed. Any or all Actions may fail.
In the event of failure, actions bring the State Machine into an error
state, and the State Machine will be reinitialized.
#### backupOwnKeys
The 'backupOwnKeys' action is to make a backup of all Own
Keys. This is useful, if we need the original state later after
changes may have been made to Own Keys.
Keys, and allows for restoration of the Own Keys.
#### disable
The 'disable' action is to disable KeySync and shut down the State
Machine on that device. It may be called in an number of scenarios. For
example, a user has rejected a pEp Handshake on either device involved
in a pEp Handshake. At this time, in all cases, invoking the 'disable'
function results in the FSM transitioning to state End, which disables
the KeySync feature. pEp KeySync can be manually re-enabled in the pEp
settings on an affected device.
The 'disable' action does as it implies. This action shuts down the
State Machine and disables KeySync functionality on the impacted device.
It is most commonly called in 'Cancel' or 'Reject' scenarios. For
example, if a user rejects a pEp Handshake on a device involved
in a pEp Handshake, the 'disable' action is called. Invoking the 'disable'
function results in the State Machine transitioning to state End,
which automatically disables the KeySync feature. pEp KeySync can be
manually re-enabled in the pEp settings on the disabled device.
<!-- No longer in code?
@ -1848,21 +1859,18 @@ additional information on why and when these changes are triggered.
### Events
While being in a State Events may occur and the corresponding Event
Handler will be executed. Please refer to the desired State
({{finite-state-machine-code}}) for additional information on the
While in a State, Events receive incoming messages and prompt the
execution of any event handlers (conditions, actions, messages, or
transitions) contained within. Please refer to the desired State
({{finite-state-machine-code}}) for additional information on specific
event handlers.
In the following the variants of Events that may occur are described.
#### Init Event
When the State Machine transitions to a State the Init event is
occurring to this State. If an Init Event Handler is present for this
State this Event Handler is called. The Event Handler may contain
Conditions, Actions, sending of Messages and Transitions. All States
can have a handler for an Init event, including the InitState.
When the FSM transitions to a new state for the first time, the Init
event (if present) is called. Init events typically drive UI actions
and event handlers associated with core functionality of the protocol.
Example of an Init Event Handler:
@ -1881,7 +1889,7 @@ Example of an Init Event Handler:
#### Message Event
If a Sync Message (cf. {{messages}}) arrives through the Network then
the Event with the name of the Message is occurring.
the Event with the name of the Message occurs.
Example of an Message Event Handler:
@ -1904,13 +1912,13 @@ Beacon Message arrives:
#### Signaled Events
Events, which don’t share their name with a Message, are being
Events, which don’t share their name with a Message, are
signaled from engine code.
Example of an Signaled Event Handler:
The KeyGen Event has no corresponding Message. Therefore, it is not
occurring when a Sync Message arrives but when it is signaled from
The KeyGen Event has no corresponding Message. Therefore, it does not
occur when a Sync Message arrives, but rather when it is signaled from
code:
{::include ../shared/fence-line.mkd}
@ -1952,10 +1960,10 @@ The wire format of Sync Messages is defined in ASN.1
(cf. {{asn-type-definitions-code}}), using PER.
Sync Messages are transported as Attachments to pEp Messages. Hence
they’re transported by the same Transports, which are transporting pEp
they’re carried by the same Transports, which transmit pEp
Messages. Some Sync Messages must be sent in copy on all
Transports. Others are transported on the Active Transport only. The
Active Transport is the Transport, on which the last Sync Message was
Active Transport is the transport on which the last Sync Message was
received.
@ -1994,7 +2002,7 @@ Contexts are:
A Sync Message can have a Rate Limit ratelimit=\<numeric\>. That means
it is only possible to send out one message each \<numeric\> seconds. A
Rate Limit of 0 means no Rate Limit checking.
Rate Limit of 0 means no Rate Limit checking.
Example:
@ -2016,7 +2024,7 @@ automatically calculated fields, defined with the auto keyword, and
fields, which are copied in and out from the I/O buffer, marked with
the fields keyword.
The wire format of the fields is depending on their type.
The wire format of the fields is depending on their type.
The types are defined in {{asn-type-definitions-code}}. Additionally,
the two basic types bool (ASN.1: BOOLEAN) and int (ASN.1: INTEGER) are
@ -2044,15 +2052,15 @@ Example for a field coming from I/O buffer
#### I/O Buffer
There is an I/O Buffer for all Fields, which are occurring in
There is an I/O Buffer for all Fields which occur in
Messages. All Messages share this I/O buffer. Fields with the same
name share one space in the I/O Buffer. Hence, the I/O Buffer is built
as superset of all Fields’ buffers. Sending
as superset of all Fields’ buffers.
#### Sending
Sending is being done by:
Sending is performed as follows:
1. Calculating all auto Fields and copying the result into the I/O
Buffer
@ -2096,7 +2104,7 @@ For more information on the messages used in the KeySync Protocol, see
### List of Messages Used in Finite-State Machine
-->
-->
<!--
#### Version
@ -2528,7 +2536,7 @@ protocol Sync 1 {
go Sole;
}
}
on CommitReject {
if sameNegotiation {
do untrustThisKey;
@ -2552,7 +2560,7 @@ protocol Sync 1 {
go Sole;
}
}
on CommitReject {
if sameNegotiation {
do untrustThisKey;
@ -2826,7 +2834,7 @@ protocol Sync 1 {
state HandshakingGrouped {
on Init
do showGroupedHandshake;
// Cancel is Rollback
on Cancel {
send Rollback;
@ -2923,7 +2931,7 @@ protocol Sync 1 {
// beacons are always broadcasted
message Beacon 2, type=broadcast, ratelimit=10,
message Beacon 2, type=broadcast, ratelimit=10,
security=unencrypted {
field TID challenge;
auto Version version;
@ -2975,12 +2983,12 @@ security=unencrypted {
}
// trust in future
message GroupKeysForNewMember 12,
message GroupKeysForNewMember 12,
security=attach_own_keys_for_new_member {
field IdentityList ownIdentities;
}
message GroupKeysAndClose 13,
message GroupKeysAndClose 13,
security=attach_own_keys_for_group {
field IdentityList ownIdentities;
}
@ -3045,8 +3053,8 @@ in pEp KeySync FSM.
-- Written by Volker Birk
PEP
{ iso(1) org(3) dod(6) internet(1) private(4) enterprise(1)
pEp
{ iso(1) org(3) dod(6) internet(1) private(4) enterprise(1)
pEp(47878) basic(0) }
DEFINITIONS AUTOMATIC TAGS EXTENSIBILITY IMPLIED ::=
@ -3145,7 +3153,7 @@ LocalWords: Boppart boolean showFormingGroup broadcasted keysync
LocalWords: unclarity GroupKey Volker repos APIs devs unsecure
LocalWords: cryptographic KeySync's KeyReset Requester's
LocalWords: Programme SynchronizeGroupKeys Groups's untrusted
LocalWords: NegotiationRequestGrouped
LocalWords: NegotiationRequestGrouped
LocalWords: OwnKeysForNewMember GroupKeysAndClose
LocalWords: SendGroupKeysForNewMember showDeviceAccepted
LocalWords: GroupKeyResetElection


+ 3696
- 0
pep-keysync/review/draft-pep-keysync-01-pre20200525-krb.txt
File diff suppressed because it is too large
View File


+ 1
- 4
shared/ascii-arts/sync/join-device-group.atxt View File

@ -7,10 +7,7 @@
| | | |
| | | |
| 1. Beacon | |
|--------------------------------->| |
| | | |
| | 1. Beacon | |
|----------------------------------------------------->|
|--------------------------------->|------------------>|
| | | |
| 2(w). NegotiationRequestGrouped | |
|<---------------------------------| |


+ 1
- 4
shared/ascii-arts/sync/join-device-group_cancel.atxt View File

@ -23,10 +23,7 @@
| | - - - - - - - ->| |
| | | |
| C8. Rollback | |
|<---------------------------------| |
| | | |
| | | C8. Rollback |
| | |------------------>|
|<---------------------------------|------------------>|
| | | |
,----------!. | | |
|New device|_\ | | |


+ 1
- 4
shared/ascii-arts/sync/join-device-group_reject.atxt View File

@ -23,10 +23,7 @@
| | - - - - - - - ->| |
| | | |
| R8. CommitReject | |
|<---------------------------------| |
| | | |
| | | R8. CommitReject |
| | |------------------>|
|<---------------------------------|------------------>|
| | | |
,----------!. | | |
|New device|_\ | | |


Loading…
Cancel
Save