[anonsec] comments on the BTNS core I-D

kent at bbn.com (Stephen Kent) Mon, 30 July 2007 17:50 UTC

From: kent at bbn.com (Stephen Kent)
Date: Mon, 30 Jul 2007 13:50:57 -0400
Subject: [anonsec] comments on the BTNS core I-D
In-Reply-To: <20070730171551.GI1199@Sun.COM>
References: <p06240505c2cd5414684e@[]> <f89aup$pa$1@sea.gmane.org> <p06240508c2ce6ce745e0@[]> <f8as41$dt0$1@sea.gmane.org> <p06240507c2cfef99ae12@[]> <20070730154751.GC1199@Sun.COM> <p06240518c2d3bdce3f9f@[]> <20070730171551.GI1199@Sun.COM>
Message-ID: <p06240521c2d3d0acab9f@[]>

At 12:15 PM -0500 7/30/07, Nicolas Williams wrote:
>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).

Do you even have a copy of "Strunk and White" on your bookshelf?

>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 :)

That's a good argument too, and if that's the one that will cause 
this text to be changed, I'll buy into it :-).

>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"?

no, I meant to "note that here." Just a single letter typo :-).

>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).

Then perhaps the text should define a BTNS entry more clearly, near 
the beginning, and discuss the "catch-all" BTNS entry as a special 

>  > 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.

You're welcome.