[Ietf-not43] CRISP play by play

[April Marine]

And for those of you who just can't get enough CRISP, here are Cathy's
much more detailed notes for a fuller flavor of the mtg for those of you
who could not attend.  Many many thanks to her for her efforts!

A.


Cross Registry Information Service Protocol WG (crisp)

Wednesday, March 19 at 1530-1730
=================================

CHAIR: Ted Hardie <hardie at qualcomm.com>


AGENDA:

Agenda Bashing


Review output from working group last call of requirements draft.
        Andy Newton


Review of method for selecting protocol
        Chairs


Call for volunteers for specific evaluation elements
        Chairs


All other business

        Time permitting, Leslie Daigle will present "IRIS light"; this is
        not intended as a working group document, but relates to
        some of the documents under evaluation.

---

Ted Hardie [TH], working group chair, called the meeting to order.

Blue Sheets to go around.

Introduced Co-Chair: April Marine <april.marine at nominum.com> [AM]

Introduce Ned Freed as IESG responsible person for WG items.

Thank you to Patrik Falstrom [PF] as previous area advisor.

---

Agenda bashing:

None.


Last Call Comments on CRISP Reqts Document - (Andy Newton [AN])

Slide: Missing Text - Comments?

George Michaelson [GGM]: Need to add text defining a bag before you
use the word bag]

[AN]: It is defined in 3.1.13.2

[GGM]: Then need to move it up before it is used.

[AN]: Okay.

Slide: Result vs. Entity (3.2.1)
no comments

Slide: Base Function v. Domain Function

[TH]: Charter is specific to domains; received some
comments to suggest that it would be better to split. One discussion
where the actual changes have not yet been submitted to the list.
Rick - You and Ross are reviewing the document. Any comments?

Rick Wesson [RW]: Didn't have a chance to type up notes, but agrees
whole-heartedly with <one issue -- missed what he said> raised.
Doesn't think Ross is here.

[TH]: Since effective date fell during IETF, extending at least a
week. If anyone means to suggest changes to the reqts, then send
to the list.

[AM]: Coming to Andy or the list?

[AN]: If they come to me, I will send the list.

[TH]: When can we expect them?

[AN]: At least 3 weeks.

[TH]: So, April 15th?

[AN]: Yes.

---

Next item: Method for selecting the protocol (Ted Hardie)

If you haven't read the recent versions of the documents, please
do so. There are major differences since the service requirements
were split out into its own document.

Proposal to the group: the idea has been put forth to evaluate
the documents by first identifying the protocol reqts (MUST, MAY,
SHOULD, etc), then evaluating the implementation documents against
the protocol reqts. If something doesn't meet the protocol reqts,
then it would not be permitted to proceed to service reqts
evaluation. I.e., this staged evaluation process would have a
knock-out principle. If knocked out in the protocol stage, a
document would not proceed to the service reqts stage.

[RW]: Makes sense.

[TH]: Anyone opposed?

<No one vocalized opposition.>

[TH]: Okay, the sense of meeting on how to proceed is noted;
we'll take it to the list.

[TH]: Now, supposing that the WG adopts such a knock-out principle,
how would this actually work? Rick, you previously volunteered to
maintain the matrix that identifies the protocol reqts. Are you
still willing to do this?

[RW]: Yes.

[TH]: Andy, would you develop the matrix of the MUST, MAY, etc
from the reqts?

[AN:] Yes.

[AM]: And send to the list?

[RW]: Yes, please send to the list because everyone needs to agree
whether the actual protocol reqts that need to go onto the matrix
are.

[TH]: Who populates the matrix? Who decides whether it meets the
protocol reqts? Preferably, not the implementer. Also, it would
be good to have at least 2 sets of eyes reviewing the protocol
reqts per protocol. <Silence> If we need to, what about reviewing
just part of the protocol reqts? <further silence>

[RW]: Is this specific to the domain protocol only?

