On Tue, Oct 6, 2020, at 17:36, Hannes Tschofenig wrote:
> In the work on QUIC did you discuss the ability to make the encoding
> such that there are no ways to express a number in two different ways,
> as shown in your example with the single byte 25 decoding to 37 and the
> two byte sequence 40
Hi Ekr,
I had a chat with Richard about this and this change makes a lot of sense
(particularly since the current cTLS draft only defines the encoding of varints
up to 3 bytes).
In the work on QUIC did you discuss the ability to make the encoding such that
there are no ways to express a number
On Mon, Oct 5, 2020 at 9:59 PM Christian Huitema
wrote:
> 1994 called. It wanted to talk about distinguished encoding rules.
>
Could you expand on this idea?
I am not sure what you mean, because most things from circa 1994 are pretty
naive, to my eye.
thanks,
Rob
> On 10/5/2020 8:08 PM, Er
1994 called. It wanted to talk about distinguished encoding rules.
On 10/5/2020 8:08 PM, Eric Rescorla wrote:
> I don't have a strong opinion on whether to require a minimal
> encoding, but if we're not going to use QUIC's encoding as-is, then I
> would rather stick with the existing scheme, which
I don't have a strong opinion on whether to require a minimal encoding, but
if we're not going to use QUIC's encoding as-is, then I would rather stick
with the existing scheme, which has twice as large a range for the 1 byte
encoding and is thus more compact for a range of common cases.
-Ekr
On
In that case, why use QUIC's encoding at all? It would just put the burden
on the receiver to check that the minimal encoding was used.
Would it instead make more sense to modify QUIC's encoding, such that the
2-byte encoding doesn't encode the numbers from 0 to 16383, but the numbers
from 64 to (1
Can you just say “QUIC rules but use the minimum possible length”?
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
I agree that the HRR code path is hard to reason about, but I don't really
see an attack here. Is it your contention that the HRR code path leads to
an attack not accounted for by existing proofs?
I don't think this is likely. One way to think about this problem is as
follows [1]. Given an attacke
On Mon, Oct 5, 2020 at 6:38 PM Martin Thomson wrote:
> Oh, I consider that to be a feature. One that I exploit. It's sometimes
> awkward to build a structure then prepend a length that has a
> variable-length encoding. If you know the maximum length, the varint
> encoding allows you to avoid h
Yeah, I'm certainly sympathetic to this. TBH, from an aesthetic perspective
I prefer what's in cTLS now (though it had the same property) but I figured
that some consistency was nice.
-Ekr
On Mon, Oct 5, 2020 at 6:31 PM Marten Seemann
wrote:
> One thing that’s a bit annoying about QUIC’s vari
Oh, I consider that to be a feature. One that I exploit. It's sometimes
awkward to build a structure then prepend a length that has a variable-length
encoding. If you know the maximum length, the varint encoding allows you to
avoid having to move memory.
That said, cTLS won't authenticate bo
One thing that’s a bit annoying about QUIC’s variant format is that there
are multiple ways to encode a number. This has led to some complications in
the specification (e.g. QUIC requires you to use the minimal encoding for
frame types, but allows all encodings everywhere else).
It would be nice to
Hi folks,
cTLS uses a bespoke varint format. Now that QUIC is nearly done, I propose
adopting their varint format.
https://github.com/tlswg/draft-ietf-tls-ctls/pull/28
Any objections?
-Ekr
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Transport Layer Security WG of the IETF.
Title : The Transport Layer Security (TLS) Protocol Version
1.3
Author : Eric Rescorla
Filename
On 10/5/20 10:21, Christopher Patton wrote:
A couple pointers for getting started:
Thank you for providing these links! I'm going through
the first one now and will note that it does not even
mention the HelloRetryRequest message. So while I am
confident there has been quite a bit of study of
I have entered these as an issue in the repo:
https://github.com/tlswg/tls-exported-authenticator/issues/66
spt
> On Oct 2, 2020, at 12:50, Roman Danyliw wrote:
>
> Hi!
>
> I've assumed the role of responsible AD on this document. As such, I
> performed an AD review of draft-ietf-tls-exporte
I submitted these as an Issue in the repo:
https://github.com/tlswg/draft-ietf-tls-external-psk-importer/issues/37
spt
> On Oct 1, 2020, at 16:22, Roman Danyliw wrote:
>
> ** Section 1. Editorial. Expand acronym on first use:
> -- s/TLS 1.2 PRF/TLS 1.2 Pseudorandom Function (PRF)/
> -- s/KDF/
Roman,
Thanks for your review. Some comments inline.
spt
> On Oct 2, 2020, at 19:42, Roman Danyliw wrote:
>
> Hi!
>
> I've assumed the role of responsible AD on this document. As such, I
> performed an AD review of draft-ietf-tls-md5-sha1-deprecate-03.
>
> Thanks for writing this documen
A couple pointers for getting started:
1. Check out Dowling et al.'s recent analysis. Published a month or so
ago, it's the most recent proof of security of the full handshake (also
includes PSK modes): https://eprint.iacr.org/2020/1044
2. Check out Paterson and van der Merwe's survey
19 matches
Mail list logo
