[anonsec] AD Review: Probably and Applicability Statement

[mcr at sandelman.ca (Michael Richardson)]

Sam Hartman wrote:
> I wonder if the working group has adequately reviewed section 5.7.  In
> particular do we actually have a strong consensus that caching of BTNS
> credentials is inappropriate?  We certainly have a lot of issues to
> work through before we can recommend this caching.
> But if there is no caching how is that leap of faith at all?
> 
> If there is such a consensus then Section 5.7 should be removed and a
> section added to the applicability statement saying that leap of
> faith/credential caching is out of scope.

(re-reads 5.7)
I think that we wish to retain it.

btw, I think that s/SSH/implementations of the SecSH protocol/ there.

5.7 doesn't really tell me whether I'm allowed or encouraged to cache 
credentials. Remember that a ssh client gets to interact with the user, while 
the IPsec IKEv* usually does not. This is the point of the table, but perhaps 
that point is lost.

Finally, the decision to cache the credentials for next time is something
a compliant implementations could do as a "local matter". Where it matters is 
whether we have any mechanisms for invalidating the cache, or indicating that 
records should be purged. SSH started without that. It now has provisions to 
do that via a DNSSEC authenticated SSHFP record.


> and multihoming worse.  IN particular think about address selection
> for inner addresses with anonymous open services and show that this
> problem is not worse in a BTNS universe.

   Yes, I asked this question several times in person and on the list,
and the consensus was that BTNS would not function with IPsec NAT-traversal, 
because we didn't know what to propose for the inside (CHILD_SA).