Re: [MLS] Zaheduzzaman Sarker's Discuss on draft-ietf-mls-architecture-10: (with DISCUSS and COMMENT)

[Sean Turner <[e-mail]>]

Zahed,

I believe there were two discuss points:

# Why no explicit recommendation of using secure transport for MLS

We ended up with a reworded s8.1 (was s7.1) that includes the following recommendation:

      *RECOMMENDATION:* Use transports that provide reliability and
      metadata confidentiality whenever possible, e.g., by transmitting
      MLS messages over a protocol such as TLS [RFC8446] or QUIC
      [RFC9000].

I think the “discussion”, I’d call it acknowledgement that it’s a good idea, can be found here:
https://github.com/mlswg/mls-architecture/pull/183

I would be remiss though in not pointing out this bit from the Security and Privacy Considerations:

   While MLS should be run over a secure transport such as QUIC
   [RFC9000] or TLS [RFC8446], the security guarantees of MLS do not
   depend on the transport.

# Support Roman’s recommandation wrt s7.4.3.2/7.1.2. countering (now s8.4.3.2/8.1.2)

Roman has cleared this, but the two in conflict were:

OLD:

(a) Section 7.4.3.2

     *RECOMMENDATION:* Always use encrypted group operation messages to
     limit privacy risks.

(b) Section 7.1.2.
     *RECOMMENDATION:* Never use the unencrypted mode for group
     operations without using a secure channel for the transport layer.

NEW:

(a) Section 8.3.1.2.
      *RECOMMENDATION:* Use encrypted group operation messages to limit
      privacy risks whenever possible.

(b) Section 8.1.2.
      *RECOMMENDATION:* Never use the unencrypted mode for group
      operations without using a secure channel for the transport layer.



For your comment regarding FEC (s7.1.4 is now s8.1.4), there was this “discussion":
https://github.com/mlswg/mls-architecture/issues/184

spt

> On Mar 5, 2024, at 16:29, Zaheduzzaman Sarker <[e-mail]> wrote:
> 
> Hi Sean,
> 
> Thanks for the ping. As I didn't receive any reply to my comments or discuss, I was not aware of the plans and resolutions. I will have a look, however, if you can point me on how my discussion point is addressed it will help me to do a fast response.
> 
> //Zahed
> 
> On Tue, Mar 5, 2024 at 8:42 PM Sean Turner <[e-mail]> wrote:
> Zahed,
> 
> Hi! A new version has dropped (actually I think two since your ballot position was entered) and I was hoping you could take a quick peek to see if this version addresses you discuss points; one at least is addressed as Roman has withdrawn his DISCUSS.
> 
> Cheers,
> spt
> 
> > On Feb 1, 2023, at 11:15, Zaheduzzaman Sarker via Datatracker <[e-mail]> wrote:
> > 
> > Zaheduzzaman Sarker has entered the following ballot position for
> > draft-ietf-mls-architecture-10: Discuss
> > 
> > When responding, please keep the subject line intact and reply to all
> > email addresses included in the To and CC lines. (Feel free to cut this
> > introductory paragraph, however.)
> > 
> > 
> > Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
> > for more information about how to handle DISCUSS and COMMENT positions.
> > 
> > 
> > The document, along with other ballot positions, can be found here:
> > https://datatracker.ietf.org/doc/draft-ietf-mls-architecture/
> > 
> > 
> > 
> > ----------------------------------------------------------------------
> > DISCUSS:
> > ----------------------------------------------------------------------
> > 
> > Thanks for working on this specification.
> > 
> > After reading section 7, I would like to discuss why there is no explicit
> > recommendation of using secure transport for MLS. This section and subsections
> > point out various strong opinions to use secure transport. I there is any
> > particular reason to support secure transport protocol then it should be
> > mentioned. I kind of feel that the work "transport" here does not really only
> > refer to Layer 4 transport protocols, needs some clarification.
> > 
> > I also support Roman's discuss that the recommendation on section 7.4.3.2 and
> > section 7.1.2 are countering each other.
> > 
> > 
> > ----------------------------------------------------------------------
> > COMMENT:
> > ----------------------------------------------------------------------
> > 
> > - It took time for me to understand that the recommendation in section 7.1.4
> > refers to different set of transport protocols than those examples mentioned in
> > beginning of section 7.1 :-), yes, I did not took the "unidirectional" word
> > seriously. However, I think some clarification and/or reference to some FEC
> > scheme for unidirectional transport here would be good.
> > 
> > 
> > 
>