Subject: [Acme] ACME or EST?

From: Paul Hoffman <[email-masked]>
Date: Tue, 25 Nov 2014 13:41:19 -0800

Greetings again. The abstract of the ACME pre-draft at https://github.com/letsencrypt/acme-spec (which Richard will hopefully publish as a real draft soon) says:

   This
   document describes a protocol that a certificate authority (CA) and a
   applicant can use to automate the process of verification and
   certificate issuance. The protocol also provides facilities for
   other certificate management functions, such as certificate
   revocation.

This overlaps a lot with "Enrollment over Secure Transport" (EST), <https://tools.ietf.org/html/rfc7030>.

For many people who saw last week's announcement, the main use case of ACME is "make it easy to create a client that can create a key, get it enrolled with a server, get the new certificate back, and install that certificate in a web server". What does/will ACME offer that EST does not already?

--Paul Hoffman

---

From: Richard Barnes <[email-masked]>
Date: Tue, 25 Nov 2014 16:55:51 -0500

A few things off the top of my head:

* If nothing else, much less ASN.1.  (Cf. JOSE vs. CMS)
* Support for other certificate management functions, e.g., revocation
* Validation of possession of identifiers
* Cleaner use of HTTP

On Tue, Nov 25, 2014 at 4:41 PM, Paul Hoffman <[email-masked]> wrote:

> Greetings again. The abstract of the ACME pre-draft at
> https://github.com/letsencrypt/acme-spec (which Richard will hopefully
> publish as a real draft soon) says:
>
>    This
> For many people who saw last week's announcement, the main use case of
> ACME is "make it easy to create a client that can create a key, get it
> enrolled with a server, get the new certificate back, and install that
> certificate in a web server". What does/will ACME offer that EST does not
> already?
>
> --Paul Hoffman
> _______________________________________________
> Acme mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/acme
>

---

From: "Joe Hildebrand (jhildebr)" <[email-masked]>
Date: Tue, 25 Nov 2014 22:17:46 +0000

>* Validation of possession of identifiers

Although I sympathize with less ASN.1 and better HTTP use, the other two 
points are stronger technical differentiators, so in future answers to 
this question it might be better to focus more on those.  

I personally would like to make sure we have mapped whatever use cases are 
in EST to see if there are edges that ACME hasn't yet considered.  I would 
also like to ensure that the operational model that is implied by ACME is 
congruent enough with EST that an operator might be able to use both in 
parallel - if possible.  If it's not possible, I would like to have a 
crisp answer as to why we think that is a good thing.

-- 
Joe Hildebrand

---

From: Richard Barnes <[email-masked]>
Date: Tue, 25 Nov 2014 17:24:22 -0500

> crisp answer as to why we think that is a good thing.

I would also like to have this analysis.  It would probably be better for
someone more familiar with EST than me to do it.

--Richard

---

From: Nico Williams <[email-masked]>
Date: Tue, 25 Nov 2014 16:37:17 -0600

> * If nothing else, much less ASN.1.  (Cf. JOSE vs. CMS)

RFC7030 defines very few new ASN.1 types... oh.  It uses the ASN.1 IOS.
Eww.  Yeah, OK, I see your point.

That ugly ASN.1 in RFC7030 is for the response to a "request
required/desired attributes" request.  Your I-D doesn't have this
feature, presumably because there's no real need for it.  Can you
confirm?

A request for supported attributes might be useful, but probably only
for purposes _other_ than HTTPS servers.

(If there were a need for such a thing then defining ASN.1 types that
don't use the IOS would be trivial.  Using JSON would be fine too, and
since that's what you prefer, go for it.)

> * Support for other certificate management functions, e.g., revocation

And rollover?  And re-certification?

I mean, one of the most useful features would be to have fresh and/or
short-lived cert management to avoid revocation: re-certify the
EE's cert frequently, even when there is no key rollover.

Among other things it'd make OCSP stapling less necessary.

> * Validation of possession of identifiers

"
   All requests for a given ACME server are sent to the same HTTPS URI.
"

I'd expect different kinds of requests to use differen URIs (that seems
to be best practice, but then again, you're not claiming that ACME is
RESTful, so hey).

"
   It is assumed that clients are configured with this URI out of band.
"

Clients could learn it via RFC5988 link relations, no?

"
   ACME requests MUST use the POST method, and since they carry JSON
   ...
"

Er, are there no requests for information?  E.g., OCSP Responses,
acceptable attributes (for CSRs), ...?

Nico
--

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 25 Nov 2014 14:50:13 -0800

> * If nothing else, much less ASN.1.  (Cf. JOSE vs. CMS)

The JOSE message structure has been much more problem-laden than CMS ever was. Yes, ASN.1 is ugly; many people feel the same (or worse) about JOSE.

> * Support for other certificate management functions, e.g., revocation

That seems like a good point.

> * Validation of possession of identifiers

And that seems like another good one, one that I had missed in EST.

> * Cleaner use of HTTP

That's quite debatable. The current ACME draft is likely to change when more requests are filled in. Personally, I prefer the HTTP used in EST, but both will probably converge after a while.

