Subject: Re: [dane] [openpgp] The DANE draft

From: Paul Wouters <[email-masked]>
Date: Wed, 5 Aug 2015 04:14:42 -0400 (EDT)

On Wed, 5 Aug 2015, Daniel Kahn Gillmor wrote:

> i'm not subscribed to [email-masked], feel free to forward if you think
> this would be useful.

[ I added dane back to the CC: as I think it will be useful to keep the
   openpgp discussion there too, as some people there also wanted a
   different specification of the RDATA ]

> key discovery vs key validation
> -------------------------------
>
> As an optional key discovery mechanism for OpenPGP, i think this
> proposal has merit.  I share Watson's concerns about "smuggling in a
> different trust model", but i have no complaints about DNSSEC validation
> being used as a corroborative validation mechanism, should clients
> choose to accept it for validation purposes.  For clients that *don't*
> choose to accept it for validation purposes, they should validate the
> keys via their usual mechanisms, and rely on OPENPGPKEY records solely
> for discovery purposes.

The text does make it clear that you have that choice:

    The proposed new DNS Resource Record type is secured using DNSSEC.
    This trust model is not meant to replace the Trust Signature model.
    However, it can be used to encrypt a message that would otherwise
    have to be sent out unencrypted, where it could be monitored by a
    third party in transit or located in plaintext on a storage or email
    server.  This method can also be used to obtain the OpenPGP public
    key which can then be used for manual verification.

So there is no "smuggling".... DNSSEC is used to protect the transport,
and as a poor man's better-than-nothing web-of-trust alternative.

> metadata leakage
> ----------------
>
> I'm a little concerned about the potential for metadata leakage -- i
> don't want my MUAs to do DNS lookups every time i try to send mail to
> someone whose keys i dont have.

The MUA can present you with information to manually verify or put a trust
level to the key. The MUA should also cache negative attempts to get a
key and limit these so avoid fingerprinting email send times by looking
at DNS queries. That part is not in the current RRtype specification,
but should go into the openpgpkey-usage document (co-authors wanted!)

> localpart mangling
> ------------------
>
> I have no strong preference for base32 vs. digested localpart for the
> hostname.  Digested localparts require a little bit more work to invert
> than base32, but given the low entropy of typical normalized localparts,
> they don't provide a lot of protection against a determined attacker.

And as clearly stated, were never meant to provide security.

> I'm slightly more concerned with e-mail address length limits on base32
> than on digested localparts -- a long localpart plus a long domain name
> could make for a very large DNS label, whereas a fixed digest should
> give us a fixed bound on size.

Do you forsee email addresses > 256/2 to be common use?

> In either case, some canonicalization will be required (before base32 or
> digest, whichever is chosen).  fwiw, i believe that case normalization
> of the localpart is pragmatic for today's networks, despite not being
> within the letter of the RFC.  I would advise clients to downcase before
> doing a lookup.

Thanks. I share that belief.

> The main advantage for base32 over digested localpart seems to be for
> synthesized OPENPGPKEY records in an online-signing DNSSEC-capable
> server.  I don't believe this is a significant advantage for a key
> discovery mechanism for OpenPGP, because i believe some people will want
> to verify the OpenPGP certificate itself, regardless of its DNSSEC
> status, and the OpenPGP certificate won't have wildcards in it.

Other people believe there is some use. If the only downside is not
supporting insanely long email addresses, which I think are a more
rare event, I think that it is okay.

