Re: [psg.com #441] IESG - Architecture - atsign - additional IESG Response

[Bill Sommerfeld <sommerfeld%east.sun.com@localhost>]

[Cc's trimmed.]

For the WG (background):

Increased scrutiny of vendor/implementation-specific extension
mechanisms (such as the user@domain syntax used by ssh) by the IESG
appears to be fallout from problems experienced with RADIUS, where
vendor extensions have caused interoperability and security problems.

See:

http://www.ietf.org/internet-drafts/draft-iesg-vendor-extensions-02.txt

For the document editor:

the original issue appears to have resulted with a confusion between
the use of the id@domain syntax; while the syntax of these names
resembles that of RFC822 email addresses, they are most definitely not
email addresses.  I suggest inserting a clarification to that effect
in the section.

For any IESG members listening:

I believe this WG can demonstrate a track record for responsible use
of this feature by the implementor community.

In particular, under the taxonomy described in the above draft, usage
is either "minor extensibility", or does not create a radius-like
security issue as the id@domain options are used in a context which
doesn't allow for "noncritical" options to be ignored.

Most commonly, they're used to select amongst several ways of doing
something in a negotiation; failure to understand an option means that
an alternative option acceptable to both peers may be accepted; if no
alternatives are available, this would likely be due to security
policy -- the peers will simply fail to talk.

It is extraordinarily unlikely that the use of id@domain identifiers
will result in the peers misunderstanding each other; I'd say that the
risk of such problems is dwarfed by the risk to interoperability from
out-and-out implementation errors.

						- Bill