I think the "we can revoke certs, and get reissued certs more cleanly" and "we inherently are showing possession of identifiers" are good enough arguments to drop the discussion of EST for this use case.

--Paul Hoffman

---

From: Tony Arcieri <[email-masked]>
Date: Tue, 25 Nov 2014 14:59:45 -0800

On Tue, Nov 25, 2014 at 2:50 PM, Paul Hoffman <[email-masked]> wrote:

> The JOSE message structure has been much more problem-laden than CMS ever
> was. Yes, ASN.1 is ugly; many people feel the same (or worse) about JOSE.

We make extensive use of both CMS and JOSE for our enterprise's HSM-backed
encryption service. We've gone full bore switching from CMS to JOSE with
everyone agreeing CMS is terrible and JOSE is less terrible.

Are there specific concerns you have? I think the main advantage is JOSE is
considerably easier to implement than ASN.1, and aside from a handful of
problems has fewer potential ambiguities and misinterpretations than ASN.1
(e.g. BERserk). JSON largely follows the LANGSEC requirements of:
content-free or regular and full recognition before processing. ASN.1 fails
this test.

Personally I'd probably be more of a fan of something like Cap'n Proto for
the message format as an ASN.1 replacement, but compared to CMS, JOSE has
been a breath of fresh air for us.

Seeing ACME is using JOSE actually makes me more excited about it.

-- 
Tony Arcieri

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 25 Nov 2014 16:03:59 -0800

> The JOSE message structure has been much more problem-laden than CMS ever was. Yes, ASN.1 is ugly; many people feel the same (or worse) about JOSE.

Yep, shades of grey or, in this case, shades of mud.

> We make extensive use of both CMS and JOSE for our enterprise's HSM-backed encryption service. We've gone full bore switching from CMS to JOSE with everyone agreeing CMS is terrible and JOSE is less terrible.
> 
> Are there specific concerns you have?

Wait for it...

> I think the main advantage is JOSE is considerably easier to implement than ASN.1, and aside from a handful of problems

There you go. :-) Folks who have fought with ASN.1 longer than JOSE find CMS's "handful of problems" already solved and JOSE's ones completely frustrating because they were brought up in the WG years ago (literally) and never fixed.

It doesn't matter; JOSE will work adequately for ACME.

--Paul Hoffman

---

From: Tony Arcieri <[email-masked]>
Date: Tue, 25 Nov 2014 16:08:21 -0800

On Tue, Nov 25, 2014 at 4:03 PM, Paul Hoffman <[email-masked]> wrote:

> There you go. :-) Folks who have fought with ASN.1 longer than JOSE find
> CMS's "handful of problems" already solved

More generally, there were two severe vulnerabilities discovered this year
related to ASN.1:

https://www.usenix.org/conference/usenixsecurity14/technical-sessions/presentation/meyer
http://www.intelsecurity.com/resources/wp-berserk-analysis-part-1.pdf

ASN.1 is *not* "LANGSEC-friendly". JOSE comes a lot closer. For that reason
alone, ASN.1 is inferior.

-- 
Tony Arcieri

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 25 Nov 2014 19:34:20 -0500

How about XKMS? It has much less ASN.1, its all angle brackets.

Stephen F. knows about it, he was the WG chair.

Less ASN.1 is always good.

---

From: Michael Jenkins <[email-masked]>
Date: Tue, 25 Nov 2014 20:20:24 -0500

Setting aside the technical differences for a moment, the intents of EST
and ACME are different; EST was intended to support enrollment of arbitrary
types of devices that are more-or-less already known to the CA, whereas
ACME is for provisioning the web servers of domain owners. This difference
of intent explains, for instance, why ACME supports "validation of
possession of identifiers", while EST has the notion of "authorization".

Without having read ACME in depth, I suspect EST is a bit more general.
That's not to say ACME couldn't be made more general - and certainly not to
claim that generality is necessarily good :) but it serves some cases.

On Tue, Nov 25, 2014 at 7:34 PM, Phillip Hallam-Baker <[email-masked]
> wrote:

-- 
Mike Jenkins
[email-masked] - if you want me to read it only at my desk
[email-masked] - to read everywhere else
443-634-3951

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 26 Nov 2014 01:25:41 +0000

> Stephen F. knows about it, he was the WG chair.

I'd put that down as approx. valiant, failed, attempt #4 at
cert mgmt. Ah well:-)

S.

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 26 Nov 2014 01:41:45 +0000

Correct me if I'm wrong but I'm hoping that a first order
requirement for acme is that it be designed to work, and
actually works, in a situation where the CA is not trying
to make money or to get anyone to sign in blood as to the
binding between an identifier and public key. Or indeed
between loads of identifiers and loads of public keys,
under some rational constraints about names. And that it
can hence be confidently used as an out of the box default
by web servers, xmpp servers, mail servers, clients etc etc.

I think that is a new priority, but not a new requirement,
and assuming that the crew who're behind acme deliver the
other goods promised, then that in itself will I think be
enough to justify them deciding to prefer punch cards if
that's what works out of the box, by default and for anyone
who's bothered to jump through a few name binding hoops.

