headers
Kurt Zeilenga | 1 May 2008 01:04
Favicon

Secdir review of draft-daboo-imap-annotatemore-13

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 others should treat  
these comments just like any other comments.

This document defines an extension to IMAP [RFC3501] to allow metadata  
(or annotations) to attached to and read from various objects.  I see  
no serious problems with this draft, but do have some comments.

I think the second consideration might better be stated first and  
worded not only to discuss arbitrary data, not just data of arbitrary  
size.  Hence, an attacker can not only use this as an avenue for a  
denial of service attacks upon servers and upon the clients of any  
user, but can use the mechanism to mount a wider range of attacks upon  
servers and clients.  I recommend this be called out even if this  
issue exists in the base protocol.

There should be some discussion of any possible privacy concerns  
regarding any of the defined entries.   Also, when you say "all users  
of the system", do you really mean all?  Some implementors might take  
this as precluding use of access controls to restrict who sees what.   
It might be better to drop replace "all" with "authorized".

A couple of non security related comments:

I assume text/plain entries can span multiple lines.  It would be good  
to include a multi-line example in the document.  Also, an octet  
string example might be useful.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Spencer Dawkins | 1 May 2008 03:39

Gen-ART Review of draft-ietf-mpls-ldp-capabilities-02

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: draft-ietf-mpls-ldp-capabilities-02
Reviewer: Spencer Dawkins
Review Date: 2008-04-30
IETF LC End Date: 2008-04-25 (yeah, I'm late)
IESG Telechat date: (if known)

Summary:

This draft is almost ready for publication as a Proposed Standard.

Comments:

Almost all my "review comments" below are about 2119 language - this is a 
very SHOULD-y draft. I'd especially call Russ's attention to my comment 
about multiple occurrences of the same capability in one message, in Section 
7.

idnits 2.08.08 reports "no issues", FWIW.

Abstract

   A number of enhancements to the Label Distribution Protocol (LDP)
   have been proposed.  Some have been implemented, and some are
(Continue reading)

Permalink | Reply | 0 comments |
headers
Dean Anderson | 1 May 2008 01:31

Re: Blue Sheet Change Proposal

Sorry, missed this. Inline:

On Tue, 15 Apr 2008, TS Glassey wrote:

> Dean -
> ----- Original Message ----- 
> From: "Dean Anderson" <dean <at> av8.com>
> To: "Wes Beebee (wbeebee)" <wbeebee <at> cisco.com>
> Cc: "IETF Discussion" <ietf <at> ietf.org>
> Sent: Wednesday, April 09, 2008 10:28 PM
> Subject: RE: Blue Sheet Change Proposal
> 
> 
> > Speaking as president of the LPF; not a lawyer but a knowledgeable
> > layman.
> >
> > I think you are correct that the patent issue is a red herring.
> 
> No its not.
> 
> > The
> > patentee has the _right_ (not the obligation) to keep patent application
> > contents secret.
> 
> Sure but not when they submit that IP to others to get their 'contributed 
> work product' added into that IP.
> 
> So in response to your commentary, "No Dean they do not because that would 
> constitute an act of fraud by the party Submaringing the Patent in that they 
> are 'extorting through an apparent agreement as to joint ownership of the
(Continue reading)

Permalink | Reply | 0 comments |
headers
Olafur Gudmundsson | 1 May 2008 17:33

RE: Last Call: draft-ietf-pce-pcep (Path Computation Element (PCE) Communication Protocol (PCEP)) to Proposed Standard

Yes this is well written document,
I find it scary how many flags fields the document defines in message types
with no flags defined and NO GUIDANCE on the scope of these flags.
Are they per "object Class +object type" or per message type.

Are these needed or just nice to have?
What is the harm to just define these fields as Reserved ?

         Olafur

At 05:56 30/04/2008, Romascanu, Dan (Dan) wrote:
>I would like to congratulate the editors for the inclusion and content
>of the Manageability Consideration section. It is well written, and
>includes detailed information that will be very useful for implementers
>as well as for operators who will deploy the protocol.
>
>One nit: in section 8.6 s/number of session/number of sessions/
>
>Dan
>
>
> > -----Original Message-----
> > From: ietf-announce-bounces <at> ietf.org
> > [mailto:ietf-announce-bounces <at> ietf.org] On Behalf Of The IESG
> > Sent: Wednesday, April 16, 2008 11:49 PM
> > To: IETF-Announce
> > Cc: pce <at> ietf.org
> > Subject: Last Call: draft-ietf-pce-pcep (Path Computation
> > Element (PCE) Communication Protocol (PCEP)) to Proposed Standard
> >
(Continue reading)

Permalink | Reply | 0 comments |
headers
Spencer Dawkins | 2 May 2008 05:41

Gen-ART Review of draft-ietf-bfd-base-08

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: draft-ietf-bfd-base-08
Reviewer: Spencer Dawkins
Review Date: 2008-04-30
IETF LC End Date: 2008-05-07
IESG Telechat date: (if known)

Summary: This document is almost ready for publication as a Proposed 
Standard.

Comments: I have a small number of review comments that involve 2119 
language.

There are a small number of nits reported:

  == No 'Intended status' indicated for this document; assuming Proposed
     Standard

  ** There is 1 instance of too long lines in the document, the longest one
     being 1 character in excess of 72.

  == Missing Reference: 'KEYWORDS' is mentioned on line 48, but not defined

  == Unused Reference: 'KEYWORD' is defined on line 1985, but no explicit
(Continue reading)

Permalink | Reply | 0 comments |
headers
Thomas Narten | 2 May 2008 06:53
Picon
Favicon

Weekly posting summary for ietf <at> ietf.org

Total of 25 messages in the last 7 days.

script run at: Fri May  2 00:53:01 EDT 2008

    Messages   |      Bytes        | Who
--------+------+--------+----------+------------------------
 12.00% |    3 | 13.34% |    31847 | bernard_aboba <at> hotmail.com
 12.00% |    3 |  9.69% |    23118 | bertietf <at> bwijnen.net
  8.00% |    2 | 11.69% |    27893 | spencer <at> wonderhamster.org
  8.00% |    2 |  7.66% |    18274 | heinerhummel <at> aol.com
  8.00% |    2 |  7.36% |    17575 | bruno.decraene <at> orange-ftgroup.com
  4.00% |    1 |  8.02% |    19144 | bernarda <at> windows.microsoft.com
  4.00% |    1 |  6.14% |    14661 | gzorn <at> arubanetworks.com
  4.00% |    1 |  5.84% |    13942 | glenzorn <at> comcast.net
  4.00% |    1 |  5.06% |    12066 | dean <at> av8.com
  4.00% |    1 |  4.88% |    11653 | dnelson <at> elbrysnetworks.com
  4.00% |    1 |  2.89% |     6897 | narten <at> us.ibm.com
  4.00% |    1 |  2.87% |     6856 | randy_presuhn <at> mindspring.com
  4.00% |    1 |  2.68% |     6396 | stbryant <at> cisco.com
  4.00% |    1 |  2.56% |     6103 | ogud <at> ogud.com
  4.00% |    1 |  2.54% |     6060 | paulfunk <at> alum.mit.edu
  4.00% |    1 |  2.50% |     5961 | dromasca <at> avaya.com
  4.00% |    1 |  2.36% |     5633 | kurt.zeilenga <at> isode.com
  4.00% |    1 |  1.92% |     4574 | jari.arkko <at> piuha.net
--------+------+--------+----------+------------------------
100.00% |   25 |100.00% |   238653 | Total
Permalink | Reply | 0 comments |
headers
Eric Rescorla | 3 May 2008 23:12

Re-review of draft-ietf-simple-imdn

I originally reviewed version -06 of this document
(2008-02-8). Examining the diff, it does not appear to me that any of
my comments from my previous review. Looking back in my mail folder, I
don't see any reasponses from the authors telling me my review was
wrong, so I'm retransmitting it here.

-Ekr

$Id: draft-ietf-simple-imdn-06-rev.txt,v 1.1 2008/02/08 18:17:54 ekr Exp $

This document describes a mechanism for IM senders to request status
notifications for their IMs. The sender attaches a header specifying
the status conditions he wants to be notified of and intermediaries
and the receiving UA notify the sender (or someone else of his choice)
subject to policy constraints.

One thing I'm not clear on is how the recipient determines where to
send the IMDN. Are they supposed to read the "From" field? One thing
that I don't get is how the IMDN-Route header interacts here.
It looks to me like this gets stuffed in the "To" in the IMDN.
What happens if someone puts an IMDN-Record-Route that points
to an IMDN-ignorant UA?

Overall, this document seems pretty well written and clearly lays out
the security issues.

That said, I'm concerned about the bounce/reflection threats discussed
in S 14 (where the sender asks for notification to a third party
victim).  I'm particularly concerned about the "note" field, since a
natural implementation seems to be to include an excerpt from the
(Continue reading)

Permalink | Reply | 20 comments |
headers
SM | 3 May 2008 23:14

Re: draft-pearson-securemail-02.txt

At 23:15 29-04-2008, Internet-Drafts <at> ietf.org wrote:
>         Title           : Applicability Statement for SecureMail: A 
> framework for increasing email security

In Section 2:

   "email delivery until the information is available again - and yet,
   email is about speedy delivery.  In addition, the behaviour of email"

Email is not about speedy delivery.  It is a best effort.  From a 
user's point of view, it may appear speedy compared to snail 
mail.  Furthermore, the sender has an expectation that the message 
will reach the intended recipient(s).  Some operators silently drop 
bounces in the bit bucket and delivery failures go unnoticed.

In Section 4:

   "It uses Transport Layer Security (TLS) for confidentiality and
    integrity of the message and Sender ID [RFC4406] and the Sender
    Policy Framework (SPF) [RFC4408] to authenticate the sender."

TLS only creates provides confidentiality and integrity of the 
message between the sending server and receiving server.  It's all 
plain text at the submission and delivery stages.  To preserve the 
integrity of the message, you'll need some assurance between sender 
and receiver.  SenderID and SPF does not authenticate the sender.  It 
only provides a means to restrict which server can send mail for a domain.

In Section 4.2, you mention that the sender authentication methods 
mitigate the risk.  If you are using an email address from an ISP,
(Continue reading)

Permalink | Reply | 2 comments |
headers
Frank Ellermann | 4 May 2008 00:44
Picon
Picon

Re: draft-pearson-securemail-02.txt

SM wrote:

> SenderID and SPF does not authenticate the sender.

For starters they have different concepts of "sender",
PRA and envelope sender, and RFC 4408 section 10.4 
offers references (AUTH + SUBMIT) for folks wanting
more.  

> It only provides a means to restrict which server
> can send mail for a domain.

A domain indicated by PRA *or* envelope sender, with 
different ideas about this "or" being exclusive or
inclusive, and as indicated in the HELO or EHLO.  

The public enthusiasm for adding op=auth indicating
RFC 4409 option 6.1 "enforced submission rights" was
limited, IMO it would add what is missing "for folks
wanting more" wrt RFC 4408, but as long as receivers
are not interested it's pointless.

An op=auth for PRA would be slightly more convoluted:

It would indicate RFC 4409 option 8.1 "add 'sender'"
*plus* a fix for this section covering Resent-From,
but the RFC 4409 authors already said that they are
not interested to fix section 8.1 in 4409bis, and the
Last Called 2822upd also did not update its section
boiling down to "PRA violates MUSTard in 2822(upd)".
(Continue reading)

Permalink | Reply | 1 comment |
headers
Glen Zorn | 5 May 2008 02:27
Favicon

Secdir review of draft-ietf-iptel-tel-reg-05

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.  

I found no security problems with this draft.  A couple of nits: section
4.1, paragraph 1 says "New tel URI parameters and new values for
existing tel URI parameters MUST be registered by IANA" but I think it
should be "New tel URI parameters and new values for existing tel URI
parameters MUST be registered with IANA"; section 5, last sentence says
"The supporting RFC publications for parameter registrations described
this specification MUST provide detailed security considerations for
them." but it seems like there is at least one word missing after
"described" -- maybe "described in"?
Permalink | Reply | 1 comment |

Gmane