Re: Last Call: <draft-ietf-dane-openpgpkey-07.txt>

[John C Klensin <[e-mail]>]

Paul (and others),

There is no question that the email-addrquery draft needs work,
even the author has said so.  I've tried to start a thread on
the SMTP list that identifies some possible issues to be
examined.  If you want to have a constructive conversation about
that draft, please move it there.  Probably it would be best to
wait for the next draft and comment on it rather than attacking
-01.   

None of this is relevant to the proposed experiment advocated by
dane-openpgpkey unless you want to try to convert this
discussion into "dane-openpgpkey is no worse than
email-addrquery, therefore it should be approved".  I suggest
not going there because the IETF doesn't need to approve _any_
flawed protocol and, be being in Last Call, there is a claim
that dane-openpgpkey is finished and ready to go, a claim that
has never been made for email-addrquery.

I'll respond to your comment below if you want to make it on the
SMTP list, but suggest that the description of _any_
key-location or key-retrieval must mechanism be clear about the
difference between obtaining a purported key and determining its
validity for some intended use in order to be taken seriously.
This thread periodically seems to lose track of that distinction.

     john



--On Wednesday, February 17, 2016 22:24 -0500 Paul Wouters
<[e-mail]> wrote:

> On Tue, 16 Feb 2016, John Levine wrote:
> 
>>>>>      https://tools.ietf.org/html/draft-moore-email-addrque
>>>>>      ry-01
>> 
>>> Unfortunately, the draft is useless for end-to-end
>>> encryption, as it relies on a clean path from the client to
>>> the recipient's SMTP server ...
>> 
>> I would encourage anyone interested in this topic to read the
>> draft, particularly section 4.  No, it does not depend on a
>> clean path from the MUA to the recipient MTA.
> 
>     This section defines a service extension to the Mail
> Submission
>     Protocol [RFC6409] which can be used by an authenticated,
> authorized
>     client to query an SMTP server on port 25 for information
> about an
>     email address.  This is intended only as a workaround for
> port 25
>     blocking, so the extension is minimally tailored for that
> purpose.
> 
> So if my ISP is blocking port 25, I am forced to ask my ISP if
> the
> remote party could accept encrypted email and to which key?
> 
> It is not "end to end" encryption, if the ISP can change the
> outcome.
> 
> So again, the above draft does not provide a workable solution
> for
> the openpgpkey draft.
> 
> Paul
>