Re: secdir review of draft-ietf-abfab-gss-eap-naming-05

[Sam Hartman]

> "Richard" == Richard Barnes  writes:

Richard> I have reviewed this document as part of the security
Richard> directorate's ongoing effort to review all IETF documents
Richard> being processed by the IESG.  These comments were written
Richard> primarily for the benefit of the security area directors.
Richard> Document editors and WG chairs should treat these comments
Richard> just like any other last call comments.
Richard> text that causes me concern is the following: " These names
Richard> MUST NOT be used for attributes issued by a party other
Richard> than one closely associated with the source of credentials
Richard> unless the source of credentials is re-asserting these
Richard> attributes.  " The use of "MUST NOT" here implies that the
Richard> intent is for the application reading attributes to have
Richard> assurance that they are "closely associated with the
Richard> source".  However, the application has no way of verifying
Richard> whether this MUST NOT has been adhered to, so the entity
Richard> setting names is trusted in this regard.  The document
Richard> should note this, and the corresponding risk that the namer
Richard> will break this MUST NOT.  This risk is hard for the reader
Richard> to evaluate because (AFAICT) the document doesn't specify
Richard> who sets names in this system.  (Passive voice considered
Richard> harmful.)

Yeah, we need more clarity around that as everyone who reads the
document brings up this issue.  I think it's OK because enforcing that
MUST NOT is a spec design issue in draft-ietf-abfab-aaa-saml, and a
couple of drafts in kitten.  I.E. if the IETF does its job, then
applications can depend on that MUST NOT being enforced.  We need to
make it more clear and we need to be careful when reviewing those other
specs.

So, I'll work on proposing text for this, but I think this is a clarity
issue rather than a security problem.

secdir review of draft-ietf-abfab-gss-eap-naming-05

[Richard Barnes]

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the IESG.
These comments were written primarily for the benefit of the security
area directors.  Document editors and WG chairs should treat these
comments just like any other last call comments.

This document defines a method for assigning names to information from RADIUS 
and GSS-EAP, in particular SAML attributes received via the latter.

The security considerations in this document are difficult to evaluate because 
the general architecture is unclear to me, e.g., who attaches these names to 
things and who reads them.  (The naming scheme itself seems well defined.)  The 
text that causes me concern is the following:
"
These names MUST NOT be used for attributes issued by a party other than one 
closely associated with the source of credentials unless the source of 
credentials is re-asserting these attributes.
"
The use of "MUST NOT" here implies that the intent is for the application 
reading attributes to have assurance that they are "closely associated with the 
source".  However, the application has no way of verifying whether this MUST 
NOT has been adhered to, so the entity setting names is trusted in this regard. 
 The document should note this, and the corresponding risk that the namer will 
break this MUST NOT.  This risk is hard for the reader to evaluate because 
(AFAICT) the document doesn't specify who sets names in this system.  (Passive 
voice considered harmful.)  

If the names did not have this implied security semantic, then the identity of 
the namer wouldn't be an issue.  Then this document could just define the 
format of the names and move on.

This is a nonsense MUST: "a service MUST make a policy decision"

Editorial:
Page 7: "thatwe know"
Page 8: "MAy be absent" (or is this an update to RFC 2119?  :) )
Page 11: "mechansisms are permitted"
Page 13: "Sam hartman"

MalcolmBETTS90013533 is out of the office.

[Malcolm . BETTS]

I will be out of the office starting  03/10/2012 and will not return until
22/10/2012.

I will not have access to email, I will respond to your message when I
return on October 22nd.

Gen-ART review of draft-ietf-6man-udpchecksums-04

[Peter Yee]

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at


Document: draft-ietf-6man-udpchecksums-04
Reviewer: Peter Yee
Review Date: Sep-30-2012
IETF LC End Date: Oct-2-2012
IESG Telechat date: Oct-11-2012

Summary: This draft is basically ready for publication, but has nits that
should be fixed before publication. [Ready with nits.]

Presuming the assumptions in I-D.ietf-6man-udpzero are valid and agreed to
by the community, this document
provides an update to 2460 to allow the use of zero checksum UDP packets
over IPv6 in certain cases involving
protocols tunneled inside of UDP packets.

Nits:

General: references throughout the document to various Internet Drafts will,
of course, need to be cleaned up.

General: a comma after "e.g." is preferred in American English.

Abstract, last sentence: "defines" -> "define"

Section 3, first sentence: "tunnelled" -> "tunneled"
Change the comma after "checksum" to a period to split the sentence,
capitalizing the following "there".
Then change "compute" -> "computing" and "check" -> "checking" for
parseability.

Section 3, last sentence: "cost, " -> "cost".

Section 4, 4th paragraph: "The below" -> "The points below"
Also: "an UDP" -> "a UDP"

Section 4, 1st bullet item, last sentence: "reception UDP" -> "reception of
UDP"

Section 4, 4th bullet item, 1st sentence: "port, destination" -> "port, and
destination"
Also: "fields :" -> "fields:" (eliminate a superfluous space
character)

Section 5, paragraph 5 (the replacement text), last sentence: you refer to
RFC 2460.  That
would seem to read oddly when the replacement text is actually inserted into
RFC 2460.
I think it would be preferable to put in a specific cross-reference to where
in 2460 the
existing method resides instead of the document itself.

Section 5, item 2, last sentence: "call," -> "call"

Section 5, item 5, 1st sentence: "UDP Tunnels" -> "UDP tunnels" for
consistency.

Section 5, item 6, 2 occurrences: "Non-IP" -> "non-IP"

Section 5, item 8, parenthetical: " Necessary" -> "necessary".  Note the
leading space before
"Necessary" that is omitted in the replacement.

Section 8 includes one incredibly long run-on sentence.  I would suggest
splitting it as follows:

However, this does not lead to any significant new vulnerabilities as
checksums are not a
security measure and can be easily generated by any attacker. Properly
configured tunnels
should check the validity of the inner packet and perform any needed
security checks
regardless of the checksum status. Most attacks are generated from
compromised hosts
which automatically create checksummed packets (in other words, it would
generally be
more, not less, effort for most attackers to generate zero UDP checksums on
the host).

Authors' Addresses:
Unused Fax and URI fields may be omitted.
Phone numbers  should be presented in international dialing format to
facilitate use, e.g.,
+1 703 501 4376 and +46 10 714 82 87.

Re: [dnsext] Last Call: (Extension Mechanisms for DNS (EDNS(0))) to Internet Standard

[John C Klensin]

--On Tuesday, October 02, 2012 23:39 -0700 SM 
wrote:

>  From Section 7 of the draft:
> 
>   "Responders which choose not to implement the protocol
> extensions
>defined in this document MUST respond with a return code
> (RCODE) of
>FORMERR to messages containing an OPT RR in the additional
> section
>and MUST NOT include an OPT record in the response."
> 
> That looks like a change [1] to STD 13.  Responders which
> respond with a return code of 4 would not be compliant.
>...
> The IETF might wish to consider whether it is necessary to
> align the text in the two drafts.
>...

One observation on this part of the thread...

While I'm much more concerned about the substantive impact of
deprecating a possibly-useful (even if painful to use) feature
without adequate justification and documentation, I believe that
documents being processed for classification as Internet
Standard should be held to a very high standard for editorial
quality and clarity and consistency of relationships to other
specifications.  If others agree with that belief, SM's analysis
appears to represent a strong case that the current version of
this draft (and possibly draft-ietf-dnsext-rfc6195bis-04) are
not ready for prime time.

   best,
john

Re: [dnsext] Last Call: (Extension Mechanisms for DNS (EDNS(0))) to Internet Standard

[John C Klensin]

--On Wednesday, October 03, 2012 10:43 +0200 João Damas
 wrote:

> I believe you are saying the same things when you are both
> saying that for this to work there may be more than one way to
> do it but all options require completely new functionality in
> implementations (either by implementing support for new labels
> types or by implementing new fall back behavior). The
> conclusion is still the same.

Hmm.  I'm not completely sure who "you" was intended to include,
but my conclusion from the above is that there is no substantial
justification for eliminating, at this time, a capability that
might prove better on balance when and if new capabilities are
considered and tradeoffs evaluated.

To summarize my perspective on this as of now:

(1) No one is making a case for retaining binary labels

(2) The case has not been made, at least in the document, for
eliminating label types.  An argument that there are other ways
to do a particular type of label is not persuasive unless there
is a comprehensive and written analysis of what other labels
might be considered and what the tradeoffs among approaches
would be.  And an argument that almost any significant added
functionality would be very slow and costly to deploy may be an
argument for not approving such functionality, but it is not an
argument for eliminating one, but not all, of the underlying
capabilities.

IMO, this discussion has turned up two ways in which the case
for eliminating the possibility of additional label types could
be made:

(2.1) Demonstrating that simply having the capability defined
and available in principle is somehow harmful.

(2.2) The WG has consensus on a bright line that defines the
nature of proposals that would require going to DNSng rather
than EDNSx-type extensions to the current model, has concluded
that any extensions or alterations to the label definition of
1034/1035 would require crossing that line, and is prepared to
document that line and get IETF consensus on it (either as part
of this document or one normatively referenced from it).

best,
john

Re: [dnsext] Last Call: (Extension Mechanisms for DNS (EDNS(0))) to Internet Standard

[SM]

From Section 7 of the draft:

 "Responders which choose not to implement the protocol extensions
  defined in this document MUST respond with a return code (RCODE) of
  FORMERR to messages containing an OPT RR in the additional section
  and MUST NOT include an OPT record in the response."

That looks like a change [1] to STD 13.  Responders which respond 
with a return code of 4 would not be compliant.


On publication of draft-ietf-dnsext-rfc2671bis-edns0-09, will it be 
part of STD 13?


From RFC 3225:

  "In the event a server returns a NOTIMP, FORMERR or SERVFAIL response
   to a query that has the DO bit set, the resolver SHOULD NOT expect
   DNSSEC security RRs and SHOULD retry the query without EDNS0 in
   accordance with section 5.3 of [RFC2671]."

There's a normative reference [2] to that RFC in this draft.

In Section 1:

 "This document deprecates Extended Labels, and therefore Binary Labels,
   obsoleting [RFC2673]."

draft-ietf-dnsext-rfc6195bis-04 mentions that:

 "The Binary label type is Historic [RFC2671bis]."

The IETF might wish to consider whether it is necessary to align the 
text in the two drafts.


Regards,
-sm

1. Whether it is a change or not depends upon how one reads RFC 
6410.  The write-up mentions that there are no unused features in the 
specification that greatly increase implementation complexity.  It is 
unclear whether this document is a minor revision of RFC 2671.


2. http://www.ietf.org/mail-archive/web/weirds/current/msg01668.html