[TH]: Yes. Looking for reviewers...
Leslie Daigle [LD]: Volunteers for LDAP review.

[PF]: If no one is willing to do the review, maybe that is a sign
that the protocol is not ready to proceed.

[GGM]: Not volunteering doesn't necessarily mean we are unwilling,
it just reflects than many have too much to do already.

[TH]: Are the protocols too large to review in their entirety? Is
it better to do by chunks?

[LD]: Would it be easier to review once the matrix is prepared?

[TH]: It's harder to say 'no' in person than on the list.

[PF]: Let me re-phrase: if there is too much to do, is there an
alternative mechanism for evaluating the protocol?

[RW]: Any thoughts about why people might not be willing to step up?

*** Must have missed something here. Next comment does not seem to
follow from previous. ***

[AN]: Not the right thing to do without Eric [Hall] here.

[TH]: Definitely not right to do without Eric.

[PF]: Perhaps the document authors could evaluate their documents
compliance with the protocol reqts and the WG could review the
results.

[LD]: That would certainly ease the pain for the WG members and
at least allow us to get on to the next step.

William Leibzon [WE]: How long would it take to produce the matrix?

[AN]: It would have to be after the reqts document is done. Since
that has been postponed until April 15, the matrix could not be
completed any sooner than that.

[TH]: So it depends on when the milestones are set.

[WE]: I would volunteer, but I am biased in favor of ldap.

[LD]: It sounds like it might be better for the document authors to
fill-in the matrix first, then have the reviewers verify their
findings.

Richard Shockey [RS]: I agree.

[TH]: Is there anyone who disagrees?

<silence>

[TH]: Ask for a hum vote.
   FOR: (those in favor of the document authors making the initial
        review): <vocal hums>
   AGAINST: <no hums>

[AM]: So, who will volunteer to review to verify the authors'
matrix results?

LDAP Matrix Review:
  Peter Gietz
  Richard Shockey

IRIS Matrix Review:
  Ed Lewis
  Scott Hollenbeck

[PF]: Volunteers, if it turns out you don't have sufficient time to
perform the review, please let the chairs know asap.

[TH]: We will also call for secondary reviewers on the mailing list.
We also need to confirm with Eric [Hall] (author of the LDAP
protocol proposals) that he has the time to fill in the matrix for
the LDAP documents, since he has already indicated that he has time
constraints.

[TH]: What sort of target deadline should be set for filling in the
matrix? Unless we just want to say by Vienna?

[GGM]: Good choice.

[LD]: Filled in AND reviewed?

[GGM]: Yes. If you have someone responsible for reviewing, then
it makes it easier to be accountable by deadlines.

[TH]: Do the volunteers agree to that timing? <Volunteers indicate
agreement> Okay, then the matrix will be completed and reviewed
prior to Vienna.

[TH]: Other related topics to the evaluation?

<Silence>

---

AOB?

[RW]: Could we have a discussion about bags?

[TH]: Any particular issue?

[RW]: I still don't understand the term even though I have
read the document several times.

[AN]: At the last WG session, there was lots of discussion re: the
cost settlement issue. The WG decided not to do cost settlement,
but it did want to allow someone to do that with the protocol
if they so choose. Protocol needs to be flexible enough to
facilitate that.

[RW]: Is this about state?

[AN]: For example, the protocol gives back a referral and hands back
a bag which has no meaning to the protocol. What is in that bag is
up to the first server and the reference server. Make sense?

[RW]: It makes sense, but some folks game the protocol. Can't the
client just guess what is in the bag?

[AN]: The bag may contain crypto with the referral, but this protocol
should not go into details about what is in that bag.

[GGM]: So we are allowing from day 1 that cost settlements are
permitted. That is okay, but 3-way conversations are no good;
are you sure you want this in the requirements?

[AN]: It doesn't say what the bag is, only that it can be done.

[GGM]: Doesn't it say that.... (lost track of the conversation) ?

