Subject: [apps-discuss] Ted Lemon's No Objection on draft-ietf-appsawg-rfc5451bis-09: (with COMMENT)

From: "Ted Lemon" <[email-masked]>
Date: Wed, 10 Jul 2013 20:29:17 -0700

Ted Lemon has entered the following ballot position for
draft-ietf-appsawg-rfc5451bis-09: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Throughout the document, the term "this header field" and "the header
field" is used to refer to the Authentication-Results header field. This
isn't very user friendly—I keep wondering if the antecedent has changed.
Once it's clear to the reader what the document is about, I think this is
less of an issue, but it made starting to read it kind of painful. I
think it would be more friendly to say "the authref header field" each
time, even though it's an extra word. I realize that this is a fairly
minor cognitive load for the reader, but when it comes to even minor
cognitive loads, less is more.

In 2.5.7:
   Extension results MUST only be used within ADMDs that have explicitly
   consented to use them.
Wouldn't it be better to say:
   Extension results MUST NOT be used within ADMDs that have not
explicitly
   consented to use them.

I suggest this because "MUST only" is not an RFC 2119 key word, but I
think you mean the two words together to be normative.   It's
understandable either way, so this is a minor nit, but take it for what
it's worth.

>From section 5:

   For simplicity and maximum security, a border MTA could remove all
   instances of this header field on mail crossing into its trust
   boundary.  However, this may conflict with the desire to access
   authentication results performed by trusted external service
   providers.  It may also invalidate signed messages whose signatures
   cover external instances of this header field.  A more robust border
   MTA could allow a specific list of authenticating MTAs whose
   information is to be admitted, removing all others.

Although this alludes to the problem of breaking DKIM, for example, it
doesn't fully address it.   A DKIM message may be signed in a way that
can be validated, and yet not come from a trusted external service
provider.  If the DKIM signature includes an Authentication-Results
header, removing it will break the signature, preventing the MUA from
validating it.   This seems like a big loss of functionality, since the
end user doesn't have a way of opting out of this breakage.

This could be easily mitigated by changing the name of the header field
rather than removing it: change it to Elided-Authentication-Results or
something.   Then the MUA can reverse that and calculate the DKIM
signature.

I realize that this may be a non-issue in practice.   I haven't seen a
DKIM signature that signed an Authentication-Results header, and maybe it
just never happens.   But this seems so easy to fix that it ought to be
worth the minor effort involved.

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 11 Jul 2013 11:09:07 +0100

> something.   Then the MUA can reverse that and calculate the DKIM

Don't think its that easy. There could be >1 DKIM Signature header
field and >1 AR header field. Also sounds quite hacky;-)

S.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 11 Jul 2013 12:12:48 +0000

> field and >1 AR header field. Also sounds quite hacky;-)

Deleting headers is also hacky.   Figuring out which headers are covered by a DKIM signature, assuming MTAs that prepend headers, is pretty straightforward—you just see how many of a type of header were listed in the DKIM signature, and consume that many from the header history, starting from the DKIM header.   So yeah, it's hacky, and maybe it's not worth doing, but I think it could be done and could work _if_ it were worth doing.

---

From: Barry Leiba <[email-masked]>
Date: Thu, 11 Jul 2013 08:28:20 -0400

There were, similarly, conversations in the DKIM WG about trying to
reconstruct broken signatures through mailing lists by looking for a
"[listname]" prefix on the Subject header and stripping it and retrying the
sig validation.  After discussion, the WG had clear consensus that any such
heuristics could be attempted, but NOT within the scope of the standard --
they were too dicey, leaving too many questions open (what if a spammer
prepended "[my.bad.url]" to a signed message?).

This falls into the same category, and you're asking for a new header field
name to be reserved for this, just in case it might work.  No, it's not a
good approach.

Barry

On Thursday, July 11, 2013, Ted Lemon wrote:

> On Jul 11, 2013, at 6:09 AM, Stephen Farrell <[email-masked]<javascript:;>>
> wrote:
> Deleting headers is also hacky.   Figuring out which headers are covered
> by a DKIM signature, assuming MTAs that prepend headers, is pretty
> straightforward—you just see how many of a type of header were listed in
> the DKIM signature, and consume that many from the header history, starting
> from the DKIM header.   So yeah, it's hacky, and maybe it's not worth
> doing, but I think it could be done and could work _if_ it were worth doing.
>
>

---

From: Ted Lemon <[email-masked]>
Date: Thu, 11 Jul 2013 14:33:41 +0000

On Jul 11, 2013, at 8:28 AM, Barry Leiba <[email-masked]> wrote:
> There were, similarly, conversations in the DKIM WG about trying to reconstruct broken signatures through mailing lists by looking for a "[listname]" prefix on the Subject header and stripping it and retrying the sig validation.  After discussion, the WG had clear consensus that any such heuristics could be attempted, but NOT within the scope of the standard -- they were too dicey, leaving too many questions open (what if a spammer prepended "[my.bad.url]" to a signed message?).
> 
> This falls into the same category, and you're asking for a new header field name to be reserved for this, just in case it might work.  No, it's not a good approach.

