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

From: [email-masked]
Date: Mon, 07 Jun 2004 13:45:56 +0000

>I don't understand the comment.
>Names of the form "user@host" are used in a number of places (email, login
>names in ftp://user@host/ URLs, NAIs for roaming, IM identifiers and more).
>
>I *think* the purpose of the paragraph
>
>      Names with the at-sign ('@') in them are allocated by the owner of
>      DNS name after the at-sign (hierarchical allocation in [RFC-
>      2343]), otherwise the same restrictions as above.
>
>is to give local extensibility to protocol parameter identifiers; there
>are a number of variants that are commonly suggested for this, and DNS
>based naming is one of them. (It's not a particularly good one, though -
>DNS names change hands too often to be considered "completely stable", and
>we do tend to want stability in parameter naming..... it also gives all
>the problems of "X-" headers in enabling wide deployment of
>non-interoperable extensions; if this isn't currently in use, and we need
>to push back on the document for other reasons, it might be worth asking
>the authors whether losing this would cause them heartburn.

---

From: [email-masked]
Date: Mon, 07 Jun 2004 13:45:55 +0000

---

From: Damien Miller <[email-masked]>
Date: Tue, 08 Jun 2004 16:26:39 +1000

>>the authors whether losing this would cause them heartburn.

OpenSSH uses this feature now and I plan to use it in the future
for new extentions (ciphers and auth methods). Banning this will render
widely deployed software non-compliant.

The use of user@domain in the secsh protocol is completely orthogonal to
its use in URIs or email. These names are used as internal protocol
identifiers, not in addressing. IMO this is much more elegant a
namespace than X-whatever.

The "stability" issue seems irrelevant too - there are no catastrophic
consequences if the domain name goes away. Remember that these are,
by definition, vendor or site-local extensions.

-d

---

From: "Timo J. Rinne" <[email-masked]>
Date: Tue, 08 Jun 2004 17:05:53 +0300

> by definition, vendor or site-local extensions.

I agree.  Above is also fully applicable to Tectia SSH products of SSH 
Communications Security Corp.

-- 
Timo J. Rinne <[email-masked]>        Fredrikinkatu 42   +358 20 500 7000 T
Director, New Product Technologies FIN-00100 Helsinki +358 20 500 7051 F
SSH Communications Security Corp.  Finland            http://www.ssh.com

---

From: Bill Sommerfeld <[email-masked]>
Date: Tue, 08 Jun 2004 11:21:19 -0400

[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

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 8 Jun 2004 11:18:21 -0500

> by definition, vendor or site-local extensions.

I agree.

The '@' sign here is used to reserve part of the namespace of named
SSHv2 protocol elements for private allocation (the extensions that this
enables are typically not proprietary, though they may be).

More importantly, these names are not visible to users and so users
won't try to interpret them -- these names are internal to SSHv2.

This feature has been used in production deployments for several
extensions to SSHv2, so it cannot be removed, even if the removal made
sense -- which it does not.

Nico
--