Subject: [anonsec] Comments on applicability statement

From: touch at ISI.EDU (Joe Touch)
Date: Mon, 05 Dec 2005 16:36:05 -0800

Sam (et al.),

Below is a summary of how we addressed your feedback from 8/9/2005 on
the draft-ietf-btns-prob-and-applic-00.txt. Let us know if any of these
issues should remain open.  This refers to feedback on 00 as applied to 01.

Pending updates (open issues) are noted as [PENDING UPDATE #...]

FYI, updates 1-7 address private feedback from the first round by others.

Joe

- ----

Summary of pending updates from this email:

#8 replicate applicability statement for SAB and CBB

#9 address IKE vs. CBB comparative strength
   (number of vulnerabilities, level of protection provided)

#10 clarify S-CBB self-signed SSL example
    (host in URL matches host in certificate)

#11 clarify HTTPS and channel binding example

#12 Sec 4 (now 5 in v01) replicates disussion;
    is there a better way to handle this?

#13 Sec 5.3 (now 4.2 in v01) should use ssh
    rather than SSL as leap of faith (examine and address)

#14 Sec 5.2 (now 4.2 in v01) discusses leap-of-faith
    need to discuss this on the list further
    (as per discussions in Vancouver)

- ----

Sam Hartman wrote:

> Overall I think the document is fairly good.  I do have a few comments
> I am submitting as an individual.
>
> Large concerns:
>
> Section 3.  Please sjeparate the applicability statement for SAB and
> CBB even if you need to duplicate text.  I think this will make it
> much cleaner to evaluate when considering whether protocols meet the
> applicability statement.

We had debated whether we agreed this was useful to do, but now concur
it probably is, esp. regarding applicability to upper layer protocols.

[PENDING UPDATE #8]

> I don't tend to agree with the assertion that IKE is stronger than
> CBB.  That depends entirely on what's going on; I can think of
> situations where CBB is stronger and situations where IKE is stronger.

I believe we had addressed this in -01. The term "strong"
was removed because the table was not intended as a comparison
of "strength" which as I understood was mostly used in comparing
cryptographic algorithms. The subsequent paragraph we attempted
to qualify the comparison: (from -01, right before 3.1.1)

  "The following is a discussion of each of these use cases.
   Vulnerabilities and benefits are discussed in later subsections
   of this section separately. The labels in the table are organized
   by the least authenticated side, where SAB is the least secure
   because it uses no authentication, CBB is more secure because
   it uses authentication external to IPsec, and IKE is the most
   secure because it relies on integrated authentication. Note that
   the measure of least/most secure is based solely on the integration
   of authentication in these labels, and does not consider the
   comparative strength of various authentication algorithms."

We're currently deveoping a further revision to address exactly how
IPsec and CBB would differ in terms of the protections provided.

[PENDING UPDATE #9]

> I don't understand how s-cbb has anything to do with self-signed certs
> and websites.

There are two ways to interpret how self-signed certificates work in
websites. In one case, they're self-signed and unchecked. However, most
implementations require that the application allow the override to
accept the self-signed certificate. There's no difference between the
application 'deciding to allow all unsigned certs' (as a webserver
typically does) and the application asking the user to check the
contents of the certificiate manually. In both cases, the lower layer is
asking the upper layer to accept the certificate; the lower layer has no
way of knowing how deep the upper layer inspection was.

This is NOT the same as just accepting the unsigned certificate at the
lower layer. I.e., the host in the URL is required to match the domain
in the certificate.

(this should be made more clear than the 00-01 update provided)

[PENDING UPDATE #10]

> I actually don't understand how https is similar to cbb at all in that
> there is no channel binding.

The binding occurs at the socket layer; even though there is no official
API, one has been implemented that allows the verification exchange.

[Part of PENDING UPDATE #10]

> I'm not sure that section 3.1 makes a good applicability statement.
> In particular, it does not easily answer the two questions I would
> expect from an applicability statement.  As an operator considering
> deploying BTNS, is BTNS appropriate for my use case.  As a protocol
> designer considering relying on BTNS, is BTNS appropriate for my
> needs?  I wonder whether we really need to break out all the
> asymmetric cases.  Instead I think it might be useful to focus on the
> capabilities of a peer.  That way you would need to describe when it
> is acceptable to set up an association with an anonymous peer (SAB
> applicability statement) and when it is acceptable to set up an
> association to a peer you will bind at a higher layer (CBB
> applicability statement).

Added sec 3.4 to address this point - perhaps that should be the
'applicability statement' section?

We also probably need to change the title of section 3.3 to something
like "modes of BTNS" rather than 'uses'.

[PENDING UPDATE #11]

> Section 4 seems to duplicate a lot of the content I would expect to
see in section 3.

(note - section 4 is now section 5 in 01)

It is intended to provide a summary, rather than a duplication. Is there
a better way to address this?

[PENDING UPDATE #12]

> Section 5.3 .

(note - section 5.3 is now 4.2 in 01)

> I think ssh is a better example for leap of faith than
> ssl.

Agreed - this mod fell off the list with the section renumbering; it
will be fixed in 01.

[PENDING ISSUE #13]

> Section 5.3 should either rule this extension in scope or out of
> scope.  Currently it just mentions the extension but takes no
> position.

Good question - we'll take that to the list, and leave it as a pending
issue for now.

[PENDING ISSUE #14]

> A bunch of small things:
>
> TLS not SSL in description of https.

Done.

> In section 1.1 it seems odd to say that we use IPsec both because it
is widely deployed and is facing deployment challenges.

Done.

> I don't understand why the definition of CBB and SAB belongs in 1.1;
> it seems like we want a section break between the assumptions and the
> description of the two modes of operation.

It's not intended as a definition, but to foreshadow. We don't describe
or define the terms, just the acronyms.

> Please cite a definition for DOS, DDOS and flash crowd.

We're not sure these are needed; they seem to be ubiquitous terms in the
both the security community and elsewhere, and this is not intended to
be an introduction to network security issues.

- -----