Kurt Roeckx wrote:
> So I guess you're also saying that a server that implements TLS
> 1.1 to TLS 1.3, but disables TLS 1.2 and TLS 1.3 support should
> ignore the supported_versions even when it knows about it?
>
> I guess I have same questions but with only TLS 1.3 disabled, to
> be sure when w
(was Re: [TLS] PR#625: Change alert requirements)
Digging up an old sub-thread...
On 09/20/2016 08:03 AM, Eric Rescorla wrote:
>
> in Record Layer there's the following text:
>
> legacy_record_version : This value MUST be set to { 3, 1 } for all
> records. This field is deprec
On Mon, Nov 7, 2016 at 6:50 PM Benjamin Kaduk wrote:
(was Re: [TLS] PR#625: Change alert requirements)
Digging up an old sub-thread...
On 09/20/2016 08:03 AM, Eric Rescorla wrote:
in Record Layer there's the following text:
legacy_record_version : This value MUST be set to { 3, 1 } for al
On Mon, Nov 7, 2016 at 4:04 PM, David Benjamin
wrote:
> On Mon, Nov 7, 2016 at 6:50 PM Benjamin Kaduk wrote:
>
> (was Re: [TLS] PR#625: Change alert requirements)
>
> Digging up an old sub-thread...
>
> On 09/20/2016 08:03 AM, Eric Rescorla wrote:
>
> in Record Layer there's the following text:
David Benjamin wrote:
> Once you've gotten as far as to switch to TLSCiphertext, I don't see a
> reason not to enforce. Keying on versions is problematic (which is why we
> avoided a transition to enforcement), but keying on whether the record is
> encrypted seems fine. I think it just didn't occ
Hi,
Please find the text I propose. Let me know if you have any comment
regarding the proposed text. Unless I receive comment on it, the text will
be publish as soon as draft submission is possible.
Yours,
Daniel
The cipher suites defined in this document are based on the AES-GCM
and AES-C
Hi,
The current draft is only considering TLS1.2. TLS1.3 is only mentioned for
advocating AEAD.
Do you think we should add text that details how to proceed with TLS1.3 ?
If so what do you think of the following text ?
Comments are welcome!
Yours,
Daniel
The assigned code points are only ex
I don't understand this. I have no problems with a recommendation
(i.e., SHOULD), but you will find that many implementations will not
comply with these requirements when pushed.
On 8 November 2016 at 14:09, Daniel Migault wrote:
>The cipher suites defined in this document are based on the A
On 8 November 2016 at 14:01, Brian Smith wrote:
> Since this field isn't included in the additional_data of the AEAD in TLS
> 1.3 any more, it isn't authenticated. That means an active MitM can use this
> to transport up to 2 bytes of information hop-to-hop if the receiver doesn't
> check it. That
On Mon, Nov 07, 2016 at 10:16:13PM -0500, Daniel Migault wrote:
> Hi,
>
> The current draft is only considering TLS1.2. TLS1.3 is only mentioned for
> advocating AEAD.
>
> Do you think we should add text that details how to proceed with TLS1.3 ?
> If so what do you think of the following text ?
10 matches
Mail list logo
