[anonsec] Comments on applicability statement

Joe Touch

2005-12-06 00:36:05 UTC

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)

- ----

Post by Sam Hartman
Overall I think the document is fairly good. I do have a few comments
I am submitting as an individual.
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]

Post by Sam Hartman
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]

Post by Sam Hartman
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]

Post by Sam Hartman
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]

Post by Sam Hartman
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]

Post by Sam Hartman
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]

Post by Sam Hartman
Section 5.3 .

(note - section 5.3 is now 4.2 in 01)

Post by Sam Hartman
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]

Post by Sam Hartman
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]

Post by Sam Hartman
TLS not SSL in description of https.

Done.

Post by Sam Hartman
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.

Post by Sam Hartman
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.

Post by Sam Hartman
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.

- -----