> RDATA content/structure
> -----------------------
>
> The -03 spec §2.1 currently suggests that the RDATA should be an
> "RFC4880 OpenPGP public keyring", but RFC 4880 doesn't define a "public
> keyring" in any reusable way (see
> https://tools.ietf.org/html/rfc4880#section-3.6).
>
>
> § 2.2 says:
>
>   The RDATA Wire Format consists of a single OpenPGP public key as
>   defined in Section 5.5.1.1 of [RFC4880].  Note that this format is
>   without ASCII armor or base64 encoding.
>
> But 5.5.1.1 is *just* a public key packet.  This is not a useful record
> to store.
>
> Instead what you want is probably exactly one "Transferable Public Key"
> (https://tools.ietf.org/html/rfc4880#section-11.1), which is the
> standard for the composable OpenPGP certificate format.  But see the
> "Filtered Certificates" section below for more detail.

I will update the reference to refer to that section. Thanks. That
does look better.

> Key Transitions
> ---------------
>
> While i say "exactly one" Transferable Public Key, i'm assuming that the
> DNS is OK with serving multiple OPENPGPKEY records at a single label.

What is the advantage of multiple DNS records with 1 key over one DNS
record with multiple keys? While I'm all four specifying one method to
increase chances of interop, I'm not particularly set on one or the
other solution.

> Filtered Certificates
> ---------------------
>
> Given that some users have aggregated OpenPGP certificates that are
> quite large (my own is currently ~475KB), we don't want to require
> people to publish their entire certificate in the DNS.  Because OpenPGP
> certificates ("transferable public keys) are composable (they consist of
> a series of packets, many of which can be dropped), a reasonable policy
> for filtering the certificate for size purposes should be suggested.

We mention this in Section 5:

https://tools.ietf.org/html/draft-ietf-dane-openpgpkey-03#section-5

> At a minimum, the OPENPGPKEY record for [email-masked] MUST contain:
>
> * primary key X
>  - one User ID Y, SHOULD match [email-masked]'
>   - self-signature from X, binding X to Y.
>
>
> [ note: I do not believe we need to require that the User ID MUST match
>  the looked-up record, though it's obviously preferable to a validator
>  if it does. ]
>
> This extremely minimal record might not provide an encryption-capable
> subkey, though, and the primary key may not be encryption-capable
> itself.
>
> So a more sensible transferable public key would also include all
> relevant subkeys:
>
> * primary key X
>  - one User ID Y, SHOULD match [email-masked]'
>   - self-signature from X, binding Y to X.
>  - encryption-capable subkey Z
>   - self-signature from X, binding Z to X.
>  - [ other subkeys if relevant ...]
>
>
> Owners of the record may also want to include some up-to-date
> third-party certifications which they think would be helpful for
> validation, which would result in:
>
> * primary key X
>  - one User ID Y, SHOULD match [email-masked]'
>   - self-signature from X, binding Y to X.
>   - third-party certification from V, binding Y to X
>   -  [ other third-party certifications if relevant ...]
>  - encryption-capable subkey Z
>   - self-signature from X, binding Z to X.
>  - [ other subkeys if relevant ...]

[...]

> With GnuPG, you can achieve a rough minimization with:
>
>  gpg --export-options export-minimal,no-export-attributes $PGPFPR > opengpgpkey.pgp

The idea was not to specify these policies in the DNS RRtype. Just tell
people to keep to small keys. It did include an example gpg command
in appendix A, but your command seems even better so I will update it.

I would prefer not to mention specific key elements as those might
change and are not really relevent for the DNS specification. Or perhaps
these recommendations could go in the openpgpkey-usage document.

Paul

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 05 Aug 2015 12:28:26 +0100

> And as clearly stated, were never meant to provide security.

Hmm.

With no hats, I gotta say I prefer the harder to invert local part
(i.e. hashed) to the reversible one (b32).

If this experiment ends up successful, then I think we'll be setting
a precedent for other per-user identifiers to be used as part of a
DNS name so I do not believe that arguments about this aspect ought
be decided solely based on PGP or SMIME or DANE. We should also
consider that some other protocol is highly likely to follow what
seems to have worked (just as _blah.example.com has been mimicked)
and where we don't now know the privacy consequences of copying
the pattern we're setting here.

For that reason, I really would prefer that we stick to the hash and
not go for the reversible per-user identifier.

(Separately, I also don't buy that there will be much use for actually
reversing the b32 encoding and if there were then the relevant work
could just as easily be done in advance by a server that is willing
to answer for a few known alternatives.)

So sorry to continue an argument but shouldn't this experiment be
a more conservative about privacy just in case it ends up wildly
successful?

Ta,
S.

---

From: Patrick Ben Koetter <[email-masked]>
Date: Wed, 5 Aug 2015 15:11:21 +0200

> not go for the reversible per-user identifier.

ACK

p@rick

-- 
[*] sys4 AG
 
https://sys4.de, +49 (89) 30 90 46 64
Franziskanerstraße 15, 81669 München
 
Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein

---

From: "Paul Hoffman" <[email-masked]>
Date: Wed, 05 Aug 2015 08:12:06 -0700

Wearing my author hat: I don't care between b32 and hashing. Both are 
equally easy to document. However:

> a more conservative about privacy just in case it ends up wildly

How is using the hash more conservative about privacy, except in zones 
that are signed with NSEC instead of the more common NSEC3? If you 
assume zones signed with NSEC3, both options are equally susceptible to 
dictionary-based guessing attacks, given that the effort to create 
search dictionaries for the billion of common LHS names is pretty low 
even for hashes.

--Paul Hoffman

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 05 Aug 2015 16:25:08 +0100

> search dictionaries for the billion of common LHS names is pretty low

Tempora. That on-path attacker has a far easier time reversing the
b32 than anything based on the hash. Even with DPRIVE, we don't know
how to handle the recursive to authoritative part.

So a "putative other protocol that copies this" could well do a great
job on hiding identifiers only to be caught out by following this b32
convention.

I do accept that hashing doesn't make much difference for PGP or SMIME
since the DNS answer in the success case almost certainly gives the
game away, but I don't think that has to be true in general.

The failure case may also be of interest though, with hashing, that DNS
answer doesn't immediately tell the attacker to whom I'd like to send
email. And I guess if some MUA adopts this there'll be quite a few
negative answers for quite some time, so there's a privacy difference
there I think. (Not sure if that was raised before - apologies if so.)

S.

---

From: Carsten Strotmann <[email-masked]>
Date: Wed, 05 Aug 2015 17:36:04 +0200

Hello Paul,

> search dictionaries for the billion of common LHS names is pretty low

for OPENPGPKEY/SMIMECERT zones, operators could (maybe SHOULD) use
NSEC/NSEC3 "narrow" signing to prevent "zone-walking".

The issue is more in the DNS query logs. My experience from working with
many DNS-admins over the last decade tells me:

DNS-Admins that could/would snoop into DNS-query logs by creating a
small Perl script to decode the email addresses seen in the logs.

Less DNS-Resovler Admins would go all the way of breaking hashes either
using dictionary-based guessing attacks or a rainbow table.

Breaking hashes requires much more "willful intent" than decoding BASE32.

The hashing communicates a "don't go here" message, even though it is
technically not a strong protection.

It is like having a closed door vs. no door at all. No door communicates
"come in, no secrets, we're open" while the closed door (even if it can
be opened by minor force) communicates "private space".

Best regards

Carsten

---

From: "Paul Hoffman" <[email-masked]>
Date: Wed, 05 Aug 2015 08:55:58 -0700

> how to handle the recursive to authoritative part.

Thanks, I was only thinking of off-path attackers.

I agree that, if we are concerned with on-path watchers, hashes would 
preserve much more privacy than Base32 encodings.

--Paul Hoffman

---

From: Patrik Löhr <[email-masked]>
Date: Wed, 05 Aug 2015 18:35:09 +0200

Hi Paul,

that's the point - we are concerned with on-path watchers.
That is why we are in strong favour of hashing like i already stated:
Hashing does not protect against "decryption" - but it makes a distinct
difference whether I need to make a targeted attack on a hash, or can
arbitrarily search through the plaintext in a stream of data.

Best
Patrik

Am 05.08.2015 um 17:55 schrieb Paul Hoffman:
> _______________________________________________
> dane mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dane

-- 
Patrik Löhr

Posteo e.K.
Methfesselstr. 38
10965 Berlin

tel. +49 30 85074618
mail <[email-masked]>
web <https://posteo.de>

USt-IdNr.: DE186713958
Handelsregister: Berlin-Charlottenburg · HRA 47592 B

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 5 Aug 2015 18:32:46 +0000

On Wed, Aug 05, 2015 at 06:35:09PM +0200, Patrik L?hr wrote:

> That's the point - we are concerned with on-path watchers.
> That is why we are in strong favour of hashing like I already stated:

I don't think hashing (without salt) provides sufficient obfuscation
to deter on-path attacks.  If you're serious about mitigating
on-path passive monitoring of DNS lookups, you MUST not only hash
the localparts, but the hash MUST include a salt.

Building a table of the top few billion localpart names is just
too cheap.

Even with salting, very large domains like gmail.com, ... are still
substantially vulnerable to attack without a reasonably high
iteration count.  However, a high iteration count makes the
construction of the zone data rather expensive.

I don't think  it is possible to construct any reasonable mechanism
that avoids metadata leakage with DNS queries sent in the clear.

If avoiding metadata leakage is important, the lookups need to
happen over TLS or IPsec.  Half-measures that attempt to obfuscate
DNS queries are not IMHO a useful direction to pursue.

The reason I proposed hashing (long ago) was to deal with long
localparts, not enhance privacy.  I did propose including the domain
name in the hash ("breaking" DNAME support, really requiring per
address not per localpart data) to frustrate data recovery by zone
walkers, but that was not about mitigation of on-path metadata
collection.

-- 
	Viktor.

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 05 Aug 2015 20:04:46 +0100

Hiya,

On 05/08/15 19:32, Viktor Dukhovni wrote:
> to deter on-path attacks. 

Compared to b32 hashing is clearly less bad, if we're putting
user-specific identifiers in the DNS. The requirement to have a
large table and to pre-calculate that does increase the effort for
attachers. I don't think anyone has claimed that that would
deter all attackers. And even for the most capable attacker,
it would I think make it a little harder to do some kinds of
pattern matching.

And btw, I would assume use of a salt is impractical as would
any mechanism that means that DNS queries for the same thing
will differ each time. That seems more like a DNS-next-gen
thing, but maybe I'm wrong about that. Be nice if so, but I
suspect not.

S.

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Wed, 05 Aug 2015 15:06:28 -0400

> and as a poor man's better-than-nothing web-of-trust alternative.

ah, right.  Please don't use the term "Trust Signature model" here.
While RFC 4880 does specify "trust signatures", they're not commonly
used, and they don't represent the most common implementations of how
people interact with OpenPGP's network of identity assertions (aka "web
of trust") -- we don't want to conflate "Trust Signature" with "web of
trust".

> The MUA can present you with information to manually verify or put a
> trust level to the key.

i think you are referring to the validity of a key for a given e-mail
address here.  in OpenPGP-land, "trust" usually means something
different (e.g., how much you're willing to rely on identity assertions
made by the key itself, analogous to "is this X.509 cert a trust
anchor?")

> The MUA should also cache negative attempts to get a key and limit
> these so avoid fingerprinting email send times by looking at DNS
> queries. That part is not in the current RRtype specification, but
> should go into the openpgpkey-usage document (co-authors wanted!)

Sounds far more reasonable than query-on-every-message, though i'm not
just worried about fingerprinting e-mail send times -- i'm also worried
about tracking user associations directly by lookup.

> And as clearly stated, were never meant to provide security.

Digested local parts provide a little more privacy, not security.  But i
agree it's only a little bit, given the low entropy of most localparts.

Is it conceivable that someone wants to use a high-entropy localpart to
avoid address leakage via key lookup? In that case, it seems like you'd
do just as well to have your high-entropy localpart uniquely identify
your key in the first place, with something like
[email-masked].

> Do you forsee email addresses > 256/2 to be common use?

you've dropped the units here -- 256/2 what?  are we talking about
characters or octets?  if octets, under what encoding?  I agree that
e-mail addresses are rarely this long today, but we should be cautious
and explicit about any additional constraints when we're proposing to
mapp a limit from one domain (DNS) onto another domain (e-mail
localparts).

> rare event, I think that it is okay.

Steven's point about raising the cost slightly for passive attackers
(e.g. TEMPORA) seems at least as relevant to me as the feasibility of
online-signed zones serving up end-user OpenPGP certificates that can't
possibly match the requested address exactly.

That said, there's a separate scenario, where as a domain administrator
i want to mint and sign an OpenPGP certificate on each query (even ones
where i have no user), to avoid the possibility of someone enumerating
all my actual users by walking the localpart space.  minting a matching
certificate would be creatable with the base32 approach

(how would this work?  something like the following: the DNS server
responsible for these records would keep a domain-wide long-term secret.
upon a query that it finds it has no legitimate record for, it would
hash the query name and the long-term secret into a seed for a PRNG.
from the PRNG output, it would deterministically derive secret key
material and any other variable metadata (like creation date) needed to
derive a new certificate.  it could cache or discard these certificates
as requested, because it could always re-generate them exactly from a
new query.  when a user opens a matching account, the user's personal
key would replace the domain-generated one.  i'm not saying this is a
great system, just outlining how it might be done for a system that
wants to keep its userbase hidden)

I'm still on the fence here, as you can tell :P

> increase chances of interop, I'm not particularly set on one or the

Hm, the more i think about it i find i prefer it aesthetically, but i'm
not sure i have a good engineering argument.  I don't see a great way to
effectively prevent people from doing either one -- are there any DNS
record types explicitly prohibit multiple records in response to a given
query?

OpenPGP composable certificates are just a series of OpenPGP packets
concatenated; two certs concatenated together are themselves also just a
series of OpenPGP packets by induction.  We could say that the RDATA
"MUST start with a Public Key Packet and MUST NOT contain more than one
Public Key Packet".

> https://tools.ietf.org/html/draft-ietf-dane-openpgpkey-03#section-5

looks sensible, though i think some of the terminology is slightly off
there.  i could try to provide patches for that section if you like.
how is the draft developed -- how do you prefer edits sent to you?

> these recommendations could go in the openpgpkey-usage document.

That seems OK to me as well.

     --dkg

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Wed, 05 Aug 2015 15:32:14 -0400

> there I think. (Not sure if that was raised before - apologies if so.)

yep, i raised that concern too, thanks for reinforcing it :)

the cost of inverting a digest is definitely more than the cost of
inverting b32, but it's unlikely to be difficult for an interested
attacker to invert otherwise low-entropy domain names or localparts of
e-mail addresses.

see djb's writeup on nsec3walker for a related example of how low the
bar is for doing large-scale hashing with the kind of low-entropy input
spaces found in DNS:

 http://dnscurve.org/nsec3walker.html

It's not exactly the same problem, but a good example of how small the
protection is against a motivated adversary in this context.

           --dkg

---

From: Paul Wouters <[email-masked]>
Date: Thu, 6 Aug 2015 04:23:54 -0400 (EDT)

> NSEC/NSEC3 "narrow" signing to prevent "zone-walking".

email addresses are not secret. That is not the privacy you can protect
at all. Anyone can either do a internet search or just attempt to
deliver an email to figure out if the email address is valid.

The only realy privacy concern is learning who is querying, meaning who
is interested in mailing a particular user - assuming everything else on
the email path is secureb by TLS, and the domain is large enough to
actually hide the userbase (that is, nohats.ca is already a lost cause,
because everyone knows a TLS connection to mx.nohats.ca means you are
going to email me)

> Breaking hashes requires much more "willful intent" than decoding BASE32.

But that difference these days is basically zero as soon as someone puts
up a module for johntheripper or hashcat or something on github.

> technically not a strong protection.

If the sysadmin does not respect privacy on base32, they will not
respect privacy on hash(very simple names) or even hash(former-lover)

> be opened by minor force) communicates "private space".