Frankly, I couldn't give a rat's arse if its asn.1 or xml
or json or punch cards via courier, or pigeons, so long as
it works well enough, as a default, and at scale.

So I'g suggest dumping the arguments about representation
and just asking whoever's willing to host a service that'll
work what they like today, and then making sure the protocol
can do everything that the clients of that need, via that
representation. If another CA with a different whimsy turns
up tomorrow, it's not hard to map from one representation
to another. And we can setup a new list for that in about
a few hours.

Cheers,
S.

PS: I've nothing at all against the current CAs charging,
and used to earn a living selling folks that s/w. It's a
fine, but subtly different, thing to be doing compared to
what I hope this list ends up producing.

PPS: I've no clue if the folks behind this will manage to
deliver, but they sure seem like they've a great chance at
so doing, so I'll cut 'em slack until developments develop.

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 25 Nov 2014 21:20:04 -0500

What's the new name for XML?  Legacy json?

XKMS definitely has some worthy ideas to consider.  But it never got much traction AFAIK.

SCEP, XKMS, KMIP, PKCS7/10, EST...  the nice thing about enrollment protocols is there are so many to choose from.

It's trendy, but maybe capturing mindshare and lowering the barrier to acceptance is really important for getting everyone to get a cert.

	/r$

--  
Principal Security Engineer, Akamai Technologies
IM: [email-masked] Twitter: RichSalz

---

From: Nico Williams <[email-masked]>
Date: Tue, 25 Nov 2014 20:59:47 -0600

[Apologies for the noise.]

> https://www.usenix.org/conference/usenixsecurity14/technical-sessions/presentation/meyer

I don't see where that refers to anything to do with ASN.1 or BER/DER.

> alone, ASN.1 is inferior.

ASN.1 is just syntax.  *BER* is the horror, as are all tag-length-value
encodings (Protocol Buffers, I'm looking at you too).

ASN.1 types can be encoded by XML, and there's even JSON encoding rules
proposals floating about for ASN.1.

If you like XDR/NDR/... (or TLS' ad-hoc encoding) you might like ASN.1's
OER.  XDR and OER are siblings; XDR is the bigger brother.  (I hope some
of you get that awful joke.)

The *nice* thing about ASN.1 is the availability of tooling -- yes,
decades late, to be sure, at least for decent open source tooling, but
still, it exists now.  That's not nothing.  Tooling is the answer to
hand-coded encoder/decoder accidents.

I'm curious as to what type(s) of _encoding rules_ you think is good for
security.

Assuming (wrongly?) a need for bags-of-bags-of- bags-of-...-of-scalars
generality, I see these kinds of encodings, historically:

 - tag length value: BER and sisters DER and CER, Protocol Buffers, ...
    - with definite lengths: DER, Protocol Buffers
    - with indefinite lengths: CER)

 - textual friends of TLV: XML, JSON

 - fixed-sized fields everywhere possible: XDR, NDR, OER, PER, and
                                           FlatBuffers [I think])

 - ad-hoc fixed-sized fields everywhere possible: IP, UDP, TCP, TLS,
                                                  SSHv2, ...

All of these are equivalent to each other in some way.  E.g.,
FastInfoSet is a compact encoding of XML using OER.

What types of encoding am I missing?

BER/DER, XML, XDR, NDR -- all of these have had notable security
vulnerabilities in decoding.  I'm not sure if JSON has had any though...

...oh, wait, no, JSON _has_.  Yes, even if you exclude 'Ruby', 'Rails',
and 'YAML' from your search, you'll find JSON parser security bugs.

Even Protocol Buffers implementations have had decoder security bugs (a
brief search turns up at least one, but I bet there's been more than one).

My question should really be: what types of encoding am I missing that
fit the bill (bags of bags of ... stuff) and are inherently safe(r) to
parse?

My take is that TLV is worse for security than any other encoding
because there's too much redundancy:

 - the 'T', which is redundant relative to the schema that generally one
   must know anyways), and
 - the lengths ('L'), which are all too easy to use without proper
   bounds checking.

   All encodings that can encode arbitrary-size data (i.e., all useful
   ones) will have to encode lengths internally, but TLV encodings tend
   to encode many more lengths than are needed.

