Subject: Re: [Anima] two EST question/suggestions

From: "Max Pritikin (pritikin)" <[email-masked]>
Date: Fri, 8 Sep 2017 22:50:33 +0000

> On Aug 29, 2017, at 2:31 PM, Michael Richardson <[email-masked]> wrote:
> 
> 
> Max, I suggest that we add some text to section 2 to indicate that BRSKI EST
> connections SHOULD be HTTP 1.1 persistent connections.
> I wrote:
>        <t>Establishment of the TLS connection for bootstrapping is as
>           specified in EST <xref target="RFC7030"/> section 4.1.1 "Bootstrap
>           Distribution of CA Certificates" <xref target="RFC7030"/>.
>           While EST section 3.2 does not insist
>           upon use of HTTP 1.1 persistent
>           connections, BRSKI connections SHOULD use
>           persistent connections.  This is due to the provisional state
>           that occurs in the TLS connection.
>           The following extensions are added for automation:
>         </t>
> 

I agree with this and used the change to tighten language about EST integration a bit more:
	https://github.com/anima-wg/anima-bootstrap/commit/def9e6351b03f93073f7ff09ebbabd87e8643f95

> We may also want to say something about HTTP 2.0's multiplexed
> request/responses (I think we don't want them).  I'm not sure exactly what
> the list of things we don't want yet, or how to express this.
> I am sure that we don't want QUIC (or SPDY) or other stuff like that!
> 
> I don't know if the binary-ness of HTTP2 matters to use at all in the end,
> and we should just let that upgrade path simply proceeed.

The only HTTP version we indicate is 1.1. in your language inserted above. 
EST is similarly vague, only referencing 1.1. in the context of persistent connections. 

I agree a statement that HTTP2 etc is ok so long as it doesn’t change the possible client state machine…  ?

> 
> The other question is about the use of 102 Processing codes, and 201 Created
> codes.  I think that we discussed making /requestvoucher more RESTful by
> returning a 201 Created, along with a Location: header, and decided against
> it.  I think that I'm partly re-opening this question. (Shall I make it a ticket)

I’d recommend a ticket. Not sure I want to open this again but am willing to hear the argument. 

> 
> The reason for my question is about Registrar->MASA interactions that need to
> occur, and timeouts that might occur.  Returning a 201 Created pointing to a
> URL that could be used to retrieve the resulting voucher would provide a nice
> way to do things. If upon the pledge issuing the GET, the voucher still isn't
> ready, a 102 Processing code could be returned.
> 
> I'm particularly concerned that the pledge not set too-short timeouts here,
> as the only recourse it would have is to close the connection.

understood,

- max

> 
> --
> Michael Richardson <[email-masked]>, Sandelman Software Works
> -= IPv6 IoT consulting =-
> 
> 
> 
> _______________________________________________
> Anima mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/anima

---

From: Eliot Lear <[email-masked]>
Date: Tue, 12 Sep 2017 16:33:52 +0200

Hi,

> I agree a statement that HTTP2 etc is ok so long as it doesn’t change the possible client state machine…  ?

You need an MTI, and it should be the easiest and most compact thing to
implement.  While CoAP would be optimal, HTTP/1.1 is more than
sufficient, and the features in 2 in this case are not only unnecessary,
but undesirable overhead.

Eliot

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 13 Sep 2017 08:03:45 +1200

> but undesirable overhead.

I am a bit bothered by the assumption that all devices of interest can be assumed
to include X, for whatever value of X we deem to be MTI. Or are you only
intending MTI to apply at the server end?

It seems to me that we want to minimise the requirements for low end pledge
devices, and every item that we make mandatory works against that.

     Brian

---

From: Eliot Lear <[email-masked]>
Date: Tue, 12 Sep 2017 22:42:03 +0200

> intending MTI to apply at the server end?

Hmm.  Actually, I don't like my own text precisely for the reason you
state.  But I do think we don't want to create a plethora of choices. 
There is an interoperability issue here that has to be addressed.

> devices, and every item that we make mandatory works against that.

Right, but we need to have something there.

Eliot

---

From: Michael Richardson <[email-masked]>
Date: Tue, 12 Sep 2017 16:51:35 -0400

> intending MTI to apply at the server end?

We are running over HTTP 1.1, we have to assume that.
The issue is that both client and server libraries will grow HTTP 2, and we
need to know if this is a problem.

    > devices, and every item that we make mandatory works against that.

BRSKI does not target constrained devices;  in the future having only an HTTP
2 library (because the application is using that) might be simplest.  Is it
going to work okay?

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 13 Sep 2017 10:25:14 +1200

> 2 library (because the application is using that) might be simplest.  Is it

I don't see why not. But isn't there potentially a class of devices that
while not being 'constrained' in the formal sense, nevertheless needs to
minimise its software footprint? So the implementer will want to choose
the solution with the smallest footprint, rather than whatever MTI we
happen to define in 2017.

Of course we can always change the MTI later, but if we say right now that
the MTI only applies to the server side, adding new solutions for future
types of pledge becomes more straightforward. As far as I can see, this
would have zero impact on first-generation implementations; initially
both servers and clients will support the MTI anyway.

   Brian

---

From: Michael Richardson <[email-masked]>
Date: Tue, 12 Sep 2017 19:57:43 -0400

> happen to define in 2017.

Yes, I agree with you.

That's why I would like us to permit pledges to support a single client HTTP
library.  They will use whatever HTTP client library that they need for their
primary application... so if it's a webrtc nanny camera, then it might well
be HTTP2 + QUIC.

The problem with HTTP2 is that it permits requests and responses to be
interleaved and not-sequential in the TCP sense.  This potentially has a poor
interaction with the BRSKI state machine.  We ought to say something about
this *today*.

    > both servers and clients will support the MTI anyway.

My take is that the server has to support every single MTI that we have every
supported.  That's okay.  But, HTTP 1.1 with persistent connections is the
minimum (not the maximum).

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 14 Sep 2017 08:13:33 +1200

> minimum (not the maximum).

Fair enough. I just want to be sure that when someone comes up with
a brilliant new method with a tiny footprint, pledges are free to adopt
it despite any MUSTs we write down in 2017.

    Brian

---

From: "Max Pritikin (pritikin)" <[email-masked]>
Date: Tue, 19 Sep 2017 20:34:15 +0000

Any protocol work needs balance future proofing (anticipating changes in the MTI) against clear and definitive statements to meet the current requirements. If there are places where the current language falls down commenting on that specific language would help.

Re the HTTP/2 discussion:

HTTP/2 is requested by the client via one of the RFC7540 section3 methods. There is nothing in the MTI BRSKI language that would block attempts to so upgrade by clients. The server could of course support this if it so desired. 

I don’t see an advantage to HTTP/2 for BRSKI and EST interactions. I guess a server could finish authentication of the client and immediately initiate a server push of the csrattributes, voucher response (if available), and other messages. This would save some round trips but in the primary flows the client needs to perform a crypto operation that is used or verified by the server before a response is generated. So the basic state machine, I think, would continue to flow as currently specified. 

I agree with the conclusion below that "TTP 1.1 with persistent connections is the minimum (not the maximum)” and that we don’t have anything else to say here. 

- max

> On Sep 13, 2017, at 2:13 PM, Brian E Carpenter <[email-masked]> wrote:
>