[AN]: No, it only says that the bag is passed with the referral.

[GGM]: Is it still on table, that if a bag is a vehicle for a thing,
then it should say what it is?

[LD/AN]: It could be state, it could be something else. It doesn't
say what it is.

[GGM]: So we just didn't want to call it a cookie?  ;-) implied

[RW]: If this protocol is going to be used for state, or for other
things, we need to go down that path now.

[AN]: We don't need to go down that path. We already went thru that
discussion in Atlanta. We don't want to do escrow, but do want to
allow mechanism where that could be tied in.

[RW]: I think we need to include those (items) in the protocol.

[GGM]: I think we need to say that clients must not change the
contents of the bag and must pass it on cleanly.

[AN]: In reqts and inter-operability issues, what if the service
chooses to use that option (drop the bag): what is missing from
the text?

[GGM]: The text that explains what is going on between the two
parties.

[TH]: That's not what is going on.

[GGM]: I can think of using this as a means of rate-limiting;
this guy has queried 50 times and the bag with the referral
includes a crypto-signed comment warning the referee of this.

[RW]: We would to need to use crypto to make sure the bag is not
modified by the client. Therefore, we need to give some thought
into how that is done.

[AN]: If we start going done crypto path, lots of issues, crypto
versions. The current protocol language leaves it generic enough
that server-to-server can decide what type of crypto to use.

[GGM]: What if there is just enough to prevent reverse engineering
 ... remediated....

[TH]: This is a relay bag, not a remediation bag. The client is
just a relay, not, e.g., a gateway.

[GGM]: Okay, so you do a query with no bag, then get answer with
no bag.

[LD]: Rick, what is it you are driving at? If you are saying we
need to get a lot more specific, that's true. But defining the
protocol this way gets us to the service reqt. Let's put this off
until we deal with that.

Kent Crispin [KC]: Isn't that up to the end user? If the bag gets
messed up by the client, then why does it need to get involved in
crypto?

[AN]: True, client makes the choice of whether it checks the sigs.

[LD]: The language says that the client must pass it on unmolested.

[RW]: If server creates a bag and hands it to client, and if the
client takes the bag out of the referral, can the referral server
know that the bag is missing?

[AN]: Yes? No?

[RW]: ...missed the point...

[AN]: So you are looking for a mechanism to guarantee to the referral
server that the query did not have the bag removed?

[RW]: Yes, exactly! The referral server might want to treat queries
that come as referrals differently then direct queries.

[KC]: I disagree. If the referral doesn't have the bag, then it
doesn't get the value-added treatment that would come with the
existence of a bag.

[LD]: I want to agree, but the failures messages should be different.

[AN]: This is the client monkeying with the bag, and the server has
to take precautions that query is not coming from an abusive client?

[LD]: It needs more thought, but one possibility is that query

(...noise...missed the point...)

[WE]: I support verifying handing the bag with the referral and would
like a way to do it. Referral can be different if we want the bag to
be sent, but that makes it necessary to have two kinds of referrals.

[AN]: If we go into modifying the answer to say whether there is a
bag, then it makes the protocol much heavier because then replies
requires signing.

[WE]: I also want to ask why crypto is not part of the protocol?
e.g., tls

[TH]: TLS is good for certain threat models, but not sure that needed
for the threat model present in this protocol.

[WE]: We might want to use the same protocol for our internal network,
which might require crypto, and use it publicly, which doesn't.

[TH]: The protocol already has the notion that there could be
multiple authorization models.

[WE]: But that does not ensure end-to-end confidentiality threat.

[TH]: So you have a perceived need for e-t-e confidentiality?

[WE]: Yes.

[TH]: Please sent text to the list.

[KC]: You get a referral with a bag, and don't get a bag without
a referral.

[TH]: You might get a referral without a bag.

[KC]: Or you could provide a null bag. But if there has to be some
additional info with the bag, that defeats the purpose of the bag.
Just an observation.

