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

From: Toerless Eckert <[email-masked]>
Date: Wed, 10 Jul 2019 16:59:07 +0200

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 <[email-masked]>, Sandelman Software Works
>  -= IPv6 IoT consulting =-
> 
> 
> 

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

---

From: Michael Richardson <[email-masked]>
Date: Wed, 17 Jul 2019 13:10:48 -0400

Toerless Eckert <[email-masked]> wrote:
    > 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.

Based upon feedback on the -00 and -01, it appears that nobody actually sends
the CTE header, so we have no signal about it being binary or base64, and
everyone just sends base64.  So the clarification becomes that the CTE
header is redundant, should be ignored, and the payload is always base64.

If we did an rfc7030bis, then we might define new end-points, but that seems
like busy work to me.

    > 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 ?

always base64 the payloads

    >> 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 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.

I have added a section to BRSKI that clarifies that, despite EST7030 being
base64 encoded, BRSKI payloads (voucher, voucher-request) are binary.

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 17 Jul 2019 19:39:42 +0200

> header is redundant, should be ignored, and the payload is always base64.

Great. That could be written more explicitly in the draft.

> If we did an rfc7030bis, then we might define new end-points, but that seems

Agreed. A small update RFC will be much more economical and if well
written also much easier to understand.

> always base64 the payloads

I figured that. But i think you are also saying that you do
not need to send CTE to be backward compatible, thats even better.

> base64 encoded, BRSKI payloads (voucher, voucher-request) are binary.

Thats ok. to ensure that BRSKI is as independent of an rfc7030 update
draft as possible, but it would be good to also suggest doing this in your updte
draft so that any other rfc7030 extensions could foolow that lead.

Btw: If there is no more feedback from the WGs you addressed in this
mail, please consider asking for a slot on the agenda of eithre of them
anyhow. Much harder for them to ignore the issue in email than in the
room ;-)

(which of course doesn't mean that we shouldn't discuss in ANIMA, but i
guess we agree that any better http/est? expert opinion input would be helpfull).

Cheers
    toerless

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 17 Jul 2019 23:55:16 +0200

> always base64 the payloads

Which means that the content-type headers lie.
Backwards combyativbility [actual autocorrect result :-)] can be nasty.
But sniffing this out should be easy.

Grüße, Carsten

---

From: Michael Richardson <[email-masked]>
Date: Sun, 21 Jul 2019 22:51:54 -0400

> Which means that the content-type headers lie.  Backwards
    > combyativbility [actual autocorrect result :-)] can be nasty.  But
    > sniffing this out should be easy.

You are saying that the Content-Type: application/pkcs* claims are
incorrect, because the payloads have been base64 encoded.
This would be quite normal had these payloads been carried in email
(which does happen) but then there would have been a useful CTE header to
clarify the encoding.

I agree that it's definitely inconsistent, and this is why I think it's not
enough for it to just remain as errata.

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works        | network architect  [ 
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [