[core] Signaling of BERT in TLS draft

[Jim Schaad]

I have just sat down to try and get my BERT support working correctly (and
clean up some block transfer bugs at the same time), and I have a question
about signaling support for BERT.

The document has the following two ways to signal BERT.

1. Use the SZX value of 7, presumably as part of a an early request to
signal that it is supported.
2. The use of the Block-wise transfer capability option combined w/ the
Max-Message-Size Option.


Questions:

1. The following sequence of events occurs

Signal - Max-Message-Size=3+K, Block-wise Transfer
Signal - Max-Message-Size=1152
Signal - Max-Message-Size=3+K

At the end of the sequence is the block-wise transfer capability still
enabled or not? The text says that step two in this sequence indicates that
it is no longer supported but I question that this is the intent. I think
it means that you can't do it not that it is no longer supported and thus
step three would re-able it.

2. If I send an SZ value of 7 as part of an early request, is this an
indicator for the channel as a whole or only for the specific request?

Jim

[Carsten Bormann]

Hi Jim,

thank you for the feedback.
Those “questions from the implementers” are always very useful.

Post by Jim Schaad
I have just sat down to try and get my BERT support working correctly (and
clean up some block transfer bugs at the same time), and I have a question
about signaling support for BERT.
The document has the following two ways to signal BERT.
1. Use the SZX value of 7, presumably as part of a an early request to
signal that it is supported.
2. The use of the Block-wise transfer capability option combined w/ the
Max-Message-Size Option.
1. The following sequence of events occurs
Signal - Max-Message-Size=3+K, Block-wise Transfer
Signal - Max-Message-Size=1152
Signal - Max-Message-Size=3+K
At the end of the sequence is the block-wise transfer capability still
enabled or not?

Yes. 5.3 says:

Both capability and setting options are cumulative. A CSM does not
invalidate a previously sent capability indication or setting even if
it is not repeated. A capability message without any option is a no-
operation (and can be used as such). An option that is sent might
override a previous value for the same option. The option defines
how to handle this case if needed.

Post by Jim Schaad
The text says that step two in this sequence indicates that
it is no longer supported

Where?

Post by Jim Schaad
but I question that this is the intent. I think
it means that you can't do it not that it is no longer supported and thus
step three would re-able it.
2. If I send an SZ value of 7 as part of an early request, is this an
indicator for the channel as a whole or only for the specific request?

This is for the specific request.

(For the channel, it is useful to know max-message-size in order to know whether BERT makes sense.
For a specific request, a requester can indicate in this way that it would prefer BERT, but there is no way to say “I have a max-message-size of 129 KiB, but for this request, 16 KiB blocks would be the bee’s knees...)

Grüße, Carsten

[Jim Schaad]

-----Original Message-----
Sent: Tuesday, December 12, 2017 12:15 PM
Subject: Re: [core] Signaling of BERT in TLS draft
Hi Jim,
thank you for the feedback.
Those “questions from the implementers” are always very useful.

Post by Jim Schaad
I have just sat down to try and get my BERT support working correctly
(and clean up some block transfer bugs at the same time), and I have a
question about signaling support for BERT.
The document has the following two ways to signal BERT.
1. Use the SZX value of 7, presumably as part of a an early request to
signal that it is supported.
2. The use of the Block-wise transfer capability option combined w/
the Max-Message-Size Option.
1. The following sequence of events occurs
Signal - Max-Message-Size=3+K, Block-wise Transfer Signal -
Max-Message-Size=1152 Signal - Max-Message-Size=3+K
At the end of the sequence is the block-wise transfer capability still
enabled or not?

Both capability and setting options are cumulative. A CSM does not
invalidate a previously sent capability indication or setting even if
it is not repeated. A capability message without any option is a no-
operation (and can be used as such). An option that is sent might
override a previous value for the same option. The option defines
how to handle this case if needed.

Post by Jim Schaad
The text says that step two in this sequence indicates that it is no
longer supported

The text in section 5.3.2 states:

Subsequently, if the Max-Message-Size Option is
indicated with a value equal to or less than 1152, BERT support is no
longer indicated.

To me that says I should go into an unknown state.

Where?

Post by Jim Schaad
but I question that this is the intent. I think it means that you
can't do it not that it is no longer supported and thus step three
would re-able it.
2. If I send an SZ value of 7 as part of an early request, is this an
indicator for the channel as a whole or only for the specific request?

This is for the specific request.

Good, that was my guess, but was not sure.

Jim

(For the channel, it is useful to know max-message-size in order to know
whether BERT makes sense.
For a specific request, a requester can indicate in this way that it would prefer
BERT, but there is no way to say “I have a max-message-size of 129 KiB, but for
this request, 16 KiB blocks would be the bee’s knees...)
Grüße, Carsten

[Jim Schaad]

Rereading the section again I just noticed that I was totally misreading it. For some reason I was reading it as supports BERT not supports block-wise transfer.

Sorry.

Jim

-----Original Message-----
Sent: Tuesday, December 12, 2017 12:15 PM
Subject: Re: [core] Signaling of BERT in TLS draft
Hi Jim,
thank you for the feedback.
Those “questions from the implementers” are always very useful.

Post by Jim Schaad
I have just sat down to try and get my BERT support working correctly
(and clean up some block transfer bugs at the same time), and I have a
question about signaling support for BERT.
The document has the following two ways to signal BERT.
1. Use the SZX value of 7, presumably as part of a an early request to
signal that it is supported.
2. The use of the Block-wise transfer capability option combined w/
the Max-Message-Size Option.
1. The following sequence of events occurs
Signal - Max-Message-Size=3+K, Block-wise Transfer Signal -
Max-Message-Size=1152 Signal - Max-Message-Size=3+K
At the end of the sequence is the block-wise transfer capability still
enabled or not?

Both capability and setting options are cumulative. A CSM does not
invalidate a previously sent capability indication or setting even if
it is not repeated. A capability message without any option is a no-
operation (and can be used as such). An option that is sent might
override a previous value for the same option. The option defines
how to handle this case if needed.

Post by Jim Schaad
The text says that step two in this sequence indicates that it is no
longer supported

Where?

Post by Jim Schaad
but I question that this is the intent. I think it means that you
can't do it not that it is no longer supported and thus step three
would re-able it.
2. If I send an SZ value of 7 as part of an early request, is this an
indicator for the channel as a whole or only for the specific request?

This is for the specific request.
(For the channel, it is useful to know max-message-size in order to know
whether BERT makes sense.
For a specific request, a requester can indicate in this way that it would prefer
BERT, but there is no way to say “I have a max-message-size of 129 KiB, but for
this request, 16 KiB blocks would be the bee’s knees...)
Grüße, Carsten