Issues
--
* tlswg/tls-flags (+0/-0/💬3)
1 issues received 3 new comments:
- #13 Usage also for (D)TLS 1.2 (3 by chris-wood, thomas-fossati, yoavnir)
https://github.com/tlswg/tls-flags/issues/13
* tlswg/external-psk-design-team (+3/-0/💬0)
3 issues created:
- John's review (by chris-
> Without thinking it through completely, I think it would probably be safe to
> add something about gradual processing, but your text seems to allow throwing
> it away, which seems undesirable.
Hm yes. On the other hand, some implementations might deliberately discard some
fragments
to keep th
On Sun, Nov 7, 2021 at 12:10 PM Hanno Becker wrote:
> > Without thinking it through completely, I think it would probably be
> safe to add something about gradual processing, but your text seems to
> allow throwing it away, which seems undesirable.
>
> Hm yes. On the other hand, some implementati
> I actually do not believe that this will work correctly in all cases.
> Consider the case where we have a 2K message where
the peer sends:
> - 1000, 1000
> ... som retransmits
>
> - 700, 700, 600
I shouldn't have said "aligned" but "overlap": Fragments would be considered
precisely if they ha
On Sun, Nov 7, 2021 at 1:32 PM Hanno Becker wrote:
> > I actually do not believe that this will work correctly in all cases.
> Consider the case where we have a 2K message where
> the peer sends:
> > - 1000, 1000
> > ... som retransmits
> >
> > - 700, 700, 600
>
> I shouldn't have said "aligned"
> Re (2), I think we could just add a sentence saying that it was legal to
> process any in-order data immediately.
I wouldn't want to restrict that to in-order data, but keep the door open for
e.g. crypto implementations
which can even process data out of order. E.g. process the beginning of a
I'd like to preface my comments by observing that we are in AUTH48 for
DTLS, and it's only being held up on resolving #254
(and maybe #247 which I just saw). So absent serious flaws, I think we
should make as few changes as possible, especially
because if what you propose turns out to be fine we ca
> 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 you to buffer, ...
That existing text does not allow the mentioned
