Subject: Re: [dane] dane-protocol-16 lacks real introductions

From: John Gilmore <[email-masked]>
Date: Sat, 11 Feb 2012 01:15:14 -0800

I hadn't looked over the draft in awhile (instead focusing on the
email discussions), which is probably good, since I'm now seeing it with
fresh eyes.

I find it hard to read.  It lacks a lot of context and explanation for
those who haven't been buried deep in the acronyms.  I find myself
longing for the editing touch of Jon Postel (e.g. RFC 791).

For example, the abstract starts off:

  "TLS and DTLS use PKIX certificates..."

Howabout an abstract like:

   Encrypted communication on the Internet often uses Transport Level
   Security (TLS), which depends on third parties to certify the keys
   used.  This document improves on that situation by enabling the
   administrator of a domain name to certify the keys used in that
   domain's TLS servers.  This requires matching improvements in TLS
   client software, but no change in TLS server software.

This gets rid of a lot of jargon ("bindings of keys", "entities that
operate the DNS", "PKIX certificates") but says the same thing.

Similarly, the first sentence of the first section after the Abstract,
called the "Introduction", is:

   The first response from the server in TLS may contain a certificate.

That's not a $%*$&# introduction!!!  

How about starting with a graf (stolen partly from RFC 2246's abstract) like:

N.  Motivation

   Applications that communicate over the Internet often need to
   prevent eavesdropping, tampering, or forgery of their
   communications.  The Transport Layer Security (TLS, RFC XXXX)
   protocol provides this kind of communications privacy over the
   Internet, using encryption.

Follow that with a whole section on motivation:

   The security properties of encryption systems depend strongly on
   the keys that they use.  If secret keys are revealed, or if
   published keys can be replaced by bogus keys, these systems
   provide little or no security.

   TLS uses "certificates" to protect keys.  A certificate combines a
   published key with other information such as the name of the
   service that the key is used by, and this combination is digitally
   signed by another key.  Having a certificate for a key is only
   helpful if you trust the other key that signed the certificate.  If
   that other key was itself revealed or substituted, then its
   signature is worthless in proving anything about the first key.

   On the Internet, this problem has been finessed for years by
   businesses called "Certifying Authorities" (CAs).  They protect
   their secret key vigorously, while supplying their public key to
   the software vendors who build TLS clients.  They then sign
   certificates, and supply those to TLS servers.  TLS client software
   uses a set of these CA keys as "trust anchors" to validate the
   signatures on certificates that the client receives from TLS
   servers.  The client software allows any CA to usefully sign any
   other certificate.

   This solution has gradually broken down by the appearance of
   untrustworthy CAs.  A single trusted CA which betrays its trust,
   either voluntarily or by providing less-than-vigorous protection
   for its secrets and capabilities, can compromise any other
   certificate in TLS, by signing a replacement certificate that
   contains a bogus key.  Several real-world occurrances that
   exploited such CAs for mass-scale wiretapping, subversion of major
   software or web sites, or large-scale fraud [add references] have
   brought TLS's previous CA model into disrepute.

   DNS Security (DNSSEC, RFC XXXX) provides a similar model that
   involves trusted keys signing the information for untrusted keys.
   However, DNSSEC provides three significant improvements.  Keys are
   tied to names in the Domain Name System (DNS, RFC XXXX), rather
   than to arbitrary identifying strings; this is more convenient for
   Internet protocols.  Signed keys for any domain are accessible
   online via a straightforward query using the standard DNSSEC
   protocol, so there is no problem distributing the signed keys.  And
   the keys associated with a domain name can only be signed by a key
   associated with a suffix of that domain name (e.g. example.com's
   keys can only be signed by com's keys), preventing an untrustworthy
   signer from compromising anyone's keys except their own subdomains.
   Like TLS, DNSSEC relies on public keys that come built into the
   DNSSEC client software, but these keys come only from a single "root
   domain" rather than from a multiplicity of CAs.

We still need a graf to connect up that previous "introduction", e.g.:

N.  Introduction

   Each client begins a TLS connection by exchanging messages with a
   TLS server.  It looks up the server's name using the Domain Name
   System to get an Internet Protocol (IP) address.  It then begins a
   TCP or UDP connection to a client-chosen port at that address, and
   sends an initial message there.  However, the client does not know
   at this stage whether an adversary is intercepting and/or altering
   its communication before it reaches the TLS server.  It does not
   even know whether the real TLS server associated with that domain
   name has ever received its initial messages.

   [then resume with what's now the first graf of 1. Introduction here]
   The first response from the server in TLS may contain a certificate.

There are other places in the document which also jump right into the
details without a real introduction, but let's see how well people
like these first suggestions before I try to improve other places.

	John

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 11 Feb 2012 09:41:59 -0800

> email discussions), which is probably good, since I'm now seeing it with

+1

> operate the DNS", "PKIX certificates") but says the same thing.

Works for me. Do others like this? (And, yes, I think we can ignore DTLS until the body of the spec.)

> like these first suggestions before I try to improve other places.

I'm fine with adding these for motivation; I'm also fine with leaving them out but adding something along the lines of "This document assumes an understanding of TLS".

--Paul Hoffman

---

From: John Gilmore <[email-masked]>
Date: Sun, 12 Feb 2012 01:58:11 -0800

> I'm fine with adding these for motivation; I'm also fine with
> leaving them out but adding something along the lines of "This
> document assumes an understanding of TLS".

Thank you, Paul.

The beauty of Postel's RFCs was that they taught me internetworking
while also teaching me which bits went into which fields.  I believe
that was one of the reasons that TCP/IP won over the IEEE or ANSI or
telco style standards, which tell you exactly what fields exist, but
not necessarily WHY they exist, nor how to think about their context.

Clearly you need to understand TLS to do design work on the TLSA
protocol, or to code a TLSA implementation.  But at what level do you
need to understand TLS to merely deploy TLSA in your domain?  I think
this I-D should document TLSA well enough to satisfy that much larger
set of people.

How is our reader going to "first understand TLS before you read this
RFC" without reading RFC 5246?  To really read 5246 and figure out
what byte values TLS transmits, you have to be a data structures guru,
or at least be able to compile nested datatypes in your head.  (It's
quite a redundant encoding; I suspect some people would be surprised
at how much predictable plaintext is in there.)

XDR was invented by Bob Lyon down the hall from me at Sun, so I am one
of the few with the expertise to figure that stuff out.  But my first
time in there, I was shocked to find deeply nested conceptual
structures as the only documentation, rather than the ascii bitfield
diagrams that Postel's RFCs used to explain TCP and IP packet
structures (and that our Draft uses in Section 2.1).

We should find ways to explain what DANE and TLSA do, which don't
involve first teaching the reader a one-hit-wonder data structure
serialization language buried in another RFC.  If we throw our most
naive readers to THOSE lions, we'll fail part of our audience, who we
should be gently educating.

I'll transcribe more comments on other parts of the document soon.

	John

---

From: bert hubert <[email-masked]>
Date: Sun, 12 Feb 2012 12:23:48 +0100

> not necessarily WHY they exist, nor how to think about their context.

I want to amplify this point. One reason I think the draft was kept short
was the contentious nature of the discussion at times. One way to achieve
consensus is to minimize the amount of stuff we want to achieve consensus
on. 

It turns out there is a large class of documents that make perfect sense
only once you grasp them.  In other words, you can get it only once you got
it.  How you transition into this stage of understanding however is left as an
exercise to the reader. Quite literally I might add.

I hope, and will vocally support, adding the necessary verbiage and diagrams
even if makes people uncomfortable again because it adds stuff someone out
there might disagree with.

> this I-D should document TLSA well enough to satisfy that much larger

Richard Stevens showed us the way - it is an art to add only exactly what is
needed, while making sure that what we leave out does not compromise the
message.

> I'll transcribe more comments on other parts of the document soon.

Thank you!

	Bert

---

From: Martin Rex <[email-masked]>
Date: Wed, 15 Feb 2012 00:19:53 +0100 (MET)

Paul Hoffman wrote:
>John Gilmore wrote:
> Works for me. Do others like this?
> (And, yes, I think we can ignore DTLS until the body of the spec.)

The purpose "enabling the administrator of a domain name to certify ..."
is IMHO falling short, in that it mentions only one of three purposes.

The additional purposes of DANE are (2) confirming or (3) repudiating
certificates issued by well-known CAs from the TLS X.509 PKI for DNS names.

-Martin

---

From: John Gilmore <[email-masked]>
Date: Wed, 15 Feb 2012 13:46:45 -0800

> certificates issued by well-known CAs from the TLS X.509 PKI for DNS names.

We're discussing the abstract -- a short paragraph.  I was trying for
generality and succinctness.  We do get into all the details later in
the document.

If a TLSA record specifies the key for a trust anchor for PKIX
validation, for example, then I still consider it to be "certify[ing]
the keys used in that domain's TLS servers".  The TLS server provides
a certificate (in the chain that it sends the client) that uses that
key, so the key "is used in that domain's TLS servers".  And the TLSA
record certifies that that key is usable as a trust anchor.  (Other
usage types can certify it as other path components.)

I don't see how a TLSA record can be used to repudiate a certificate
issued by a well-known CA (other than by certifying a different one).
For example, there is no usage type of "repudiate this trust anchor".
It seems to me that repudiation of bad certs or CAs is just a side
effect of the certification of good ones.  Am I mistaken?

I welcome suggested replacement text for the abstract, if after
this explanation you still think that the text is insufficient.

	John