Re: [Anima] addressing Content-Type-Encoding errata on EST / RFC7030 --- relationship to BRSKI

[Toerless Eckert <[e-mail]>]

Thanks, Michael,

inline

On Mon, Jun 17, 2019 at 11:55:35AM -0400, Michael Richardson wrote:
> 
> I have posted the draft
>   https://datatracker.ietf.org/doc/draft-richardson-lamps-rfc7030est-clarify/
> 
> this morning.  It attempts to address the errata posted by Sean Turner in
> 2017 on RFC7030.  Specifically the use of Content-Type-Encoding (CTE) and
> base64. You can see my other query to httpbis at:
>   https://mailarchive.ietf.org/arch/msg/httpbisa/m4l4G_lHKfQVfSeAn7IxReUioD0
> 
> In doing BRSKI (draft-ietf-anima-bootstrapping-keyinfra) interop testing we
> had a number of confusions about whether or things are base64 encoded, and if
> they are always base64 encoded, why send the CTE header, and if BRSKI is
> binary or base64 encoded!
> 
> Given that RFC7030 is somewhat well deployed, acting on the errata that Sean
> Turner noted is a bit difficult!  (As a process thing, it's a problem that
> his 2017 errata seems to have gone into /dev/null).
> 
> I am posting the core of the proposal at the bottom of this email.
> It tries to leverage the Postel doctrine in a way.
> 
> Some questions/issues:
> 
> 1) does this belong in secdispatch?
> 
> 2) is this appropriate for LAMPS?

No idea, but if those WGs don't want to pick up the work,
then i would certainly be happy to have the argument with OPS AD
to do it in ANIMA given how i see this as an important dependency
for BRSKI. Even though i would obviously prefer a WG thats
more an expert at this. But "this" seems to be completely
security unrelated and only about HTTP and payload encoding
issues, so i fear its just considered to be a pain in the neck
by every working group ;-)

> 3) independant submission seems wrong.

Yes. I think this should be a small, fast standardized
update to 7030 and any possibly existing standards using 7030.

Your document is a great start IMHO.

My main suggestions would be some better
strucutre and some more explanations.

For the structure, i would just like to see sections 4..6
grouped into one section like "RFC7030 changes and clarifications".

For the explanations i would primarily like to see a bit
more text discussing backward compatibility and relationship
to the 7030 erratas.

>From what i guess to understand:

Erratas 4384 and 5108 seem not to introduce any backward
compatibility issues with whats observed in the field.
So your draft suggest to adopt them.

Errata 5107 on the other hand seems to be asking to remove CTE header
by default, but doesn't really say what to do with 7030 base64 payload.
One could interpret it to send binary which would be backward incompatible,
or one could interpret it as sending base64 by mutual agreement, but
without explicitly writing this into a text its guesswork.

So your drafts section 4 seems to be this refinement of 5107 to close
this gap, but it doesn't refer/explain to 5107 and explain the difference.

What seems to be incomplete in your draft is whether to send or
not to sent CTE, it only says to ignore it upon receipt. So, whats
the minimum requirement for fully backward compatibility on sending ?

-> EST server could deduce whether client rquires CTE by
   looking at EST client request headers and not send CTE 
   when client doesn't use it ?
-> EST client MUST continue to send CTE ?

(not quite sure).

Of course, 7030bis could specify non-fully backward compatible
option, which is never to use CTE, but it would be good to explain
real good technical reasons instead of just pointing to standards
for HTTP.

To me, the strongest technical reason is that proliferation of EST(bis)
would be helped if EST(bis) can be implemented as an app on non-EST dedicated
HTTP servers, and i think that was the whole point of of how EST
was designed, and that is only possible when EST(bis) does not expect
non-standard HTTP behavior.

> 4) ANIMA BRSKI needs to clarify things itself, and I will add a section on
>    this, but I'm hesistant to add a normative reference here.
>    I have an idea of appropriate text that I will post on Tuesday.
>    Getting clarity here is really the most important thing for me.

I would like to see avoiding to drag this issue into BRSKI text 
unless we have to. I would simply have a reference to this draft 
in BRSKI and one sentence about it near the first mentioning of 7030 in
BRSKI.

If BRSKI finishes RFC before this draft, it would later be part of
the update list of this draft once it becomes RFC. If this draft
finishes RFC before BRSKI, we can still qickly fix up the BRSKI
examples (i guess its's mostly examples).

Even if BRSKI review asks for the document to become a normative
dependency, its still better to have these signaling details
not clutter up the BRSKI text and that cluttered text be something
thart needs to be copied into other 7030 extensions.

To do this, IMHO, the draft text you proposed should accordingly be extended
to establish extensible guidance when to use no-CTE/base64-DER-payload
vs. binary payload for existing and future messages.

> 5) I don't have a simple answer for the /csrattrs API. Maybe it needs to be solved
>    by creating a new end point.  or it could be done with Accept: header.

How is the csrattr problem different ? Your section 4 looks as
if it should/could be handled the same as the CA related
command/replies.  If not, then please add text explaining the issue.

> ps: it's ironic to me, this is perhaps something that could also be solved
>     by versioning the API in the URL.

Wouldn't really help for a CTE legacy client connecting to a new server
and choking on the absence of CTE from that server, right ?

>    For the other three methods, when the client is aware that this is an

Which other three methods ?
(this text seems to be a bit out of context...)

>    amended server then it SHOULD send the POST request in binary form
>    (DER-encoded), and omit the Content-Transfer-Encoding header.  How
>    the client knows what kind of server it is dealing with is
>    communicating with is detailed in the next section.
> 
>    An amended server, when it receives a request that has no Content-
>    Transfer-Encoding header, or has a Content-Transfer-Encoding header
>    with the "binary" attribute, MUST respond in the same binary format.
> 
>    When an amended server receives a request in CTE-base64 form, then it
>    MAY respond in kind.  It is reasonable for a server to be configured
>    to ignore or fail requests of this form, either via run-time
>    configuration, or via a compile-time option.  A main reason to do
>    this is to avoid a permutation that requires testing in the future
>    when no legacy EST clients are expected to connect.

I'd say we need to figure out which methods from 7030 or extensions need
to continue using base64 DER payload (without CTE) because
implementations exist that are relevant to be compatible with, all others use
binary without CTE. And that text goes into the draft. I see no need
to optimize base64 away given how i don't think that HTTP shouldn't
really be the transport for bitrate sensitive communications. Aka:
EST over COAP could of course all be binary.

Cheers
    Toerless

> --
> Michael Richardson <[e-mail]>, Sandelman Software Works
>  -= IPv6 IoT consulting =-
> 
> 
> 



> _______________________________________________
> Anima mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/anima