[TH]: The only thing we do need to define in the protocol is idea of
carriage: how the bag gets its contents should not be discussed, but
the integrity of the referral does need to be discussed.

[RW]: My general understanding is that if tags are defined, that
would be done in individual drafts?

[TH]: That, or in private agreements.

[RW]: Okay.

Another thing: in provreg, there is the idea that privacy can be
used at different levels by different actors. Has anyone here
thought about areas , e.g., law enforcement, where certain levels
of privacies are overridden?

Randy Bush [RB]: Why are queries from law enforcment any different
from an access standpoint? They can use court orders if they need
it.

[TH]: The protocol doesn't need to get into details. It's sufficient
that it provides for different levels of access.

Ed Lewis [EL]: Regarding the bag, is the client going to be
penalized for removing the bag? If so, then the protocol will need
to have mechanism to say that it was there.

[AN]: The protocol says that bag should not be stripped.

[GGM]: If I receive a referral without a bag, I can make policy
about what to do with it, e.g., reject all queries without bags.
It is good to push this to the policy space. Sensible.

[AN]: So it is okay to put that it should not be stripped
in the reqts document?

[GGM]: Yes, it's a vehicle for getting stuff done.

[LD]: Please make sure you note Kent's point. If going to make
greater use of the bag, then pull that out and make it more
structured.

[RW]: Can there be multiple bags?

[AN]: The answer is in part of missing text: initial query returns
bag, second query adds to the bag. Or should it return a separate
bag?

[RW]: The problem with the mechanism is pre-knowledge of all
potential bags. If we pass multiple bags, the server could
understand one but not another.

[LD]: Whether we do it as multiple components in one bag, or
multiple bags, does it matter?

[AN]: Do you have a use case?

[RW]: Off hand, I can't think of one.

[LD]: Passing multiple bags might help by maintaining the simplicity
of evaluation of the bags.

[TH]: It could be a security hole if the server has to handle each
bag separately, but that's not a huge problem since it could test
be tested.

[AN]: I cannot think of an appropriate use case.

[LD]: Perhaps if you had one server participating in multiple meshes?

[RW]: Or you could have referral loops, and the size of the bag
could grow. With multiple bags, it is easier to identify and handle,
e.g, if there are three bags versus one huge bag.

[AN]: ... missed response...

[RW]: For instance, a whois query to <>  will provide a referral to
another registrar. In EPP, will have two different parts.

[AN]: I'm not following you.

[TH]: Maybe it would help if you write up and send to the list?

[RW]: Okay. I appreciate the conversation on bags.

***** ADD THIS TO OFFICIAL CRISP NOTES ****

[RW]: Do we have a concept of authority in CRISP?

[AN]: Not really. It just discusses the difference between a
registry and a registrar in reqts doc, but not talking about
anything like hashing.

[RW]: I was only wondering if we have authoritative bit.

[LD]: We do not currently. It could be one of the bits in the
result set.

***** END OF RELEVANT CRISP DISCUSSION *****

----

IRIS lightweight - Leslie Daigle

Draft was submitted right before cut-off.

Slide: What it is.

Slide: Particulars

Slide: Why do this?

Slide: Example - credential registry application

Slide: Potential applicability for IRIS dreg / domain availability

[RW]: It sounds like it is only for authoritative stuff?

[LD]: No, you can do referrals and non-authoritative answers.

[TH]: Let's be very clear that the IRIS lightweight draft does
not meet the charter reqts. If it is something we decide to adopt,
then okay, but it is not currently on the charter. (Just wanted to
re-iterate that point.)

[GGM]: Are you sure that allowing a fast way to check availability
is a good thing? Is that opening it up to social engineering?

[AN]: We already have this; IRIS lightweight just offers a
lower cost to answer.

[GGM]: Certificate load stuff... hate/love udp... why do you want
to get certs in this way?

[LD]: That is out of scope. This is just an example to demonstrate
the IRIS lightweight proposal.