I might agree but I think the gain for this is so incredibly small, that
I think the gain for use of online signers plus email address
corrections by the smtp+dnssec combined server is actually a more likely
and minorly useful thing to have.

And don't get me wrong. I'd rather see zonefiles with a hash than with
base32 cut from an esthetical point of view.

Paul

---

From: "Jiankang Yao" <[email-masked]>
Date: Thu, 6 Aug 2015 16:39:20 +0800

From: Paul Wouters
Date: 2015-08-06 16:23
To: dane WG list
CC: IETF OpenPGP
Subject: Re: [dane] [openpgp] The DANE draft

>deliver an email to figure out if the email address is valid.

if there is a "email zone walking", the email spammer can use this feature to get the valid addrees easily and send trash emails.
If we hope to prevent the spammer from getting the email address easily, the email address should be regarded as secret.

Jiankang Yao

---

From: Hosnieh Rafiee <[email-masked]>
Date: Thu, 6 Aug 2015 08:49:53 +0000

> -----Original Message-----
> From: dane [mailto:[email-masked]] On Behalf Of Paul Wouters
> 

Disagree! This really depends on the person and scenarios. 
For some people maybe it is not a problem to share their email addresses or put them on their public websites because it is a part of their job. For example a company shares its email to others so that other can contact them. But for someone like a president of a country or a politician  it is important because a criminal can bug them by threatening them, try to hack their email by sending messages with fake links to do phishing attack or send codes inside html body of the email to access their computer and infect it. Therefore, from privacy point of view, as much information as I can have about a victim, the chance of attack is higher. 

