On Fri, Jul 24, 2015 at 10:53 AM, Daniel Kahn Gillmor
<dkg(_at_)fifthhorseman(_dot_)net
wrote:
On Fri 2015-07-24 12:40:31 +0200, Phillip Hallam-Baker wrote:
1) The draft is approaching IETF last call. People working on OpenPGP
should review it now.
I looked at it with Petr Spacek after the meeting, and i plan on
providing Paul with a more detailed review shortly.
DANE is trying to do three different things. It is trying to be a key
discovery service, a security policy publication mechanism and a way
of validating keys using the DNSSEC.
I think this overview is accurate. I also think all these things are
necessary. While i'm not particularly excited at the prospect of a
hierarchically controlled system like DNS being the One True System, we
do need to find ways to address these three goals anyway.
Agreed. But OpenPGP already has a fairly effective key distribution
infrastructure. As a rough guide:
The CryptoMesh = OpenPGP Key Servers + Certificate Transparency - Cruft
+ Marketting bullcrap.
I am happy to leverage the DNS as one way to validate keys but it can't be
the only way. And the way it is designed means it isn't actually a
particularly convenient one.
And don't underestimate the value of marketing bullcrap. Before the Web,
people had been trying to make network hypertext work for decades.
So the way that I would approach using DNSSEC to validate a key for '
alice(_at_)example(_dot_)com' would be to introduce a record in the DNS
with the
semantics 'X is authorized to sign for *@example.com'.
I think you mean "X is authorized to certify any key+User ID where the
user ID matches *.example.com", not that X is allowed to make sign mail
for *@example.com. right?
Yes, every end entity should have their own key. But if all you do is
domain validation then the domain owner is alway going to be able to sign
for alice(_at_)example(_dot_)com by publishing a key.
I don't think that is a big problem because I don't think you can expect
digital signatures to be legally non-repudiable without some additional
infrastructure to validate the key holder in the real world. Like an
in-person notary verification at minimum.
I like this idea as a way of validating keys
for the DNSSEC (the third of your three prongs of DANE). If you were to
make a record with the semantics "any OpenPGP key+User ID where the User
ID matches *@example.com should not be considered valid *unless* it is
certified by this key", then you could use it as a security policy
mechanism (prong two).
There might be a requirement for that type of record. It is in effect a
cryptographically enforced variant of CAA. But stopping unauthorized use of
OpenPGP is not top of my priority list right now.
I would not attempt to fill the DNS with keys for Alice, Billybob,
Carol, Doug, Ethelred and co. It is not working for TLS and I don't
think it will work for OpenPGP or S/MIME.
So it sounds like the part you disagree with is the use of DNS/DANE as a
key discovery service (prong one).
Yes, the key servers work. They are deployed. The only reason to replace
them would be with something better.
I do not find the idea of relying on the DNS for my keys remotely
comforting and would not want to rely on such a record directly. The DNS
has no persistence to it. Give me the MIT keyserver any day.
What would interest me is if I could take a DNSSEC trust chain and intern
it in a blockchain. At that point the whole process becomes transparent
and
I have a key I can place quite a bit of reliance on.
It sounds to me like you're interested in DNSSEC Transparency. Perhaps
you could take that up in the trans WG? I know there are other people
interested there (i am!) but this discussion doesn't belong on the
OpenPGP mailing list.
Yes, I have written a TRANS notary (besides the one Rob wrote). I know the
spec. But that is an infrastructure targeted at a single task and working
within a set of rather obnoxious constraints (PKIX).
Right now, that discussion certainly does not belong in TRANS any more than
OpenPGP. I am suggesting we use therightkey(_at_)ietf(_dot_)org for that sort of
discussion.
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp