Re: [apps-discuss] Splitting RRVS

[Ned Freed <[e-mail]>]

> On 3/27/2014 3:35 PM, Murray S. Kucherawy wrote:
> > The IESG's answer to that can probably be found in the comments from the
> > IESG ballots:
> >
> > https://datatracker.ietf.org/doc/draft-ietf-appsawg-rrvs-header-field/ballot/


> Yeah.  I keep forgetting that we now have access to such things...

> I don't recall the rationale for the outcome of SMTP Priority,

If memory serves, it was essentially the opposite situation: The
original focus was on the SMTP extension and the header mechanism was
added later.

Whereas here the header mechanism came first and the extension was added
later.

> but the
> logic in Pete's note appears to be quite broken.

I would not call it broken, but it's definitely overwrought.

> Pete's argument is:
 
> http://datatracker.ietf.org/doc/draft-ietf-appsawg-rrvs-header-field/ballot/#pete-resnick

> > It seems to me that the header field is a complete hack, and has
> > potential for screwing up content signatures when stripped,
> > potentially unnecessarily revealing information to the end user,  and
> > standardizing it encourages trying to tunnel the message instead of
> > bouncing it when the SMTP extension fails.

>       1.  Stripping is an issue for most header fields.  And yes, it
> certainly will break a DKIM signature... IF the signature covers such
> fields and the field is stripped.  The issue is general.  Applied
> consistently, therefore, Pete's concern means that we can never make any
> new header field a standard.  Alternatively, Pete fails to consider
> (recommending) simply not having the signature cover the (potentially)
> problematic field, or, at least, documenting the danger.

SSDD. Every time one of our security mechanisms has the great good luck to get
some traction, we try and build on it, usually with mixed results. (It's really
hard to fault this given how poor our track record with security mechanisms
is.)

DKIM is no exception. It solves an important identification problem for
messages traveling between ADMDs, and arguably does it in a fairly optimal
fashion. But that does not make it a candidate for things like end-to-end user
signatures, where issues including, but hardly limited to, header stripping
invariably show up.

>       2.  The concern for hiding information from the recipient does not
> distinguish between the intended recipient, versus an unintended
> recipient who now has the mailbox address.  This probably makes a
> difference, but I won't pursue it here.  In any event, the premise of
> the stated concern is that having the information only in the envelope
> somehow hides it from the recipient.  Given that envelope information is
> regularly transferred into header fields at delivery time, this
> assumption is not valid.  A separate question to ask is whether
> revealing the information matters. It might also be worth noting that
> most MUAs do not show more than a few, common header fields.

Er, no. Copying envelope information into the header requires implementation
work: You have to not only implement the extension to even have the information
in hand, you'd also have to intentionally extend it to do this. There may be
some implementors out there that go considerably out of their way to violate
security models, but I haven't run into them. Corners get cut a lot more often
than they get added.

>       3. Lastly, the argument that standardization "encourages" use of
> the header field misses the point behind documenting it in the first
> place:  to get consistent behavior.  Pete's argument is that of a purist
> rather than a pragmatist.  Worse, it ignores the nature and purpose of
> standardization, and replaces these with an aesthetic preference.  Is
> the header field a protocol element? (yes)  Is it expected to be useful?
> (presumably yes) Is there a better way to achieve its function?
> (presumably no)  Does it need to be used consistently? (yes)  These are
> the normal kinds of criteria used to determine whether something is
> worthy of standardization, rather than "it's a hack".

I for one don't have a problem calling it a hack. It puts it in good company
with a lot of other standards, some quite important and successful.

> The email operations world would certainly be a better place if
> SMTP-level adoption of options were more progressive.  So the desire to
> rely on the SMTP option, here, makes sense.  This is a delivery-related
> mechanism; so it's optimal to place it in the handling/delivery
> sub-system.  But it's not practical, given long and UNreliable adoption
> of SMTP options.

I'd characterize it as more unpredictable than unreliable, but that's just
a nit.

				Ned