IESG Narrative Minutes
Narrative Minutes of the IESG Teleconference on 2010-03-11. These are not an official record of the meeting.
Narrative scribe: John Leslie (The scribe was sometimes uncertain who was speaking.)
Corrections from: Dan, Russ
1 Administrivia
2. Protocol Actions
2.1 WG Submissions
2.1.1 New Items
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
2.1.2 Returning Items
Telechat:
2.2 Individual Submissions
2.2.1 New Items
Telechat:
Telechat:
2.2.2 Returning Items
3. Document Actions
3.1 WG Submissions
3.1.1 New Items
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
3.1.2 Returning Items
3.2 Individual Submissions Via AD
3.2.1 New Items
3.2.2 Returning Items
Telechat:
3.3 Independent Submissions Via RFC Editor
3.3.1 New Items
3.3.2 Returning Items
1243 EST break
1249 EST back
4 Working Group Actions
4.1 WG Creation
4.1.1 Proposed for IETF Review
4.1.2 Proposed for Approval
Telechat:
4.2 WG Rechartering
4.2.1 Under evaluation for IETF Review
Telechat:
4.2.2 Proposed for Approval
5. IAB News We can use
6. Management Issues
Telechat:
7. Agenda Working Group News
1434 EST Executive Session started for details of IDNAbis appeal, Ross excused himself.
(at 2010-03-11 08:00:05 PST)
draft-ietf-dnsext-axfr-clarify
Abstract: The Domain Name System standard mechanisms for maintaining coherent servers for a zone consist of three elements. One mechanism is the Authoritative Transfer (AXFR) defined in RFC 1034 and RFC 1035. a. s/consist/consisting ? b. "three elements" in first sentence, then "one mechanism". Please align terms.
draft-ietf-ecrit-specifying-holes
Halfway serious question: can a hole have a hole? I think I can infer that the answer is "no" from the syntax; for clarity, it might be good to include an explicit statement that these polygons are either "exterior" or "interior" and an interior polygon cannot contain another interior polygon. Does this sentence from sectino 3 apply: Similarly, a polygon containing a hole with an island must be represented as two polygons mapping to the same service. Editorial nit: it's likely an obvious inference but it might be good to include an explicit description about which service to return, related to this sentence at the end of section 6: A location falls within the area described by a polygon if it is within the exterior boundary and not within any interior boundary. I.e., if the location falls within an interior boundary, map it to the interior service; if it falls within the exterior boundary and not within any interior boundary, map it to the exterior service.
Section 3., paragraph 1:
> Holes related to an exterior boundary polygon MUST adhere to the
> following rules: (...)
Section 6., paragraph 0:
> Interior parts are specified in clockwise direction, such that the
> upward normal is opposite to the upward normal of the exterior part.
DISCUSS: A quick glance at the GML spec seems to indicate that there
is no requirement that interior rings can't overlap with themselves or
the exterior in other ways than on a single point. There apparently also
no requirement that interior rings need to specified in clockwise
order. (And that exterior rings would need to be specified in
counterclockwise order, if that's what's implied here.)
Have I missed something in the GML spec? Or are we more
restrictive than GML itself? If so, why?
Section 3., paragraph 5: > Figure 2: Incorrect Hole Specification with Boundary Sharing Nit: Suggest s/Incorrect/Correct/ similar to the captions of Figures 3 and 4. Section 3., paragraph 11: > 1 Polgon with a 2 Polygons that map Nit: s/Polgon/Polygon/
Ralph's question seems perfectly sound. In particular, the case where the hole in a hole yields the same destination as the polygon itself. It would be worth adding clarifying text for these cases. --- Nit: Section 1 s/that's/thats/ But note that "whose" is acceptable even though the protocol in inanimate.
Section 1 says: > > This document describes how holes SHOULD be specified in service > boundaries defined using a GML encoding for the polygons and their > internal elements (holes). > I think the following would be a better way to state the purpose of this document: > > This document describes the RECOMMENDED approach to specifying holes > in service boundaries defined using a GML encoding for the polygons > and their internal elements (holes). Section 7 says there are no security considerations. However, there seem to be some if these recommendations are not followed. Can we capture the most important ones in section 7?
AD to check LC comments
Figure 4 is labeled inconsistently, and may result in some confusion. I suggest adding the words "Incorrect" and "Correct", as in Figures 2 and 3, to the left and right polygons respectively. In this case, one needs to review the body text carefully to see that the left polygon is an incorrect specification.
Section 5 says that "Interior parts are specified in clockwise direction, such that the upward normal is opposite to the upward normal of the exterior part." but there seems to be no statement that the vertices of the exterior part are to be listed in counterclockwise direction. (That may be inherited from the GML specification.)
The working group did explicitly discuss recommending holes over dividing such regions into multiple polygons, but that discussion is not captured here. I suggest adding something like the following to note that discussion took place: The working group considered that the types of regions described in this memo could be represented in various ways as multiple polygons without holes, but concluded on the recommendations here to avoid potential problems with the arbitrary division of regions and to align with existing geospatial system practices. I also had to ask again about the island case and encourage making it easier to not miss that discussion.
draft-ietf-sip-domain-certs
I have reviewed draft-ietf-sip-domain-certs-05 and have couple of
small concerns that I'd like to discuss before recommending approval
of the document:
- The document uses "AUS" as a synonym for the host (domain) part of
the SIP URI. However, it looks like in RFC 3263 the AUS is actually
the whole SIP URI. If that's the case, small clarifications (mostly of
form "AUS"-> "domain/host part of the AUS") are needed.
- Section 5 says:
> Thus, in the certificate Proxy-A receives from Proxy-B, Proxy-A
> looks for the host name ("Proxy-B.example.net") or an identity
> consisting of a SIP URI ("sip:example.net") that asserts Proxy-B's
> authority over the example.net domain.
This is a bit confusing; according to the rest of the document,
Proxy-A does NOT look for "Proxy-B.example.net" in the certificate,
right? (only only "sip:example.net" or "example.net")
This is a Discussion point for the rest of the IESG and does not impact this
document per se. The authors should not worry about it, and the Discuss will be
cleared during the IESG telechat.
I would like to use this document as an example to understand what sort of
overlap is reasonable between IESG review and IETF Last Call. In this case the
LC does not end for 8 days after IESG review. Where do we stand if the comments
recieved during LC result in changes of substance to the document? Do we rely on
the responsible AD holding a Discuss? What happens if the responsible AD thinks
the changes are OK, but the rest of the IESG might not be so happy?
AD to check LC comments.
This looks like a fine document and I will vote No Objections after the call.
But I would like to discuss a couple of things during the IESG telechat, as they
also affect draft-saintandre-tls-server-id-check.
1) Recommendation to use EKU.
2) Use of URIs versa SRVName - advantages/disadvantages.
The first sentence of the introduction may have been accurate when this work started years ago. The phrase "has started to appear" is dated now, and should be updated.
draft-ietf-tsvwg-port-randomization
This is a good and much needed document, thanks for writing it. I
did have one issue, however. Perhaps I'm missing something but the
document first says:
Port numbers that are currently in use by a TCP in the LISTEN state
should not be allowed for use as ephemeral ports.
but then later the algorithms say:
if(resulting five-tuple is unique)
return next_ephemeral;
This does not appear to be sufficient to prevent the use of a
port in the LISTEN state. The if statement simply checks whether
there's an open connection between this host and some other specific
host. It does NOT check whether there could in the future be a
connection between this host and the specific host. If we are
opening a connection for application X between hosts A and B,
you cannot choose a port that another application Y is already
listening on host A. Even if A and B at the moment are not having
an open connection for application Y between them.
The document says: As mentioned in Section 2.1, the dynamic ports consist of the range 49152-65535. However, ephemeral port selection algorithms should use the whole range 1024-49151. Since this range includes ports numbers assigned by IANA, this may not always be possible, though. A possible workaround for this potential problem would be to maintain a local list of the port numbers that should not be allocated as ephemeral ports. Thus, before allocating a port number, the ephemeral port selection function would check this list, avoiding the allocation of ports that may be needed for specific applications. Ephemeral port selection algorithms SHOULD use the largest possible port range, since this improves obfuscation. First, what does the document actually recommend as the default policy? The use of the entire range, or the entire range minus locally configured list? Second, I think the comment about IANA isn't quite right above. The issue is not the IANA allocation, its the possibility that some application would be running on a port. You already discussed avoiding ports that are in the listen state. So this appears to leave only the case where the application is not yet running but will later run and want to use its well known port. Please be more specific about what the problem actually is.
I support Tim's discuss regarding port range selection.
I think there needs to be some text between this text in section 2.1: The dynamic port range defined by IANA consists of the 49152-65535 range, and is meant for the selection of ephemeral ports. and this text in section 3.1: It is important to note that a number of applications rely on binding specific port numbers that may be within the ephemeral ports range. If such an application was run while the corresponding port number was in use, the application would fail. Therefore, ephemeral port selection algorithms avoid using those port numbers. that explains the (as far as I can tell) unstated assumption that ephemeral ports could be selected from the IANA "registered" port range, 1024-49151. Reading on, it seems the issue is addressed here: 3.2. Ephemeral port number range As mentioned in Section 2.1, the dynamic ports consist of the range 49152-65535. However, ephemeral port selection algorithms should use the whole range 1024-49151. I suggest clarifying to: 3.2. Ephemeral port number range As mentioned in Section 2.1, the dynamic ports consist of the range 49152-65535. However, ephemeral port selection algorithms should also use available ports in the range of registered ports, 1024-49151. Therefore, the port selection algorithm should be applied to the whole range 1024-65535.
I have reviewed draft-ietf-tsvwg-port-randomization-06, and have
couple of small concern that I'd like to discuss before recommending
approval of the document:
- Section 3.3.1 says '"random()" is a function that returns a
pseudo-random unsigned interger number in the range 0-65535'.
The document is not very clear on exactly what the requirements for
this function are. If I recall right, the output of typical
implementations of POSIX random() may look random to simple
statistical tests, but it is not unpredictable (seeing couple of
values allows you to fully predict future outputs).
While this use probably doesn't need a cryptographically secure
strong random number generator, it looks like some degree of
unpredictability would be needed?
- Section 3.4 suggests use of a 32 bit key, which has exploitable
security problems -- to make the sequence unpredictable (even after
seeing couple of values), more is needed (and since bits here are
cheap, so there's no real reason to use less than 128).
Charlie Kaufman's SecDir review identified a number of minor clarifications/editorial nits that should be addressed; it seems the authors are already addressing those.
It is interesting that Algorithms 1, 3, and 4 statistically favor port numbers one greater than allocated port numbers. But probably not worth noting.
Since we are trying to replace the TCP MD5 signature option [RFC2385] with TCP AO, it seems like a bad idea to reference it in the document as a security solution. As pointed out in the Gen-ART Review by Avshalom Houri on 2010-03-03, the first portion of the document (up to and including Section 3.2) is lengthy and repeating while it is lacking some background. When and how are the techniques described in the document to be used? Is this texpected to be used in every transport protocol implementation in every environment? The Gen-ART Review by Avshalom Houri also makes many suggestions for improving the document. Please consider them.
One other issues that got raised was would it be possible to give advice about
getting initial randomness. Perhaps pointers to other RFC. The problem is
partially hard for a small residential NAT that has just booted. Saying there
should be some randomness does not really help implementers without a way to do
that.
This is a very long discuss and many of the appoints in are purely asking we
certain attacks considered. It's perfectly reasonable to resolve theses with a
"Yes" and pointer to the list.
RFC3605 is not commonly implemented for RTP and I find it very concerning that
this would break RTP. The recommendation here violate the recombination in Req-4
of BCP 127. It would be very easy to define the algorithm here such that they
preserved port parity. Why not do that? If one does not, some RTP receivers when
told to send RTP to port x, will deice the parity is wrong and actually send it
to x-1. This is not good. Breaking port+1 continuity breaks RTCP but that has
not turned out to be as critical as breaking RTP. However, it would nice to see
an this draft support that unless there was a reason it was not possible.
Regardless of how we resolve this, I believe this draft needs to be changed so
it is consistent with BCP 127, or we need to change BCP 127 before this can be
published. We should not be publishing a draft that violates an existing BCP.
I only find two normative statements. The first
Ephemeral port selection algorithms SHOULD use the largest possible
port range, since this improves obfuscation.
This relies on the suggestion that somehow one would maintain a local list of
port numbers that should not be allocated as ephemeral ports. How is a OS such
as Linux supposed to actually implement this? Is there a list IANA is providing
with real time updates? When IANA allocated a new port to a protocol, how long
before they could reliably use that across existing computers. I don't find this
to be implementable. I would like the draft updated such that it has advice that
is clear to implementers what they need to do. I worry the current advice will
result in ports such as 5060 being allocated and then servers tripping to run on
that port not being able to get it for no reasons that is parent to the end user
who will see it as an intermittent problem that goes away when they reboot. That
not a design I would consider good for a BCP.
The second normative statement is one SHOULD obfuscate the allocation of their
ephemeral ports. It then goes on to describe a series of possible algorithm to
do this which all seem to lack any crypto analysis. The problem of having a
algorithm that generates a number that is hard to predict by an attacker that
has seen the previous sequence of numbers the algorithm produced is pretty well
understood so I expected to see pointers to concrete analysis here.
Alg 1.
If the attacker knows that port x in in use, they know that port x+1 is twice as
likely to be chosen as the next port as say x-1. I'm not a crypto person but
this sort of property always makes me pretty uncomfortable about deciding what
the security properties of this are. Did crypto people look at it? Can we
describe the security properties of this.
Alg 2:
You have count = num_ephemeral but I have a hard time imagining anyone would set
it this high. It still won't guarantee 100% port usage as you point out in the
note. It seem from the text below figure 3 you are saying that count = 2 would
be fine. Same issue in some of the other ALGs.
Alg 3:
I'm fairly skeptical of the advice on choosing the key sizes. I'm not a crypto
person but I'd love to see some analysis of this. Let's consider some different
keys sizes (yes, I realize the draft recommends 32 or 64, I'll get to that). If
the key size was 16, and the attacker could see what port was used for a single
connection, they could brute force the key space and have the key, or at least a
small number of possible entries for the key if there were collisions in the MD5
space. Now lets consider a 32 bit key. Again if the attacker could see two
connections, they could brute force the space (the machine I am on right now
looks like it would do that in about 5 seconds) on the first connection which
would get them to about 2^16 possible keys, but on the second connection, they
could filter these keys and get down to a very small number. Now I realize the
draft says to use 64 bits it attackers can probe for ports but do we have any
crypto analysis of any of this? If 64 bits enough? 32 bits clearly is not. If I
could probe for several ports and had and FPGA card in my computer, could I
easily figure out 64 bits? Is there discussion on this you can point me at?
I suspect I would be much more conformable with something that had been looked
at lots, like AES counter mode. Again, I'm not even qualified to suggest
anything here but I'm looking for evidence the crypto stuff was seriously looked
at.
Alg 5:
The idea that an end user should configure N does not seem practical. How would
they figure out what to do. Most the implementors I know would choose 500 for
the default because it was in the RFC and the RFC was golden and you MUST do
exactly what it says, unless of course it is a SHOULD in which case they don't
even bother to read it much less do it but I degrees. The 500 is going to have a
wrap around after a mere 256 ports while at the same time only proving a 8 bits
of security which seems like it would be inadequate for many cases. This is
harmful in that it passes an impossible hard problem of choosing a good value of
N to the end user which will not provide security while at the same time
providing the illusion of being more useful than it probably is. If this
algorithm is not a good choice, remove it from the BCP. If it is only a good
choice for certain cases, make it clear which cases this should be used instead
of the other ones.
Section 3.5 provides some ideas about pros and cons of various algorithms but no
real advice one which ones to use and when. Would if be possible to pick one
algorithm and just recommend that? If the view is we need to develop experience
to find out which one of these is the best for a general OS, then this should be
experimental not BCP.
I find this far from what I would expect in a BCP on such an important topic. I
think it could be vastly improved by having the security folks define an
algorithm, working with the Apps, RAI, and behave folks to make sure that it
does no more harm than necessary to existing applications. And overall make it
be a tight specification where it is clear what an implementation MUST do to be
compliant. A draft where vendors can have very poor implementation and still
claim to be compliant is not good.
For the IESG more than the authors .... My current understanding of BCP would imply this should be a PS that update TCP, UPD, DCCP, and SCTP but I don't really understand why it is a BCP. Though ephemeral pot sounds of some relevance to my discuss, I suspect you want a s/ephemeral pot/ephemeral port/ Having made a nearly infinite number of typos in my life, I did like this one.
There are a couple of issues I would like to discuss before moving to No Object
for this
document...
(1) Section 3.2 states that "ephemeral port selection algorithms should use the
whole range
1024-49151." [As noted in the comment section, I believe that 49151
should be 65535.]
I get the concept of using the largest possible range, but
this seems to violate the spirit of
RFC 4340, among others.
The following paragraph notes that this range includes assigned ports so "this
may not be
possible". Upon review, a very significant number of ports in the
range 1024-49151 have
been assigned. I would like to understand how to determine
which of the set of IANA
registered ports should be made available for ephemeral
port selection.
(2) There are issues with the computation of next_ephemeral in Algorithm #1
which will skew the selected. While the impact of this issue in isolation is
relatively
minor, the fix is very straightforward. (See follow up email.)
(3) Depending upon which IANA registered ports are available for ephemeral port
selection,
issues 1 and 2 in combination with algorithm #1 can create a
situation where certain ports
in the range 1024-49151 are significantly more
likely to be selected. (See follow up email.)
section 3.1, final paragraph s/DCCP is not affected is not affected/DCCP is not affected/ Section 3.2 states: As mentioned in Section 2.1, the dynamic ports consist of the range 49152-65535. However, ephemeral port selection algorithms should use the whole range 1024-49151. Shouldn't the whole range be "1024-65535"?
I support the issues raised by Pasi, Robert and Tim in their DISCUSSes
Before suggesting that NATs follow the recommendations in this
document, there should be more discussion of the impact of the
recommendations on deployed systems using symmetric RTP/RTCP
that expect sequential binding.
The text should acknowledge that applications using RTP are really at the mercy of what their underlying UDP implementation (for the current majority of RTP users anyway) chooses to do with this recommendation.
Section 4.
If this document is supposed to make recommendations on NAT behavior I think it
needs to discuss when it makes sense in the context of the terminology of the
NAT behavior documents, like RFC 4787 and 5382 that do discuss port assignment
in the NAT.
As I see the NAT behavior around port obfuscation is dependent on at least three
things. The nat's port assignment rule, if it is preserving. Secondly what it
does when it fails to preserve and if it has port parity preservation. So I find
the text under specified, but still gives recommendations that do go against the
current BCPs. Thus we must also consider if this document actually updates
theses BCPs.
draft-ietf-geopriv-loc-filters
This is a good document and I was ready to ballot Yes. However, like
other reviewers I had trouble with the normative requirements. In my
case Section 3.3 said:
An implementation MUST support the functionality as shown in Figure 3
with <ns-bindings> replacing the prefix. No other variant is
supported.
I do not understand what to implement based on this. In particular,
Section 3.3 has also Figure 4 that shows another variant. Is only the
first one required to be supported? What exactly does "MUST support
this example snippet of XML" mean?
Section 9.1., paragraph 2:
> [I-D.ietf-geopriv-arch]
> Barnes, R., Lepinski, M., Cooper, A., Morris, J.,
> Tschofenig, H., and H. Schulzrinne, "An Architecture for
> Location and Location Privacy in Internet Applications",
> draft-ietf-geopriv-arch-01 (work in progress),
> October 2009.
DISCUSS: Downref: Normative reference to an Informational draft:
draft-ietf-geopriv-arch (ref. 'I-D.ietf-geopriv-arch'). Didn't see it
called out in the IETF LC.
Non-blocking comments: Section 3.1., paragraph 1: > The <moved> element MUST contain a value in meters indicates the > minimum distance that the resource must have moved from the location > of the resource since the last notification was sent in order to > trigger this event. Note that the condition could be met by a change > in any axis including altitude. But surely not only by change along a single axis, right? (I think what you mean is that the length of the vector between the two points is longer than <moved>.) Section 5.2.3, paragraph 1: > If the Target was previously outside the region, the notifier sends a > notification when the Target's location is within the region with at > least 50% confidence. Similarly, when a Target starts within the > region, a notification is sent when the Target's location moves > outside the region with at least 50% confidence. Why 50%? Why not 30 or 70%? (Magic number.) Section 5.2.3, paragraph 2: > Note that having 50% confidence that the Target is inside the area > does not correspond to 50% outside. The confidence that the location > is within the region, plus the confidence that the location is > outside the region is limited to the confidence of the location. The > total confidence depends on the confidence in the location, which is > always less than 100% (95% is recommended in [RFC5491]). The benefit > of this is that notifications are naturally limited: small movements > at the borders of the region do not trigger notifications. Whether the last sentence is true depends entirely on how accurate the positioning is compared to the movement. Section 9., paragraph 0: > 9. References idnits reports several unused references, including normative ones. Section 3.3., paragraph 5: > In times where it is desireable to know if any one element of a list Nit: s/desireable/desirable/
I found the second paragraph of Section 1 hard to parse The frequency of notifications necessary for various geographic location applications varies dramatically. The subscriber should be able to get asynchronous notifications with appropriate frequency and granularity, without having to issue a large number of notifications that are not important to the application. The second sentence appears to mix "getting" notifications with "issuing" notifications. Are you attempting to distinguish asynchronous notifictations from requst/response transactions? --- Nit of the smallest type Section 1 s/that allows the number/that allow the number/
The Gen-ART Review by Ben Campbell on 9 March 2010 raised some concerns
that ought to be addressed before this document is approved, and I have
summarized them below.
(1) Section 3.6 seems to create a profile of the rate-control
document, but minor modifications to the normative requirements
are made. Can you motivate why rate-control does not work as-is?
If not, perhaps the two documents should be harmonized.
(2) The empty notify language in the 2nd paragraph of Section 3.6
seems to conflict with the MUST statements in rate-control
document:
>
> ... depending on the event package and subscriber
> preferences indicated in the SUBSCRIBE request, the NOTIFY request
> MUST contain either the current full state or the partial state
> showing the difference between the current state and the last
> successfully communicated state.
>
This also indicates that the two documents should be harmonized.
(3) In Section 3.2, first paragraph after figure 2, the text effectively
declares the example as normative, but fails to offer normative text.
Also, the "No other variant" language is confusing; it is not clear
what restriction in the example is constrains <ns-binding>. Please
make the examples informative and provide normative text.
The Gen-ART Review by Ben Campbell on 9 March 2010 raised some concerns that are not included in my DISCUSS position. Please consider them.
AD needs to review LC comments
3.3. Element Value Changes
Figure 3 shows an example where a notification is sent when the civic
address tokens A1, A2, A3, or PC change (all 4 must change in order
to let the <trigger> element evaluate to TRUE). In times where it is
desireable to know if any one individual of a list of CAtypes change,
then they have to be put into separate <changes> filters to ensure
you are notified when any of the element values change.
In the last sentence: do you mean something like:
<filter id="123" uri="sip:presentity@example.com">
<trigger>
<changed>//ca:A1</changed>
</trigger>
<trigger>
<changed>//ca:A2</changed>
</trigger>
<trigger>
<changed>//ca:A3</changed>
</trigger>
<trigger>
<changed>//ca:PC</changed>
</trigger>
</filter>
instead of:
<filter id="123" uri="sip:presentity@example.com">
<trigger>
<changed>//ca:A1</changed>
<changed>//ca:A2</changed>
<changed>//ca:A3</changed>
<changed>//ca:PC</changed>
</trigger>
</filter>
?
3.5. Location Type:
<?xml version="1.0" encoding="UTF-8"?>
<filter-set
xmlns="urn:ietf:params:xml:ns:simple-filter"
xmlns:lf="urn:ietf:params:xml:ns:location-filter">
<filter id="123" uri="sip:presentity@example.com">
<what>
<lf:locationType exact="true"> geodetic
Are leading spaces insignificant in this case?
</lf:locationType>
</what>
</filter>
</filter-set>
The DISCUSS and COMMENT issues are based on input from Dale Worley.
The following items are problematic as they point to ambiuities in the
specification:
1. Section 3.3, element value changes: In the example, changes in the
subordinate civic address components "A1", "A2", etc. will cause a
trigger, but changes in "country" will not. This is probably
unrealistic; in a realistic application, a trigger on one civic
address component would be or'ed with triggers on each higher-level
civic address component.
2. Section 3.3, element value changes: The statement "An
implementation MUST support the functionality as shown in Figure 3
with <ns-bindings> replacing the prefix. No other variant is
supported." is nowhere near clear enough to be a specification. In
particular, the uses in figures 4 and 5 are clearly distinguishable
from the use in figure 3 (based on the number of <trigger> and
<changed> elements).
1. The draft could use a careful editing for English usage. Some problems are simple statement structure (e.g., "This document defines a new event filters and describes others using existing mechanisms that may be relevant to a subscriber in the context of location filtering:" does not grammatically connect to the following list). Other problems leave out information (e.g., the text of section 3.1 does not state that the <moved> element is a child of the <trigger> element, although the example makes that clear). 2. Section 3.2, speed changes: The statement "An implementation MUST support the functionality as shown in Figure 2 with <ns-bindings> replacing the prefix. No other variant is supported." is nowhere near clear enough to be a specification. 3. Section 3.6, rate control: It might be useful to provide a more extended example than figure 9, one that shows the initial SUBSCRIBE and NOTIFY, and the subsequent SUBSCRIBE that lengthens the max-interval value.
Section 3.6 should be more clear on whether it is restricting the use of all the
mechanics in event-rate-control, or only noting which of those mechanics need to
be used to achieve the purpose addressed in this draft. In particular, I suggest
changing "The implementation of only these two attributes" to "The use of only
these two attributes".
Ben Campbell's genart review comments are related.
These are very small nits: 2nd paragraph of 3.3 would read more correctly if you said A1, A2, A3 _and_ PC change. <changes> is a typo The labels for figure 3 and 4 are wrong - should say Element Value Change Example
draft-ietf-6man-ipv6-subnet-model
I concur with Ralph's DISCUSS. There is very little new in this document. Maybe
the issues is best handled with an errata to the document that it updates.
Regrettably, I'm having some trouble with access to the datatracker today, and
my original DISCUSS text was lost. Retyping...
I'm raising a discuss-discuss. Do we need a full document to achieve the goals?
Can the changes to RFC 4861 be accomplished with an Errata? Much of the
document is a restatement of other RFCS and I worry that the RFC 2119
requirements may be confusing or subtly in conflict with other RFCs. How often
has the behavior in section 4 been observed; I'm aware of one mis-implementation
that was corrected some time ago.
From list item 3 of section 2:
Neither of these tests are acceptable definitions for an address
to be considered as on-link as defined above, and this document
deprecates and removes both of them from the formal definition of
on-link.
Why are these test not acceptable definitions for on-link?
This document needs a terminology section to define or point to the intended
definition of "subnet" and various terms from RFC 4291, et al. such as Prefix
List. Pointers to some of the terms are given in the body of the doc, not
always on first reference, and a terminology section would be helpful.
---
"The
original Neighbor Discovery (ND) specification [RFC4861]": s/original//; RFC4861
is the current ND specification.
---
From bullet 2 of section 2:
Redirect
Messages do not contain sufficient information to signal that an
address is off-link.
Redirect messages give no indication either way about on- or off-link; perhaps
reword as:
Redirect
Messages do not contain any information about whether an address is
on- or off-link.
---
Section 4., paragraph 0:
> 4. Implementations compliant with [RFC4861] MUST adhere to the
DISCUSS: The document seems to lack a both a reference to RFC 2119 and
the recommended RFC 2119 boilerplate, even if it appears to use RFC
2119 keywords.
The Gen-ART Review by Pete McCann on 2010-03-09 included some editorial comments. Please consider them if an update to this document is needed for any reason.
This is a DISCUSS DISCUSS, which I believe needs clarification before I can
approve this document. Some of the requirements in sections 3 and 4 modify the
hosts behavior defined in RFC 4861 that this document updates. RFC 4861 is
however a Draft Standard, so would not approving these changes modify the
interoperability conditions on which base the advancement of 4861 from PS to
Draft was approved?
I support Lars' DISCUSS about the need to include mandatory 2119 boilerplate.
draft-ietf-mext-binary-ts
Section 3.1
The alignment requirement for this sub-option is:
4n if A, B, C, D, E, or F is set
2n if G, H, I, or J is set
n if K, L, M, N is set
Is there a missing "or" in the last line?
If J and K are set, is the alignment 2n or n?
What does it mean to have an alignment requirement of 4n?
---
I agree with Cullen that reviewing this before draft-ietf-mext-flow-
binding seems rash. Isn't it possible that review comments on that other
document might require changes of substance here.
I suggest that the responsible AD should hold a Discuss until the other
document is completed.
1. This is a discuss question that I do want to have answered before endorsing
publication of this document.
As it is not clear what the purpose of these traffic selectors are. Do you need
to have a traffic selector for the DCCP Service Code? Considering that you
included other special fields I think this needs to be considered. However, that
would only separate out the initial connection establishment for DCCP. Not that
it may not be unimportant as DCCP do allow for multiple services to share a
port. And if one needs to separate traffic for one of these services and then
update with more specific filtering rules after having detected the first
packet?
2. Section 3.1, (K)Start DS - Differential Services:
For
the purpose of this specification the DS field is 8 bits long,
were the 6 most significant bits indicating the DS field to be
matched and the 2 least significant bits MUST be set to 0 by the
sender and ignored by the receiver.
To me it appears to be the wrong specification of how to treat the ECN bits. It
is very important that anyone trying to match a DS start value against an actual
packet flow must not include the two least significant bits in this octet that
are used for ECN. Otherwise you select packets from the flow in a very strange
mannor.
This also applies to Section 3.2 field M specification
draft-ietf-dnsext-dnssec-alg-allocation
INTRODUCTION, paragraph 2: > Updates: 2535, 3755, 4034 (if approved) It's a bit odd to update RFCs that have already been obsoleted (2535, 3755).
In section 2, the document says:
>
> ..., the IETF SHOULD re-evaluate the requirements for entry into
> this registry when approximately 120 of the registry entries have
> been assigned.
>
RFC 2119 does not apply to this statement: s/SHOULD/should/
If it did, then a reference to RFC 2119 would be needed.
Section 4 reserves values 123 through 250 in the IANA registry:
http://www.iana.org/assignments/dns-sec-alg-numbers/dns-sec-alg-numbers.xhtml
It should reserve through 251.
DISCUSS DISCUSS. I'd like to ask the AD to have a look at Sam Weilers, comments
from Jan 9 and resulting threads. My read of the list is that there was
consensus that non Standards Track RFC could not specify a MANDATORY algorithm
and I'd like to understand if I misreading the consensus here. If there is
consensus for this, the I think this draft needs to reflect that consensus and
would agree with Sam Weiler's email of March 2 that was sent to IESG and secdir
list.
IANA Considerations - 'IANA is requested to mark values 123 through 250 as
"Reserved".'
As the 'Resrved lable is applied only in order to trigger a review of the policy
of administration of this registry in case entries are consumed at a higher rate
than expected, I think that a comment should be made that the reservation is
made per RFC XXXX (where XXXX is the number of this RFC when approved) so then
when this event happens future IANA and users generation will have an easy
pointer to where this came from.
I agree with Russ' DISCUSS comment - the range of Reserved should extend to include 251.
draft-ietf-tcpm-tcp-auth-opt
Section 2.1, third para: s/TCP-AO not/TCP-AO is not/
I have reviewed draft-ietf-tcpm-tcp-auth-opt-10, and have one concern
that I'd like to discuss before recommending approval of the document:
It seems TCP-AO is mainly useful for places where TCP-MD5 is used
today (i.e., routers), and most hosts on the Internet would never
need it. Given this, "TCP implementations MUST support TCP-AO" does
not sound reasonable to me.
Thanks for this document. General sigh of "at last" :-)
A few small wrinklettes...
ISN is used in Section 1 without expansion.
(although it is subsequently expanded multiple times)
---
Section 4.2
>> The Length value MUST be consistent with the TCP header length;
this is a consistency check and avoids overrun/underrun abuse.
When the Length value is invalid, TCP MUST discard the segment.
"MUST be consistent" is a little vague. I can only assume that you
mean that the length must not imply that the option extends beyond the
end of the header as specified by the header length.
---
MKT is used in Section 4.2 without expansion or reference.
Add a forward pointer to 5.1?
---
Semantic tautology.
I think the phrase "TCP-AO option" may include some redundancy.
Cf. the header to Section 4.2.
---
Section 9.1
s/implmentation/implementation/
The Gen-ART Review by Wassim Haddad on 2010-03-09 raised two minor
issues:
- Page 13, Figure 3: traffic keys derived show two "Send_Other_key"
in all 3 boxes. Shouldn't be Rcv_Other_key?
- Page 37: sub-section 2: a) Privacy: "TCP exposes "only" the MKT
IDs, MAC, and overall option. Question: is "only" really needed?
I think the first one ought to be corrected. Please consider the
second one as well.
The Gen-ART Review by Wassim Haddad on 2010-03-09 included some editorial comments. Please consider them if an update to this document is needed for any reason.
The drafts says
TCP implementations MUST support TCP-AO.
This would require this draft to be an "update" to the base TCP spec.
Given that this does not work with NATs, I think it is too much to expect all
implementations to support it. Many devices are nearly 100% deployed behind NATs
and have close to no need for the security this provides. Is there some
discussion on some list I should go read about this to get an idea of the
Consensus for this?
Give this disables much of ICMP, particularly destination unreachable, would it be worth mentioning in the applicability statement of situations when it was not appropriate to use it or timing consideration changes that needed to be made to applications using it?
This is a good document.
I have one probably pedantic and trivial to address
comment, but I would like to fully understand the implication of the following
text before recommending approval of this document:
10. Obsoleting TCP MD5 and Legacy Interactions
TCP-AO obsoletes TCP MD5. As we have noted earlier:
>> TCP implementations MUST support TCP-AO.
Does this mean that the document should include the appropriate "Updates: <TCP
spec>" field at the top?
4.2. The TCP-AO Option
o RNextKeyID: An unsigned 1-byte field indicating the MKT that the
sender is ready use to receive authenticated segments, i.e., the
"ready use to receive"?
desired 'receive next' keyID.
14. IANA Considerations
[NOTE: This section be removed prior to publication as an RFC]
I don't think this note is correct, the section is non empty.
I support the discuss positions regarding the conformance language ("MUST
support") for
implementations of TCP.
draft-ietf-yam-rfc1652bis
Section 4., paragraph 1: > The following dialogue illustrates the use of the 8bit-MIMEtransport > service extension: Suggest to use RFC2606 example domains in this example.
This is a process question for the IESG and not meant for authors of WG. So
given the text of LC was clear the downref was for all of RFC 2045, RFC 2046,
RFC 5321 and RFC 5322 (all Draft Standards), I think those just all got moved to
Full Standard at same time. Will the IESG announce they have been move to Full
Standard to as part of this announcement?
draft-ietf-tcpm-tcp-ao-crypto
I have reviewed draft-ietf-tcpm-tcp-ao-crypto-02, and have couple of
small concerns that I'd like to discuss before recommending approval
of the document:
- In other contexts where manually configured pre-shared keys are
used, it has been found useful to specify some minimum requirements
for management interfaces -- i.e. how the human-readable/entered input
is converted to the octet string. For example, here's what
draft-ietf-bfd-base said about this:
For interoperability, the management interface by which the
password is configured MUST accept ASCII strings, and SHOULD also
allow for the configuration of any arbitrary binary string in
hexadecimal form. Other configuration methods MAY be supported.
Something similar would be needed here, IMHO (and BTW, I don't think
mandating support for UTF-8 or SASLprep is needed in this context).
- It looks like many of the informative references need to be normative.
At the very least, RFC 4493 (or NIST-SP800-38B, depending on which you
prefer) and RFC 2104; and normative references to AES (FIPS 197) and
SHA-1 (FIPS 180-3) are needed, too.
- Section 3.1.1, "based on PRF-HMAC-SHA1 [RFC2404]": the pointer to
RFC2404 here doesn't sound quite right (2404 doesn't define any PRFs;
it's just one protocol that happens to use HMAC-SHA1). Perhaps just
"based on HMAC-SHA1 [RFC2104][180-3]" would be sufficient? (also
applies to pointers in 2.2, 3.1.1.1, and 3.2)
- Section 3.1.1, "based on AES-CMAC-PRF-128 [RFC4615]": This is also
confusing, since the PRF in RFC 4615 uses a very different
construction. Perhaps just "based on AES-CMAC [800-38B][FIPS197]"?
(also applies to pointer in 3.1.1.2 )
- Section 3.1.1: "not an even multiple of the output size" initially
confused me (why an odd multiple is not allowed?). "exact multiple",
perhaps?
Idnits finds some missing/erronous references (which really ought to have been fixed before sending this to IETF last call...)
The Gen-ART Review by Avshalom Houri on 2010-03-09 includes some editorial comments. Please consider them if an update to this document is needed for any reason.
Agreeing with Pasi's DISCUSS on management interface for keys.
3.1.1. Concrete KDFs
- "||": For any X || Y, "||" represents a concatonation
"concatenation"?
operation of the binary strings X and Y.
- Output_Length: The length in bits of the key that the KDF will
produce. The Output_length is represented within two
octets. This length must be the size required for
the MAC algorithm that will use the PRF result as a
seed.
I assume this is in network byte order? It would be better to state this
explicitly.
draft-ietf-mip4-rfc3344bis
There is an Erratum reported against RFC 3344.
It should either be:
- verified and incorporated into this document
or
- rejected
The Gen-ART Review by Miguel Garcia on 2010-03-08 raised a few
editorial issues. Please consider them. I would really like to
see the comments about Appendix G addressed, so it is repeated
here for convenience:
- The structure of Appendix G is a bit confusing. Section G.1 lists
the changes made since RFC 3344. Sections G.2 and G.3 list the Major
and Minor Changes, respectively, but it is not clear to me if these
are changes since RFC 3344 or they include earlier changes as well.
To add more confusion, Section G4 lists the changes since RFC 3344,
but wasn't this what Section G.1 is all about?
draft-ietf-smime-cms-rsa-kem
I have reviewed draft-ietf-smime-cms-rsa-kem-12, and have couple of
small concern that I'd like to discuss before recommending approval of
the document:
- It looks like the ASN.1 is not fully aligned with 18033-2 and X9.44.
I might be misinterpreting this, but to me it looks like 18033-2 and
X9.44 would use OID "id-ac-generic-hybrid" (instead of id-rsa-kem) as
the "top-level OID", and id-kem-rsa would be found in
GenericHybridParameters.kem structure.
(The OID id-rsa-kem doesn't seem to occur in 18033-2/X9.44 at all?
And BTW, it's *very* confusing to have two different OIDs named
id-rsa-kem and id-kem-rsa.)
- Section 2.1, "KDF3 (see [IEEE-P1363a])": IEEE 1363a-2004 doesn't
have KDF3; it does, however, define KDF2. Should this be KDF2, or
should the reference point to X9.44?
- It looks like ANS-9.44 needs to be normative references, since you
need the KDF to implement this.
Typo: A.2, "public key n,e)" -> "public key (n,e)"
The second Last Call expires 2010-03-11. The IESG should not declare
that the downrefs called out in that Last Call are acceptiable to the
community until the Last Call is actually over. I do not expect any
objection, but let's not jump the gun.
Thanks for the examples in the back. I know they helped at least one implementor.
draft-gould-rfc4310bis
Thanks for the clear and concise Appendix A that made reviewing this document so much easier.
5.2.5 <update> command If the server does not support the "urgent" attribute, or cannot expedite processing, it returns an error message. Does the server still perform the update, or is the update completed at the lower priority?
draft-arkko-pana-iana
Editorial nit: 2.4 and 2.5 "for these bits" -> "for these values"
16 experimental message types look like a lot. I can imagine a single experiment that might need 4 or 5. The risk, always, is that there are enough codepoints that people start to have expectations about their persistence. If you were able to reduce this pool I would not be unhappy.
The Gen-ART Review by Wassim Haddad on 2010-03-09 included very minor editorial comments. Please consider them if an update to this document is needed for any reason.
draft-ietf-mpls-mpls-and-gmpls-security-framework
Typo and question, end of section 4.1:
This section is focused outsider attach. The insider attack is
discussed in section 4.4.
Change first sentence to "This section is focused on outsider attacks."
Are all of section 4.1-4.3 focused on outsider attacks or just section 4.1?
---
In section 5.2.4:
Bullet formatting in list after "The following is a non-exhaustive list of PW-
specific threats:" is incorrect.
In a bullet list a little farther along:
- Since guessing a valid PW label is not difficult
- it is relatively easy to introduce seemingly valid foreign
packets
delete second bullet marker "-" "
---
Several bullet lists in section 5.2.5 are
formatted inconsistently (I'll stop commenting on bullet list formats now!)
---
Section 7.1.1: add citation of RFC 2385 to mention of TCP MD5?
draft-ietf-ecrit-framework
The Gen-ART Review by Francis Dupont on 2010-03-05 raised two minor
issues. What, if anything, was done to address these IETF Last Call
comments:
(1) the Terminology is incomplete, no PSAP for instance
(2) the GPS stuff seems a bit USA centric; you should show the
document to a GPS (or Galileo) expert
The Gen-ART Review by Francis Dupont on 2010-03-05 included some editorial comments. Please consider them if an update to this document is needed for any reason.
AD needs to check if any new LC comments came.
Few small comments as part of my AD review. Typically I would have sent these
before IETF Last Call but given the timing of the IESG calls and next IETF
meeting, I decided we could sort them out as part of IETF Last Call. They are
all small and could likely be fixed with RFC Editor notes after we decide what
they need to say.
6.2.1 Para 2. The statement that user provided location information is less
accurate seems to be contradicted by the later statement that emergency
responders will be dispatch to user self-declared location. I know what you are
getting at here but seems like some words could be tightened up.
Section 9.1 - para 1. Typo with the xref.
Section 10. The text around the contact header and GRU does not seem right. Are
contacts optional in an INVITE? a device with a global reachable IP can still
use a GRU. When you say that the B2B contact manipulations should result in a
contact header that is usable for call back it sounds like you are saying that
current B2BUAs will all do this. Is that true or did it mean to say this can be
a problem and they need to do this? The text here just seems to a a bit out of
sync with the phone-bcp. Just have a look at this section and see if you think
any changes are needed.
Section 10. Use of PAI. Need to discuss how this works with anonymous call.
Places like women's shelters, or many phones in some legal jurisdictions,
typically configure all calls to be anonymous in the 3325 sense yet it seems
like they still need call back from emergency call to work. I also wonder about
how the spec-T would work. If the solutions requires every service provider to
have a spec-T with every psap, this does not seem feasible. How does the PAI not
get removed when passing it to out of the domain of the service prover and too
the psap?
Section 14. 2nd para. At the time this was first written, this was true,
however, at this point of time the IETF does have consensus about keying for
SRTP. It seems that given that security is desirable, we should use the agreed
on keying solution.
Last paragraph of section 5: These restrictions on UA design
are out of place for an IETF document. If the intent is to
just ask UI implementors and regulators to consider these
concerns, the language should be adjusted.
2nd paragraph page 18: "[RFC4119] with a recent extension [RFC5139]"
ages badly. Suggest "[RFC4119] with an extension [RFC5139]" instead.
Section 9.3 needs a little more clarity to reflect 6.3 correctly.
It is not
clear enough that this should only happen if the UA has
not provided location
information itself, and needs to discuss how the proxy determines whether UA has
sufficient support on its own. Some
pointers to other discussion in this
document may help, but as written,
this can be read to require a proxy to
perform these actions no matter what the UA does.
The sentence "This is a change from [RFC3261] where the Contact: header
is optional." is incorrect. Inclusion of a Contact header field in an
INVITE request is MUST strengh for a UAC in 3261. UASs are allowed to
accept INVITE requests without a Contact header field only for backwards
compatibility with RFC2543 implementations.
Section 15, paragraph 2 is missing a reference to PhoneBCP at the
beginning of the sentence.
Section 1: PSAP is not explained in this section, please write out on first usage Section 1: NENA (National Emergency Number Association): I guess that this is an USA National association, if that is true please make it clear. Section 6.2.2 The threshold for when interior location is needed is approximately 650 square meters. This value is derived from fire brigade recommendations of spacing of alarm pull stations. However, interior space layout, construction materials and other factors should be considered. In this type of reference it would be good to specify which fire brigade that has this recommendations. I would be highly surprised if the California recommendations are exactly the same as the one in Stockholm.
draft-ietf-geopriv-prefix
Section 2.1., paragraph 1: > [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate > Requirement Levels", BCP 14, RFC 2119, March 1997. Unused Reference: 'RFC2119' is defined on line 113, but no explicit reference was found in the text
AD to check LC comments
AD to check IANA is OK
draft-ietf-autoconf-adhoc-addr-model
The document include RFC 2119 boilerplate but uses lower case requirements words
throughout both normatively and non-normatively.
I know this document comes from the autoconf working group, but as far as I can
tell, none of the principles or rules are specific to autoconfiguration. The
term "autoconfigure" is used only sporadically in the document. Is this
document specifically about autoconfiguration or configuration in general? It
would help to include some text explaining the scope of the document.
Expand DAD (end of section 6.2). For consistency, either use "DAD" in both 6.1
and 6.2, or in neither.
---
The first paragraph of section doesn't accurately
describe the applicability:
The configuration proposed by this model is applicable to any
router's IP interface. It specifies IP addresses and IP subnet
prefixes to be configured on network interfaces.
Perhaps "This model gives guidance about the autoconfiguration of IP addresses
and the IP subnet prefixes as on-link on router's IP interfaces."??
---
I was OK
with section 4 up to and including the principle about not configuring an
interface with any knowledge of on-link prefixes. Then I got lost. While the
following paragraph about L2 communication regardless of configuration of on-
link prefixes is true, it's seems irrelevant because the principle advices
against the configuration of on-link prefixes. The last paragraph may also be
true, but appears out of place in a document about a network model in which
nothing can be guaranteed about on-going L2 connectivity.
---
Re-reading
sectinos 6.1 and 6.2, I am pretty sure there is no fundamental difference in the
ways in which this model can be applied to IPv6 and IPv4. For example, doesn't
this observation apply to IPv4 as well as IPv6?
o There is no mechanism to ensure that IPv6 link-local addresses are
unique across multiple links, hence they can not be used to
reliably identify routers.
"routers" or "router interfaces" - which hints at something that might need
clarification: IP addresses are used both as interface addresses and sometimes,
by selecting one global address from those assigned to the interfaces, as an
identifier for the entire router.
Why does the model suggest no on-link prefixes for IPv6 and allow /32 on-link
prefixes for IPv4? Why not /128s for IPv6 or, conversely, no prefixes for IPv4?
---
> IP Addressing Model in Ad Hoc Networks Title doesn't fit the document too well - the document is not only about ad hoc networks, and it doesn't describe a general IP addressing model, just guidelines for addressing router interfaces.
It seems the content of this document could be summarized "if you want to use a routing protocol that requires unique addresses (within the routing domain), link-local addresses are not sufficient (since they're unique only within a link)". I wonder if the document title should be more precise about this? Perhaps something like "Why Link-Local Addresses Are Not Sufficient For Ad Hoc Routers"?
The Gen-ART Review by Francis Dupont on 2010-02-27 included very minor editorial comments. Please consider them if an update to this document is needed for any reason.
draft-ietf-csi-hash-threat
Well written document, thanks. I had a few comments though: Term ADD not defined. > Theoretically this attack could harm > SEND, but in real-world situation is to achieve it. ... is hard to achieve it? > From the security > point of view, at the moment, this solution is more reasonable > then defining different hash algorithm for each hash. ... than defining ...? > The computation of the Digital Signature field is described > [rfc3971]. ... described in? > The computation of the Digital Signature field is described > [rfc3971]. It is produced as the SHA-1 hash over the IPv6 addresses, > the ICMPv6 header, the ND message and other fields, e.g. the Message > Type Tag and ND options, and signed with the sender's private key. > Private key corresponds to the public key in the CGA parameters > structure. It is usually authorized through CGAs. The signature field simply binds the private and public key together. It works for both CGA and certificate-based SEND. Indeed, routers use the certificate-based mode in practice exclusively. > o The third possible solution is to encode the algorithm in the CGA. > This would reduce the strength of the CGA and make it vulnerable > to brute force attacks. ... and also bidding down attacks, if I'm not mistaken. If the hash algorithm is part of the CGA parameters structure, simply choose a hash algorithm that is completely broken and find a value that matches the victim's address AND uses the bad algorithm within the CGA parameters structure. > o Possible solution is also the hybrid solution which would require > the hash algorithm to be the same as CGA, if CGA option is > present, and to use the Hash agility option if the CGA option is > not present. In such way, SEND is not bound exclusively to CGA. Isn't there also a hybrid solution where the hash is in the address bits for CGA based addresses, and all certificate-related hash operations are in the certificate? But maybe I'm missing something obvious. > o None of the previous solutions supports the negotiation of the > hash function. One of possible solutions is the negotiation > approach for the SEND hash agility based on the Supported > Signature Algorithm option described in [sig-agility]. I would have noted the bidding-down issue already here (as you do for some other alternatives). > The negotiation approach for the hash agility in SEND based on the > Supported Signature Algorithms option is vulnerable to bidding-down > attacks, which is usual in the case of any negotiation approach. > This issue can be mitigated with the appropriate local policies. Perhaps some mitigation can be offered, but policy really isn't a solution to the bidding down problem. Anyway, the security consideration section kind of ends without making a conclusion. My conclusion -- perhaps not surprisingly! -- is that the RFC 4982 approach seems to be valid approach. And this is what current standards track specifications say. Do the authors of this document want to change that situation, or not? It would be useful to draw a conclusion.
Is this document INFORMATIONAL or STANDARDS TRACK? The ballot say INFO and the
document says STANDARDS TRACK. If you meant to say INFORMATIONAL, I will be
happy to clear this discuss.
Intended status is informational.
INTRODUCTION, paragraph 2:
> Intended status: Standards Track
DISCUSS: I may be missing something obvious, but why is this document
on the standards track? It's a threat analysis that merely makes a few
observations on hash agility might be added to SEND in the future.
Wouldn't Informational be the appropriate category?
COMMENT: AD, this document needs a ballot issued. List of editorial nits sent directly to the authors.
Based on the SecDir reviews by Julien Laganier and Paul Hoffman,
it seems this document needs a major rewrite (and one of the
authors seems to agree):
http://www.ietf.org/mail-archive/web/secdir/current/msg01540.html
http://www.ietf.org/mail-archive/web/secdir/current/msg01537.html
http://www.ietf.org/mail-archive/web/secdir/current/msg01536.html
There are a couple of minor warnings reported by idnits, and it would be good to fix these if a new revision of the document is being prepared. --- Section 3.2 s/concer/concern/ --- Section 3.2 Even though real-world scenarios make SEND immune to recent hash attacks introduced through X.509 certificates, theoretically they are possible. This feels like a contradiction or is confusing. If the attacks are possible, do we need to worry about them? If SEND is immune, we do not need to worry even if the attacks are easy and possible. If we *do* need to worry about them, then obviously SEND isn't immune.
Assuming Informational RFC. The Gen-ART Review by Pete McCann on 2010-03-09 included some editorial comments. Please consider them if an update to this document is needed for any reason.
The OPS-DIR review performed by Richard Woundy raised a number of issues that
deserve consideration before the document can be approived:
1. Section 3. “Supposing that the hash function produces an n-bit long output,
since each output is equally likely, an attack takes an order of 2^n operations
to be successful. Due to the birthday attack, if the hash function is supplied
with a random input, it returns one of the k equally-likely values, and the
number of operations can be reduced to the number of 1.2*2^(n/2) operations.”
About the use of ‘n’ and ‘k’ as variables. Does k = 2^n? Worse yet, the only
other time ‘k’ is mentioned as a variable, it is defined as a key (in section
3.4). In any case, I would change the second sentence to something like the
following for greater clarity: “Due the birthday attack, if the hash function is
supplied with a series of random inputs, the likely number of inputs required to
produce a single hash collision can be reduced to 1.2*2^(n/2).”
Is there a solid technical reference to the “birthday attack”? Since I am not a
security expert but otherwise curious about this, I looked it up in Wikipedia:
<http://en.wikipedia.org/wiki/Birthday_attack>. The Wikipedia article suggests
that the number of hash inputs to obtain a single hash collision can be reduced
to about 1.25*2^(n/2) input – where 1.25 is approximately the square root of pi
/ 2 – but I am not sure about the mathematics. Again, I AM NOT A SECURITY
EXPERT.
2. Section 4. There are five proposed solutions to enable SEND to leverage new
hash algorithms (such as SHA-3) via hash algorithm agility.
Which of the solutions is the recommendation of this document? I am guessing it
is number five: “negotiation approach for the SEND hash agility based on the
Supported Signature Algorithm option described in [sig-agility]”, mostly because
there is a reference to an actual draft in that proposal. But the document never
comes out and says that explicitly. It should, especially since the Abstract
claims to “decide” this.
There is no discussion in this section about hash agility concerning backwards
compatibility, i.e. the situation where some SEND devices support sig-agility
and others do not. At least it should be raised as an issue to be overcome. To
be fair, this topic does seem to be addressed in http://tools.ietf.org/html
/draft-cheneau-send-sig-agility-01#section-2.1.
3. Section 6. Security Considerations
“This issue can be mitigated with the appropriate local policies.” Maybe this is
obvious to the author, but I would state what should be configurable in the
local policies. Here is related text from the Security Considerations section of
[sig-agility], http://tools.ietf.org/html/draft-cheneau-send-sig-
agility-01#section-7: “To mitigate this issue, nodes are allowed, on a local
policy, to refuse to check certain types of signature (i.e. those which are
[known] to be flawed) and will treat the associated messages as unsecured.”
The threat analysis seems to rely on the existence of human readable fields in
X.509 certificates for the ADD process (section 3.2). Is there an implicit
requirement that a human that is managing the SEND device be able to read and
validate these fields? Or is this validated in some automated manner?
There are a significant number of typos in the document that detract from its readability. Abstract The first use of the acronym ‘SEND’ should be spelled out: /SEND/SEcure Neighbor Discovery (SEND)/ /Current SEND specification/The current SEND specification/ /for the hash algorithm agility/for hash algorithm agility/ /to provide analysis/to provide an analysis/ Section 1 /Cryptographically Generated Addresses (CGA)/Cryptographically Generated Addresses (CGAs)/ /Authorizaton Delegation Discovery/Authorization Delegation Discovery/ /variaty/variety/ /First hash attacks/The initial hash attacks/ /significantlly/significantly/ /Depending on the way how the Internet protocol uses the hash algorithm, Internet protocol can be affected/Depending on how the SEND protocol relies on the hash algorithm, Internet Protocol (IPv6) operation can be affected/ Section 3 /Up to date, all demonstrated attacks are attacks against a collision-free property./To date, all demonstrated attacks are attacks against the collision- free property./ /underlaying hash function/underlying hash function/ /no matter of the hash algorithm weaknesses/no matter the weaknesses of the hash algorithm/ /fingerprints/or fingerprints/ /on SEND by the cases of use/on SEND by the use cases/ /support the hash agility/support hash agility/ Section 3.2 /Router sends to a host/A router sends to a host/ /Potential problem for the attacker/The potential problem for the attacker/ /allowe/allow/ /does not allowe to provide/does not allow/ /biggest concer are/the biggest concerns are/ /such human-readble data such would prevent attacks/such human-readable data would prevent attacks / Section 3.3 /is described [rfc3971]/is described in [rfc3971]/ /Private key corresponds/The private key corresponds/ /The Digital Signature field the example of the non-repudiation digital singature/The Digital Signature field is an example of a non-repudiation digital signature/ /Possible attacks on such explicit digital signature/A possible attack on the Digital Signature field/ /He underlays one of the messages to be signed/The attacker signs one of the messages/ /but in real-world situation is to achieve it/but in real-world situations it seems difficult to achieve/ Section 3.4 /the integrity protection/integrity protection/ /the collision attacks/collision attacks/ /a non human-readable data/non human-readable data/ Section 4 /Previous section/The previous section/ /SEND context prevents/The SEND context prevents/ /The most effective and secure would be/The most effective and secure solution would be/ Section 6 /offeres/offers/ /by providing solution for the hash agility support/by providing a solution to support hash agility/
draft-ietf-l3vpn-mvpn-considerations
RFC 4364 is cited but the reference is not defined.
draft-ietf-pana-preauth
In section 6, I'm not clear what "authorized PaCs" are in this sentence: It is recommended that the authorized PaCs are limited to well-known IP networks for a given PAA.
RFC 5191 says the following:
10.2.2. Flags
There are 16 bits in the Flags field of the PANA message header.
This document assigns bit 0 ('R'), 1 ('S'), 2 ('C'), 3 ('A'), 4
('P'), and 5 ('I') in Section 6.2. The remaining bits MUST only be
assigned via a Standards Action [IANA].
So to my understanding this document can not be published as an experimental and
get the E bit assigned.