All,
On Mar 21, 2007, at 2:22 PM, ext Marc Silbey wrote:
As promised I've included our comments and questions below on Access
Control. The draft looks very good and the below comments are
minor. I'm
looking forward to discussing these in further detail.
On March 21 the WAF WG discussed Marc's comments during a Voice
Conference. Below are the minutes from that discussion.
Regards,
Art Barstow
---
Attendees (ordered by first name): Anne van Kesteren, Art Barstow,
Brad Porter, Cameron McCormack, John Hrvatin, Marc Silbey, Marcos
Caceres, Matt Oshry, Thomas Roessler
Scribe: Cameron
Chair: Art
Discussion:
AB: mark sent some comments to the public list today
... use these 45 minutes for those comments
MS: i'm new to standards body work, so if we need more time to go
through the comments, it's cool
... not surprsiing comments, just minor
... i don't know if we want to spend the time here on them? or maybe
the editors can go through them and comment?
AB: we could go through comment by comment, but have brad/anne had a
look?
<art> http://lists.w3.org/Archives/Public/public-appformats/
2007Mar/0011.html
AV: will brad still be an editor?
BP: no matt will be
AV: didn't seem controversial, except the one that said post was
safe
... the most complicated one is 17, which proposed chnages to the
algorithm. thomas had some comments too about how deny/accept works.
... other than that, it's not just for scripts. cross-site xslt or
something could be a use, too.
... that would change comments 1 and 2
... i already made changes to the nonpublished draft. i don't know
about changing "XML" into "resource", should check that.
BP: maybe we can just go through the issues you see
AV: yep
... thomas do you want to tell them?
TR: the ones that jump out at me are that some people can argue post
is as safe as get, and would be useful
... more discussion on how/when resources can be POSTed
... other is comment 11, where you propose a rewording " [...] allow
and block list "
... those lists aren't in the spec now
BP: block should be deny, sorry
TR: that suggests allow/deny statements are on the same level
... but the current approach is as discussed at the F2F at the TP,
process the allow rules, then the deny rules is scoped by the
preceding rule
... [reads out some text from the draft]
... i'd oppose that change, since it amounts to a different
algorithm
AV: can you give a concrete example where it would differ?
TR: the current approach you can say: allow from *.com except
example.com
... then another rule: allow from a.b.example.com except
www.example.com
... but that except www.example.com is scoped to the "allow from
a.b.example.com"
... so the pairs can be treated in arbitrary order, and that maps
back to the syntax considerations that you get in HTTP headers
... and when you combine the headers
AV: since they're in pairs you can simple rename one to deny
TR: i agree
... the proposal goes beyond that, as i read it
... it's not very clear to me, the current wording defines some
terms
... the proposed rewording doesn't do that
MS: we could remove that sentence there
TR: let's have another look at what that says
MS: should be what's in the spec today, but changing except to deny
AV: i definitely got more comments about "except" being more
annoying than "deny"
TR: i can live with that, as long as the hierarchy is clear
MS: remove the allow and block part
AV: a resource that has the AC policy enabled, consists of a list,
which has tuples, each tuple consists of two lists
<matto> tuple
AV: a tuple represents a set of AC rules, within the tuples you have
an allow list and a set of deny domains
... when you request a resource, you go through all the tuples with
the request domain, see if there's a positive match and no negative
match
... no i'm saying it wrong
... the deny clause only applies if there's a positive match first
MS: that'd be secure by default, right?
AV: that you can process the deny and allow rules in any order, is
not correct
... only if the allow clause says it's ok will you check the deny
rules
TR: can we jump to the matching alg in sec 3 in the WD?
... the numbered item 3 is in the inner layer
AV: hmm?
TR: [reads text]
AV: you run the subalgorithm for each AC rule
TR: number 3 is part of that
... why is that neccessarily correct?
AV: i agree we should redo the numbering, it's confusing
<marcsil> * marcsil switch MS for BP starting with "maybe we can
just go through the issues you see"
TR: you can have 3 on either level actually, it doesn't matter
MS: examples would be good, since it's complex
AB: in order for this spec to get out of CR, we should have some
exhaustive test cases too
... satisfied with that comment?
TR: agreement about comment 11
AB: did you have another comment to raise now?
TR: i only see the comment half an hour ago
AV: I do think the alg in 3 is wrong
... because step 2 should only be executed if step 1 was a match
<tlr> ACTION: anne to fix step 2 in the matching algorithm to only
apply if step 1 matched
<trackbot> Created ACTION-74 - Fix step 2 in the matching algorithm
to only apply if step 1 matched [on Anne van Kesteren - due
2007-03-28].
AB: another level of indentation?
AV: probably not, make another variable or something
TR: i'd suggest go away from numbering it all. "if there is a match
for an item from the allow rule set, then 1. ..."
... move it closer to pseudo code
... would marc mind going through the EBNF in comment 12?
MS: i can try!
... i got this from one of the networking guys, who works with EBNF
for a while
... adding the scheme/port specifier, that's so that it's explicit
there
... the first comment on the access item is just adding those
specifiers
AV: currently the port can't be a wildcard
... same for scheme
MS: when we talked about this we got agreement, if you're going to
trust the entire domain, you can probably trust all of the ports on
it
... it made sense to just be more flexible, to say trust the whole
domain regardless of the port
AV: not sure if it makes sense for scheme
... for http vs https it does
... but if you wanted to be secure you'd put in https
MS: if you're trusting any site, you should trust any port on the
server
... similarly for scheme
... just be more flexible
TR: another one: removal of examples that match your additions?
MS: the example is about an error, no you shouldn't block these
examples
AV: hjow is the first one allowed?
... it's already conforming
... the first example in comment 14
<tlr> " We're concerned that allowing "example.*" wildcarding maybe
unnecessarily flexible and lead to mistakes by web developers"
TR: the conforming/nonconforming examples are spread through
... you don't want example.*, but you want to keep overall
asterisks?
MS: confused
... allowing example.*, it's not specific enough
... a web dev using that may be trying to mean something but
unintentionally opens a hole
... the *.* is similar to that
TR: *.* is similar to that, but you are permitting an * as an access
item
MS: that makes sense, but if you're going to allow asterisks plain,
then it's safe enough for anyone
... when getting more granular you get more flexible, but more
dangerous
AV: last part of the domain has to be a label?
MS: i personally think so
... if we can find an example where that's not true, i'm ok in being
convinced otherwise
... i might have a domain and lots of different schemes
AV: you don't always own all of the top level stuff
TR: there's an org that might add to them
... i'm inclined to agree with it
... broad wildcards are easier to understand, makes sense to me
... smoke it out further in last call
AB: any other views?
MS: might be helpful if there are other WGs to run this by
... maybe in LC, but would be good to get input from other folks
AV: does the provided EBNF solve the issue?
... domain should be label?
TR: no it should be domain...
... label has no dot in it
AV: the last part has to be a label, and the last part is labels
separated by dots
... the last part of the domain pattern has to be a label, the rest
is wildcardlabel separated by dots
... i'm wondering if the EBNF is correct
<tlr> [12]http://ietf.org/rfc/rfc1034
[12] http://ietf.org/rfc/rfc1034
<tlr> <domain> ::= <subdomain> | " "
<tlr> <subdomain> ::= <label> | <subdomain> "." <label>
<tlr> <label> ::= <letter> [ [ <ldh-str> ] <let-dig> ]
TR: domain can be a sudomain or a space
... so i guess we should be using subdomain
MS: trying to allow a star-style wildcard, again it should be
flexible
TR: that's not the question here. the EBNF in the comment refers to
domain from RFC1034, which expands to space or subdomain
... i believe you mean subdomain
... it's a label or a concat of a subdomain "." label, according to
the ebnf in rfc1034
... i don't think you're aiming to allow a space character there?
AV: i don't think subdomain is the right one
TR: in your view which one is right?
AV: a new one
TR: back to reqs discussion
<tlr> www.*.example.com
TR: you want to allow such examples?
AV: this was mainly about the top level domain not being empty or *
MS: *.example.com should be ok
TR: do you want to allow wildcard somewhere in the middle?
... i hear anne proposing that the pattern be able to match
www.*.example.com
... and the syntax that marc proposes would not allow that pattern,
but only *.example.com
... wouldn't be able to have an additional prefix
... personally i don't really care either way, slight preference for
whatever is simpler
MS: what do you prefer anne?
AV: you didn't want to allow toplevel domain to be wildcarded
... i thought that would be a required part
... your proposal only allows * before a certain domain?
MS: you should be able to star subdomains
... are we agreeing?
TR: no you're not
AV: you should be able to say person.*.example.org
... the * in the current proposal only allows one level, it's not a
complete wildcard
... only matches a single label, which should be clear from the
matching alg
MS: is the "person" a "www" or really a subdomain?
... when would you use that?
ftp.au.debian.org
CM: debian mirrors have that form
MS: i'm ok with allowing that if there are actually scenarios using
that form of domain
TR: you now are agreeing, anne to propose new EBNF?
... marc, comment 13 is uncontentious, 14 follows on
... the question about 2.1 is well taken
... and anne needs to fix the bnf and the examples
<tlr> ruleset ::= rule (LWS? "," LWS? rule)+
TR: that's the current bnf
... that one is wrong
<tlr> ruleset ::= 1# rule
TR: we originally wrote it like that
... a mistake when transforming it to EBNF
... i agree on 15
... 16, that deny rules take precedence over any allow rules: this
one would again ...
AV: allow/deny rules are paired
TR: 16 would lift that pairing, and i'd rather keep it
MS: we should just clarify that
... it isn't that deny takes precedence over allow?
TR: denies are scoped to one particular allow rule
MS: the comment should clarify that overall, if there is a deny,
then it takes precedence over an allow
AV: by default, access is denied. then go through each tuple. for a
given tuple, if allow rules say it's allowed, only then check the
deny rules in that tuple. if those deny rules say it's denied,
overall access is denied.
MS: right
AV: if the allow rules don't say allow, but the deny rules might
still match, you just go on to the next tuple
MS: "deny rules take precedence over their paried allow rule"?
AB: make it more explicit
AV: more examples
MS: a summary at the top, to make it clear
AB: time check, need to do 2 extra things
... we could continue this discussion next week?
MS: just comment 17 left
TR: i wouldn't object against getting 17 done today
AB: we'll resume this discussion next week
... can do more discussion on public list too