IMO, this makes a good encoding:

 - a schema is needed to decode/parse because tags are not used
 - fixed sized fields are be used wherever possible, even if it's
   somewhat wastful
    - in particular fixed-sized integer fields (in powers of two bit widths)
 - fixed sized lengths are used wherever lengths are needed
 - adjacent booleans are packed in obvious ways
 - optional/defaulted field absence/presence encoded as booleans early
   on in each struct/whatever
 - no sets (on the wire there's always an order in which things appear)
 - good docs

   (the ITU-T x.68x and x.69x docs are actually quite good _references_
   once one gets familiar with them...)

ASN.1 has a good such encoding: OER.

A good syntax is one that's easy to write parsers for.

A *good* reference implementation is always needed for both, the syntax
and the encoding rules, because programmers always screw up (which
brings us to verifiable implementations...).  And that's needed in
multiple programming languages, with extremely liberal licenses, they
must be free in all senses, preferably verifiable, and definitely
portable.  No wonder these bugs keep happening...

Nico

PS: I'm not a fan of ASN.1 as a syntax.  It works well enough as long as
    one sticks to base x.680, but add in the Object Information System
    syntax and it gets messy fast (the tiny bit of ASN.1 in RFC7030
    shows this clearly).  But I am a fan of its expressiveness and
    generality, and I prefer it over ad-hoc syntax and encodings.

    Also, syntax is not that important: one can always create a better
    equivalent.  Encoding rules are forever.

---

From: Nico Williams <[email-masked]>
Date: Tue, 25 Nov 2014 21:16:49 -0600

> What's the new name for XML?  Legacy json?

They have very different semantics :( but I get the joke :)

> XKMS definitely has some worthy ideas to consider.  But it never got

If there's anything worse than ASN.1^H^H^H^H^H BER it's got to be XML...

> SCEP, XKMS, KMIP, PKCS7/10, EST...  the nice thing about enrollment
> protocols is there are so many to choose from.

And yet deployment as a fraction of enrollment activity is not
significant for any of them.  OK, OK, I don't have numbers as to this.

> It's trendy, but maybe capturing mindshare and lowering the barrier to
> acceptance is really important for getting everyone to get a cert.

As long as it's something that CA operators decide to offer.  Or those
CA operators that do win enough market share.

Syntax and encoding are only barriers though.  If barriers are the only
problem, then by all means, otherwise you're right.

Nico
--

---

From: Randy Bush <[email-masked]>
Date: Thu, 27 Nov 2014 07:19:47 -0500

> I would also like to ensure that the operational model that is implied
> by ACME is congruent enough with EST that an operator might be able to
> use both in parallel - if possible.

could you explain why?  transition?

> alone, ASN.1 is inferior.

are there pure LR parsers for jose?

Stephen Farrell wrote:
> Frankly, I couldn't give a rat's arse if its asn.1 or xml or json or
> punch cards via courier, or pigeons, so long as it works well enough,
> as a default, and at scale.

i would think you, of the farrelous brothers, would be concerned about
the langsec-friendly aspect.

randy

---

From: "Joe Hildebrand (jhildebr)" <[email-masked]>
Date: Thu, 27 Nov 2014 16:30:13 +0000

>could you explain why?  transition?

There are at least a few pockets of folks who have made bets on EST, and 
I'd like to be able to get those people onboard with the overall approach. 
 Some of them may want to transition, and some of them may want to run a 
mix of protocols in order to not have to modify and re-test existing code 
paths.

>are there pure LR parsers for jose?

JOSE is "just" JSON.  Here is my favorite small JSON parser:

https://github.com/quartzjer/js0n/blob/master/src/js0n.c

That code makes it pretty clear what parser styles are possible.

JSON has plenty of other issues, but ease or clarity of parsing is not one 
of them.  For examples, look in RFC 7159 for interoperability problems.  
CBOR was developed (partially) to address most of those issues.

-- 
Joe Hildebrand

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 27 Nov 2014 16:43:44 +0000

> the langsec-friendly aspect.

Not much tbh, far less than getting something that can be
turned on by default. And ISTM that any of the reaosnable
choices, about which we sometimes endlessly debate, all
work.

S.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 27 Nov 2014 11:58:24 -0500

> the langsec-friendly aspect.

One of the many reasons to drop ASN.1, particularly the Deranged Encoding Rules.

The type of coding error that comes up is as follows:

Tag Length[ Tag Length [Value]]

Lets say each atom has a length of 1 byte, this would be coded

xx 03 xx 01 xx

Now what happens if the coder is wrong and instead gives:

xx 99 xx 01 xx

Buffer overrun error time!

ASN.1 has the added stupidity of the tags being variable lengths which
makes it quite likely that there will be an error in the encoding.

What this means is that you can not tell folk 'just use an ASN.1
package'. It is a bitch to write the code and you cannot rely on
others to get it right.

ASN.1 is deprecated. It is not for use in new projects. This is a new
project. Ergo no ASN.1

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 27 Nov 2014 21:13:48 +0000

> choices, about which we sometimes endlessly debate, all

I agree that the wire format (syntax) is less important than the
feature set (semantics).  In particular, there I'd like to see some
discussion of what kind of "proofs of control" should be acceptable
with a lights-out DV certification authority.

A certification authority that issues a cert to anybody who asks
without any evidence of domain control may employ the most cool
message syntax and still be a bad idea.

A certification authority that makes it too difficult for most
domains to prove the legitimacy of the request would be pointless.

A certification authority that always accepts the weakest form of
evidence even for domains that should be able to present stronger
evidence would be unfortunate by bringing everyone's security down
to the lowest common denominator.

In terms of protocol standards, sure, encodings need to be discussed
and message structures agreed, ...  However, at the end of the day,
the trade-offs that LE will make between security and usability
are what really counts.

-- 
	Viktor.

---

From: Christian Huitema <[email-masked]>
Date: Thu, 27 Nov 2014 22:42:39 +0000

> Buffer overrun error time!

On the other hand, there is enough information in the BER/DER encoding to perform run time verifications and avoid these overruns. It falls in the general category of "never trust input received from the network."

You can find this kind of errors with pretty much any "variable length" format. If you have explicit length coding, then you must check the consistency of the stated length with the message buffer. If you have implicit coding, e.g. using some kind of delimiter, you must checks that delimiters happen before the end of the message.

Then, there is all the fun related to integer overflow, especially when the syntax uses element counts rather than element length. Or stack overflow if the decoder uses recursion. Remember the attacks using "specially crafted JPEG images?"

I am not sure that the message description language matters very much, the quality of the implementation matters much more. And, as far as protocol go, better keep the syntax as simple as possible. But you are right about the level of "exotic complexity" in ASN.1. It does not help.

-- Christian Huitema

---

From: Tony Arcieri <[email-masked]>
Date: Thu, 27 Nov 2014 16:34:14 -0800

On Thursday, November 27, 2014, Christian Huitema <[email-masked]
<javascript:_e(%7B%7D,'cvml',[email-masked]');>> wrote:
>
> I am not sure that the message description language matters very much
>

Here's a paper that argues otherwise:

http://www.cs.dartmouth.edu/~sergey/langsec/papers/langsec-tr.pdf

-- 
Tony Arcieri

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 27 Nov 2014 21:30:03 -0500

> On the other hand, there is enough information in the BER/DER encoding to perform run time verifications and avoid these overruns. It falls in the general category of "never trust input received fr…

But as a programer responsible for the security of the code, that
means I can't just take an off the shelf ASN.1 library and use it. I
have to roll my own to be sure the checks are made. Which in fact is
what I do.

So the existence of ASN.1 tools does nothing to reduce the impact of
the needless complexity.

> I am not sure that the message description language matters very much, the quality of the implementation matters much more. And, as far as protocol go, better keep the syntax as simple as possible.…

That is why I would like us to stick to one data model and at most two
encodings of that data model going forward. Those being text and
binary.

---

From: Christian Huitema <[email-masked]>
Date: Fri, 28 Nov 2014 05:09:54 +0000

> But as a programer responsible for the security of the code, that means I can't just take an off the shelf ASN.1 library and use it. I have to roll my own to be sure the checks are made. Which in fact is what I do.

That's your choice, but the first step should be to write your own fuzz test. If the library passes, it is probably good. And if you write your own code, you will still need to test it.

-- Christian Huitema

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 28 Nov 2014 10:20:17 +0000

changing subject line to the interesting bit...

> with a lights-out DV certification authority.

Yep. Fully agree about DV. But DV isn't the only kind of
validation I'd like to be supported here.

I'd like if it were possible to extend that to include cases
where one has control over the web server, but not the DNS.

Now there are dangers in that so I'm not sure if it's really
doable, but I've controlled web servers below tcd.ie for years
(e.g. [1]), without any control over DNS, and I'd like to be
able to do better than self-signed out of the box there too.

The current spec [2] seems to allow for that via the "provision
a file on the web server" method, but the details of that
("simpleHttps" I guess?) aren't clear. I'm also not sure of
the security implications, which could be a killer (for having
key authorization depend on this mechanism alone) so I'm sure
there's work to be done there.

But I'd very much like to just update apache on my servers
and have that go get certs that work.

S.

[1] https://down.dsg.cs.tcd.ie/yesicanrichard.txt
[2]
https://github.com/letsencrypt/acme-spec/blob/master/draft-barnes-acme.md

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 28 Nov 2014 08:21:23 -0500

It is not clear to me that the form of the proof needs to be hard
coded into the enrollment protocol. It should certainly be possible to
layer in additional validation steps to support stronger validation.

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 28 Nov 2014 13:25:09 +0000

> layer in additional validation steps to support stronger validation.

Entirely correct. However, what I'm most interested in (for now)
is the by-default case that e.g. might be used when one installs
a web server. And support for that case probably does need to be
baked in so that a web server install script can just work.

S.

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 28 Nov 2014 08:33:35 -0500

> Entirely correct. However, what I'm most interested in (for now) is the by-
> default case that e.g. might be used when one installs a web server. And
> support for that case probably does need to be baked in so that a web server
> install script can just work.

Which is the initial primary use-case, of course.

In case folks haven't seen the video: https://www.youtube.com/watch?v=Gas_sSB-5SU  The demo starts 45 second into the three-minute video.

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 28 Nov 2014 07:32:08 -0800

> where one has control over the web server, but not the DNS.

Those two paragraphs don't really go together. You absolutely can do DV in cases where you don't have control over the DNS; that's basically how all web certificate enrollment happens today.

--Paul Hoffman

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 28 Nov 2014 07:49:35 -0800

On Fri, Nov 28, 2014 at 7:32 AM, Paul Hoffman <[email-masked]> wrote:

> Those two paragraphs don't really go together. You absolutely can do DV in
> cases where you don't have control over the DNS; that's basically how all
> web certificate enrollment happens today.

To put a slightly finer point on it, web validation is extremely useful in
cases
where you only have loose control over the DNS.

-Ekr

---

From: Eliot Lear <[email-masked]>
Date: Fri, 28 Nov 2014 17:05:35 +0100

Viktor,

> to the lowest common denominator.

What you've written above is quite consistent with the notion of
opportunistic security ;-)  At the same time, I'm not sure what it means
in practice.  Does it mean, for instance, that DV is not to be allowed? 
Is a single system required, or is there some sort of classification
approach?

Eliot

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 28 Nov 2014 17:09:17 +0000

> validation I'd like to be supported here.

I did not know that DV necessarily implied control of DNS.  I was
using the term to mean something other than EV where the petitioner
though some "high touch" process demonstrates possession of a business
name and associated domains.  Are there certificates for TLS servers
other than EV or DV?

In any case, the details of the supported proofs are I think worthy
of discussion.

> where one has control over the web server, but not the DNS.

Related issues:

  * Does the web server have to be on port 443 with TLS enabled
    (perhaps with a temporary self-signed certificate)?  Or is it
    sufficient to control port 80 or some other port with or without
    TLS?

  * If on port 443, is an existing certificate from any of the
    usual public CAs (other than LE) (if also usable as a TLS client
    cert to authenticate to the provisioning system) accepted as
    evidence of authenticity for bootstrapping trust with LE?

  * If the domain is DNSSEC signed, is it reasonable (I hope)
    to raise the bar, and require proof of DNS control?  Since
    bootstrapping with just web server control and no existing
    credentials is vulnerable to MiTM, and signed domains are
    making an effort to harden against such attacks?

  ...

> ("simpleHttps" I guess?) aren't clear.

That's an important part of what I'd like to see discussed?

> and have that go get certs that work.

Right, security and convenience are, roughly speaking, at opposite
ends of a set of trade-off decisions.  So one needs to make choices
with some care.

To Phillip's reply, yes these choices are largely orthogonal to
the protocol, except to the extent that the protocol needs to be
sufficiently expressive to communicate the various proofs.  And
yet I'd still like to see a discussion of the substance before we
dive into analysis of the form.

-- 
	Viktor.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 28 Nov 2014 12:19:51 -0500

> Those two paragraphs don't really go together. You absolutely can do DV in cases where you don't have control over the DNS; that's basically how all web certificate enrollment happens today.

I think the underlying question is whether we are just going to
support one provider of free certs (who has yet to issue one) or
support a more general approach. My view is that we should, not least
because my employer has been giving away SSL certs for eight years...

The significant change here is the automation. Free isn't enough on its own.

In addition, any new proposal has to work with DANE and with HSTS and
CAA. Not at all difficult to do, but does require some thought.

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 28 Nov 2014 10:31:36 -0800

On Nov 28, 2014, at 9:19 AM, Phillip Hallam-Baker <[email-masked]> wrote:
> support a more general approach.

That doesn't seem like an underlying question at all. The current ACME pre-draft supports the general case, and so far no one other than you have suggested otherwise.

--Paul Hoffman

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 28 Nov 2014 10:37:01 -0800

>    evidence of authenticity for bootstrapping trust with LE?

Why should ability to control port 80 or 443 be a determinant for proving control of "web server" at "domain name"? Not all web service is run on port 80, and not all secure web service is run on port 443. A CA can validate that the requestor can control some HTTP service on some port at the domain name. If a CA has a policy that is more restrictive than that, ACME can trivially support that policy with more error codes.

>    making an effort to harden against such attacks?

I disagree that ACME-the-protocol should raise the bar past what we use for domain verification today. It's fine if a CA who uses ACME does.

--Paul Hoffman

---

From: Nico Williams <[email-masked]>
Date: Fri, 28 Nov 2014 12:58:54 -0600

On Thu, Nov 27, 2014 at 09:30:03PM -0500, Phillip Hallam-Baker wrote:
> > [...]

I find this very strange, whether said about ASN.1 or anything else.
Sure, often there's no better choice than open-coding whatever you need,
but do you write everything in assembly?  Probably not.

My advice: find the most hackable ASN.1 open source tooling, and use
that.  My preference is Heimdal's ASN.1 compiler, which is damn near
standalone, produces C code as well as bytecode (--template option), and
is easy to hack on to output other code.
https://github.com/heimdal/heimdal/tree/master/lib/asn1

> > I am not sure that the message description language matters very
> > much, the quality of the implementation matters much more. And, as
> > far as protocol go, better keep the syntax as simple as possible.
> > But you are right about the level of "exotic complexity" in ASN.1.
> > It does not help.

The base languages, x.680, is not exotic at all.  Compared to XDR, for
example, it has a few features that XDR doesn't have (e.g., default-able
struct fields, SETs), and somewhat different syntax, but otherwise the
two are roughly very similar.  It's *just* syntax, after all.  It's the
encoding rules that are cause problems, and even there, ASN.1's rules
cover all the bases: don't use the TLV encodings.

