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

[Zaheduzzaman Sarker <[e-mail]>]

Thanks Sean, I have cleared by discuss.

//Zahed

On Wed, Mar 6, 2024 at 5:46 PM Sean Turner <[e-mail]> wrote:

> 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.
> > >
> > >
> > >
> >
>
>