Subject: [spfbis] Things that need discussion face to face?

From: Andrew Sullivan <[email-masked]>
Date: Tue, 10 Jul 2012 07:13:09 -0400

Dear colleagues,

The Vancouver IETF meeting is approaching, as is the deadline for a WG
meeting agenda.

Speaking only for myself, I haven't seen a great deal of discussion
here of the sort that seems to require face to face time.  Are there
particular issues people think we need to discuss in person, or should
we cede the time back to the rest of the IETF?

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Douglas Otis <[email-masked]>
Date: Tue, 10 Jul 2012 16:03:49 -0700

On 7/10/12 4:13 AM, Andrew Sullivan wrote:
> Dear colleagues,
> 
> The Vancouver IETF meeting is approaching, as is the deadline for a
> WG meeting agenda.
> 
> Speaking only for myself, I haven't seen a great deal of
> discussion here of the sort that seems to require face to face
> time.  Are there particular issues people think we need to discuss
> in person, or should we cede the time back to the rest of the
> IETF?

Dear Andrew,

Asia represents a significant market ignored by this draft as it fails
to accommodate current email practices in this region.

http://tools.ietf.org/html/rfc6530

This change even discourages A-label encoding of mail parameters.  UTF-8
mail parameters will break SPF libraries that lack necessary conversion
utilities, and where use of RFC3492/RFC5890 may not be sufficient
without checks for illegal UTF-8 code-points.

Email addresses should be conveyed in the sender's native language
where possible, with assurances proper conversion methods have been
applied.  This update ignores security concerns likely to affect a
large population likely to prefer email-addresses not expressed in
US-ASCII.  Leaving DNS look-up handling undefined or suggesting
A-labels should be retained in the in the return path is not acceptable.

Perhaps this issue might be worthy of some discussion.

Regards,
Douglas Otis

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 10 Jul 2012 19:08:23 -0400

On Tuesday, July 10, 2012 04:03:49 PM Douglas Otis wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 

We have an open issue to work on this issue that no one has gotten to yet:

http://trac.tools.ietf.org/wg/spfbis/trac/ticket/28

Given that we haven't gotten to it yet, it's hard to know if it needs face to 
face discussion.

Scott K

---

From: S Moonesamy <[email-masked]>
Date: Tue, 10 Jul 2012 17:00:13 -0700

>without checks for illegal UTF-8 code-points.

The draft is work in progress.  Scott Kitterman pointed out that 
there is an open issue in the tracker ( 
http://www.ietf.org/mail-archive/web/spfbis/current/msg01782.html 
).  My individual opinion is that the working group is not ignoring issues.

>Perhaps this issue might be worthy of some discussion.

There was a working session for the last IETF meeting as the face to 
face discussion was viewed as conducive to attempt to resolve the 
open issues which have generated substantial discussion on this 
mailing list.  In my individual opinion an issue is worthy of a face 
to face discussion if it was previously discussed on the mailing list 
and it is difficult to resolve.

regards,
S. Moonesamy

---

From: Douglas Otis <[email-masked]>
Date: Wed, 11 Jul 2012 11:18:55 -0700

On 7/10/12 5:00 PM, S Moonesamy wrote:
>> Asia represents a significant market ignored by this draft as it
>> fails to accommodate current email practices in this region.
>> 
>> This change even discourages A-label encoding of mail parameters.
>> UTF-8 mail parameters will break SPF libraries that lack
>> necessary conversion utilities, and where use of RFC3492/RFC5890
>> may not be sufficient without checks for illegal UTF-8
>> code-points.
> 
> There was a working session for the last IETF meeting as the face
> to face discussion was viewed as conducive to attempt to resolve
> the open issues which have generated substantial discussion on this
> mailing list.  In my individual opinion an issue is worthy of a
> face to face discussion if it was previously discussed on the
> mailing list and it is difficult to resolve.

Dear SM,

Updates to older documents often confront difficult issues when
security in conjunction with evolved infrastructure is considered.
This evolution permits users an ability to recognize message sources
without reliance on non-validated display names.

Should the current document which fails to address current
infrastructure assert SMTPUTF8 exchanges be prohibited when SPF might
be used?  How will local-part macros handle UTF-8 encoded local-parts?
 What process will ensure valid A-labels can be derived from UTF-8
encoded mail parameters?

Will WG documents remain work-in-progress until security issues have
been resolved?  Security should not be considered a "future" feature.
Security should be considered essential for any protocol.

