On Monday, 31 October 2016 20:19:15 CET Dave Garrett wrote:
> On Monday, October 31, 2016 08:05:59 pm Matt Caswell wrote:
> > On 31/10/16 23:53, Dave Garrett wrote:
> > >> I came up with some alternative wording that I think captures the
> > >> discussion:
> > >>
> > >>
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
On Monday, October 31, 2016 08:05:59 pm Matt Caswell wrote:
> On 31/10/16 23:53, Dave Garrett wrote:
> >> I came up with some alternative wording that I think captures the
> >> discussion:
> >>
> >> https://github.com/tlswg/tls13-spec/pull/748
> >
> > I see no reason to require servers to
On 31/10/16 23:53, Dave Garrett wrote:
>> I came up with some alternative wording that I think captures the discussion:
>>
>> https://github.com/tlswg/tls13-spec/pull/748
>
> I see no reason to require servers to validate the legacy version value.
> That's just excess complexity. If the extension
On Monday, October 31, 2016 07:26:30 pm Matt Caswell wrote:
> On 31 October 2016 at 23:13, David Benjamin wrote:
> > On Mon, Oct 31, 2016 at 6:34 PM Kurt Roeckx wrote:
> >>
> >> On Mon, Oct 31, 2016 at 07:11:10PM +, David Benjamin wrote:
> >> > On Mon,
On 31 October 2016 at 23:35, Eric Rescorla wrote:
> Our current implementation also processes the extension unconditionally.
>
> I'm not convinced that this represents an improvement, both for the reason
> that Kurt
> indicates and just in terms of simplicity of story. The current
Our current implementation also processes the extension unconditionally.
I'm not convinced that this represents an improvement, both for the reason
that Kurt
indicates and just in terms of simplicity of story. The current design is
simply
"if supported_versions is present, then use it", whereas
On Mon, Oct 31, 2016 at 6:34 PM Kurt Roeckx wrote:
On Mon, Oct 31, 2016 at 07:11:10PM +, David Benjamin wrote:
> On Mon, Oct 31, 2016 at 2:57 PM Ilari Liusvaara
> wrote:
>
> > On Mon, Oct 31, 2016 at 06:43:52PM +, Matt Caswell wrote:
> > > A few
On Mon, Oct 31, 2016 at 07:11:10PM +, David Benjamin wrote:
> On Mon, Oct 31, 2016 at 2:57 PM Ilari Liusvaara
> wrote:
>
> > On Mon, Oct 31, 2016 at 06:43:52PM +, Matt Caswell wrote:
> > > A few supported_versions questions:
> > >
> > > 1) What should a server
David Benjamin wrote:
> Ilari Liusvaara wrote:
>
>> The case where legacy_version < TLS1.2 IIRC isn't specified, but
>> ignoring legacy_version is reasonable in this case too.
>>
>
I imagine that there will be three common implementations for the
,
Xiaoyin
From: Matt Caswell<mailto:fr...@baggins.org>
Sent: Monday, October 31, 2016 2:44 PM
To: tls@ietf.org<mailto:tls@ietf.org>
Subject: [TLS] supported_versions question
A few supported_versions questions:
1) What should a server do if supported_versions
On Mon, Oct 31, 2016 at 07:11:10PM +, David Benjamin wrote:
>
> We could say the versions extension only applies to 1.2 and up. I.e. don't
> bother advertising 1.1 and 1.0 as a client and servers ignore 1.1 and 1.0
> when they see them in the version list. That keeps the protocol deployable
>
On Mon, Oct 31, 2016 at 06:43:52PM +, Matt Caswell wrote:
> A few supported_versions questions:
>
> 1) What should a server do if supported_versions is received but
> ClientHello.legacy_version != TLS1.2? Fail the handshake, or just
> ignore legacy_version?
If legacy_version > TLS1.2, the
A few supported_versions questions:
1) What should a server do if supported_versions is received but
ClientHello.legacy_version != TLS1.2? Fail the handshake, or just
ignore legacy_version?
2) What should a server do if supported_versions is received,
ClientHello.legacy_version == TLS1.2, but
14 matches
Mail list logo