> is interested in mailing a particular user - assuming everything else
> on the email path is secureb by TLS, and the domain is large enough to

Nope, some people who really care about their privacy uses different emails for different purposes (business, family, friends).

> But that difference these days is basically zero as soon as someone
> puts up a module for johntheripper or hashcat or something on github.

Again disagree. 

Hosnieh

---

From: Paul Wouters <[email-masked]>
Date: Thu, 6 Aug 2015 04:54:24 -0400 (EDT)

> If we hope to prevent the spammer from getting the email address easily, the email address should be regarded as secret.

So if you use NSEC3 and base32, they need to break the NSEC3 hashing,
which has various parameters to make it easier or harder, but all are
basically in the range of a few days of GPU cracking.

If you use NSEC3 and sha256(LHS) then the work increase is basically
making a table for every 8 letter combination and dictionary names which
should be far less computations than the NSEC3 breaking. And to defend
your email address against this, you have to make it so it is not easilly
guessable with known names and that makes it harder to convey your email
address verbally to other people - the exact opposite of what you want.

Also, the only current alternative for people is to push their email
address plaintext to a keyserver. So even with base32, we are
increasing the privacy of email addresses of openpgp users.

I really do believe that the hashing is not an affective security
meassure.

Paul

---

From: Hosnieh Rafiee <[email-masked]>
Date: Thu, 6 Aug 2015 08:56:01 +0000

