rebased.
` The first sentence seems to say ‘you can do whatever you want’, but the second seems to say “you should sign the messages” This doesn’t seem to be about integrity; it says Evidence must be confidential. Is that actually a requirement?
I don't see where it says RATS messages have to be confidential. 'end-to-end' means between RATS roles. Which can be achieved at different nesting levels; where nesting is interpreted to mean nesting in the message (data) layers. Summary - I don't see a problem with the proposed text.
I am inclined to agree with Ned here, but we could change the first line, while we're at it. The reuse of the word "protected" used in the 1st sentence in the 2nd sentence now might make it more clear that this message protection can happen on many layers.
Ok but this PR merges into the branch instead of master. Recommend rebasing on master so that order of merge doesn't matter.


** Section 12.1.2.1. Would it be more precise to say: OLD The degree of protection afforded to this key material can vary by device, based upon considerations as to a cost/benefit evaluation of the intended function of the device. NEW The degree of protection afforded to this key material can vary by the intended function of the device and the specific practices of the device manufacturer or integrator.


Throughout the document the term "trust anchor" is meant in the to be a public key and associated (meta)data. This definition does not cover attestation schemes based on symmetric crypto, e.g., , and Arm PSA, and should be extended to also cover such cases.
Was there specific text that you believe needs to be changed?
yes, we identified at least two places: §7.1 and §12.4.
Reads great to me. Any other opinions?


Add in text from Birkholz draft, with some wordsmithing and grammatical fixes from Dave Thaler


Here's a first attempt to combine terminology sections, and trust model. Includes new terms Endorser and Appraisal Policy per recent discussion. Signed-off-by: Dave Thaler
Done
Done. (But if you have feedback on a sentence like this in the future, please attach the comment directly to the code line under the "Files changed" tab, to make it easy to find which phrase you're referring to.)
Done
Updated. How about now?
I would like to discuss the possibility of combining the terms "Endorsement" and "Attestation Result". Just like we have an Appraisal Policy for a verifier and an Appraisal Policy for a relying party, some might view an Attestation Result as an Endorsement for use by the relying party. I'm ok either way, but wanted to discuss this in our next call to see if others think it would help or confuse things.
I still believe my original definition of Attestation is good, I haven't seen any comments here about what the problem was. For comparison, URL says it's "The process of validating the integrity of a computing device such as a server needed for trusted computing.". I'm also ok with that definition.
I’m OK with that wording for introducing the concept. It may break down if the terminology for ‘device’ and ‘trusted computing’ become overly specified / specific.
The word 'health' is generally being used where other words such as 'trustworthiness', or 'state' could be used. I'm concerned that 'health' might not easily be synonymous with 'trust'. It also seems to bias the architecture toward NEA (RFC5209) which IMO does not define attestation.


possible text closing .
The architecture draft should say that known-good reference values can be either a part of an endorsement or part of an appraisal policy or both.
I would only want to mention "known-good reference values" at all if it comes with an explanation of why they're not sufficient in the real world. Not sure whether we want the arch doc to go there. We can discuss in a meeting.
I wouldn't say they are never sufficient. I would say KGVs serve a specific purpose. And this purpose is documenting the successful loading of well-known software on well-known Attester equipment, where the Attester equipment supports the signing of extended/hashed measurements. Adding Guy/Ned as they probably have better words for this based on their work with TCG & DICE. Eric
Hi Eric, Dave, I'd just add one more restriction to the list... if "known good values" means "if the measured hash in a PCR is exactly this value then we're good", the domain has to be narrowed to single-threaded well-known software instances, e.g., the components of a BIOS. The complexity of known-good-values comes with asynchronous threads such as IMA in Linux; in that case, the hash in the TPM PCR can only serve as a check on the (perhaps huge) number of individual hashes in the log file, each of which needs its own Known Good Value. Hence the SWID tags. I'm certainly not qualified to say how all this would work in EAT- or TEEP-land... /guy Juniper Business Use Only
Going back to Laurence’s original request. The observation he is making is that both the Endorser and the Appraisal Policy for Evidence Owner entities can say what is a ‘reference’ or ‘known good’ value. Presumably, an Owner entity did some due diligence to ensure the KGV is indeed ‘good’ given Owners may not have access to source code or other tools that the original vendor has access to. But ultimately, all appraisal decisions are qualified by the Owner’s wishes. There is complexity in ecosystems when a vendor (e.g. BIOS vendor) doesn’t give up ownership of the FW even though the computer is sold to the customer. The PC owner might have a policy that allows the BIOS vendor to supply an Appraisal policy for just the BIOS. The Roles architecture for the BIOS component may differ from the Roles architecture for other components. In this case, the Endorsement and Policy roles may be supplied by the same Entity (i.e. the bios vendor). See more inline below - Nms>
The architecture doc should (must?) facilitate a good understanding of attestation end-end for the reader. K-g-v seem like a very core concept to attestation. Leaving them out of the architecture document will leave the reader scratching their head, like I was scratching mine. I don’t think it has to be a detailed, concise or definitional explanation. Something like this: For some claims the Verifier will compare the claims in the Evidence to known-good-values or reference values. In many cases these are hashes of files, SW or memory regions. In other cases they might be expected SW or HW versions. In other cases, they may be something else. The actual data format and semantics of a known-good-value are specific to claims and implementations. There is no general purpose format for them or general means for comparison defined in this architecture document. These known-good-values may be conveyed to the Verifier as part of an Endorsement or as part of Appraisal Policy or both as these are the two input paths to the Verifier. LL
I agree that the concept Laurence outlines should be in the architecture doc. I think there are words to that effect currently. For example, section 7.2 says “devices from a given manufacturer have information matching a set of known-good reference values,” and “Thus, an Endorsement may be helpful information in authenticating information about a device, but is not necessarily sufficient to authorize access to resources which may need device-specific information such as a public key for the device” Admittedly, this is scant and leaves a lot to the reader to figure out or make assumption. The architecture could more clearly capture the idea that Endorsements are “reference” claims that are compared with Evidence claims to validate their correctness. It should introduce other common terms such as ‘known good values’, ‘reference values’ and ‘endorsed values’ as roughly synonymous. I think it should go further to say that Endorsements can include values that are static (intrinsic) that don’t require attestation, but can be asserted about a class of device, platform, entity and appraised according to an appraisal policy for Evidence (Even though the claims don’t appear in Evidence). While I think it is possible to interpret the existing wording according to the above understanding, it is also possible to interpret it differently. Therefore, the section should be improved. I also think the first sentence (and definition in terminology) are insufficient. While “An Endorsement is a secure statement that some entity (e.g., a manufacturer) vouches for the integrity of the device’s signing capability.” – is correct, it is insufficient because it is also a statement about the devices Attesting Environment ability to collect claims securely.
Given that this Architecture document will serve as a guide to additional work that is needed from RATS wg to define data schema, interfaces for an interoperable implementations of verifiers with endorsements from multiple vendors to be compared with evidence from different implementation of attesters, isn't it worthwhile creating a hook in this document for scope of work needed to tackle it in future documents? If yes this document should define KGV, the types of KGVs that can be endorsed or defined in attestation policy, a need for data schema for each type of KGV and a set of interfaces to fetch/publish it deferred to a future document. Similar to claims encoding formats specified in section 8, a specification needed but deferred to future document for KGV endorsement formats would be useful.
A google search for "known good values" yields some mention in the Cisco trust center and a few books on security. Linux IMA mentions "good measurements" once that I could find. So there's some use of the term out there and it seems worth mentioning along with RIM. It is also a very descriptive term that is probably immediately clear to the user.


Generated from . cc NAME NAME NAME
These test vectors should cover the whole flow of the protocol, starting with the input and producing a output.


Spell out origin steps more clearly Split token caching into its own section I tried having an overall "origin" and "client" section, but it didn't flow as well.


The section references seem to be breaking the build, so I'll fix that later before we land this.
Origins currently choose whether their challenges are per-origin or cross-origin. For cross-origin, double-spend prevention is only as good as the coordination between origins and the Issuer. Per-origin allows double-spend prevention to be isolated to a single origin; also prevents the cache of tokens being take up by some other origin.
Write this as "any origins that share a redemption context must also share double spend state for that context."


The publicly verifiable basic token issuance protocol doesn't include an origin name that the issuer can see, so it does allow origins to be able to use that issuer (as long as the know the key) without explicit coordination or permission from the issuer. This isn't necessarily a problem, but we should likely mention it.


This doesn't go overboard and clarify non-collusion assumptions for all models. It simply states the requirement that entities with access to the attestation context and redemption context do not collude, and then generalizes somewhat for simplicity. cc NAME NAME
The architecture assumes that any two parties do not collude with each other. I think this is too strong an assumption. In particular, if the Origin does not collude with anyone else, what is the point of unlinkability of the issuance and redemption flows? Looking at the use cases, it seems that where the Attester and Issuer are distinct there is a needed non-collusion assumption between them to achieve desirable privacy, but I think the origin colluding with one of the Issuer or Attester should be fine and would be worth considering in scope. Also, in addition to the non-collusion assumption, are there any other assumptions made on the parties, such as honest-but-curious, or do we consider them to be potentially fully malicious? It would be nice to spell this out.
If the Origin colluded with the Issuer it would learn the client's identity (presumably), which would be bad. Ultimately, the desired property is that any sort of collusion that would allow the redemption context to be linked to the attestation context is prohibited. I'll try to clarify.


I also moved from the message namespace to the application namespace. The difference is helpfully summarized .
I see in the current draft that they register and . Since "token" is a very broad term, I'm wondering if something slightly more specific to Privacy Pass such as and might be reasonable?
If we make it more specific, it should be "private" instead of "privacy", to be "private-token" and align with the auth scheme. There's a fair amount of deployment on these types today, so this would be a relatively large change, or servers would need to tolerate both versions.
I'm in favor of making this change and having issuers support both for a little while.
Cool, that would work. NAME want to make the proposed update?
Will do!
NAME PR's up!
Looks good!


The document refers to authentication scheme attributes throughout; the term from HTTP is 'parameters'. Also, both the challenge and credentials definitions should say what to do with unrecognised parameters.


These functions do not need the "PP_" namespace prefix as it's implied from the specification. I also removed underscores in favor of normal camel case notation.


cc NAME NAME for an extra set of eyes to check me here -- ASN.1 is not my forte. I went based on the implementation , which I think matches what Frank did , but I would definitely appreciate confirmation!
Friendly bump NAME and NAME =)
Do you have a test vector / example to make sure it matches what I believe?
NAME yeah, each includes the encoded public key ().
Example, taken from the current test vector:
Looks good to me. But yeah, ASN.1 is not the most concise nor readable format.
ASN1 matches my expectations as well.
... we should make it clear, and provide test vectors to make sure it matches. The test vector could include public keys in PEM format and then print out the expected key ID.


Also update URL with correct links
Looks reasonable. Once this lands we should see about hooking about the gh-pages generation and link to that.


I cleaned up the language.
lgtm
Cullen wants LS groups because that is what legacy gear understands. Magnus wants to use MSID, which carries this.
Discussed in DC: will test out the LS group concept, Jonathan will send text to the list and we will discuss. Concerns are that there is a potential for mismatch between what is signaled in LS groups and what is signaled in MSID. We also need to work out what to do in the absence of LS groups.
bug 32 is prob dup of this
pinged Lennox
Given the discussion on CNAME, no one in the room at IETF90 objected to the idea that LS group was MTI.
Plan here is update draft to say that when creating the SDP, everything in PC has same CNAME, and the things in the same MediaStream get put in a LS (lipsync) group. This will mean legacy stuff that support LS will do the right thing, and legacy stuff that does not, will simply try and sync everything.
Cullen to ping Harald to get his LG regarding the comment above (ie. regarding its interaction with MSID)
Just to add some clarity here .... this is what I think we decided. All the RTP in a given PeerConection will use the same CNAME. For each stream, If a stream has more than one track, then the JSEP needs to create a lip sync group (see URL ) to put all the tracks in a given stream into the same lip sync group.
Yes. If no lipsync group from the remote side, everything is synchronized. If only some tracks in LS group, the rest are unsynchronized. (Basically, if you indicate you understand LS, we take what you give us, all synced)
MT, would you be willing to write some text here?
Who has the token here?
Just realized there could be a problem. Consider A, who does not want to sync its audio/video, and B, who wants its video to be synced. A offers a=group:LS with no mids. B has to reply with a subset of the proposed mids, by 5888 rules. Therefore B's a/v won't be synced. I don't see a good reason to require this, but 5888 is pretty clear. The identification-tags contained in this "a=group" line MUST be the same as those received in the offer, or a subset of them (zero identification-tags is a valid subset). When the identification-tags in the answer are a subset, the "group" value to be used in the session MUST be the one present in the answer.
There's an issue with LS when using bidirectional media sections. If media stream X (from A to B) uses media sections 1 and 2, and media stream Y (from B to A) uses media sections 2 and 3, what should be the lipsync groups? Are lipsync groups unidirectional or bidirectional?
see comment above. 5888 says bidi, but that is crazy talk.
Indeed. Crazy. What is our plan of attack here then? Can we ask MMUSIC to fix this? Either by un-screwing-up a=group (which seems unlikely), by making a new grouping semantic, or by telling us that there is a better option.
JSEP reserves the right to contradict existing standards where necessary. Generally, it seems like the need for symmetry in a=group is semantic-dependent, and so fixing it later in 5888 seems possible.
So you are suggesting that we define a=group:LS as declarative: it applies to the media that is sent by the peer that includes the grouping. I can live with that, though I suspect it will cause considerable heartburn. It certainly complicates the grouping model considerably.
yes, essentially. I don't see any way to reconcile LS with reality otherwise.
Changing the semantics of existing mechanisms by declaring that they are changed without actually changing them is a dangerous process. A simpler alternative is to drop media section reuse when LS groups are present: If a particular media section is a member of an LS group, or if a MediaStream requires its tracks to be part of an LS group, don't use it for a track in the opposite direction. The legacy case of one audio section, one video section that is used in both directions will then require that we somehow turn off LS group generation.


This LGTM. Actually, I thought I had written something like this :)
LGTM
Always remember to update both the offer and answer sections :)


LGTM
lgtm
The question has come up about what the default candidate should be set to during trickle ICE but after at least one candidate has been gathered so at least in principle you could set c= to one of those candidates. See also; URL
Want to pick a solution that works even if we we do continous trickle and ice does not finish.
Consensus on today's call is: Before ICE is completed, follow the 5245 guidance and pick the "best" candidate. Once ICE is completed, pick whatever you are actually using.
If we move to a mode where ICE never completes, perhaps use the active pair.
It turns out that this was pretty clear already. I have made it slightly clearer.


and
I tweaked this a bit, nothing major. LGTM.
For CT without AS, probably want to just tell the congestion control to stay below CT. For CT where AS is specified, do the same, but limit any streams with AS to the indicated value (in addition to total limit).
This should go into the handling-a-remote-description section.


From meeting minutes "SDP o= line increment [] While the proposed solution on the slide was accepted, it was noted that the proposal on the slide goes against what was agreed at last meeting. Emil Ivov also commented that Trickle ICE for SIP does exactly what is described on the slide. Jonathan Lennox said that we should make sure this is compatible with whatever is done in trickle ICE SIP stacks."
This algorithm becomes correct once we decide to not allow o= modification. Editorial comments follow.
Discussion in-room: 1) add example to make it clear that there is a separate counter (other than current o=) which is what increments. 2) change text about <session-version> to be more of a "note that" for an edge case, as opposed to normative text about a mainline case.
Updated this branch. PTAL
LGTM
2349: "might differ" is creepy. "differs" perhaps. 2359: "N + 2" -> must be greater than N + 1 This is basically OK modulo the above


NAME NAME PTAL
From Berlin: "A clarification to that rule was found when an offer is received with some m= lines bundled and some not; you accept all m= lines that are possible to bundle with the first m= line. "
I think we'll also have to update section 5.3.1 (Initial Answers) where it lists conditions for rejecting an m= section. Also, do we need to make similar modifications for the "balanced" bundle policy? LG with nits


Looks good to me
JSEP says: S 4.1.1. " The PeerConnection constructor allows the application to specify global parameters for the media session, such as the STUN/TURN servers and credentials to use when gathering candidates. The size of the ICE candidate pool can also be set, if desired; by default the candidate pool size is zero." The WebRTC spec says: "At this point the ICE Agent does not know how many ICE components it needs (and hence the number of candidates to gather), but it can make a reasonable assumption such as 2. As the RTCPeerConnection object gets more information, the ICE Agent can adjust the number of components"
Imagine 4 is more realistic.
so default in not defined but their is way for the JS to to set the default for a PC
Discussed in DC: default will be unspecified and left up to browsers, there will need to be a setting for applications to override this default.
w3c bug is URL


This distinguishes between the direction which was last set via setDirection (which simply affects offer/answer generation) from the direction that was negotiated, which affects whether a transceiver can send/recv media. Addresses issue .
According to WebRTC 1.0 Section 5.4 setDirection() does not take effect immediately: "The setDirection method sets the direction of the RTCRtpTransceiver. Calls to setDirection() do not take effect immediately. Instead, future calls to createOffer and createAnswer mark the corresponding media description as sendrecv, sendonly, recvonly or inactive as defined in [JSEP] (section 5.2.2. and section 5.3.2.). Calling setDirection() sets the negotiation-needed flag." My interpretation of the above is that setDirection immediately sets the transceiver.direction attribute, but that the "current direction" (distinct from the direction attribute) is only changed by calls to setLocal/setRemoteDescription. I would like to suggest that JSEP indicate precisely when the "current direction" changes. My reading of JSEP is that this is determined from the currentLocalDescription and currentRemoteDescription. For example: The direction provided in the currentLocalDescription (e.g. the "current direction") is "sendrecv" and setDirection("recvonly") is called. Since setDirection does not change the direction in currentLocalDescription, the RtpSender does not stop sending. createOffer() is called. A "recvonly" offer is generated. setLocalDescription(RecvOnlyOffer) is called. Now the direction in pendingLocalDescription changes to "recvonly", but the direction in currentLocalDescription is still "sendrecv", so the RtpSender does not stop sending. setRemoteDescription(SendOnlyAnswer) is called. Now the direction in currentLocalDescription is "recvonly", so the RtpSender will stop sending.
Bernard's description makes sense to me; currentLocal/Remote indicate the current direction state.
Fixed by


Originally raised by Magnus: Section 3.7: JSEP supports simulcast of a MediaStreamTrack, where multiple encodings of the source media can be transmitted within the context of a single m= section. I think this should be explcit that it is "simulcast transmission of a MediaStreamTrack".


Originally raised by Magnus: Section 5.1.1: R-2 [RFC5764] MUST be supported for signaling the UDP/TLS/RTP/SAVPF [RFC5764], TCP/DTLS/RTP/SAVPF [I-D.nandakumar-mmusic-proto-iana-registration], "UDP/DTLS/ SCTP" [I-D.ietf-mmusic-sctp-sdp], and "TCP/DTLS/SCTP" [I-D.ietf-mmusic-sctp-sdp] RTP profiles. I would note that [I-D.nandakumar-mmusic-proto-iana-registration] is actually published as RFC 7850. Section 5.1.1: R-12 [RFC5761] MUST be implemented to signal multiplexing of RTP and RTCP. This should include the updated as ref also.


Originally raised by Magnus: Section 5.2.1: o Session Information ("i="), URI ("u="), Email Address ("e="), Phone Number ("p="), Bandwidth ("b="), Repeat Times ("r="), and Time Zones ("z=") lines are not useful in this context and SHOULD NOT be included. Considering that b=CT is not useless, I am a bit surprised to see b= on this list. Yes, b=CT: is only useful is one like to provide a upper total bandwidth limitation. So, maybe some discussion of the possible choice?
This is just a mistake in 5.2.1 - we cover how to deal with it later in section 5. Prob need to remove the mention of b= here.


Did we not decide that modifying that offer (or an answer created by createAnswer()) is not allowed?
Agreed. This text should be culled.


The pool is only used in the first offer/answer exchange. After applying a local description, the pool size is frozen and changing the ICE servers will not result in new candidates being pooled. After an answer is applied, any leftover candidates are discarded. This only happens when applying an answer so that candidates aren't prematurely discarded for use cases that involve pranswer, or multiple offers.
I can live with this as is. Want to read again if we end up making changes to address EKR comments
Updated PR and its description based on our discussion.


I applied the following principles, which unfortunately are somewhat inconsistent with the current mux-exclusive draft. You use a=rtcp-mux to negotiate mux a=rtcp-mux-only is used by the offerer to say "I really mean it" To that end, offers contain a=rtcp-mux-only if the policy is require. Answers don't contain it because you don't need it to negotiate mux.
Those principles are consistent with bundle-only, although I wrote the mux-only examples as if mux-only should always be included whenever a=rtcp-mux is present.
NAME back at you
NAME ping
LG


attributes. As far as I can tell this can happen: On re-offers On any answer because nothing requires the offerer to generate bundle tags in the same order as m= lines (even though the data channel m= line is last) See: URL
NAME PTAL
Say you have a session where only a data channel is created. SDP looks like [session boilerplate] a=group:BUNDLE d1 m=X application UDP/DTLS/SCTP webrtc-datachannel a=mid:d1 ... Now, a media m= section is added (i.e. after first o/a). SDP becomes: [session boilerplate] a=group:BUNDLE d1 a1 m=X application UDP/DTLS/SCTP webrtc-datachannel a=mid:d1 a=ice-ufrag:ABCD ... m=X audio UDP/TLS/RTP/SAVPF 0 a=mid:a1 [no ice-ufrag or TRANSPORT attrs, since bundled] Now, where does a=rtcp-mux go? It can't go into because of the language that states Thoughts on how to resolve?
Could generating a session description be split into two parts? First, generate media-level attributes for each "m=" section, then transport-level attributes for the BUNDLE group and each non-bundled "m=" section.
That would be my preference, i.e., jam it into the BUNDLE group m= section, regardless of media type, as that's conceptually simplest, and easily handled here in JSEP. Either way, I suspect this will require changes upstream in the bundle spec.
So ... is it really not allowed in the d1 section. Unknown attributes are allowed in the d1 section, they are just ignored if they have no meaning for the data channel. Agree this sounds like something that will hit bundle.
Couldn't you do a=group:BUNDLE a1 d1 I would have thought this was prohibited, but is it really? URL
I think that's legal, but that approach doesn't work in the general case, where "m=" section A has TRANSPORT attributes that only it uses, and section B has TRANSPORT attributes that only it uses. BUNDLE just needs to allow an "m=" section to contain attributes that it normally wouldn't contain if it wasn't bundled. (If this isn't already allowed).
NAME any action needed here?
I think what we want in this scenario is to put "a=rtcp-mux" and "a=rtcp-rsize" in the data channel section. The simplest way would be to say: Which I guess could only happen in subsequent offers.
Let's go with what NAME suggests, although this makes it a bundle problem.
What would you say is needed on the BUNDLE side? Just clarification that the offerer BUNDLE-tag m= section should contain the union of all TRANSPORT and IDENTICAL attributes used by the BUNDLE group?
talked to chairs and advice from chairs on this and similar things that depend on mmusic outcomes. We put in JSEP now what our best guess is of how mmusic will end up and publish JSEP. At the same time we log a bug to check if we need to make any changes to line up with what mmusic decides. We can take changes to line up with mmusic as Last Call comments later on.
+1 with Taylor proposal to put RTP related things in data m= section if it is first and good with making this be bundles problem
NAME NAME I assume that you think that on initial offers this cannot happen because data comes last?
NAME Right. I can't think of a scenario where it wouldn't go last in an initial offer.
Agreed.
Oh, except that you aren't required to make the bundle group in order So you can have
I don't think the question whether you are allowed or not to place an RTP attribute in a non-RTP m= section is a pure BUNDLE issue. One needs to check what the specs defining those attributes say.
every SDP spec has to accept (and ignore) lines it does not understand ...
I looked into the a=rtcp-mux and a=rtcp-rsize specs, and I didn't see anything that prohibited their inclusion into a non-media section. Generally, I think BUNDLE can define the rules for this sort of thing, without fear that it will somehow contradict some other spec.
NAME NAME You may want to chime in on the current MMUSIC thread. I agree with you, but it seems to be going in the direction of "you can't do this".

I looked into the a=rtcp-mux and a=rtcp-rsize specs, and I didn't see anything that prohibited their >inclusion into a non-media section. It may not be explicitly stated, but since the semantics is about RTP and RTCP I think it is implicit. Having said that, I personally have no problem with allowing the attributes in non-RTP m- sections. I just want to verify that there is no text that has to be modified somewhere, and/or whether there is some text that has to be added somewhere :)
Resolved by
Looks good.


LGTM and if Justin wants to tie in the stuff from my comment a bit more that is great
NAME PTAL
seems like it's generally right,LGTM


I agree with justin here. my bad for missing that.
The 4th bullet on page 64 is ambiguous at "this m= section". It looks like this bullet should just be merged with the previous bullet.
I'm not sure what the problem is here, but I'm not against merging it. NAME
The bullet point in question is the one that reads If this m= section was present in the previous answer then the state of RTP/RTCP multiplexing MUST match what was previously negotiated.
LGTM


Fixed
also tagging NAME (who might be unhappy with 'default' which matches Chrome behaviour but not Firefox behaviour (it generates a uuid)
ping NAME NAME
NAME NAME PTAL - Barring any objections this one ought to get merged.
Folks, I think this one is pretty uncontroversial - planning to land this next week if there are no objections.
Take this simplified SDP offer from a remote endpoint (in parts taken from : A single audio and video stream. No a=mid (there is quite some text taking care of that) but no a=msid line either. URL shows a live example. Both Chrome (without unified-plan) and Firefox will fire the ontrack event (or legacy onaddstream) with a single mediastream containing an audio and video track. This has been like that since... 2012-ish? Unified plan support in Chrome changes this behaviour: URL ontrack is fired with an empty set of media streams. onaddstream is not fired. This is quite a change in behaviour. And unexpected, I didn't expect any issues for this trivial case of a single audio/video track. As NAME webrtc-pc assumes/requires a=msid to be present and . In particular this says which means firing with no streams is technically correct. JSEP seems to assume it is present as well, but has this text about a=msid in Note the "If present". What if it is not present? The closest I could find in terms of guidance was this from the and its section about handling a=msid is supposed to be present in initial offer so we are talking about dealing with non-webrtc entities send an offer. Given that there is plenty of support for entities that do not support a=mid (an RFC published in 2010) in JSEP do we need backward compability for the case of a single audio/video track each but no msid? Interop between browsers is probably not affected, due to Chrome still interpreting and sending a=ssrc:123 msid:...
note that a proper webrtc client will include "no streams" as (maybe with a track) which allows differentiating between "no streams because I do not use any" and "msid???" Thanks NAME for another
aside: the interesting case you have trouble distinguishing between is "no msid because I haven't started sending a track yet" and "no msid because I don't support msid". It's one case where we still have trouble if RTP packets arrive ahead of signalling. But - yes, I think we are better off sticking with the 2012 behavior, default stream and all. We can handle the case above by changing the stream associations of the receiver if a new SDP (with msid) arrives after the RTP packets.
there used to be a a=msid-semantic line that would allow determining whether a party wants its offer to be treated assuming msid support. Browsers still send it :-)
How are non-signaled tracks supposed to be handled anyway? There's JSEP language about creating a track for it, but what about webrtc-pc? (If a track exists in the forest, and nobody is around to surface it to JavaScript, does it still exist?) "Run the following steps for each media description in description" means no ontrack will fire until we do have something signaled. If the track (and/or stream) only exists in some inaccessible way they're almost conceptual until the signaling does arrive. And when it does arrive, we know whether or not MediaStreams were signaled. So we should know what to do, same things as if we didn't receive early RTP packets? Does the distinction matter? I love that we can tell the difference between "no streams because I do not use any" and "no msid signaled" whether or not "a=msid:-" was present. I had not thought about that! Unless I'm confused about something, I suggest: If is present, do what Chrome does: don't create any stream. If the line is completely missing, do what Firefox (or Chrome Plan B) does: create a MediaStream with a random id. Does that work for people?
By the way I thought this was a webrtc-pc issue when I replied above, so I was thinking about what to do in JavaScript rather than talking about any JSEP change.
I suppose we need some JSEP language to handle the lack of any a=msid but i agree with what you propose above. We do have have a=msid:- and we need to handle that in webrtc-pc too. Will file an issue there.
All webrtc-pc says is "let msids be a list of the MSIDs that the media description indicates transceiver.[[Receiver]].[[ReceiverTrack]] is to be associated with. Otherwise, let msids be an empty list" And says "The special value "-" indicates "no MediaStream"." So that already takes care of the case correctly, I claim. I agree. We need to solve what the media description (JSEP) says about this. Right now : "If present, "a=msid" attributes MUST be parsed as specified in [I-D.ietf-mmusic-msid], Section 3.2, and their values stored." I think it needs to say what happens when it is not present. Something like: "If no a=msid is present, then in place of "msid-id", create a single "id" unique to this end-point, if one hasn't already been created for this connection."
"if one hasn't already been created for this connection"; so future tracks will share the same stream? There is always at most a single "default stream"?
NAME says he observed this is how Firefox and Chrome work. URL
See URL
LGTMreason I asked is that chrome generates a MediaStream with id "default" -- see URL while Firefox does not. (I do not see any reason to change the legacy behaviour of chrome even though it seems a bit odd that the RNG always emits the right bytes for "default")


Several small updates: Issue 15: local media state, local resources correct, removed comment. - Issue 16: updated wording to use 'calling this method', removed comments, - Issue 17: changed stopTransceiver to stop, removed comments, - Issue 18: changed 'directional attribute' to 'direction attribute', removed comments,
LGTM once lands
18) [rfced] Section 4.2.5: We see "direction attribute" but not "directional attribute" in RFC 3264. Will this text be clear to readers? (We ask because we also see "A direction attribute, determined by applying the rules regarding the offered direction specified in [RFC3264], Section 6.1" in Section 5.3.1 of this document.) Original: More specifically, it indicates the [RFC3264] directional attribute of the associated m= section in the last applied answer (including provisional answers), with "send" and "recv" directions reversed if it was a remote answer.
This should indeed be , as that's the terminology used by 3264.
NAME please close this issue once you consider it resolved.
17) [rfced] Section 4.2.2: Will "stopTransceiver" be clear to readers? We could not find this string elsewhere in this document, anywhere else in this cluster of documents, in any published RFC, or in google searches. Original: The stopped property indicates whether the transceiver has been stopped, either by a call to stopTransceiver or by applying an answer that rejects the associated m= section.
This should be , rather than .
NAME please close this issue once you consider it resolved.
16) [rfced] Section 4.1.16: Should "The effects of this method call" be "The effects of calling this method," and should "This call" be "Calling this method"? Original: The effects of this method call depend on when it is invoked, and differ depending on which specific parameters are changed: ... This call may result in a change to the state of the ICE Agent.
SGTM
NAME please close this issue once you consider it resolved.
15) [rfced] Section 4.1.10: Please confirm that "local media state" and "local resources" (as opposed to remote) are correct in the context of setRemoteDescription. (We ask because we see identical wording in Section 4.1.9 ("setLocalDescription").) Original: This API changes the local media state; among other things, it sets up local resources for sending and encoding media.
yes, this is correct
NAME please close this issue once you consider it resolved.
12) [rfced] Section 4.1.8.1: We had trouble with this sentence. If neither suggestion below is correct, please clarify. Original: While this could also be done with a "sendonly" pranswer, followed by a "sendrecv" answer, the initial pranswer leaves the offer-answer exchange open, which means that the caller cannot send an updated offer during this time. Suggestion : While this could also be done with a "sendonly" pranswer, if followed by a "sendrecv" answer the initial pranswer leaves the offer/answer exchange open, which means that the caller cannot send an updated offer during this time. Suggestion : While this could also be done with a "sendonly" pranswer followed by a "sendrecv" answer, the initial pranswer leaves the offer/answer exchange open, which means that the caller cannot send an updated offer during this time.
suggestion seems right


This is in response to a post NAME made on .
Thanks for the PR! So as an interoperability standard, if the retry service encodes "4000", what does the server do with that? Do we need to add a config parameter for the time_t that serves as time 0?
Timestamps should be absolute, not relative, in which case I'm not sure you need a 0. There's nothing special about midnight 1 January 1970.
Ah, so you're just suggesting declaring a later date to begin the epoch? Makes sense
Why do we need to have a sential time? If it's a precision vs. range issue then shifting the epoch makes sense.
Sorry, I don't know what "sential time" is. What are you proposing?
What I'm proposing is that we not treat any times differently. It's not clear to me why 4000 needed special treatment.
4000 is just an example. The intent of using the epoch was to have common agreement on when tokens expire without any QUIC-LB-specific coordination. The current draft uses 1970 as a timebase, which absolutely makes integers longer than it needs to be. IIUC the PR doesn't have any baseline so it's unclear how the server and retry service are supposed to interpret each other's expiration times. As we're probably speaking past each other: what, precisely, does the integer in this field indicate?
It's the end of the validity period for the token in some convenient timebase.
Alright, we agree on that. So this PR is being a little less precise on synchronization, which is fine, but isn't addressing the fact that we're counting from 1970. Fair enough. Dear QUIC WG, First a moment of unforgivable pedantry. Universal time is unfortunately not the right name for UTC, which is slightly different. It could also mean UT1 or some other variations It's also not clear what the future of computer timekeeping is and I know several places don't synchronize to UTC internally. I think the best way to handle this is to say something like "synchronized" and leave open as to exactly how that is done. I agree with the comments that there are too many options and should be fewer. Other then that I didn't see any problems but I'm probably too sleepy right now to spot them. Sincerely, Watson Ladd Astra mortemque praestare gradatim


Definitely an edge case, but the LB will spray stateless resets everywhere because the CID is random. If the LB tracks fourtuples, though, it shouldn't be a problem.
Maybe make this part of a thing about stateless LBs.
So, what's the plan ?
NAME raises an interesting point about stateless LBs in .


After thinking it through, various XOR schemes were extremely vulnerable to manipulation, so I went with a brute force approach.
The server now needs to include this field. For the no-shared state service, we just need language that the Retry service needs to encode enough information validate the packet DCID as well and drop if it fails validation. If it does, the server MUST use the packet DCID in the retrysourceconnection_id TP. For the shared state service, the retry source connection ID is going to have to be in the token. We might be able to compress this by xoring some fields; I'll think about it.


I will probably delete the Stream Cipher algorithm entirely, but consider this an intermediate step.
Merging to enable the next round of edits


by popular demand in .
As discussed at IETF 108. Split from .
Thanks for filing this. I agree that this was the feedback, but I'll take it from the list to be sure.
Removing this seems fine to me.
Yes, do it.
Seems fine.
Do it.
Do it.
Nick Harper concurred on the list
Yes, that works. Minor comment.


Adding a description to signaling options to improve readability. I have pending to update L2TP after the other issue is solved URL
Thanks, Victor. Does the text reflect the latest version of signaling/discovery split?
leaf l2tp-type { type identityref { base t-ldp-pwe-type; } description "T-LDP PWE type."; }
The type should be taken from this registry: URL
A new IANA-maintained module is created to fix this issue.


adds a missing digest parameter corrects CDDL for suit-text removes dangling
I have discovered this because the EAT build process pulls the SUIT CDDL in for validation using the cddl tool.
NAME posted to the list the following: I think I found a little typo in the draft-ietf-suit-manifest-14 ... At the "Appendix A. A. Full CDDL" of the "SUITSeverableMembersChoice", the last two members are pointing to "SUITCommand_Sequence" are probably typos as following,
In draft-ietf-suit-manifest-04 In the example manifest image-digest parameter is set for component 0 in common sequence. The load sequence sets component-index to 1 and after directive-copy it specifies image-match condition. However, the image-digest parameter has not been set for component-index 1 causing the condition to fail as . Is it expected that parameters are implicitly copied from source component when copy-directive is executed? Should the image-digest be also specified for component-index 1 or perhaps for all components? Another observation in the example is that vendor-id and class-id parameters and corrsponding condition checks are specified for component 0, which seems to be the "external storage". Wouldn't it be better to specify the VID and CID globally for the entire device or for the component 1, which seems to be the one running the image? / common / 3:h'a2024782814100814101045856880c0014a40150fa6b4a5 3d5ad5fdfbe9de663e4d41ffe02501492af1425695e48bf429b2d51f2ab45038202582 000112233445566778899aabbccddeeff0123456789abcdeffedcba98765432100e198 7d001f602f6' / { / components / 2:h'82814100814101' / [ [h'00'] , [h'01'] ] /, / common-sequence / 4:h'880c0014a40150fa6b4a53d5ad5fdfbe9d e663e4d41ffe02501492af1425695e48bf429b2d51f2ab450382025820001122334455 66778899aabbccddeeff0123456789abcdeffedcba98765432100e1987d001f602f6' / [ / directive-set-component-index / 12,0 , / directive-override-parameters / 20,{ / vendor-id / 1:h'fa6b4a53d5ad5fdfbe9de663e4d41ffe' / fa6b4a53-d5ad-5fdf- be9d-e663e4d41ffe /, / class-id / 2:h'1492af1425695e48bf429b2d51f2ab45' / 1492af14-2569-5e48-bf42-9b2d51f2ab45 /, / image-digest / 3:[ / algorithm-id / 2 / sha256 /, / digest-bytes / h'00112233445566778899aabbccddeeff0123456789abcdeffedcba9876543210' ], / image-size / 14:34768, } , / condition-vendor-identifier / 1,F6 / nil / , / condition-class-identifier / 2,F6 / nil / ] /, } /, (...) / load / 11:h'880c0113a1160016f603f6' / [ / directive-set-component-index / 12,1 , / directive-set-parameters / 19,{ / source-component / 22:0 / [h'00'] /, } , / directive-copy / 22,F6 / nil / , / condition-image-match / 3,F6 / nil / ] /,


Let's remove this sentence and add more information when we will have this additional experimental data
This area probably needs more experimentation in general. For instance, it is unclear how much we could partition such IPv6 addresses by origin like we ask for mDNS names. Given we already talk about this approach in the privacy section, these sentences do not feel mandatory to keep. No strong feelings either way though.
I looked at the current text more closely and I see what you are saying, especially regarding different origins. We should probably talk about the separation of origins or browsing contexts more in the introduction though. Currently it only refers to the fingerprinting threat, which could be construed to simply mean a long-term identifier.
I don't think we needed to nuke this whole section, just the future version of the document sentence.


introduce numbered sections for YAML NAME since each media type is defined in its IANA consideration, would it be ok for you if we just add a section for YAML? Feel free to PR with another proposal.
NAME could you PTAL ? :)
to be honest, i prefer definitions to have URIs and not just registrations. but if we have URIs, that's already a lot better than not having URIs! thanks!
it's maybe just OCD (and because it's very useful for URL to have linkable references) but i think it's nice to have numbered sections for everything that's being defined in the spec. in this case, i suggest to have a numbered section for each of the four media types, and to have a brief explanation of what it identifies. that way, each definition is self-contained and can be easily referenced when necessary. NAME NAME


WGLC comments on Operation Requirements section. Added several overlooked requirements
Discussed on 12/8 interim, and folks seemed fine with this. I.e., it's ready to merge.


We need an IANA considerations section even if we make no requests of them. It's just part of the process and the section can be removed during the final publication phase.


This PR adds a short paragraph referencing the various academic works that has gone into MLS. The references to the various works still need to be cleaned up, which I will do once the list is complete. In particular, each reference needs to be checked for correctness (eprint version vs. publicized version) and then included as informal reference in the yaml header of the document.
Is there another RFC you can point to that links academic papers on the protocol? I'd expect TLS 1.3 to be a good example of this, but I don't see them do this. The references should be cited properly if we do include it (ie, added as citations at the top of the file)
The references are in the appendices. For instance URL The reader should refer to the following references for analysis of the TLS handshake: [DFGS15], [CHSV16], [DFGS16], [KW16], [Kraw16], [FGSW16], [LXZFH16], [FG17], and [BBK17].
TLS 1.3 as cited by NAME was indeed the inspiration for this. The idea was to just have a small paragraph to point the reader in the right direction and then have the full bibliographic entry in the "Informal References" section. As noted above, I intend to properly format all the references once we agree on what references to include, as formatting them into the right yaml is a bit of a pain.
Thanks Konrad!


Adding this check would be the first step in recognizing that an Update operation may have maliciously excluded a person from the group.
This would go better in the "Ratchet Tree Updates" section, right after "Derive secret values for ancestors of that node using the KDF keyed with the decrypted secret". That would align better with where in the code you want the checks to be. Other than that, LGTM.
Fixed
Thanks Michael !
Here's the Weekly Digest for : - - Last week 4 issues were created. Of these, 1 issues have been closed and 3 issues are still open. :greenheart: , by :greenheart: , by :greenheart: , by :heart: , by :speaker: , by It received 4 comments. - - Last week, 9 pull requests were created, updated or merged. Last week, 8 pull requests were updated. :yellowheart: , by :yellowheart: , by :yellowheart: , by :yellowheart: , by :yellowheart: , by :yellowheart: , by :yellowheart: , by :yellowheart: , by Last week, 1 pull request was merged. :purpleheart: , by - - Last week there were 4 commits. :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by - - Last week there was 1 contributor. :bustinsilhouette: - - Last week there was 1 stargazer. :star: You are the star! :star2: - - Last week there were no releases. - - That's all for last week, please :eyes: Watch and :star: Star the repository to receive next weekly updates. :smiley: You can also .


This is something we've been meaning to do for a while, and just haven't gotten around to. The Init message directly creates a group with a specified member list. The cost of group creation is O(N) DH operations for the sender, and O(1) for receivers.
This now has an OPEN ISSUE regarding the fact that we'll need to add PKE encryption for that message, as agreed out of band, let's merge this and add encryption in the next iteration.
Here's the Weekly Digest for : This week, 8 issues were created. Of these, 4 issues have been closed and 4 issues are still open. :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :heart: , by :heart: , by :heart: , by :heart: , by The issue most discussed this week has been: :speaker: , by It received 9 comments. This week, no pull requests has been proposed by the users. This week, 4 users have contributed to this repository. They are , , , and . This week, no user has starred this repository. This week, there have been 4 commits in the repository. These are: :hammerandwrench: Merge pull request from rozbb/mlsplaintext-signature Multiple clarifications around Framing by :hammerandwrench: Merge pull request from rozbb/hpke-encrypt Clarify how HPKE ciphertexts are computed by :hammerandwrench: by :hammerand_wrench: by # RELEASES This week, no releases were published. That's all for this week, please watch :eyes: and star :star: to receive next weekly updates. :smiley:
Here's the Weekly Digest for : - - Last week 5 issues were created. Of these, 1 issues have been closed and 4 issues are still open. :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :heart: , by - - Last week, 9 pull requests were created, updated or merged. Last week, 3 pull requests were opened. :greenheart: , by :greenheart: , by :greenheart: , by Last week, 1 pull request was updated. :yellowheart: , by Last week, 5 pull requests were merged. :purpleheart: , by :purpleheart: , by :purpleheart: , by :purpleheart: , by :purpleheart: , by - - Last week there were 8 commits. :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by - - Last week there were 2 contributors. :bustinsilhouette: :bustinsilhouette: - - Last week there was 1 stargazer. :star: You are the star! :star2: - - Last week there were no releases. - - That's all for last week, please :eyes: Watch and :star: Star the repository to receive next weekly updates. :smiley: You can also .
We have a long-standing OPEN ISSUE on creating a group with a single Init message instead of N Add messages, which would change the work of initialization from O(N log N) to O(N). I would propose roughly the following: Then the processing would be: Find the welcome that's for you Initialize a one-member tree from the Welcome Use the UserInitKeys to populate the leaves of the tree Use the DirectPath to populate the creator's direct path (as in Update)
Fixed by URL
Similarly to the for a new member, this is a PKE operation: the encryption of this message is missing from the description. This message needs to be encrypted to each client otherwise it leaks all public keys of the tree which would otherwise be protected under the common framing. A secondary question appears as a consequence. There is static key reuse for the leaves until they update, we designed HPKE so that it should be fine but I would still add an [OPEN ISSUE] for it.


Here's the Weekly Digest for : - - Last week 3 issues were created. Of these, 1 issues have been closed and 2 issues are still open. :greenheart: , by :greenheart: , by :heart: , by :speaker: , by It received 1 comments. - - Last week, 6 pull requests were created, updated or merged. Last week, 1 pull request was opened. :greenheart: , by Last week, 1 pull request was updated. :yellowheart: , by Last week, 4 pull requests were merged. :purpleheart: , by :purpleheart: , by :purpleheart: , by :purpleheart: , by - - Last week there were 6 commits. :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by - - Last week there was 1 contributor. :bustinsilhouette: - - Last week there was 1 stargazer. :star: You are the star! :star2: - - Last week there were no releases. - - That's all for last week, please :eyes: Watch and :star: Star the repository to receive next weekly updates. :smiley: You can also .
Here's the Weekly Digest for : - - Last week, no issues were created. - - Last week, 3 pull requests were created, updated or merged. Last week, 2 pull requests were updated. :yellowheart: , by :yellowheart: , by Last week, 1 pull request was merged. :purpleheart: , by - - Last week there was 1 commit. :hammerandwrench: by - - Last week there was 1 contributor. :bustin_silhouette: - - Last week there was 1 stargazer. :star: You are the star! :star2: - - Last week there were no releases. - - That's all for last week, please :eyes: Watch and :star: Star the repository to receive next weekly updates. :smiley: You can also .
Here's the Weekly Digest for : - - Last week 2 issues were created. Of these, 0 issues have been closed and 2 issues are still open. :greenheart: , by :greenheart: , by - - Last week, 2 pull requests were created, updated or merged. Last week, 2 pull requests were opened. :greenheart: , by :greenheart: , by - - Last week there were no commits. - - Last week there were no contributors. - - Last week there were 2 stagazers. :star: :star: You all are the stars! :star2: - - Last week there were no releases. - - That's all for last week, please :eyes: Watch and :star: Star the repository to receive next weekly updates. :smiley: You can also .


It seems like there's a major thing missing here, namely how the sender of a Commit transmits the new node signatures to the other members of the group. We need something like that before this lands. The most obvious approach would be to add a field to DirectPathNode, as you have with RatchetNode.
It would also be handy to include in the intermediate node an indication of which leaf signed it. Otherwise you have to do "trial verifications" (cf. trial decryption), which is expensive.
Was this addressed? it's mentioned that the signature should be transmitted in "Synchronizing Views of the Tree" but there's no signature in the transmitted DirectPathNode
NAME changes the strategy for signing the tree, everything should be sorted out there.
Here's the Weekly Digest for : - - Last week 8 issues were created. Of these, 0 issues have been closed and 8 issues are still open. :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :speaker: , by It received 1 comments. - - Last week, 6 pull requests were created, updated or merged. Last week, 1 pull request was opened. :greenheart: , by Last week, 3 pull requests were updated. :yellowheart: , by :yellowheart: , by :yellowheart: , by Last week, 2 pull requests were merged. :purpleheart: , by :purpleheart: , by - - Last week there were 10 commits. :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by - - Last week there were 2 contributors. :bustinsilhouette: :bustin_silhouette: - - Last week there was 1 stargazer. :star: You are the star! :star2: - - Last week there were no releases. - - That's all for last week, please :eyes: Watch and :star: Star the repository to receive next weekly updates. :smiley: You can also .
Here's the Weekly Digest for : - - Last week 4 issues were created. Of these, 0 issues have been closed and 4 issues are still open. :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by - - Last week, 14 pull requests were created, updated or merged. Last week, 8 pull requests were updated. :yellowheart: , by :yellowheart: , by :yellowheart: , by :yellowheart: , by :yellowheart: , by :yellowheart: , by :yellowheart: , by :yellowheart: , by Last week, 6 pull requests were merged. :purpleheart: , by :purpleheart: , by :purpleheart: , by :purpleheart: , by :purpleheart: , by :purpleheart: , by - - Last week there were 10 commits. :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by - - Last week there were 3 contributors. :bustinsilhouette: :bustinsilhouette: :bustinsilhouette: - - Last week there were no stargazers. - - Last week there were no releases. - - That's all for last week, please :eyes: Watch and :star: Star the repository to receive next weekly updates. :smiley: You can also .
Here's the Weekly Digest for : - - Last week 11 issues were created. Of these, 1 issues have been closed and 10 issues are still open. :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :heart: , by :speaker: , by It received 2 comments. - - Last week, 11 pull requests were created, updated or merged. Last week, 6 pull requests were opened. :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by Last week, 4 pull requests were updated. :yellowheart: , by :yellowheart: , by :yellowheart: , by :yellowheart: , by Last week, 1 pull request was merged. :purpleheart: , by - - Last week there were 2 commits. :hammerandwrench: by :hammerandwrench: by - - Last week there were 2 contributors. :bustinsilhouette: :bustin_silhouette: - - Last week there were 2 stagazers. :star: :star: You all are the stars! :star2: - - Last week there were no releases. - - That's all for last week, please :eyes: Watch and :star: Star the repository to receive next weekly updates. :smiley: You can also .


It seems like we have a few separable issues here: Whether we require a single signature scheme for the whole group Whether signature schemes are included in the ciphersuite Whether we have an MTI ciphersuite / signature algorithm What new ciphersuites should be defined, and what algorithms should go in them Let's discuss this at the interim and maybe break this PR into a few bits
Note that specification required registries imply that there is a designated expert pool. I will add some text to create one. The text is very similar to the TLS DE pool text from with some tweaks that, hopefully, address the misunderstandings uncovered during non-standards track registry requests. Note the process is: (assuming that the IESG eventually approves this draft) When the IESG approves this draft, the responsible AD assigns some DEs (like 2-3 suggested by the WG chairs). These DEs are in charge of all registrations regardless of whether the draft comes from the WG or elsewhere as all requests go to the MLS DEs mailing list.
Here's the Weekly Digest for : - - Last week 3 issues were created. Of these, 0 issues have been closed and 3 issues are still open. :greenheart: , by :greenheart: , by :greenheart: , by :speaker: , by It received 1 comments. - - Last week, 7 pull requests were created, updated or merged. Last week, 2 pull requests were opened. :greenheart: , by :greenheart: , by Last week, 4 pull requests were updated. :yellowheart: , by :yellowheart: , by :yellowheart: , by :yellowheart: , by Last week, 1 pull request was merged. :purpleheart: , by - - Last week there were 3 commits. :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by - - Last week there were 2 contributors. :bustinsilhouette: :bustinsilhouette: - - Last week there were 2 stagazers. :star: :star: You all are the stars! :star2: - - Last week there were no releases. - - That's all for last week, please :eyes: Watch and :star: Star the repository to receive next weekly updates. :smiley: You can also .
Here's the Weekly Digest for : - - Last week 3 issues were created. Of these, 0 issues have been closed and 3 issues are still open. :greenheart: , by :greenheart: , by :greenheart: , by - - Last week, 4 pull requests were created, updated or merged. Last week, 3 pull requests were updated. :yellowheart: , by :yellowheart: , by :yellowheart: , by Last week, 1 pull request was merged. :purpleheart: , by - - Last week there was 1 commit. :hammerandwrench: by - - Last week there was 1 contributor. :bustin_silhouette: - - Last week there were no stargazers. - - Last week there were no releases. - - That's all for last week, please :eyes: Watch and :star: Star the repository to receive next weekly updates. :smiley: You can also .
This seems to accurately reflect the consensus we had at the last interim, and there's nothing I can't live with otherwise. I will probably file a follow-up to convert the Derive-Key-Pair operations to use HKDF directly, as discussed, avoiding the need for intermediate values or truncation of SHA-512.


You can also strike this sentence further down: " In particular, for the leaf node, there are no encrypted secrets, since a leaf node has no children."
Note that this severs the connection between the HPKE key in the leaf and the parent of the leaf. Whereas before, the leaf HPKE key was derived from a path secret, and the parent HPKE key was derived from the next path secret. Now the parent path secret is set directly, and the leaf HPKE key is set completely independently, with no dependency on a path secret. So we're losing a bit of internal structure in the tree. But this seems OK because that structure was never observable to the group -- only the holder of the leaf knows the leaf path secret, so nobody else could verify that the leaf was related to its parent.


This PR adapts the Welcome logic so that the new joiners get their path secrets directly, rather than from a DirectPath. This cleans things up in a few ways. The new joiners no longer have to have the context for the previous epoch (which was used to encrypt the DirectPath). And we can get away with one HPKE operation per new joiner instead of two (one for the EncryptedKeyPackage and one for the DirectPath). The major cost is that there's a bit more complexity in the TreeKEM. Instead of just producing and consuming DirectPaths, you now need to know which path secrets go with which nodes. You also need tree math to identify the common ancestor of two leaves, but there's a simple closed-form formula for that, expressed in the Python code here.
NAME - Curious if this seems implementable to you. Clearly it's possible, since I did it in Go :) But it also needs to make sense to other people.


The first commit is editorial. I removed all the DH terminology I could find and replaced it with KEM terminology. The second commit is related to URL It would massively reduce complexity of implementations if people were able to rely on HPKE to do all private key parsing, key validation, public key computation, etc. Currently, all the information in the deleted CFRG and NIST sections is either redundant (performed by HPKE) or outdated and performed correctly by HPKE (e.g., old P-256 DH secret representation). Instead of having all this duplicated, it would be easier to keep it in one place. An issue with the new definition of : Repeatedly calling can be computationally expensive. Each call requires computing the group hash (which, okay, it could be cached) and serializing a struct. It would be nice to do something that's cheaper but still ties context into the secret key generation.
Update: This now uses HPKE's function to do all the heavy lifting


A couple of minor editorial changes to the current draft, namely: There was a missing grave accent in one of the paragraphs of the Commit section causing some formatting issues Before: ! After: ! Fix typo Pre-Shared Keys section [...], it does not necessarily provide the same [...] guarantees ~than~ as a Commit message. Resolve remaining reference to priorepoch In the Sequencing section there was a reference to a field that was introduced in 2fa6ed3c6afc7d308905255b4cabe154a48d1e4b. However, in 69e12cd61378aae4a81199c28a16e2802666b6e3, it was removed from the struct where it was added. That entire struct was then removed in 27c9c28f9634a06a9b7921ea9c15e276f8c9ff6f, after which the trail runs cold. So I wasn't able to figure out exactly what it must be based on what on what it originally was. Hence, I replaced it with something that makes sense in context. I based the new text on the following line found in the (current) Commit section: Rewrite paragraph on the new_member SenderType I found the phrase " In such cases" after the sentence "Proposals with types other than Add MUST NOT be sent with this sender type" slightly confusing and awkward. To improve this I rewrote the paragraph.
Couple of nits on your nits


This is a simple rename of to to be more descriptive of the action being performed by the message. I'll open a separate PR after this PIR is merged with updates to the spec where it uses when instead it should say (since not every actually ratchets forward key material, as I understand). Some examples of where these clarifications should happen are: Line 1203 should instead say "each MLS UpdatePath message" The sections "Ratchet Tree Evolution" and "Sychronizing Views of the Tree" should describe the process of generating the key material for an message cc NAME
DirectPath corresponds to the graph theory term "direct path" of a leaf with the root
"Direct path" is still a thing, and the object in question here operates along a direct path, but I think "UpdatePath" indicates more clearly what it's doing.


Rotating keys is important and in some cases, Signature Keys are not going to be very "long-term". Instead they're going to be rotated periodically. I thus propose we simply remove the assumption that Signature Keys are of a "long-term" nature (or otherwise "long-lived"). The second change in this PR is that I added a few words indicating explicitly that the identity must not change when updating a KeyPackage.


The unsigned PublicGroupState created by leads to an attack on the new joiner. The sender of a GroupPublicState can associate any HPKE it wants with the group, and thus learn the without being a member of the group. (The UpdatePath and the resulting partly defend against this attack, though they are subverted if the attacker has compromised any single key used in the Update Path.) To guard against this attack, this PR adds a signature over the HPKE public key in the PublicGroupState.
In light of the feedback on the mailing list from NAME re: deniability, I have upgraded this PR to sign the whole PublicGroupState.
Outstanding issue: One detail that is not fully covered by is the strategy new joiners should apply to determine who the latest committer is and make sure that both the and the last Commit are signed by the same member.
The last node to send an UpdatePath is the last one to set the root. So you can follow parent_hash to find which leaf it is. But like I said on the IETF meeting call, I don't think we should actually require that PublicGroupState be signed by the last updater. There are possible operational/sync issues if the PublicGroupState isn't fate-shared with the Commit, but that's a practical issue, not a security issue. And in any case, it's not a breaking change, so we can fix it post-draft-11 if we decide we need to.
Please fix the link on the repo page to display diffs between the current editor's draft and the WG draft. Now, it should PRs comparing back to the -00 version.
NAME Any change you could have a look at this when you have some time ? : )
Yeah, I'm gonna fix the CI and I can take a look at this as well. I tried to get it done before the interim but, well, excuses excuses
Ahah... ;) No problem!! Thanks !
NAME -- last call on this, or i'm just going to close it
Sorry. As you will have guessed, this fell through the cracks. I'll try this week to fix it out and close it out if I don't get to it this weekend :/


In preparation for feature-freeze / post-first-WGLC living, this PR removes a few issues that have been discussed and pretty much resolved. It leaves a few OPEN ISSUES that could benefit from analysis during the feature freeze.


Discussed at 20210526 Interim. Merge.
Good point about allowing PSKs in a partial Commit!


draft-08 is the latest HPKE draft, which should be stable. It is also what's being used for interop testing right now.
Discussed 20210526 Interim: Merge.


NAME NAME r?
Discussed at 20211004 interim, remove resynch with a single op (external join + remove in one op). NAME research why resynch was dropped.
A good point was raised by Jonathon Hoyland during the MLS IETF 109 meeting regarding possible concerns in using external commits for resync, particularly in the case of Alice adding/removing herself. Richard noted that this is a feature in the case that Alice is no longer synchronized with the group and therefore can use an external commit to add herself back in, removing the previous version. As opposed to any newcomer joining with an external commit, the case of Alice re-joining presents a potential security issue. Namely, as currently specified (in my reading of the draft), an existing group member, Bob, has no means to distinguish between the following cases: 1) Alice needs to resync and therefore performs an external commit and removes her prior version. 2) Alice’s signature keys are compromised (it is not necessary for the adversary to compromise any group state). The adversary performs an external commit in Alice’s name, and then removes her prior version and impersonates her to the group. One might hope that Alice notices that she is removed and communicates this to the group members OOB, but it is also possible that that she assumes some other reason for the removal, is offline, or simply is not active enough to take action for a fairly long compromise window. Even if she tries to use an external commit to get back into the group and then removes the adversary-as-Alice, there is no means for other group members distinguish the real Alice from the adversary-as-Alice and the process could be circular (until new valid identity keys are issued). While a newcomer is a fresh source to be trusted or not, Alice has been “healing” along with the group and the above option (2) allows the adversary to bypass all of that. The source of the problem is that when Alice re-syncs, she is not providing any validation of being the same/previous identity, so it is easy for other group members to accept that nothing more than a resync has taken place. Thus, a fairly straightforward solution is to require PSK use in cases where an external commit is used for resync. By enabling a PSK derived from a previous epoch during which Alice was part of the group to be injected with the external commit, Alice provides some proof of prior group membership and we avoid the total reset. This is not quite PCS in that the attacker is active following compromise, but it is a linked case. As such it is important that a conscious decision is made regarding this (either as a slight change before the feature-freeze in line with the other changes that the editors have proposed, or as a working group decision to close the issue as out-of-scope).
Just to think this with what has been discussed on the mailing list: will give members a way to do the distinction mentioned above.
NAME - I don't think that's actually the case; it would only allow the members a way to recognize that Alice is replacing herself. I think the right answer here is what Britta suggests, plus a little: We should enumerate a few specific constraints on the proposals that can be carried inline in an external Commit: There MUST be an Add proposal for the signer There MUST be an ExternalInit proposal There MUST NOT be any Update proposals If a Remove proposal is present, then: The identity of the removed node MUST be the same as the identity in the Add KeyPackage There MUST be a PSK proposal of type , referencing an earlier epoch of this group In other words, you can commit things that existing members sent (by reference), but the joiner-initiated proposals must only (a) add the joiner, and (b) optionally remove the old instance of the joiner, with the PSK assurance NAME suggests.
Coming back to this after a few weeks, I'm actually not sure this is a problem worth solving. The attack scenario (2) exists whether or not a member can resync without proving prior membership. As long as (a) the group allows external Commits, and (b) the group does not require a new appearance of an existing identity to present a PSK from an earlier epoch, then the attacker can still do the attack by first joining, and then removing the old Alice. The only difference in the case where the external commit also does the resync is that the two happen together. It also doesn't seem unreasonable to regard the ability to resync from loss of all state except the signature key as a feature, not a bug. Of course, that position would entail accepting that compromise of signature keys would be sufficient to impersonate the user, but that doesn't seem all that surprising, at least to me. So this seems like a question of group policy to me. Either the group requires ReInit PSKs on resync (and you can't recover from all-but-signature-key state loss), or it doesn't (and signature keys are the last resort). This can be documented in the Security Considerations, in a new PR. As far as , I think it's probably still worth adding the precision, but I would change the PSK part to MAY if not remove it entirely.
There is also a practical issue with using PSKs to prove past membership, in that if there have been joins since Alice lost state, the new joiners won't have the PSK. This is of course a general issue with the proof-of-past-membership PSK, but it is particularly salient here.


This PR adds a RequiredCapabilities extension that allows the members of a group to impose a requirement that new joiners support certain capabilities. The extension is carried in the GroupContext and verified at Add time (including on external commits). In the interim 2021-10-04, we briefly discussed whether this mechanism needed to be included in the core protocol. Because of its interactions with Add and GroupContextExtensions proposals, it seems worth having in the main protocol.
s currently have two usages in the spec: Pre-published key packages that you can download and put in a leaf when adding a new member leaf node content that you update when doing a full Currently, things have been designed to use only one structure for both uses, leading to some weirdness such as: and are useful in the usage 1, but are parameters of the group in usage 2. is a good name in usage 1, but would better be named in usage 2. some data is important in usage 2 and have no meaning in usage 1, hence they were designed as "mandatory-when-updating extensions" (such as , and we were also discussing about adding the in to help prevent cross-group attacks) How about using different structures for these? // Essentially identical to KeyPackage struct { ProtocolVersion version; CipherSuite ciphersuite; HPKEPublicKey hpkeinitkey; opaque endpointid; Credential credential; Extension extensions; opaque signature; } PrePublishedKeyPackage; struct { HPKEPublicKey hpkekey; opaque endpointid; Credential credential; opaque parenthash; opaque groupid; Extension extensions; opaque signature; } LeafNodeContent; enum { reserved(0), prepublishedkeypackage(1), leafnodecontent(2), (255) } LeafNodeType; struct LeafNode { // This is not included in the signature, but with the "unambiguous signature" PR that's not a problem LeafNodeType type; select(URL) { case prepublishedkeypackage: PrePublishedKeyPackage data; case leafnode_content: LeafNodeContent data; } } What would you think about refactoring like this?
If we're doing this, I'd suggest including a dedicated public key to encrypt Welcome messages to for the . NAME suggested this at some point. It gives us better FS guarantees, because the receiver of the can delete the corresponding private key immediately after decryption, while they might have to keep the other key around for a bit until they can actually issue an update. This might also help clarify .
Ties into as well because is an example of an extension that is required and should be a field instead
NAME one concern I have is how is that field in created?
When sending a full , the participant includes a new in the (it replaces the field). It computes the signature with where: corresponds to all the fields of except (the usual thing) comes from
What about the scenario where Alice pulls down Bob's key package to add him to the group? In that case Alice can't do the conversion between formats on Bob's behalf.
Alice don't have to do the conversion, this is why either contain a (when adding someone to the group) or a (when updating your own key package).
Ah somehow I missed that part in your original post. Makes sense
I like this general direction. It solves a few things. Instead of having leaf nodes contain either a prepublished thing or a normal leaf node, how about having the prepublished thing wrap the leaf node thing? As a bonus, we get separation between the key pair used for Welcome encryption and the key pair that goes in the leaf for TreeKEM. Then when Alice adds Bob, she extracts his LeafNodeContent and sends that in the Add. That doesn't let the other members of the group verify that Alice did the right thing w.r.t. expiry, but I'm not heartbroken about that. We might also be able to remove the extensions field from the outer (KeyPackage) wrapping if we turn the extension into KeyPackage field. I expect we probably need leaf extensions, but would be open to making into a field.
Why not keep sending the KeyPackage in the Add? That wouldn't cost much and would allow everyone to validate the lifetime. Note, that the lifetime is crucial in achieving PCS for pre-published key material. If I compromise Bob and get hold of the private key material of a bunch of his KeyPackages, I can add "Bob" to any group I want as long as the Credential inside the LeafNodeContent remains valid and Bob doesn't revoke the LeafNodeContent somehow. Also, we'll have to do this if we want to enable any member to send the Welcome message as you proposed here: URL
I agree that including inside is quite clean, but something is bothering me with this approach: I'd like that the is signed by the participant occupying that leaf, to protect against cross-group attacks. In the first message of this issue I did this by including in , but in fact we don't need to store it in the leaf, we just need to include it in the . In any case, if we want to include in the signature, we need a way to differentiate between leaves that triggered a commit and the ones that are "fresh". And for that I think using a tagged-union struct is the cleanest way to do it.
It always feels a bit lazy to use an extension (and implementations have to be careful to check for their presence), but we could use a extension in the same way that we use a extension. You will find both of them only on LeafContents that were updated at least once. Another result of including GroupId in the KeyPackage is that the signature will explicitly sign the and I'm not sure if that doesn't completely destroy any deniability guarantees we can still get from MLS.
I don't think there's really a good way to get the into the leaf. Because of prepublication, it would have to be optional, but in order to prevent attacks, you need rules to decide whether it's required in a given situation. It seems like the best you can do is basically TOFU: When you first get the tree, you can't validate whether the groupid should be in a given leaf or not Once you're a member, you require that groupid is sent in Update and UpdatePath.leafkey_package I could live with a solution of that character, but given it's a bit complex, might prefer to leave it out unless we get a useful property from it. NAME - Re: Sending KeyPackage in Add - Yep, that makes sense. So you would send KeyPackage in Add, and LeafNode in Update.
I tried to worked through what would be necessary to implement this. It looks like it would require some fairly invasive changes to be made to rationalize the document's structure before making this change. But those changes should probably be made anyway. Proposal: Preparatory PR: Rationalize layout Move "Cryptograhic Objects" to before "Ratchet Trees" Update "Ratchet Tree Nodes" to define ParentNode and LeafNode structs, with LeafNode initially just equal to KeyPackage Move subsections of "Key Packages" to under "Ratchet Trees" Parent Hash Tree Hashes Update Paths Move Group State to its own top-level section Main PR: Change LeafNode to have the required content: HPKE key for TreeKEM Credential Parent hash Capabilities Extensions Signature Change KeyPackage to refer to LeafNode for internals, plus: HPKE key for Welcome Lifetime Extensions Signature Add continues to send KeyPackage Update and Commit send LeafNode instead of KeyPackage Remove and Sender refer to LeafNodeRef instead of KeyPackageRef We should probably do the preparatory PR regardless of this issue.
Discussion on working call: General agreement on the approach Should sign group_id when possible Include in TBS if we at least have a flag for pre-published / in-group Or we can store it Or we could have independent structs for pre-published / in-group leaves Do we need extensions at both levels? Capabilities / lifetime should probably be promoted to fields
Many protocols which have an extensibility mechanism have a way to indicate that understanding an extension is mandatory for certain behaviors. For MLS, this would mean having a way to require a member understand an MLS extension before it can join a group. The three extension types defined currently are: MLS ciphersuites, MLS extension types, and MLS credential types. One logical way to add mandatory extensions would be to pick one of these types (the MLS extensions type) and use the high order bit or a specific range to indicate that a member must understand and implement the extension to join a group which uses that extension. The IANA values could be changed as follows: Values from 0x8000-0xffff indicate understanding the extension is required 0x7f00 - 0x7fff Reserved for Private Use (not required) 0xff00 - 0xfff Reserved for Private Use (required) If a required ciphersuite or credential becomes necessary, a new extension type could be created to add an extension in the KeyPackage or GroupInfo which would be required and would indicate support for the mandatory ciphersuites or credentials. In order to prevent some other entity from adding an MLS client that does not support a mandatory extension, we already have the KeyPackage Client Capabilities, which lists which extensions are supported by the client.
Note that though this might seem "now or never", I don't think it really is. Consider TLS by way of analogy -- it has no mechanism for specifying that extensions are required. But if a server gets a ClientHello that is missing some extension that it requires, it can just abort the handshake. Likewise in MLS, the member adding a new joiner to the group can examine that joiner's KeyPackage to see if they support the extensions needed for the group. So I think you could implement this as a non-mandatory GroupContext extension, which would state the extensions required by the group so that all members apply the same requirements for new joiners.
While you can implement this "out-of-band", that makes it implicit rather than explicit behavior.
Discussed at 20211004 interim, liked this functionality. But, instead of IANA registry use field (or extension) in group context to indicate which extensions are required. NAME to generate PR.
Discussed with NAME and incorporated this functionality into PR


Right now, the vector is described in a couple of ways. This PR standardizes on "of length ".


Any Update proposal for the sender is redundant if the Commit includes a .
This is true, but they're also harmless, since the information in the will overwrite all of their effects. Note that: A requirement to this effect would only be binding on a committer. The receiver of a Commit MUST process all of the referenced proposals, as prescribed in the Commit. A is required if a Commit covers Updates or Removes; if a Commit covers a self-Update, then it must have a . So there's no reasn to condition on "if a is included". This seems fine for some advisory text, but not an absolute prohibition.
The way I read Section 11.2 is that the receiver should verify that the committer has followed the rules, e.g. that the commit contains all valid proposals, etc., even if that is not explicit in the list of things the receiver of a commit should do. So any requirement on the committer would also affect the receiver. So if we mandate that a committer can't include self-updates if the path is populated, then it would be implicit that the receiver checks that the committer actually followed the rules when processing a commit. I'm not sure I understand your second point. My reasoning would be that if a committer wants to do an update, they would just include a path rather than an update proposal, which is redundant anyway.
Sorry NAME I missed that there was still conversation going on here before merging . On the latter point: All I'm saying is that there is no case where there is both (a) a self-update and (b) no . So you're always in the bad scenario :) In our Wire chat, you made a good point that repeated proposals for the same leaf are invalid, and self-Updates are effectively repeats of the . Reopening, will file a fresh PR to adjust the text.