First, I don't think that the argument that the current version scheme doesn't
lend itself to future-proofing is correct. Just as with GREASE, browsers can
send much higher version than they really support if they do that on a time
limited basis.
Second, while the "joint" which handles new exte
Martin Rex writes:
>The actual problem is the design flaw in TLS that availability of null
>compression is not implied, but rather given a seperate codepoint, and the
>server choosing null compression and continuing even when it is not
>explicitly asserted by the client, is a server silently maki
Hi,
>>> Hubert Kario 09/12/16 6:56 PM >>>
> are you aware of the tlsfuzzer framework?
> https://github.com/tomato42/tlsfuzzer
@Hubert Kario: Thanks for pointing me to tlsfuzzer. I had a look at the
repository before and I skimmed through the code. However, I didn't run the
code and I don't kno
On Wednesday, 14 September 2016 15:35:16 CEST Andreas Walz wrote:
> Hi,
>
> >>> Hubert Kario 09/12/16 6:56 PM >>>
> >
> > are you aware of the tlsfuzzer framework?
> > https://github.com/tomato42/tlsfuzzer
>
> @Hubert Kario: Thanks for pointing me to tlsfuzzer. I had a look at the
> repository
On 09/14/2016 04:56 AM, Hubert Kario wrote:
> First, I don't think that the argument that the current version scheme
> doesn't
> lend itself to future-proofing is correct. Just as with GREASE, browsers can
> send much higher version than they really support if they do that on a time
> limited b
On Wed, Sep 14, 2016 at 11:46 AM Benjamin Kaduk wrote:
> On 09/14/2016 04:56 AM, Hubert Kario wrote:
>
> First, I don't think that the argument that the current version scheme doesn't
> lend itself to future-proofing is correct. Just as with GREASE, browsers can
> send much higher version than th
On Wednesday, 14 September 2016 16:17:50 CEST David Benjamin wrote:
> Yes, we find list intolerance too---servers which only look at the second
> byte in a cipher suite, servers which forgot a default in their NamedGroup
> switch-case, servers which get confused on unknown HashAlgorithms, servers
>
Do you mean a TLS extension code point per TLS version?
One argument against this was that this makes it difficult to express the
client's prioritization of TLS versions, but IMHO arguably the server should
not care.
Cheers,
Andrei
-Original Message-
From: TLS [mailto:tls-boun...@ietf.
On Wednesday, 14 September 2016 17:39:59 CEST Andrei Popov wrote:
> Do you mean a TLS extension code point per TLS version?
yes, e.g. if extension 0x00a0 is present assume TLSv1.3 support, 0x0121,
TLSv1.4; same way EMS and MtE works
> One argument against this was that this makes it difficult to
Basically, I don't feel strongly about the switch to the proposed version
negotiation mechanism. But if we are going to make this change based on the
theory of having only one extension point and actively defending it, then we
should probably follow the theory and send a separate TLS extension p
Are there national TLS standards, or just national crypto-suites?
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
Both exist. E.g. China has at least one national TLS version (and cipher
suites), and Russia has cipher suites.
The line is blurred anyway, because a cipher suite (or extension) can introduce
new protocol message formats, state machine changes, authentication schemes, ...
-Original Message-
12 matches
Mail list logo
