[anonsec] comments on the BTNS core I-D

[Nicolas.Williams at sun.com (Nicolas Williams)]

On Mon, Jul 30, 2007 at 12:27:44PM -0400, Stephen Kent wrote:
> At 10:47 AM -0500 7/30/07, Nicolas Williams wrote:
> >...
> >
> >It was misspelled, and no word is missing ("because <adjective>" is a
> >legitimate English language idiom, as in "Joe was lazy because
> >spoiled").  It is an odd idiom, but one that I'm fond of.
> 
> For standards documents we tend to look for somewhat more formal writing 
> :-).

Sure, but show me that this is not formal (it's harder than you think).

Or did you mean that we want to use a subset of English likely to be
understood by most readers, including those for whom English is not a
first language?  :)  Such an argument wins me over more easily :)

I'll put a note to the RFC-Editor about this.

> > > Second, the text refers to bare RSA key payloads, plural, but I
> >> assume is it acceptable to send just one such payload, right? in
> >
> >It is plural because the nodes will be doing multiple IKE exchanges with
> >many peers thus there will be multiple bare RSA key payloads.
> 
> This is another place where it's better to use singular instances as 
> examples, rather than plural instances.  The use of a plural instance 
> as a subject creates ambiguity in the rest of the sentence, because 
> one cannot know whether the later plural objects apply to each 
> instance of the subject, or are due to the use of a plural subject. 
> That's why I suggested re-writing text from "nodes" to "a node" in 
> other parts of the document.

OK, we can change that to a singular ("A node wishing to be treated as a
BTNS node MUST include a bare RSA key CERT payload.  ...").

> >> A final question re this text: why allow sending additional certs?
> >
> >Because it would allow a node to do better than BTNS with some peer if
> >that peer could authenticate it; the node need not know a priori that
> >its peer can do so.  RFC4306 doesn't seem to disallow multiple CERT
> >payloads, but the structure of the protocol is such that only one AUTH
> >payload makes sense, thus all CERT payloads should use the same public
> >key.
> 
> yes, and it would be appropriate to not that here.

Er, "to not that here"?  Did you mean "to do that here"?

> >...
> >The BTNS catch-all entry must be the last one in the PAD.  There may be
> >PAD entries that match specific public keys -- these must come before
> >the BTNS catch-all PAD entry.
> 
> I agree that a BTNS "catch-all" entry must come last, but that entry 
> is described with two adjectives: BTNS and "catch-all." So, can there 
> be a BTNS's entry that matches a specific PUBLICKEY ID type and thus 
> is not "catch-all?" I think that was Michael's question, and mine. If 

Yes, there can be.  Such an entry could be made as a result of
connection latching (using the automatic IPsec policy editing scheme) or
some leap of faith-ish schemes (not yet defined).

> we say that a BTNS PAD entry is any PAD entry that uses the PUBLICKEY 
> ID type, then syntactically this would allow other than catch-all 
> BTNS entries.

I'll make sure that we distinguish between the BTNS wildcard PAD entry
and others.

For example, the second bullet in section 2 needs a "wildcard" qualifier
to be sprinkled here and there, and another bullet item needs to be
added describing non-wildcard BTNS PAD entries (each such entry must
match a single public key, either by value or by fingerprint).

Thanks for catching this.