Hi,
Per the latest draft of TLS 1.3, both "supported_groups" and "key_share"
extensions are REQUIRED for DHE or ECDHE cipher suites (Section 8.2). Both
extension need to provide the supported named groups in preference order.
Looks like the functions are overlapped. I was wondering, it may be ni
On Thu, Nov 26, 2015 at 09:52:37PM +0800, Xuelei Fan wrote:
> Hi,
>
> Per the latest draft of TLS 1.3, both "supported_groups" and "key_share"
> extensions are REQUIRED for DHE or ECDHE cipher suites (Section 8.2). Both
> extension need to provide the supported named groups in preference order.
>
Thanks for the quick feedback. You answered some questions puzzled me for
a while.
On Thu, Nov 26, 2015 at 10:26 PM, Ilari Liusvaara
wrote:
> On Thu, Nov 26, 2015 at 09:52:37PM +0800, Xuelei Fan wrote:
> > Hi,
> >
> > Per the latest draft of TLS 1.3, both "supported_groups" and "key_share"
> >
On Thu, Nov 26, 2015 at 11:37:12PM +0800, Xuelei Fan wrote:
> > This wouldn't work if one had to downnegotiate TLS 1.2. That is going to
> > happen A LOT.
> >
> > I think, "supported_groups" extension still can be sent for TLS 1.2, but
> can be ignored for TLS 1.3. And "key_share" extension can be
On Thursday, November 26, 2015 02:15:25 pm Ilari Liusvaara wrote:
> I actually looked at the Editors's Copy. The description is a mess: It
> seemingly first requires key_share extension, even for the first
> ClientHello... Now, that extension can't be empty... And then proceeds
> to say to omit it
On Thu, Nov 26, 2015 at 2:50 PM, Dave Garrett
wrote:
> On Thursday, November 26, 2015 02:15:25 pm Ilari Liusvaara wrote:
> > I actually looked at the Editors's Copy. The description is a mess: It
> > seemingly first requires key_share extension, even for the first
> > ClientHello... Now, that ext
HelloRetryRequest is annoying. Is there any way we can replace it with
something? I know our options are limited, here. We can't mandate offers for
everything, not just due to constrained environments, but also because
post-quantum keys could get too big.
The main thing that comes to mind would
On Thu, Nov 26, 2015 at 3:03 PM, Dave Garrett
wrote:
> HelloRetryRequest is annoying
I guess this is a matter of opinion.
The main thing that comes to mind would be to provide a way for a server to
> respond to a client with a ServerConfiguration, but not a hello, and put
> group support in t
Joe,
Can you clarify whether you believe consensus is to make the "Recommended"
list the list in the current PR or the MTI list. I can edit the document
either
way.
-Ekr
On Wed, Nov 25, 2015 at 11:05 AM, Joseph Salowey wrote:
> It looks like we have rough consensus to accept this PR. We can s
On Thursday, November 26, 2015 06:02:09 pm Eric Rescorla wrote:
> On Thu, Nov 26, 2015 at 2:50 PM, Dave Garrett
> wrote:
> > On Thursday, November 26, 2015 02:15:25 pm Ilari Liusvaara wrote:
> > > I actually looked at the Editors's Copy. The description is a mess: It
> > > seemingly first requires
On Thu, Nov 26, 2015 at 3:36 PM, Dave Garrett
wrote:
> On Thursday, November 26, 2015 06:02:09 pm Eric Rescorla wrote:
> > On Thu, Nov 26, 2015 at 2:50 PM, Dave Garrett
> > wrote:
> > > On Thursday, November 26, 2015 02:15:25 pm Ilari Liusvaara wrote:
> > > > I actually looked at the Editors's C
If empty key_share vector is used to indicate to request a server choice, I
think it is not necessary to have "supported_groups" extension as
mandatory any more. key_share extension can be used for the supported
named groups. "supported_groups" extension can be used for backward
compatibility (
On Thu, Nov 26, 2015 at 4:59 PM, Xuelei Fan wrote:
> If empty key_share vector is used to indicate to request a server choice,
>
That's not what it means. It means "I have no idea what your preferences
are, so tell
me which of the groups I support you prefer". Thus, you still need
supported_grou
On Fri, Nov 27, 2015 at 3:15 AM, Ilari Liusvaara
wrote:
> On Thu, Nov 26, 2015 at 11:37:12PM +0800, Xuelei Fan wrote:
> > > This wouldn't work if one had to downnegotiate TLS 1.2. That is going
> to
> > > happen A LOT.
> > >
> > > I think, "supported_groups" extension still can be sent for TLS 1.
On Fri, Nov 27, 2015 at 9:12 AM, Eric Rescorla wrote:
>
>
> On Thu, Nov 26, 2015 at 4:59 PM, Xuelei Fan wrote:
>
>> If empty key_share vector is used to indicate to request a server choice,
>>
>
> That's not what it means. It means "I have no idea what your preferences
> are, so tell
> me which
>
> > > > The "supported_groups" extension defines the groups, while the
>> > > "key_share"
>> > > > extension defines both the groups and the key exchange
>> information. Both
>> > > > extension has its own preferences for the supported named groups.
>> It's
>> > > > easy to get conflicted if the
On Thursday, November 26, 2015 08:28:35 pm Xuelei Fan wrote:
> If "supported_groups" extension is only for compatibility, it can be
> not-mandatory. However, if it is defined to define the supported groups
> and preferences (see bellow), it can be mandatory.
If it weren't for the fact that we're
> I think, key_share is ordered too. If considering both key_share and
> > supported_groups together, looks like there are two options
> [...]
>
> Yes, I addressed the conflict of priorities in one of my PRs, but it's on
> my todo list to rewrite it as ekr noted a few parts that needed changing.
>
On Fri, Nov 27, 2015 at 9:48 AM, Xuelei Fan wrote:
>
>
> > I think, key_share is ordered too. If considering both key_share and
>> > supported_groups together, looks like there are two options
>> [...]
>>
>> Yes, I addressed the conflict of priorities in one of my PRs, but it's on
>> my todo lis
Hi,
What's the consideration to place selected_group out of the extensions
filed in HelloRetryRequest?
struct {
ProtocolVersion server_version;
CipherSuite cipher_suite;
NamedGroup selected_group;
Extension extensions<0..2^16-1>;
} HelloRetryReq
On Thursday, November 26, 2015 09:12:14 pm Xuelei Fan wrote:
> Can key_share offers two shares for the same group?
It's currently worded "Clients MUST NOT offer multiple KeyShareEntry values for
the same parameters", which is a little ambiguous, but I interpret this as one
share per group. I don
> On Thursday, November 26, 2015 09:12:14 pm Xuelei Fan wrote:
> > Can key_share offers two shares for the same group?
>
> It's currently worded "Clients MUST NOT offer multiple KeyShareEntry
> values for the same parameters", which is a little ambiguous, but I
> interpret this as one share per gro
22 matches
Mail list logo