The various additions like x.681 and x.683 are quite complex, but not
needed for Internet protocols.

Nico
--

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 28 Nov 2014 21:37:24 +0000

On Fri, Nov 28, 2014 at 10:37:01AM -0800, Paul Hoffman wrote:

> Why should ability to control port 80 or 443 be a determinant
> for proving control of "web server" at "domain name"? Not all web
> service is run on port 80, and not all secure web service is run
> on port 443. A CA can validate that the requestor can control some
> HTTP service on some port at the domain name. If a CA has a policy
> that is more restrictive than that, ACME can trivially support that
> policy with more error codes.

Because unfortunately, Web PKI certificates are host-wide, they don't
specify a port.  Anyone who can run some program on a machine can
bind to some random port and start a web service.  Possibly port-forwarded
somewhere else via SSH!

It is far from clear to me that every "shell" user of a machine
should be authorized to obtain certificates for the whole machine.

> I disagree that ACME-the-protocol should raise the bar past what
> we use for domain verification today. It's fine if a CA who uses
> ACME does.

The protocol is just a syntax, and indeed I asking a question about
appropriate CA policy.  Perhaps some guidance to CAs implementing
the protocol would not be amiss.

As for not raising the bar, "today" there is essentially no DNSSEC
deployment (just under 1% of domains in the Alexa top 1,000,000).