In the case you are describing here, you are leaving something that is possible as an exercise to the reader, because you don't want to advise anyone to do it.   This makes sense.   In the case that we are talking about with respect to the draft under review, the draft actually makes it _impossible_ to do the validation if the header is included in the signature.

Another way to address this problem would be to just advise that DKIM implementations _not_ sign this header.   There's no reason why they should.   They probably don't, anyway.   You could just add a subsection to the security considerations:

8.12 Signing Messages That Contain the Authentication-Results Header Field

Email message signatures are usually generated somewhere within the ADMD within which an email message originates.   In some cases these signatures may be done after an Authentication-Results header field has been added.   This header field may be removed when the message is received by a transit ADMD or the final destination ADMD.   There would be no way, after that removal, to validate a signature that covered this header field.   For this reason, MTAs that compute such signatures SHOULD NOT include this header field in that computation.

---

From: Barry Leiba <[email-masked]>
Date: Thu, 11 Jul 2013 10:45:23 -0400

> Another way to address this problem would be to just advise that DKIM implementations
> _not_ sign this header.   There's no reason why they should.   They probably don't,
> anyway.   You could just add a subsection to the security considerations:
>
> Email message signatures are usually generated somewhere within the ADMD within
> which an email message originates.   In some cases these signatures may be done
> after an Authentication-Results header field has been added.   This header field may
> be removed when the message is received by a transit ADMD or the final destination
> ADMD.   There would be no way, after that removal, to validate a signature that covered
> this header field.   For this reason, MTAs that compute such signatures SHOULD NOT
> include this header field in that computation.

Now, that sounds like a reasonable approach.  Murray, what do you
think?  Even if "SHOULD NOT" is too strong, it would be a good idea to
lay out the problem and advise against signing A-R header fields.

Barry

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 11 Jul 2013 15:50:10 +0100

> lay out the problem and advise against signing A-R header fields.

Is that reasonable? Wasn't there a use-case (call it "foo") where
the recipient MTA would e.g. verify DKIM from the originator, then
add its own AR and then DKIM sign the lot for internal consumption
so internal MTAs or UAs could trust the AR header field based on
the DKIM signature of their own ADMD.

Or did it turn out nobody wanted that? Even if so, I'd say the above
reads too much like preventing the foo use-case. But you could reword
around that easily enough I guess.

S.

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 11 Jul 2013 10:51:13 -0400

On Thursday, July 11, 2013 10:45:23 AM Barry Leiba wrote:
> > Another way to address this problem would be to just advise that DKIM
> > implementations _not_ sign this header.   There's no reason why they
> > should.   They probably don't, anyway.   You could just add a subsection
> > to the security considerations:
> > 
> > Email message signatures are usually generated somewhere within the ADMD
> > within which an email message originates.   In some cases these
> > signatures may be done after an Authentication-Results header field has
> > been added.   This header field may be removed when the message is
> > received by a transit ADMD or the final destination ADMD.   There would
> > be no way, after that removal, to validate a signature that covered this
> > header field.   For this reason, MTAs that compute such signatures SHOULD
> > NOT include this header field in that computation.
> 

Except, if I get an A-R header field that's signed by an entity I trust, I can 
trust that field.  I think mediators signing them is a good thing so that 
receiving ADMDs can consider them if they trust the mediator.  If there's 
something not to do here, I'd think it would be don't remove signed header 
fields and break signatures.

Scott K

---

From: Ted Lemon <[email-masked]>
Date: Thu, 11 Jul 2013 15:21:18 +0000

> the DKIM signature of their own ADMD.

Why would a message with the second DKIM signature make it out of the ADMD?

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 11 Jul 2013 16:28:11 +0100

> Why would a message with the second DKIM signature make it out of the ADMD?

That's not the intent. The 2nd sig would be intended for consumption
within the ADMD only.

I guess a .vacation or something might mess with that though.

S.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 11 Jul 2013 15:35:00 +0000

> I guess a .vacation or something might mess with that though.

Best is the enemy of good enough?   :)

---

From: Barry Leiba <[email-masked]>
Date: Thu, 11 Jul 2013 11:46:57 -0400

> around that easily enough I guess.

Right, which is why I said that "SHOULD NOT" might (or might not) be
too strong.  Let's see what Murray's response is before we wrap
ourselves up on this.

Barry

---

From: Dave Crocker <[email-masked]>
Date: Thu, 11 Jul 2013 09:13:12 -0700

> Best is the enemy of good enough?   :)

Sorry, but that's not the issue at all.

Arbitrary restrictions is the enemy of everything.

The assertion about who signs and why might have some operational 
validity, but none of it is a requirement.   The fact that things are 
most typically done a certain way is not justification for prohibiting 
other ways.

Anyone along the path may sign and there are reasonable scenarios that 
can be described with signing by other than the originating ADMD.  Don't 
impose arbitrary restrictions.

