Nicolas,
I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
Please resolve these comments along with any other Last Call comments
you may receive.
Document:
On the Use of Channel Bindings to Secure Channels
draft-williams-on-channel-binding-01.txt
Reviewer: Eric Gray
Review Date: 04/11/2007
IETF LC End Date: 04/11/2007
IESG Telechat date: unknown
Summary:
This draft may be nearly ready to be published as a Proposed
Standard RFC. My review is a generalist review since I have
nearly no expertise in the area of this draft's concerns.
Comments:
I have the following minor comments and/or NITs.
Comments:
========
How did the following note (top of section 2.1, bottom of page 6)
survive until last call?
[NOTE: This section needs more work, I'm sure I've missed
somethings...]
___________________________________________________________________
In the same section are "must" and "should" not intended to be
capitalized (1st para after the above note)?
___________________________________________________________________
In the last sentence of the 7th bullet on page 7, is this because
information about the end-points of a channel is not considered
secure? If that is the case, would the statement change if that
information was considered secure?
Is the second recommendation bullet on page 8, intended to answer
this question? If so, shouldn't it be a requirement?
___________________________________________________________________
In the 1st bullet under "Options" on page 8, I don't see how this
is an "option" - but it is likely I am missing something. From
what it seems to me to be saying, channel binding is either a
requirement for establishing authentication in mechanisms that
support channel binding, or they are not.
>From the way I read it, it seems to me that requiring channel
binding to work in order to establish authentication in a
mechanism that supports channel binding might be getting the
cart before the horse. But - if this is not the case - I don't
see why authentication would not be required to fail (to be
established) in any such mechanism.
___________________________________________________________________
NITs:
====
In the 2nd para of the Introduction, the construction "..., while
..., but ..." is unusual and may be confusing - especially given
the length of th sentence. One word (while or but) should be used
and the other discarded.
____________________________________________________________________
I am reasonably sure that "assymetric" is an incorrect spelling.
If you mean "not symmetric" the word is "asymmetric" - but you
might mean something more interesting. See top of page 6.
____________________________________________________________________
Next para, 3rd sentence, "ptoection" looks like it's supposed to
be "protection".
____________________________________________________________________
I don't know if you are aware of the fact that you (consistently)
used a misspelled reference tag for "Lampson, B., Abadi, M., Burrows,
M., and E. Wobber, 'Authentication in Distributed Systems: Theory and
Practive', October 1991." The tag is Lapmson91 (there's a swapped
pair of letters "pm" verses "mp").
____________________________________________________________________
4th bullet on page 7, "initinial"?
____________________________________________________________________
7th bullet, same page, "a secure channels"?
____________________________________________________________________
The last sentence in the first para on page 14 is hard to parse.
I suggest something like:
"It is thought to be simpler to
push the cryptographic session protection down the network stack (to
IPsec), and yet be able to produce NICs that offload other operations
(i.e. - TCP/IP, ESP/AH, and DDP), than it would be to add support in
the NIC for the many session cryptographic protection protocols in
use in common applications at the application layer."
____________________________________________________________________
I suggest changing section 7. It currently reads:
"There are no IANA considerations in this document."
Given that this is in the IANA considerations section of this
document, that statement might be slightly more confusing than:
"There is no IANA action associated with this document."
_____________________________________________________________________
I think the word "hostbased" is supposed to be hyphenated (bottom of
page 17).
_____________________________________________________________________
_______________________________________________
Gen-art mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/gen-art
