Re: dane-openpgp 2nd LC resolution


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(_dot_)farrell(_at_)cs(_dot_)tcd(_dot_)ie> 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(_at_)nohats(_dot_)ca> 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(_dot_)Farrell(_at_)cs(_dot_)tcd(_dot_)ie will 
work and
reach you rather than your colleague Joe Bloggs than it is for
me to assume that stevie(_at_)cs(_dot_)tcd(_dot_)ie 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.

smime.p7s
Description: S/MIME Cryptographic Signature