Regards,
Douglas Otis

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 11 Jul 2012 14:27:35 -0400

> Security should be considered essential for any protocol.

No one intends to ignore actual security issues.

If you have a change to propose, please provide text.

Scott K

---

From: S Moonesamy <[email-masked]>
Date: Wed, 11 Jul 2012 13:01:51 -0700

Hi Doug,
>security in conjunction with evolved infrastructure is considered.

Yes.  That is why there is a working group to discuss and decide what 
it wants to do about the issues.

>  What process will ensure valid A-labels can be derived from UTF-8

As an example, let's say local-part macros handle UTF-8 encoded 
local-parts is raised as a security issue.  I have to explain clearly 
why I think it is a security issue.  If the working group does not 
share my opinion, I can still raise it during the Last Call if I 
believe that the working group did give due consideration to the issue.

>Security should be considered essential for any protocol.

The current deliverable is open for discussion.  Once the issues have 
been resolved it should be ready for a WGLC.  If issues have been 
missed people can raise still them.  The working group gets to decide 
on changes or non-changes.  There is an IETF-wide Last Call after that.

Can you imagine me saying to the Responsible Area Director that 
"security should be considered as a future feature"? :-)

Regards,
S. Moonesamy

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 11 Jul 2012 13:19:21 -0700

> we cede the time back to the rest of the IETF?
I'm part way through a top-down review of the -03 4408bis draft.  I have
quite a lot in there in terms of comments and edits to suggest but none of
it is "major" and all of it is in the tracker already so far.  I think it
would be convenient to talk to people in Vancouver about some or all of it,
but I don't think doing so is critical to progress.  We can do it over the
list just as easily.

I'll push to finish that review today and send it so we can figure out as a
group whether it warrants use of the slot.  Otherwise I'm happy to have
less to do in Vancouver versus more.

-MSK

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 11 Jul 2012 16:32:08 -0400

> less to do in Vancouver versus more.

I won't be in Vancouver, so I do prefer on the list unless we hit some kind of 
roadblock.  If we do, I'll participate remotely like I did last time.

Scott K

---

From: Douglas Otis <[email-masked]>
Date: Wed, 11 Jul 2012 13:58:26 -0700

> If you have a change to propose, please provide text.

Dear Scott,

SMTPUTF8 represents an important security aspect when the recipient
considers US-ASCII encoding to be opaque.  The display name is not
checked and can not act as an alternative validation method.  Many
approaches might be taken to handle SMTPUTF8.  IMHO, local-part macro
should be deprecated just like the ptr mechanism.

Deprecating local-part macros will better protect DNS caches and
eliminate most DDoS amplification vulnerabilities.  The supporting
services would be more effective when SPF queries do not vary when
different local-parts are present.  Otherwise, UTF-8 local-parts will
likely require encoding to function with most SPF macro libraries.

Any macro based upon the domain should use its A-label form, where
sub-domains offer a reasonable alternative to the use of local-part
macros.  Since there have been changes in how A-labels are generated,
some text needs to explain how invalid UTF-8 code points are disallowed.
 Perhaps this could be specified as a conversion symmetry check, or by
using a function that detects illegal code-points.

Do you see a better way to handle this issue?

Regards,
Douglas Otis

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 11 Jul 2012 20:40:14 -0400

>Do you see a better way to handle this issue?

I haven't considered it yet.  I do notice that you are consistently in favor of deprecating or removing localpart macros for other reasons than internationalization. Is it possible you've jumped to that conclusion and if you stepped back and looked at it again, you might find a better alternative solution for this issue (independent of the broader question of are localpart macros a good idea)?

Scott K

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 12 Jul 2012 20:09:01 -0400

Dear colleagues,

Unless I missed something significant, the disucussion has not
revealed anything that should be handled face to face instead of in
person.  So our plan is to cancel this session.  If you object to this
very strongly, please propose a clear agenda item with questions to be
answered in the face to face meeting by 17:00 EDT tomorrow (that's
21:00 UTC).  Otherwise, we'll inform the secretariat.

Thanks for the productive discussion on the list.  

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 17 Jul 2012 22:04:18 -0400

Dear colleagues,

As you will no doubt note, the IETF agenda for our session now reads
"cancelled" (well, "canceled", but I learned to spell in Canada).
Thanks for the productive discussion on the list!

Best,

A  

-- 
Andrew Sullivan
[email-masked]