So this is not "raising the bar" for any established scenarios,
rather asking whether we should maintain the bar at the same woefully
insecure level, even when DNS is beginning to provide greater
security.

At the very least I would expect the CAs resolver that validates
control over DNS to have DNSSEC validation turned on to drop "bogus"
replies.  However, I would also advocate that web server control
boostrapping over much weaker channels should not bypass stronger
DNS security (the domain owner has signalled the capability to
authenticate control of the domain, and we should not allow downgrade
attacks).

-- 
	Viktor.

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 28 Nov 2014 13:57:55 -0800

> should be authorized to obtain certificates for the whole machine.

And it is clear to me that they should be, if we want to see more encryption of traffic. I have no problem with some CAs saying "we'll issue you a cert only if you control port X", but I absolutely want that to be a policy of the CA, not of the enrollment protocol.

> the protocol would not be amiss.

If you want to write such a thing as a separate document whose target audience is CAs, that's grand. It does not belong in the protocol.

--Paul Hoffman

---

From: Nico Williams <[email-masked]>
Date: Fri, 28 Nov 2014 16:31:24 -0600

On Fri, Nov 28, 2014 at 01:57:55PM -0800, Paul Hoffman wrote:
> And it is clear to me that they should be, if we want to see more
> encryption of traffic. I have no problem with some CAs saying "we'll
> issue you a cert only if you control port X", but I absolutely want
> that to be a policy of the CA, not of the enrollment protocol.

