ietf-clear
[Top] [All Lists]

Re: [clear] CSV-CSA draft questions

2005-09-01 23:09:48

On Sep 1, 2005, at 6:26 PM, Earl Hood wrote:


Questions and comments are based upon the draft
draft-ietf-marid-csv-csa-02.html:

* The draft expiration is Aug 21, 2005.  Will there be a new revision?
  Does CSV have a future?


There will be a presentation made at the next MAAWG. I am also writing a draft to explain how HELO and signing-domain provide a name basis for establishing accountability. The aspect of protecting system and network resources is best done using HELO, rather than a signature, however the same name basis can be applied. Signed email will have a future and once a name basis becomes more common, it will become more apparent the value HELO offers.


* In step 1 of Section 4, is the domain name associated with the
  SMTP client obtained from the EHLO command?  If so, why not
  state that.

  I recommend to provide all necessary information (or explicit
  references to it) in the authentication/authorization steps.
  This will make it easier for implementors to create conforming
  implementations.


These are good inputs.


* I need some clarification of the use of "bit-fields".  When
  using the term "bit-fields" there is direct implication that
  the field has 16 distinct values based on 0-15 bits of the
  16 bit integer.  For example:

   --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- ---
  | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 1 | 1 | 0 |
   --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- ---
    15  14  13  12  11  10  9   8   7   6   5   4   3   2   1   0


Actually the IETF has a practice of defining the MSB as bit 0. This can be confusing when describing bit settings. Rather than specifying the bit ordering, the settings were defined by value. A bit with a value of 1 would be bit 15 per IETF big endian conventions, and bit 0 per common little endian architectures. Bit values of 1, 2, or 4 was an attempt to avoid this ambiguity.


  Contains two distinct values versus the single integer value of 6.


There are two tables where one indicates the resulting combined values.


* Does bit-field numbering start at 0 or 1? Looking at the description
  for Weight, it mentions bit value 1 and 2.  Does this indicate the
1st and 2nd least significant bits? If so, why doesn't bit numbering
  start with 0?


The LSB bit can offer a value of 1 or 0. When asserted, this bit offers a value of 1.


* I'm confused on the relationship of the Weight Bit Values and
  Weight Summed Values.  Is this have to do with the weight summation
  described in RFC-2782?


No.  This was to clarify the bit value approach.


* Does the Port part of the record have any real value?  If an
SMTP server encounters a EHLO domain that does not have a CSA record,
  is the server supposed to utilize the Port field in a previous query
  under the same domain?

  There seems to be some "walking" implications in subsequent text
justifying the setting of Port. This information should be included,
  or explicitly referenced, during the authentication/authorization
  step.


There was an attempt made to limit the number of lookups required. This was done by not requiring a search in any direction by making the assertion apply for all sub-domains. The depth of this label tree was kept constrained as well. The concept was to allow a domain to proclaim all authorized clients will have a CSA record. The initial concept of the CSA did not include this approach, and the Port field has been isolated from the rest of the associated functions.


* Should "walking" even be allowed?  This seems to increase the cost
  of failure and one has to deal with what really constitutes a
  top-level domain.  For example, what about country-based roots:
  com.au, or tx.us?  Does one consider the root domain to always be
  the first domain (right-most) of a full domain name?

Is it reasonable to require a sender to explicitly define SRV records
  for each EHLO name they will use, therefore avoiding any "walking"?


Dave Crocker and John Levine were proponents of this approach which has been replicated to a fashion within the SSP draft. The SSP draft requires upward walking.


* Does an IP address match indicate _authentication_?  And does
  a Weight of 2 indicate _authorization_?

  If so, the parenthetical comment in the following (Section 4):

    If the sending SMTP client[ID-CSV] both authenticated and
    authorized (with Weight equal 2 and the IP address matching),...

  needs to be reverse to match the respective order of "authenticated
  and authorized".

Good point.


-Doug
_______________________________________________
ietf-clear mailing list
ietf-clear(_at_)mipassoc(_dot_)org
http://mipassoc.org/mailman/listinfo/ietf-clear