Signing makes sense at any 'interesting' point of transition.  Email has 
quite a few interesting transition points, for some real-world scenarios.

d/
-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 11 Jul 2013 10:48:05 -0700

> too strong.  Let's see what Murray's response is before we wrap
Stephen stated the use case, which is also described in Section 8.1, first
bullet.  An operational environment might not be able to remove fake ones
at the border reliably, so one way to deal with that is to add your A-R
field and sign it, then send it inbound toward delivery.  An MUA or other
internal agent could verify that one (by matching the "d=" against a list
of trusted signers) and thus confirm that the content of the last one added
can be trusted.  To ensure its meaning is isolated, the "d=" domain in such
a signature could be one that only resolves within that ADMD.  I could add
this last point to that first bullet in Section 8.1.

You're right, though, that such a signature out in the wild could be (or is
likely to be) invalidated.  According to DKIM, however, that just means it
would be ignored by receivers, making it harmless added bulk.

-MSK

---

From: Ted Lemon <[email-masked]>
Date: Thu, 11 Jul 2013 17:51:52 +0000

On Jul 11, 2013, at 1:48 PM, "Murray S. Kucherawy" <[email-masked]> wrote:
> You're right, though, that such a signature out in the wild could be (or is likely to be) invalidated.  According to DKIM, however, that just means it would be ignored by receivers, making it harmless added bulk.

True enough.   And I suppose and end-to-end signature would never have this header field in it, so it wouldn't be an issue for that sort of application.

---

From: Barry Leiba <[email-masked]>
Date: Thu, 11 Jul 2013 14:12:01 -0400

>> You're right, though, that such a signature out in the wild could be (or is likely to be)
> invalidated.  According to DKIM, however, that just means it would be ignored by
> receivers, making it harmless added bulk.
>
> True enough.   And I suppose and end-to-end signature would never have this header
> field in it, so it wouldn't be an issue for that sort of application.

OK, so...
Are we done with this chat, then?  Any text change, or are we set?

Barry

---

From: Ted Lemon <[email-masked]>
Date: Thu, 11 Jul 2013 19:21:48 +0000

On Jul 11, 2013, at 1:58 PM, "Murray S. Kucherawy" <[email-masked]> wrote:
> Would you like that remark about an internal-only domain name added, or are we good to go without?  I realize it's a non-blocking issue anyway but I do like to be accommodating.

You guys are the experts.   If you think there's any value to be added by including the text, please do.   If you think it's just silly, don't let me push you into it.   I pointed out the issue because I saw a technical hole, not because I have the kind of experience that would provide guidance as to how much that hole matters.   It's certainly not a security issue.

[sorry, accidentally sent this just to Murray]

---

From: "John Levine" <[email-masked]>
Date: 11 Jul 2013 20:07:36 -0000

> If there's something not to do here, I'd think it would be don't
> remove signed header fields and break signatures.

Bad guy adds a fake A-R field and signs it, so I don't think so.

This argument reminds me of a lot of others, in which people want some
hack to handle a case which seems superfically useful, but if you
write down the actual situation where it would happen, it turns out
to be silly.

Keeping in mind that each host only removes A-R headers with its own
name, for this to matter, the message must have taken a path like

  A -> B -> C -> B

possibly with multiple hops for each arrow, and the second time B sees
the mail it wants to reverse engineer what it did the last time,
presumably because it trusts C enough to believe that it will only
pass real A-R's but not enough to believe that it does competent mail
filtering, or something.  For me, that's deep into silly.

I gather that in response to one of Pete's comments, Murray has agreed
to rewrite a section to make it clear that A-R tells downstream users
what the MTA concluded from authentication tests, but does not purport
to give them enough details so they can redo the tests or otherwise
second guess what it did.  I think this falls into the same general
category.  C tells B what C did, but it doesn't promise any details
about what happened before that.

R's,
John

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 12 Jul 2013 18:51:09 +0200

On Thu 11/Jul/2013 16:33:41 +0200 Ted Lemon wrote:
>> There were, similarly, conversations in the DKIM WG about trying
>> to reconstruct broken signatures through mailing lists by looking
>> for a "[listname]" prefix on the Subject header and stripping it
>> and retrying the sig validation.  After discussion, the WG had
>> clear consensus that any such heuristics could be attempted, but
>> NOT within the scope of the standard -- they were too dicey,
>> leaving too many questions open (what if a spammer prepended
>> "[my.bad.url]" to a signed message?).
> 
> In the case you are describing here, you are leaving something that
> is possible as an exercise to the reader, because you don't want to
> advise anyone to do it.   This makes sense.   In the case that we
> are talking about with respect to the draft under review, the draft
> actually makes it _impossible_ to do the validation if the header
> is included in the signature.

It does not, as it allows to use Elided-Authentication-Results or
similar constructs.  It words it as "MUST delete or otherwise
obscure", in the first paragraph of Section 5.

This hack is needed whenever DKIM verification is done after that A-R
processing, by a different filter within the same MTA.  Downstream
filters have to know the obscuring prefix, which is not (to be)
standardized.