The user should be able to represent all services on that host just by
having a shell on it?  If certs could be limited by port the user could
get one for the ports he/she is allowed to listen on, but...

Nico
--

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 28 Nov 2014 14:39:35 -0800

On Nov 28, 2014, at 2:31 PM, Nico Williams <[email-masked]> wrote:
> having a shell on it?  

Sure. That's the way it is today for many CAs.

> If certs could be limited by port the user could

But... what? They have been able to be for well over a decade, and yet few if any CAs choose to restrict them that way. If you want to only accept certs that have that restriction, you are free to. You just won't find many certs from major CAs like that...

--Paul Hoffman

---

From: Randy Bush <[email-masked]>
Date: Sat, 29 Nov 2014 09:01:44 -0500

> Christian Huitema <[email-masked]>
Tony Arcieri <[email-masked]>
> http://www.cs.dartmouth.edu/~sergey/langsec/papers/langsec-tr.pdf

how did you guess what i had in mind :)?  one would hope that we do not
need to be taught this lesson yet again.  the only answer i have gotten
is an example parser,
https://github.com/quartzjer/js0n/blob/master/src/js0n.c which, while an
fsm, does not unequivocally make the case that the language is lr.

randy

---

From: Randy Bush <[email-masked]>
Date: Sat, 29 Nov 2014 09:08:52 -0500

> Sure. That's the way it is today for many CAs.

is that a feature or a bug?

is it clear what is being certified and what is not are rigorously
defined?  and, if so, what proofs of possession are appropriate for
each?

randy

---

From: Richard Barnes <[email-masked]>
Date: Sat, 29 Nov 2014 09:50:31 -0500

On Saturday, November 29, 2014, Randy Bush <[email-masked]> wrote:

> > Christian Huitema <[email-masked] <javascript:;>>
> Tony Arcieri <[email-masked] <javascript:;>>

There appears to be a yacc grammar for JSON [1], which implies that it is
at least LALR.  I'm not real current on my language theory, but IIRC, that
implies that it is LR.

[1] https://gist.github.com/justjkk/436828

> [email-masked] <javascript:;>

---

From: Randy Bush <[email-masked]>
Date: Sat, 29 Nov 2014 09:56:02 -0500

> There appears to be a yacc grammar for JSON [1]

yay!  thanks.

randy

---

From: Viktor Dukhovni <[email-masked]>
Date: Sat, 29 Nov 2014 17:05:38 +0000

On Fri, Nov 28, 2014 at 01:57:55PM -0800, Paul Hoffman wrote:

> And it is clear to me that they should be, if we want to see more encryption
> of traffic. I have no problem with some CAs saying "we'll issue you a cert
> only if you control port X", but I absolutely want that to be a policy of
> the CA, not of the enrollment protocol.