From: dane [mailto:[email-masked]] On Behalf Of Jiankang Yao
 
>If we hope to prevent the spammer from getting the email address easily, the email address should be regarded as secret.

This is, IMO, a nightmare when using IPv6....  spammers sending email with new IP and sometimes they know how to bypass the content filtering antispamming ...

Hosnieh

---

From: Hosnieh Rafiee <[email-masked]>
Date: Thu, 6 Aug 2015 09:04:23 +0000

Paul,

> I really do believe that the hashing is not an affective security

By using hash, we make it harder for an attacker to find email addresses of another person. Of course, we cannot prevent the attack. 

Let me give you a real example from a real person that I name him Bob. Bob hasn't published any email address on his personal website but he used a form so that others can send me email only via form.
The spammer also tried to send hiim message via this form in a hope that they can receive an answer so that they can have his email address. But Bob also used other approaches such as captcha. 

After that, he no longer received any spamming email because it was too efforts for spammer to check the captcha and take more of their time. 

I hope it is clear,
Hosnieh

---

From: Vincent Breitmoser <[email-masked]>
Date: Thu, 06 Aug 2015 11:30:12 +0200

On 6 Aug 2015, Paul Wouters wrote:

> I might agree but I think the gain for this is so incredibly small,

The same could be said about NSEC vs NSEC3 for a motivated attacker, and
still NSEC received strong opposition.

 - V

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 06 Aug 2015 10:58:18 +0100

