On Sun, Nov 7, 2021 at 2:27 PM Hanno Becker wrote:
> > So absent serious flaws, I think we should make as few changes as
> possible
>
> Understood and agreed, though if a small tweak in wording gets all cases
> covered we care about,
> let's do it now.
>
> > Yes, the current text which requires y
> > 'Small tweak in wording': Can we say "Where possible, implementations MAY
> > process data immediately rather than buffering it"?
> That would be fine with me.
Great!
> > That existing text does not allow the mentioned simplified reassembly
> > scheme though, does it?
> No. As I indicated i
Hi Jonathan,
On 05/11/2021 15:34, Jonathan Hoyland wrote:
Hi Simo,
As I said in my email to Sam, my language here was sloppy, I meant
that the channel binding is included in the key derivation process,
and thus the output keys will be related to each other.
The term channel bindings has two d
On Mon, Nov 8, 2021 at 3:58 AM Hanno Becker wrote:
> > > 'Small tweak in wording': Can we say "Where possible, implementations
> MAY process data immediately rather than buffering it"?
> > That would be fine with me.
>
> Great!
>
> > > That existing text does not allow the mentioned simplified re
* No. As I indicated in my earlier, email, while that scheme may
technically work, it is potentially highly inefficient and I think we should
discourage it.
To be clear, not something we need to address here and now.
___
TLS mailing list
TLS@ietf.
Ok, let's defer discussion around potential rewording of the buffering text,
and go with the following:
"When a DTLS implementation receives a handshake message fragment corresponding
to the next expected handshake message sequence number, it MUST buffer it until
it has the entire handshake mes
On Mon, Nov 8, 2021 at 4:12 AM Salz, Rich wrote:
>
>- No. As I indicated in my earlier, email, while that scheme may
>technically work, it is potentially highly inefficient and I think we
>should discourage it.
>
>
>
> To be clear, not something we need to address here and now.
>
>
>
* No. As I indicated in my earlier, email, while that scheme may
technically work, it is potentially highly inefficient and I think we should
discourage it.
To be clear, not something we need to address here and now.
* Well, right now it's forbidden. I am saying we shouldn't relax that.
On Mon, Nov 08, 2021 at 04:08:51AM -0800, Eric Rescorla wrote:
> On Mon, Nov 8, 2021 at 3:58 AM Hanno Becker wrote:
>
> > > > 'Small tweak in wording': Can we say "Where possible, implementations
> > > > MAY process data immediately rather than buffering it"?
What I think about possibilities of
Hello Russ et al,
I hope this finds you well. Please find comments for
“draft-ietf-tls-external-psk-guidance-03”, below. The document is well written
and the latest revision has improved the clarity of presentation – no concerns
with publication, only minor editorial comments. Your feedba
> I have not looked at various
PQC key exchanges, but possibilities for partial processing are likely
limited if existent at all.
That's not the case - see the reference to SPHINCS and McEliece above.
> Any existing implementations will certainly
not support it.
An experimental branch of Mbed TL
Jonathan Hoyland writes:
> When someone tries to copy a message from a SCRAM handshake into some
> GSS-API run on a single TLS connection I want to be sure that it will be
> rejected, without having to understand exactly how every version of SCRAM
> and GSS-API ever (including ones that will be d
12 matches
Mail list logo
