Re: [Anima] two EST question/suggestions

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 <brian.e.carpenter@gmail.com> wrote:
> 
> On 13/09/2017 11:57, Michael Richardson wrote:
>> 
>> Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
>>>> 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.
>>>> 
>>>>> 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.
>>>> 
>>>> 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?
>> 
>>> 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.
>> 
>> 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*.
>> 
>>> 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.
>> 
>> 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).
> 
> 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
> 
> _______________________________________________
> Anima mailing list
> Anima@ietf.org
> https://www.ietf.org/mailman/listinfo/anima