Paul,

> deliver an email to figure out if the email address is valid.

That doesn't address my issue with this as a precedent. Nor the
case of negative DNS responses trivially leaking that someone at
my IP address wants to send a mail to <here> at this time. (And
yes, the trivially is a required part of the argument.)

And "are not secret" isn't, I think, the right comparison. For me,
the question is "if we want to experiment with user identifiers in
DNS names, can we do it in the least privacy unfriendly, but yet
practical, way as possible?"

Yes, some people may oversell the benefits of hashing or may believe
hashing is stronger than it is. Such mistaken beliefs however do not
make hashing worse than b32. Hashing is still a bit better.

> and minorly useful thing to have.

Can you point me at a DNS server (or real specification for one)
that generates responses in any similar fashion? I'm not aware of
any that actually do, (even if they could do), but that my just be
my ignorance.

IMO even if there is a niche of DNS authoritative servers that
can operate in that manner, requiring that that niche be used
for the experiment makes it highly likely the experiment will
fail.

So my logic would be: if b32 is needed, the experiment will
likely fail as you can't do it on many servers. If b32 is not
needed, then let's just hash since that is less bad.

> base32 cut from an esthetical point of view.

Well, let's do that then:-)

S.

> openpgp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/openpgp
>

---

From: Carsten Strotmann <[email-masked]>
Date: Thu, 6 Aug 2015 12:03:56 +0200

