Re: [Acme] Concerning alternative formats …

[Matthew D. Hardeman]

> On Mar 5, 2018, at 3:50 PM, Felipe Gasper  wrote:
> 
> 
>> On Mar 5, 2018, at 1:13 PM, Matthew D. Hardeman  
>> wrote:
>> 
>> Especially with CT logging being a pragmatic requirement, time-to-delivery 
>> for certificates is likely to increase (slightly) rather than decrease.
> 
> Quick point: the alleviation of polling would go for authz status as well as 
> to certificate delivery.
> 
> A certificate order that has 10 domains needs to poll for the status of all 
> 10 of those domains’ authorizations as well as the certificate issuance. 
> “ACME/bidi” would remove all 11 of those needs to poll.
> 

While it eliminates the need for those 11 targets to poll for, it adds the not 
insignificant infrastructure cost of nailing up a stateful connection.  It’s 
worth mention that the past decade has seen massive improvements in the network 
stack from the low layer up through application layer apis as it would pertain 
to handling a great many of these connections, but there is still some cost to 
nailing up large numbers of concurrent connections.

As others note, h2 offers numerous models under which you could achieve the 
same benefits of getting asynchronous return of results over a single TCP 
session.

I would think that even if you have a clear, consistent, bidirectional 
communication channel that it would still make sense for the individual message 
content to remain unchanged.  (Not optimizing out replay-nonce, etc.)  As a 
general matter, protocols dealing with security and integrity probably achieve 
better and stronger implementations in the field when variability and supported 
cases are reduced to the minimum required to achieve the protocol’s goals.  
Where possible, I would think removal of edge cases, exceptions, and different 
handling for different messaging protocols would be a positive value.
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] Concerning alternative formats …

[Martin Thomson]

Sure.  Plenty of ways to do that.

If your primary concern is issuance, then you don't even need server
push, you can just long-poll.  In HTTP/1.1, that's gross because it
ties up a connection and has some disgusting keep-alive properties.
In h2 there is no opportunity cost to worry about, the connection
remains usable for other things while you wait.  (You can use
prefer:wait to control timing if you want a standards-based solution:
https://tools.ietf.org/html/rfc7240#section-4.3)

On Tue, Mar 6, 2018 at 9:27 AM, Richard Barnes  wrote:
> Thomson: Could h2 push replace some of the polling here?
>
> On Mon, Mar 5, 2018 at 4:50 PM, Felipe Gasper 
> wrote:
>>
>>
>> > On Mar 5, 2018, at 1:13 PM, Matthew D. Hardeman 
>> > wrote:
>> >
>> > Especially with CT logging being a pragmatic requirement,
>> > time-to-delivery for certificates is likely to increase (slightly) rather
>> > than decrease.
>>
>> Quick point: the alleviation of polling would go for authz status as well
>> as to certificate delivery.
>>
>> A certificate order that has 10 domains needs to poll for the status of
>> all 10 of those domains’ authorizations as well as the certificate issuance.
>> “ACME/bidi” would remove all 11 of those needs to poll.
>>
>> Thanks for those who have given this suggestion their consideration. I
>> don’t mean to “gum up the gears” for the main ACME work, but as I’ve been
>> writing ACME clients the polling stuff has stuck out to me like a sore
>> thumb.
>>
>> It’s worth noting, too, that concerns about overhead may be alleviated if
>> we do get a usable WebSocket-over-HTTP/2 implementation. Or, maybe someone
>> will expose an SCTP endpoint, or a raw TCP endpoint that implements a simple
>> message-boundary layer. I think the question of pure-message, bidirectional
>> transport is more relevant than a specific transport implementation.
>>
>> -F
>
>

___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] Concerning alternative formats …

[Richard Barnes]

Thomson: Could h2 push replace some of the polling here?

On Mon, Mar 5, 2018 at 4:50 PM, Felipe Gasper 
wrote:

>
> > On Mar 5, 2018, at 1:13 PM, Matthew D. Hardeman 
> wrote:
> >
> > Especially with CT logging being a pragmatic requirement,
> time-to-delivery for certificates is likely to increase (slightly) rather
> than decrease.
>
> Quick point: the alleviation of polling would go for authz status as well
> as to certificate delivery.
>
> A certificate order that has 10 domains needs to poll for the status of
> all 10 of those domains’ authorizations as well as the certificate
> issuance. “ACME/bidi” would remove all 11 of those needs to poll.
>
> Thanks for those who have given this suggestion their consideration. I
> don’t mean to “gum up the gears” for the main ACME work, but as I’ve been
> writing ACME clients the polling stuff has stuck out to me like a sore
> thumb.
>
> It’s worth noting, too, that concerns about overhead may be alleviated if
> we do get a usable WebSocket-over-HTTP/2 implementation. Or, maybe someone
> will expose an SCTP endpoint, or a raw TCP endpoint that implements a
> simple message-boundary layer. I think the question of pure-message,
> bidirectional transport is more relevant than a specific transport
> implementation.
>
> -F
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] Concerning alternative formats …