Paul, do you have any examples of CAs that accept any port, or are
you in part making that up?  Comodo for example, requires control
of port 80:

    https://support.comodo.com/index.php?/Default/Knowledgebase/Article/View/791/16/

(See DCV method 3).

> > The protocol is just a syntax, and indeed I am asking a question about
> If you want to write such a thing as a separate document whose
> target audience is CAs, that's grand. It does not belong in the
> protocol.

I have no set views of whether such a thing should or not be written,
or, if yes, where.  I think some discussion of the topic is
reasonable, and perhaps you're trying to shut that down prematurely.
If the discussion yields some hints of some kind of consensus, then
we can worry about what to record and where.

-- 
	Viktor.

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 29 Nov 2014 09:22:08 -0800

On Nov 29, 2014, at 9:05 AM, Viktor Dukhovni <[email-masked]> wrote:
> you in part making that up?

When I got a cert for my POP server, what-used-to-be-Verisign required the proof of control to be on a port that was not 80.

However, "does someone allow it" is completely different than "should this new protocol force a business model on all CAs". In the specific case I am thinking about, I want a server that will run DNS over TCP to be able to get a certificate with ACME. For that, the ability to control port 80 on the host is completely irrelevant. The same would be true for IMAP and POP servers. There are plenty non-web uses of TLS where ACME could be useful; hobbling the protocol to be web-only seems premature.

--Paul Hoffman

---

From: Viktor Dukhovni <[email-masked]>
Date: Sat, 29 Nov 2014 22:11:39 +0000

> > you in part making that up?

Sorry about that, intended to be a harmless off-the-cuff question,
a poor choice of words no doubt.

> When I got a cert for my POP server, what-used-to-be-Verisign
> required the proof of control to be on a port that was not 80.

So they did DV not by email verification, or HTTP, but rather
actually connected to a POP server or similar?

It seems to me that control over something other than ports 25, 80
or 443 is a rather risky choice, and at some point one actually
needs to verify domain control, rather than some arbitrary TCP
endpoint on the host.

> However, "does someone allow it" is completely different than "should this
> new protocol force a business model on all CAs". In the specific case I
> am thinking about, I want a server that will run DNS over TCP to be able
> to get a certificate with ACME. For that, the ability to control port 80
> on the host is completely irrelevant. The same would be true for IMAP and
> POP servers. There are plenty non-web uses of TLS where ACME could be
> useful; hobbling the protocol to be web-only seems premature.

Sure, and the domain owner can field servers on whatever port he/she
wishes after demonstrating control over the domain, which to me
means control over the DNS (be it direct, or indirect via whoever
administers the DNS).

-- 
	Viktor.

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 29 Nov 2014 19:29:59 -0800

> means control over the DNS (be it direct, or indirect via whoever

I think this will have to be an "agree to disagree" situation. The Let's Encrypt promotional material indicates that they want to get more HTTPS out in the world, so they need to deal with the huge number of folks who use hosting companies and thus have no DNS control. I believe that is a great goal.

--Paul Hoffman

---

From: Tony Arcieri <[email-masked]>
Date: Sat, 29 Nov 2014 19:36:53 -0800

On Sat, Nov 29, 2014 at 7:29 PM, Paul Hoffman <[email-masked]> wrote:

> I think this will have to be an "agree to disagree" situation. The Let's
> Encrypt promotional material indicates that they want to get more HTTPS out
> in the world, so they need to deal with the huge number of folks who use
> hosting companies and thus have no DNS control. I believe that is a great
> goal.

I haven't fully been keeping up on the conversation, but if you're not
using DNS, what proof can be given over plaintext HTTP alone that isn't
susceptible to MitM attacks?

DNS seems like a better foundation to build on.

---

From: Eric Mill <[email-masked]>
Date: Sun, 30 Nov 2014 01:30:09 -0500

> hosting companies and thus have no DNS control. I believe that is a great

I agree with your assessment of LE's goal, and with the goal itself, but
aren't hosting companies themselves a meaningful target audience for ACME
and expanding HTTPS?

Anything that's in charge of your domain's DNS, or to whom you've delegated
control, should also be able to automate the provisioning of a free
certificate for you. No one's disputing that. So even if ACME did not prove
domain ownership by checking port 80, there'd be reason to believe it would
expand the playing field, if hosting companies found offering free
certificates a competitive feature.

That all said, I just read through the ACME draft spec[1], and none of the
listed proof-of-ownership methods involved just checking a path on port 80.

The HTTP-based proof mechanisms function by fetching a well-known URI over
port 443, and ensuring that a *valid self-signed certificate* is used to
make the connection and display the correct response. That self-signed cert
needs to use the same keypair that the server is attempting to validate for
use in making the CA-signed certificate.

That's smart, and completely removes concerns over things like
user-generated content hijacking a URI for someone else's server. To prove
you own a server without owning its DNS, you need to be able to generate a
keypair on the box and tell a webserver to use it -- the exact same control
you'd need to use Let's Encrypt in the first place -- and nothing less.

-- Eric

[1]
https://github.com/letsencrypt/acme-spec/blob/master/draft-barnes-acme.txt

-- 
konklone.com | @konklone <https://twitter.com/konklone>