Draft: draft-ietf-mls-protocol

Commentary: I think this is unnecessary and capricious . 
 Interim 2022 - 12 - 08 : Make ProtocolVersion and WireFormat two bytes Leave other enums as - is Define an IANA registry for WireFormat 
 Fixed by 
 Comment by Would it really do harm to turn this into two octets ? I do n't think message size is a real concern here . Same for ContentType and SenderType . Note : thank you for skipping 0 as a valid entry ! ! Implementers applaud you :) 
 Yep , we have tried to reserve 0 in all the enums , precisely because I was a grumpy implementor ! 
 On the one hand , yes , one octet is not that much more , and it saves worrying about space . On the other hand , in its long life , TLS has only exhausted 4 of its 65k versions , and its HandshakeType and ContentType enums are both still comfortable at 1 byte ( the analogous to the other ProposalType and ContentType here ) . Among the identifiers we have , we should be most worried about the intended extension points , namely ExtensionType and ProposalType . Both of those are already . There 's no mechanism for adding new values to ContentType and SenderType , so I would leave them at . ( Technically they could be updated by an extension -- but an extension could also make them 16 bits ! ) I can live with expanding ProtocolVersion , in case we decide to do some of the GREASE - like stuff that QUIC is doing . 
 I do n't have a strong opinion about this either , but if we make this 16 - bit wide , we should do the same for consistency for ContentType , SenderType & WireFormat ( the MLS extension document does introduce a new WireFormat for example ) . 
 Hi , I do n't think there is any expectation that we are going to exhaust the version space ( and we could do an extension later to fix that in the event we are wildly successful ) . As for the idea that implementations will be easier if things are aligned on 16 - bit or 32 - bit boundaries , that does n't help us because the Vector lengths are variable . I would leave this as is . 
 I can agree with the reasoning here 
 We talked about quite a number of different ways to do deletion in * ART groups . Give at least a high - level overview of the main ones , and mention their pros and cons . These include : just rebuild the tree  : simple , easy , no extra operations  : inefficient , puts the deleter in a trusted position in the group until every remaining member has updated update deletee 's key to blank  : fairly simple , no extra operations  : puts the deleter in a trusted position until the sibling or cousin of the deletee has updated send a delete secret over pairwise channels Pros : no trusted positions  : O(N ) , leaves a potentially - compromised leaf node in the tree send a delete secret by KEMing to everyone else Pros : no trusted positions , efficient  : leaves a potentially - compromised leaf node in the tree , multiple deletes interact in a complex way 
 I do n't quite follow the deletion algorithm that 's in there at the moment . Does it require double - join bookkeeping , If so I can add a note about that . 
 I 'm going to look at clarifying deletion in the doc ; but essentially we 're going for replace - then - blank in this initial draft . Keeping punctured trees is an option we should discuss once it 's out there . 
 I think the algorithm in is explicitly double - joined . When I get time , I 'll file another PR to move to the delete - without - double - join algorithm I posted to the list ( i.e. , puncture the tree ) . 
 Since we 're no longer using  , I think this issue is no longer relevant .
Paragraph (version B):
This registry lists identifiers for the types of messages that can be
sent in MLS.  The wire format field is two bytes wide, so the valid
wire format values are in the range 0x0000 to 0xffff.
Paragraph (version B):
Recommended: Whether support for this wire format is recommended
by the IETF MLS WG.  Valid values are "Y" and "N".  The
"Recommended" column is assigned a value of "N" unless explicitly
requested, and adding a value with a "Recommended" value of "Y"
requires Standards Action RFC8126.  IESG Approval is REQUIRED for
a Y->N transition.