[Felipe Gasper]

> On Mar 5, 2018, at 1:13 PM, Matthew D. Hardeman  wrote:
> 
> Especially with CT logging being a pragmatic requirement, time-to-delivery 
> for certificates is likely to increase (slightly) rather than decrease.

Quick point: the alleviation of polling would go for authz status as well as to 
certificate delivery.

A certificate order that has 10 domains needs to poll for the status of all 10 
of those domains’ authorizations as well as the certificate issuance. 
“ACME/bidi” would remove all 11 of those needs to poll.

Thanks for those who have given this suggestion their consideration. I don’t 
mean to “gum up the gears” for the main ACME work, but as I’ve been writing 
ACME clients the polling stuff has stuck out to me like a sore thumb.

It’s worth noting, too, that concerns about overhead may be alleviated if we do 
get a usable WebSocket-over-HTTP/2 implementation. Or, maybe someone will 
expose an SCTP endpoint, or a raw TCP endpoint that implements a simple 
message-boundary layer. I think the question of pure-message, bidirectional 
transport is more relevant than a specific transport implementation.

-F
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] Concerning alternative formats …

[Matthew D. Hardeman]

My working experience is primarily outside the PKI space, but I can offer some 
perspectives on scalability and deployment architecture issues.

WebSocket is entirely appropriate for real-time or near-real-time bidirectional 
communications of an asynchronous nature.

The overhead of WebSocket as a pure transport for the various ACME messages 
back and forth between the client and the server could be done, but would any 
server side implementation ever take full advantage with the appropriate async 
callbacks to actually achieve faster certificate delivery.

Especially with CT logging being a pragmatic requirement, time-to-delivery for 
certificates is likely to increase (slightly) rather than decrease.

In the kind of pattern that getting a certificate represents it seems WebSocket 
would add significant overhead without a lot of performance advantage.

If the content and nature of the messages would change based on WebSocket used 
as a transport, then you’ve got a whole new set of threats to model and 
consider.

Perhaps before going down that road, it would be useful to poll server-side 
implementers and deployers and see if there’s interest in a WebSocket delivery 
channel.


> On Mar 5, 2018, at 8:11 AM, Felipe Gasper  wrote:
> 
> For what it’s worth:
> 
> Regarding alternative formats, I think ACME over WebSocket would be a great 
> thing. Replay-nonce would go away, and clients wouldn’t need to poll for the 
> certificate unless the connection dropped. The server could send the 
> certificate as soon as it’s ready. A simple handshake at the start could take 
> the place of JWS, too.
> 
> -F
> 
>> On Mar 5, 2018, at 12:02 AM, Martin Thomson  wrote:
>> 
>> Unless you believe that an alternative format is ever desirable.  CBOR
>> for version 2 might be a terrible idea, but I know the IETF well
>> enough not to rule that out entirely.
>> 
>> On Mon, Mar 5, 2018 at 3:38 PM, Richard Barnes  wrote:
>>> I also note that there's no issue with Accept if we require the use of the
>>> Flattened JSON serialization.
>>> 
>>> https://i.imgflip.com/25r2ui.jpg
>>> 
>>> https://github.com/ietf-wg-acme/acme/pull/410
>>> 
>>> On Sun, Mar 4, 2018 at 6:28 PM, Martin Thomson 
>>> wrote:
 
 That's a bit silly.  I'll follow-up with httpbis.  I think that's an
 error, though probably only an error of omission.  7694 was so fixated
 on solving the content-coding issue, it neglected the obvious
 accompanying fix.
 
 On Mon, Mar 5, 2018 at 9:38 AM, Richard Barnes  wrote:
> How about Accept?  It looks like 7694 gives the server a way to specify
> encodings, but not the content type.  But 7231 says that Accept only
> replies
> to response media types.
> 
> On Sun, Mar 4, 2018 at 5:33 PM, Martin Thomson
> 
> wrote:
>> 
>> 415 is for the case where a client provides bad request content, so
>> yes.
>> See rfc7694 for details.
>> 
>> 406 is for failed conneg. Not something you expect to see much here.
>> 
>> 
>> On 5 Mar. 2018 09:25, "Richard Barnes"  wrote:
>> 
>> The lengths of the emails in this thread illustrate the complexity risk
>> here :)
>> 
>> In the interest of simplicity, I would really like to stick to
>> Flattened
>> JSON unless someone has **strong** objections.
>> 
>> Logan, to your point about library compatibility, two notes: (1) it's
>> OK
>> if we front-run libraries a little.  It's not hard for libraries to
>> upgrade;
>> this is only formatting, no crypto changes needed.  (2) Empirically,
>> this
>> must not be too big a blocker for people, since as Jacob notes, Let's
>> Encrypt only supports Flattened JSON right now and they've got a bunch
>> of
>> clients talking to them.
>> 
>> As far as headers / response codes: You're correct that 406 is wrong /
>> 415
>> is right.  But ISTM that Accept is still the right header to say what
>> is
>> right.  So the server should return 415+Accept.  Copying Thomson to
>> check
>> our work here.
>> 
>> --Richard
>> 
>> On Sun, Mar 4, 2018 at 10:43 AM, Logan Widick 
>> wrote:
>>> 
>>> How about this: Specify a default format (either "application/jose"
>>> for
>>> Compact Serialization, or "application/jose+json" with Flattened
>>> Serialization - I have no preference which one), with optional support
>>> for
>>> other formats if needed? Even with JOSE libraries that don't support
>>> all
>>> serializations and/or don't provide control over which serialization
>>> is
>>> used, a programmer would at least need to know (or experimentally find
>>> out)
>>> if a JSON serialization or if the compact one is being produced. If a
>>> JSON
>>> 

Re: [Acme] Concerning alternative formats …

[Felipe Gasper]

> On Mar 5, 2018, at 9:35 AM, Jörn Heissler  
> wrote:
> 
> On Mon, Mar 05, 2018 at 09:11:02 -0500, Felipe Gasper wrote:
>> Regarding alternative formats, I think ACME over WebSocket would be a great 
>> thing. Replay-nonce would go away, and clients wouldn’t need to poll for the 
>> certificate unless the connection dropped. The server could send the 
>> certificate as soon as it’s ready. A simple handshake at the start could 
>> take the place of JWS, too.
> 
> Moving to websocket would mean having to specify a new websocket based
> protocol and reimplementing all servers/clients.

I would think “ACME/bidi” could live alongside ACME/HTTP. The bidirectional 
variant could be described in a separate RFC that gives the differences--which 
would basically just be how to translate the HTTP-specific parts of ACME/HTTP 
to “pure messages”.

WebSocket wouldn’t necessarily be the only persistent-connection format; any 
reliable, message-oriented protocol (e.g., SCTP or WAMP “RawSocket”) could work.

> You'd also need to consider MitM (e.g. by CDN or expensive enterprise MitM
> appliances). Doing a handshake at the beginning won't be enough to keep
> those from taking over a session after the handshake.
> 
> If you wanted to eliminate the polling, it would be possible to change
> the finalize endpoint to return the certificate directly, even if it
> takes a while until the HTTP response is sent.

This would alleviate the polling for the certificate but not for authz status. 
If I have an Order with, say, 5 authzs, I’ll still need to poll for the state 
of those.

A transport layer that allows asynchronous server-to-client communication would 
facilitate quicker feedback to the client and a smoother user experience 
overall. 

-F
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] Concerning alternative formats …

[Jörn Heissler]

On Mon, Mar 05, 2018 at 09:11:02 -0500, Felipe Gasper wrote:
> Regarding alternative formats, I think ACME over WebSocket would be a great 
> thing. Replay-nonce would go away, and clients wouldn’t need to poll for the 
> certificate unless the connection dropped. The server could send the 
> certificate as soon as it’s ready. A simple handshake at the start could take 
> the place of JWS, too.

Moving to websocket would mean having to specify a new websocket based
protocol and reimplementing all servers/clients.
You'd also need to consider MitM (e.g. by CDN or expensive enterprise MitM
appliances). Doing a handshake at the beginning won't be enough to keep
those from taking over a session after the handshake.

If you wanted to eliminate the polling, it would be possible to change
the finalize endpoint to return the certificate directly, even if it
takes a while until the HTTP response is sent.

Anyway, I'm satisfied with the current protocol. Complexity should (and
can) be addressed by client implementors.


signature.asc
Description: PGP signature
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

[Acme] Concerning alternative formats …

[Felipe Gasper]

For what it’s worth:

Regarding alternative formats, I think ACME over WebSocket would be a great 
thing. Replay-nonce would go away, and clients wouldn’t need to poll for the 
certificate unless the connection dropped. The server could send the 
certificate as soon as it’s ready. A simple handshake at the start could take 
the place of JWS, too.

-F

> On Mar 5, 2018, at 12:02 AM, Martin Thomson  wrote:
> 
> Unless you believe that an alternative format is ever desirable.  CBOR
> for version 2 might be a terrible idea, but I know the IETF well
> enough not to rule that out entirely.
> 
> On Mon, Mar 5, 2018 at 3:38 PM, Richard Barnes  wrote:
>> I also note that there's no issue with Accept if we require the use of the
>> Flattened JSON serialization.
>> 
>> https://i.imgflip.com/25r2ui.jpg
>> 
>> https://github.com/ietf-wg-acme/acme/pull/410
>> 
>> On Sun, Mar 4, 2018 at 6:28 PM, Martin Thomson 
>> wrote:
>>> 
>>> That's a bit silly.  I'll follow-up with httpbis.  I think that's an
>>> error, though probably only an error of omission.  7694 was so fixated
>>> on solving the content-coding issue, it neglected the obvious
>>> accompanying fix.
>>> 
>>> On Mon, Mar 5, 2018 at 9:38 AM, Richard Barnes  wrote:
 How about Accept?  It looks like 7694 gives the server a way to specify
 encodings, but not the content type.  But 7231 says that Accept only
 replies
 to response media types.
 
 On Sun, Mar 4, 2018 at 5:33 PM, Martin Thomson
 
 wrote:
> 
> 415 is for the case where a client provides bad request content, so
> yes.
> See rfc7694 for details.
> 
> 406 is for failed conneg. Not something you expect to see much here.
> 
> 
> On 5 Mar. 2018 09:25, "Richard Barnes"  wrote:
> 
> The lengths of the emails in this thread illustrate the complexity risk
> here :)
> 
> In the interest of simplicity, I would really like to stick to
> Flattened
> JSON unless someone has **strong** objections.
> 
> Logan, to your point about library compatibility, two notes: (1) it's
> OK
> if we front-run libraries a little.  It's not hard for libraries to
> upgrade;
> this is only formatting, no crypto changes needed.  (2) Empirically,
> this
> must not be too big a blocker for people, since as Jacob notes, Let's
> Encrypt only supports Flattened JSON right now and they've got a bunch
> of
> clients talking to them.
> 
> As far as headers / response codes: You're correct that 406 is wrong /
> 415
> is right.  But ISTM that Accept is still the right header to say what
> is
> right.  So the server should return 415+Accept.  Copying Thomson to
> check
> our work here.
> 
> --Richard
> 
> On Sun, Mar 4, 2018 at 10:43 AM, Logan Widick 
> wrote:
>> 
>> How about this: Specify a default format (either "application/jose"
>> for
>> Compact Serialization, or "application/jose+json" with Flattened
>> Serialization - I have no preference which one), with optional support
>> for
>> other formats if needed? Even with JOSE libraries that don't support
>> all
>> serializations and/or don't provide control over which serialization
>> is
>> used, a programmer would at least need to know (or experimentally find
>> out)
>> if a JSON serialization or if the compact one is being produced. If a
>> JSON
>> serialization is selected as the default, a programmer should be able
>> to
>> convert between the two JSON serializations easily as needed before
>> and/or
>> after using a JOSE library. If a JSON format is declared as the
>> default but
>> the JOSE library only has the compact one, or vice-versa, conversion
>> before
>> and/or after the JOSE library would be more complex but should still
>> be
>> doable with guidance.
>> 
>> The directory meta item could be defined as something like:
>> 
>> supportedSerializations: An array of supported serialization formats
>> as
>> described in {{jws-serialization-formats}}. If this is not specified,
>> assume
>> that the server only supports [insert selected default here].
>> 
>> Then, the JWS Serialization Formats section could be changed to
>> something
>> like the following:
>> 
>> The JSON Web Signature (JWS) specification {{!RFC7515}} contains
>> multiple
>> JWS serialization formats. When sending an ACME request with a
>> non-empty
>> body, an ACME client implementation SHOULD use the HTTP Content-Type
>> {{!RFC7231}} header to indicate which JWS serialization format is used
>> for
>> encapsulating the ACME request payload.
>> 
>> Each serialization format defined for use in ACME is described