Hi Stephen,

> any that actually do, (even if they could do), but that my just be

PowerDNS with a remote backend could do this, but it would require some
glue code to be written by the admin to be able to talk to the smtp-server.

I can evision such an installation for a few large mail providers, but
not for the majority of mail server installations.

Carsten

---

From: Paul Wouters <[email-masked]>
Date: Thu, 6 Aug 2015 06:43:31 -0400 (EDT)

> still NSEC received strong opposition.

Actually, most users of NSEC3 care more about the OPT-OUT feature than
the hashing feature. And there is no OPT-OUT with NSEC.

Paul

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 06 Aug 2015 12:29:37 +0100

> not for the majority of mail server installations.

Thanks. So that implies that b32 can only in practice offer
advantage to the large mail providers who want to do PGP
like this and fuzzy stuff with "AccountName+JustMadeUp@domain"
type addresses. (For other kinds of fuzziness, e.g. upper/lower
case initial letters, I think anyone can prepare a few hashes
in advance and do almost as well.)

I think what you say above also implies that b32 will offer
no benefit to the long tail as they'll have zonefiles or the
moral equivalent.

Seems to me like more reason to not do b32. I would guess that
the large mail providers won't do this since we've not heard
from them that they would, and in fact we're heard 2nd hand that
the won't (iirc, I'm open to correction) and those large mail
providers tend to not be shy about saying what it is they would
like when they're interested in something;-)

Cheers,
S.

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 6 Aug 2015 15:47:24 +0000

> I really do believe that the hashing is not an affective security

Agreed.  Wishful thinking does not make it true.  Just because we'd
like to sprinkle crypto pixie dust to make magic happen, does not
mean it will happen.

Hashes may sound more secure, but they're not really more secure,
no matter how much we'd like them to be.

-- 
	Viktor.

---

From: Hosnieh Rafiee <[email-masked]>
Date: Thu, 6 Aug 2015 16:01:31 +0000

Viktor,

> From: dane [mailto:[email-masked]] On Behalf Of Viktor Dukhovni
> Sent: Thursday, August 06, 2015 5:47 PM
> To: [email-masked]
> like to sprinkle crypto pixie dust to make magic happen, does not mean
> it will happen.
> 
> Hashes may sound more secure, but they're not really more secure, no
> matter how much we'd like them to be.

Of course, no one expects to see a miracle from a hash function. But again this is only making it a bit harder, even you say 1% but this is quite different than a plain text.

Best,
Hosnieh

---

From: Warren Kumari <[email-masked]>
Date: Thu, 6 Aug 2015 13:07:23 -0400

... and we have just called consensus on this topic - see the email
with the subject "Consensus on the Hash vs Base32 discussion."

This has been a long and involved discussion, and we thank everyone
for hanging in there.

W

-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Thu, 06 Aug 2015 16:19:12 -0400

On Thu 2015-08-06 05:04:23 -0400, Hosnieh Rafiee wrote:

> Let me give you a real example from a real person that I name him
> Bob. Bob hasn't published any email address on his personal website
> but he used a form so that others can send me email only via form.
> The spammer also tried to send hiim message via this form in a hope
> that they can receive an answer so that they can have his email
> address. But Bob also used other approaches such as captcha.
>
> After that, he no longer received any spamming email because it was
> too efforts for spammer to check the captcha and take more of their
> time.

He will also receive no mail from me, because i prefer to mail from my
own mail user agent, and not from webforms with a captcha, which have
their own set of privacy concerns in common implementations, not to
mention UI/UX issues. :P

Plus, how does Bob reply to any of his mail?  Does his reply use an
e-mail address?  What stops one recipient from publishing his e-mail
address?

But this all seems like quite a digression: how is this an argument
about which form to use for publication of the OPENPGPKEY record?

        --dkg