Hi John,
Slow response, but as I said offlist, I wanted to let it sit
for a few more days to see if anything new developed. (And
then I got busy and let it sit even more days;-) But I don't
think anything new has developed to change where we're at.
The TL;DR here is that I continue to conclude we should
go ahead with this experiment and have put this into IESG
review and on the IESG telechat agenda for April 21st.
That leaves plenty of time for folks to comment and/or
appeal if there's more to be said that hasn't already been
said, and we have IETF95 in the meantime as well so interested
folks who're there will also have that chance to discuss.
On the topic of possible appeals which you mention way down
at the end, I think appealing my decision here or whatever
decision the IESG may reach is just fine - having the possibility
to appeal is an important part of our process - and I'll be
happy to try to help anyone who wants to appeal to craft text
if that's useful. Responses to your specific points are below.
On 12/03/16 09:00, John C Klensin wrote:
>
> --On Sunday, March 06, 2016 15:10 +0000 Stephen Farrell
> <stephen.farrell@xxxxxxxxx> wrote:
>
>>
>> Hi all,
>>
>> The 2nd IETF last call for this started on Feb 8th.
>> Thanks again for the lively discussion.
>>
>> The tl;dr version is: once a revision addresses the
>> substantive issues raised as per below, taking into
>> account reactions to this summary, and we have a chance to
>> take a quick look at -08 (I'll extend the LC to the date
>> of the -08 version plus one week), then if no new
>> substantive issues arise, I think we have rough consensus
>> to go forward with this experiment (and others to come)
>> and let the IESG review the document.
>> ...
>> 3. The local-part (lhs) issue and i18n
>> ---------------------------------------
>>
>> This has always been and will always be an issue for any
>> solution in this space. Absent changes to the mail
>> architecture, or major changes to email protocols and
>> deployment, it will always be an issue. And it's quite
>> related to the "joe+ietf" kind of lhs too, which'd need
>> ...
>> "Section 3 above defines how the local-part is used to
>> determine the location in which one looks for an
>> OPENPGPKEY record. Given the variety of local-parts seen
>> in email, designing a good experiment for this is difficult
>> as: a) some current implementations are known to lowercase
>> at least US-ASCII local-parts, b) we know from (many)
>> ...
>
> Stephen,
>
> I've been thinking about this for a few days and have concluded
> that I do not agree with your "resolution" and proposed
> approach.
That's fair enough. I think there's no doubt that this one
has rough consensus at best. (I wonder if that'll be true for
all similar experiments, and what that might be telling us,
but we'll see I guess.)
> All of what you write would be reasonable (whether we
> agree or not), except for two closely-related issues:
>
> (1) The IETF should not be encouraging experiments on the public
> Internet that could be harmful to the Internet or to existing
> deployed applications, especially standards-track ones.
My response here is yes and no.
Yes, we ought not do experiments that cause major harm. But
I don't think this one does. Paul has explained his and the
WG's logic about this, being that you end up no worse off
if taking part in this experiment. I do understand your point
about high-value emails, but I don't agree that someone in
such a position would be depending only on this experiment as
their means of validating email address to public key mapping.
The "no" part of my response is that every experiment in this
space will have to have the potential for some harm. Indeed
that is often the case when we introduce security mechanisms,
we almost always create new vulnerabilities by changing the
attack surface. And such changes require judgement and in this
case experimentation before we can really tell if the trade-off
is overall positive or not. Any experiment in this space will
create new potential ways for a bad actor in the right place
to provide bad mappings from email addresses to public keys,
but the hope is that this or some other experiment will more
than offset such potential harms by making it easier to find
public keys with sufficient reliability and hence improving
matters via more/better use of the technology, being OpenPGP
in this case.
I also consider that most all of the above has been a part of
the discussion already. While I may be summarising it from a
high level, I think the salient points were considered already.
And the above considers harm in terms of harm to users of PGP
which is a point you have raised. I think below you start to
consider a different form of harm (to the mail infrastructure)
but I wanted to address the above too.
> Several
> people with significant email operational experience have made
> the claim that this experiment could be harmful to the
> Internet's email infrastructure,
So I think the only point here is the local-part issue as
that's the only way I think that potential harm to the mail
infrastructure has been raised. If that's not correct, please
do let me know. (Other issues about DNS were raised and also
sufficiently discussed I think but are not a form of harm to
the mail infrastructure that I can see.)
> if only by encouraging a
> violation of a fairly explicit (and very important, IMO)
> provision of SMTP. As far as I can tell from reviewing the
> discussions, there has not even been effort to refute those
> claims or explain why they are not relevant.
I think you're just wrong there. The draft says to not mess
about with local-parts and to not guess and says that that
is a part of the mail architecture. And all this has been
discussed at great length.
>
> The attitude associated with the problem -- and why I think it
> is an important problem -- is perhaps best summarized in a note
> from the author posted today:
I think we're dealing with what the draft says and not with
the way folks have explained that (on any side of this debate).
>
> --On Friday, March 11, 2016 07:51 -0500 Paul Wouters
> <paul@xxxxxxxxx> wrote:
>
>> ...
>> I believe the chairs stated that the experiments of dane for
>> openpgpkey and smime can continue without tackling every
>> corner case of local-parts. Fixing the local-parts is up to th
>> email community, not the dane community.
>
> First, there is apparently disagreement with the email community
> about what is and is not a corner case.
"corner case" is not a phrase that occurs in the draft and is
therefore not really relevant at this point in the process.
> Many of the issues that
> have been raised (and the text that appears in -08) appear to at
> least some of us to involve relatively mainstream cases.
> Equally important, a "corner case" in email addresses may
> represent a few million messages a day, which I don't believe
> should be so lightly dismissed.
>
> I believe it has been said before, but the first sentence of
> Section 4 is either much more informal language than it appears
> to be (and somewhat misleading in the process) or it is wrong.
> Most (final delivery) mail systems support aliases for mailbox
> names.
Taking that sentence alone would be misleading too though.
I think para1 of section 4 is ok. It says:
"Mail systems usually handle variant forms of local-parts. The most
common variants are upper and lower case, often automatically
corrected when a name is recognized as such. Other variants include
systems that ignore "noise" characters such as dots, so that local
parts johnsmith and John.Smith would be equivalent. Many systems
allow "extensions" such as john-ext or mary+ext where john or mary is
treated as the effective local-part, and the ext is passed to the
recipient for further handling. This can complicate finding the
OPENPGPKEY record associated with the dynamically created email
address."
If someone had other text to offer that was saying the above
in a better way, and that didn't (re-)open cans of worms, then
I doubt there'd be any problem making such editorial changes.
> The specifications make no assumptions, and systems
> differ, about whether there are lexical or semantic
> relationships among the set of aliases for a given mailbox, much
> less what those relationships might be. Whether those aliases
> are somehow "variant forms" is in the mind of the beholder.
> However, if the specification simply hashes the local part
> string as given (as specified in section 3), then at least most
> of that first paragraph of Section 4 is gratuitous and should be
> out of scope for this document and dropped.
Personally, I find it useful information. But if it is
at worst gratuitous then that's no reason to not proceed
with the experiment.
>
> While I generally like the "it is just an experiment"
> justification for publishing and moving on, it seems to me,
> after having reviewed the discussion of Experimental status in
> 2026, including the specific comment about limited use in 3.3(d)
> and thinking about evolution since 2026 was published, that
> there are two reasons for publishing an experimental
> specification from an IETF WG. One is to encourage widespread
> experimentation, an approach we have often taken when we are not
> sure enough about a proposal to standardize it. The other, I
> believe much less used in recent years, is precisely the
> "limited use" case that 2026 seems to anticipate: use only by a
> prearranged group of people who understand what they are getting
> into and a recommendation to the broader community that they
> _not_ attempt to use it until after the experiment is reported
> upon. While your new paragraph in Section 1.1 and the end of
> Section 4 of -08 is a considerable improvement in other ways, it
> does not contain any hint of that "limited use" restriction or
> other warning notice nor is there any warning in Section 8.
So, this particular experiment is definitely going to be
of limited scope - the number of openpgp users is tiny compared
to email users. The number of signed domains is tiny compared
to the number of DNS domains. And there will not be 100% adoption
of this experiment in any case. And I'm pretty sure that those
openpgp users who have existing key management arrangements
(e.g. sysadmins and others with funny-handshakes) will not be
part of this, or at least won't be depending on this, as doing
so would break their existing agreements for how to handle
high-value emails (e.g. with unannounced vulnerability reports).
There is IMO no need to specify any of that in the document
as it is just the current external reality in which this experiment
will be performed.
And to head of a point repeated mail and countered: no, one
cannot in this experiment mandate a precise OpenPGP trust model.
There is too much variation in uses of PGP for that to be a
realistic ask.
> Given that there are unrefuted claims that this "experiment"
> could cause harm in or to the deployed email infrastructure or
> create additional security risks, that seems necessary.
I do not agree there are any such "unrefuted claims."
For this draft, it could be that almost every possibly relevant
controversial statement has in fact been made and refuted and
that both happened multiple times;-)
>
> (2) In general, we've explained the purpose of an IETF Last Call
> as allowing review across area and from multiple perspectives
> with the intention of resolving issues that are identified by
> the process prior to publication. When one community finds a
> problem in a specification, we generally (I believe never) allow
> the document's authors to say "we've made this mess, if you
> think it is a problem, it is your job to clean it up".
I don't think that is a fair characterisation of the overall
discussion during the two IETF last calls. While the author
has indeed asked a number of times for text, I just don't
accept your characterisation (the text in quotes) above.
> I'm
> sympathetic to the next text at the end of Section 4 and the
> desire to experiment first and deal with the so-called
> canonicalization problems later but:
> (a) Saying "some current implementations... lowercase at least
> US-ASCII local-parts" misses the point to the degree that it is
> misleading. RFC 5321 rather explicitly allows a final delivery
> MTA ("MDA") to make whatever equivalence rules it likes,
> certainly including applying any lower-case procedure it
> considers appropriate. However, nothing else is allowed to do
> so and it is no more appropriate for me, as a sender of mail to
> you, to assume that Stephen.Farrell@xxxxxxxxx will work and
> reach you rather than your colleague Joe Bloggs than it is for
> me to assume that stevie@xxxxxxxxx will reach you and not Steven
> Bloggs. Because at least one of the "possible harm" scenarios
> is associated with that particular alternate-local-part-guessing
> procedure, this example is significant rather than facetious.
>
Sorry, but the draft already says all that is required and
requires implementations to do what the mail architecture
calls for being done, that is: no messing with local-parts.
I don't see how an objection to an explanatory note like that
is a valid objection. It is just a fact that some implementations
do lowercase US-ASCII local-parts and that that has the issues
noted in section 4 (partly via reference to RFC6530). And that
fact is relevant in terms of why this experiment cannot "solve"
the variant local-part issue and is better off not trying to
"solve" that (perhaps unsolveable) issue.
And all of these issues have been discussed a lot in the two
IETF last calls.
> (b) We've been told during the Last Call that repeated efforts
> by email experts to inject these issues into the discussion and
> have them properly reflected in the document have been ignored,
> met with abuse, or turned into "we don't care about that
> problem, you solve it if you do" comments.
I'm sorry but the discussion from various folks, including
some of the "email experts" has been less than ideally phrased.
The above casts that as a one-sided problem, which is just
not correct.
> I note that the last
> sentence of the quotation from Paul Wouter's note above is
> consistent with those claims -- it asserts that the problem is
> the email community's to fix and not a DANE responsibility and
> may imply that the definition of email local-parts (a definition
> that is at least around 35 years old and arguably nearly a
> decade older than that and supported in _very_ widely
> implemented and deployed systems) is the problem and not how
> DANE wants to handle them.
Again. We are considering the text of the draft and not the
latest semi-flammible email exchange;-)
*And* the draft does not have the problem you state above.
>
> The situation with this document is in danger of turning into a
> "victory for attrition" pattern, in which the "victor" is the
> party with the most energy for continuing the discussion for the
> longest period of time.
I agree that is a potential problem here. And that there are more
than two different parties who could potentially win by attrition.
That is yet another reason to envisage that there will be more
than one experiment needed in this space. But I think we've not in
fact ended up with a win by attrition in this case.
> Whichever side on is on, that is not a
> good way to make decisions that are supposed to represent IETF
> consensus. Extending the Last Call in a situation like this one
> encourages that pattern by wearing those with concerns based on
> relevant knowledge and expertise to just give up from exhaustion
> and the demands of other work.
Sorry, but no. I extended the last call so that the changes in
08 could be considered by the list. Not so that people could
try to win via attrition.
>
> I therefore suggest that the approach of extending the Last Call
> be dropped and that either the document be returned to the WG
> for careful consideration of the input from the email community
> (moving the WG into ART if that review cannot occur adequately
> under SEC supervision) or that the IESG as a whole take a
> position on it. If it does decide to advance it, I strongly
> suggest inclusion of an applicability statement that specifies
> limited use and that carries appropriate warnings.
I believe that the scope of potential experiments here is
clear without an applicability statement. (See above.) I
also think there are appropriate warnings but of course it
could be that some additional (non-inflammatory) text will
improve the document. I'd be happy to consider recommending
any such text, that aims to improve the document and to
make the experiment usefully safer and more likely to be
a success. (I will not be happy to consider suggested text
that denigrates this particular experiment.)
>
> best,
> john
>
> p.s. I hope this can be resolved in a less time-consuming way
> and without my having to decide on whether a next step is needed
> (and would welcome comments from others on that subject), but I
> trust you have noticed that the statement above is in
> substantially the form that could be considered as the "contact
> the relevant AD" first step in an appeal of how this document is
> being handled.
As I said above I'm happy to help with any appeal if one
is needed. I also consider that appealing is just a fine
thing to do if one feels that an appeal is warranted. I
don't myself see any good grounds for appealing but that's
of course also natural.
Cheers,
S.
>
<<attachment: smime.p7s>>