Draft: draft-ietf-mls-protocol

Commentary: Also copies the " Recommended " field by reference , instead of reciting it in each registry . Note that this has a conflict with that will not catch -- " MLSContentTBS " will have to be changed to whatever new name is agreed in that PR . 
 The of absolutely needs to be unique for every signature happening in the protocol , for security and avoid signature ambiguity . That includes signatures happening in extensions . Should this be referenced in a IANA considerations to ensure there is no conflict in the future ? Or at least say something about this somewhere ? We have to think how to design things well here to be future - proof : the structure must be used for every signature done with the leaf signature keys , which includes what might happen in extensions but also in future versions of MLS . If future versions of MLS could avoid doing , that would be great ! 
 This seems to come down to whether we expect the signature keys used for MLS authentication to be used outside of MLS ( otherwise there 's no risk of confusion ) and if so , whether this spec has any influence on that usage . If you 're using your MLS key to sign Bitcoin transactions , we ca n't do much to help that . Note that there is not an issue for future version of MLS here . The label is constructed as , so a future version could just increment the part of that . Given all that , I might prefer a recommendation that signature keys not be reused across contexts , rather than trying to accommodate reuse . If we do something here , we should do something analogous to the registry , which are similarly intended for domain separation between different use cases . We should probably consider making an exporter label registry anyway . 
 I agree , we should n't do anything about someone using the MLS signature key in another protocol . About future MLS versions : I agree , but note that there is a length tag before that . It means that we impose to all signature of future MLS versions to start with ( including the quic integer ) Is it something acceptable or not , I do n't now . I just think we should have in mind that the decisions we make now on will have an impact on the design of future MLS versions . About extensions : in the extensions document , there is a signature computed with If two extensions were to use the same label then this could lead to security problems , this is why I think the labels should be in some registry to ensure they are all unique . One other thing we could do is to separate all extensions signatures from the core MLS signatures , for exemple using the label " MLS 1.0 extension [ label from extension ] " ? Like that a bogus extension ca n't introduce a security flaw in core MLS that way ?
Paragraph (version A):
Here, the functions "Signature.Sign" and "Signature.Verify" are
defined by the signature algorithm.
Paragraph (version B):
Here, the functions "Signature.Sign" and "Signature.Verify" are
defined by the signature algorithm.  If MLS extensions require
signatures by group members, they should re-use the SignWithLabel
construction, using a distinct label.  To avoid collisions in these
labels, an IANA registry is defined in mls-signature-labels.
Paragraph (version A):
Applications SHOULD provide a unique label to "MLS-Exporter" that
identifies the secret's intended purpose.  This is to help prevent
the same secret from being generated and used in two different
places.
Paragraph (version B):
Applications SHOULD provide a unique label to "MLS-Exporter" that
identifies the secret's intended purpose.  This is to help prevent
the same secret from being generated and used in two different
places.  To help avoid the same label being used in different
applications, an IANA registry for these labels has been defined in
mls-exporter-labels.
Paragraph (version A):
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.
Paragraph (version A):
Recommended: Whether support for this credential 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.
Paragraph (version B):
The "SignWithLabel" function defined in ciphersuites avoids the risk
of confusion between signatures in different contexts.  Each context
is assigned a distinct label that is incorporated into the signature.
This registry records the labels defined in this document, and allows
additional labels to be registered in case extensions add other types
of signature using the same signature keys used elsewhere in MLS.
Paragraph (version B):
The exporter function defined in exporters allows applications to
derive key material from the MLS key schedule.  Like the TLS exporter
RFC8446, the MLS exporter uses a label to distinguish between
different applications' use of the exporter.  This registry allows
applications to register their usage to avoid collisions.
Paragraph (version B):
The registry has no initial contents, since it is intended to be used
by applications, not the core protocol.  The table below is intended
only to show the column layout of the registry.