rather because of chacha?
-JimC
--
James Cloos OpenPGP: 0x997A9F17ED7DAEA6
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
limit (2^40 bits;
only twice aesgcm's limit).
So key updates or re-keying will be more universally required.
(Are there any aeads currently spec'ed with both large enough blocks and
large enough nonces safely to avoid key updates?)
-JimC
--
James Cloos OpenPGP: 0x9
bit counter to 96 bit nonce + 32 bit
counter means a max of 2**32 * 256 bits before a key update is needed, yes?
-JimC
--
James Cloos OpenPGP: 0x997A9F17ED7DAEA6
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
ords can't be
ER> more than 16KB long anyway, this isn't the critical limitation.
That does change things. I do not recall any posts noting that after I
posted an objection to the change, but I mostly missed everything from
May thru July or so because of the stroke...
Thanks fo
[I only have part of the thread available, and so am replying to the
last message I see.]
I agree that the draft MUST explicitly support chains corresponding to
a NXDOMAIN or NODATA responses to have sufficient value.
-JimC
--
James Cloos OpenPGP: 0x997A9F17ED7DAEA6
>>>>> "RB" == Richard Barnes writes:
RB> It seems noteworthy, however, that nobody is chiming in on the list who was
RB> not also part of the discussion in the room.
Not true.
-JimC
--
James Cloos OpenPGP: 0x997A9F17ED7DAEA6
s a technical objection.
And I've seen no useful or reasonable objections to Viktor's suggestion.
The sixteen bit field harms no one, and when defined and used provides
significant benefit to many.
-JimC
--
James Cloos OpenPGP: 0x997A9F17ED7DAEA6
