Skip to main content

Resource-Oriented Lightweight Information Exchange (ROLIE)
draft-ietf-mile-rolie-16

Yes

(Kathleen Moriarty)

No Objection

(Alia Atlas)
(Alvaro Retana)
(Mirja Kühlewind)
(Spencer Dawkins)
(Suresh Krishnan)

Note: This ballot was opened for revision 10 and is now closed.

Alexey Melnikov Former IESG member
(was Discuss) Yes
Yes (2017-11-16 for -14) Unknown
Thank you for addressing my DISCUSS points.

I talked to Mark Nottingham about use of RFC5005 link relations and he explained that I was mistaken. However we agreed that slightly modifying link relation definitions from RFC5005 is not the best thing.

I am still concerned that user authentication is under-specified, but I can live with existing text.
Kathleen Moriarty Former IESG member
Yes
Yes (for -10) Unknown

                            
Adam Roach Former IESG member
(was Discuss) No Objection
No Objection (2017-11-15 for -14) Unknown
Thanks for addressing my discuss points and comments.
Alia Atlas Former IESG member
No Objection
No Objection (for -11) Unknown

                            
Alissa Cooper Former IESG member
No Objection
No Objection (2017-10-25 for -11) Unknown
The schema registration in Section 8.1 says "See section A of this document." I think you mean Appendix A? Also, as with Ben I don't understand what it implies for the schema to be informative.

Section 8.3 says "Designated Expert reviews should be routed through the MILE WG mailing list.  Failing this, the Designated Expert will be assigned by the IESG." Might it be better to assign a back-up designated expert at the time of the document's approval, so that we don't end up in a situation of prolonging a registration delay by having to find and approve an expert after the WG mailing list has proved unresponsive?
Alvaro Retana Former IESG member
No Objection
No Objection (for -11) Unknown

                            
Ben Campbell Former IESG member
(was Discuss) No Objection
No Objection (2017-11-15 for -14) Unknown
Thanks for addressing my DISCUSS points and other comments!
Eric Rescorla Former IESG member
No Objection
No Objection (2017-10-20 for -11) Unknown
OVERALL
I share Martin Thomson's concerns about the restriction on 0-RTT. In
the discussion, I saw two sets of concerns about 0-RTT:

- Replay
- Lack of FS

As Martin says, the replay issue is an issue for the HTTP profile, so
any concerns should be directed there. I agree that 0-RTT has inferior
FS properties, but it's worth noting that TLS 1.2 session resumption
with tickets has FS properties that are as bad or worse than those
with TLS 1.3 0-RTT, and I don't see a prohibition here on session
resumption. This leaves me a bit unclear on the security rationale
here, and I think this needs to be consistent.


INLINE COMMENTS
      or serialization.  This approach allows the provider to support
      multiple, compatible formats allowing the consumer to select the
      most suitable version.
What does "compatible" mean here. Do you mean isomorphic?


   supporting interactive user logins by members of the consortium
   SHOULD support client authentication via a federated identity scheme.
Such as?


   Proper usage of TLS as described in Section 5.3 will in many cases
   aid in the mitigation of these issues.
You should also note that TLS 1.2 and lower client auth leaks the user's identity to on-the-wire attackers.


   supported.  TLS 1.2 SHOULD be implemented according to all
   recommendations and best practices present in [RFC7525].
You need a citation to 6125 about valiation, though I realize that 7525 cites it.
Mirja Kühlewind Former IESG member
No Objection
No Objection (for -10) Unknown

                            
Spencer Dawkins Former IESG member
No Objection
No Objection (for -12) Unknown

                            
Suresh Krishnan Former IESG member
No Objection
No Objection (for -11) Unknown