Hi,
In the draft spec of TLS 1.3, ServerKeyExchange and ClientKeyExchange get
removed, and key_share extension applies to non-PSK cipher suites only. As
RFC 4279 need ServerKeyExchange and ClientKeyExchange messages, I think TLS
1.3 updates or obsoletes RFC 4279.
Per the draft spec of TLS 1.3, if
On Friday 27 November 2015 10:50:40 Xuelei Fan wrote:
> > 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 i
On Fri, Nov 27, 2015 at 8:12 PM, Hubert Kario wrote:
> On Friday 27 November 2015 10:50:40 Xuelei Fan wrote:
> > > 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 mul
On Friday 27 November 2015 20:33:46 Xuelei Fan wrote:
> On Fri, Nov 27, 2015 at 8:12 PM, Hubert Kario
wrote:
> > On Friday 27 November 2015 10:50:40 Xuelei Fan wrote:
> > > > On Thursday, November 26, 2015 09:12:14 pm Xuelei Fan wrote:
> > > > > Can key_share offers two shares for the same group?
>
> > > I think that specifying *both* in preference order, and recommending
> > > the servers to first inspect key shares and then supported_groups
> > > (if no intersect between what server supports and what key shares
> > > client provided) would end up with more predictable behaviour and
> > >
On Friday 27 November 2015 21:20:24 Xuelei Fan wrote:
> > > > I think that specifying *both* in preference order, and
> > > > recommending
> > > > the servers to first inspect key shares and then
> > > > supported_groups
> > > > (if no intersect between what server supports and what key
> > > > sha
On Fri, Nov 27, 2015 at 9:28 PM, Hubert Kario wrote:
> On Friday 27 November 2015 21:20:24 Xuelei Fan wrote:
> > > > > I think that specifying *both* in preference order, and
> > > > > recommending
> > > > > the servers to first inspect key shares and then
> > > > > supported_groups
> > > > > (if
Hi Xuelei,
As per RFC 4279 also, both the client and server are supposed to have a set of
“Identity – key” pair on either sides. The
“ServerKeyExchange.psk_identity_hint” only helps the client in choosing an
“identity-key” pair from a list of several “identity-key pairs” the client may
have.
The idea of encrypting TLS record headers has come up before, the most
important purpose being to hide record lengths and boundaries and make
fingerprinting and traffic analysis harder. I had convinced myself that
goal this would be "too hard" to accomplish in TLS 1.3, but after
further thought I'
It is a great idea to use PSK for session resumption. However, as the
ServerKeyExchange.psk_identity_hint disappears in TLS 1.3, I was wondering,
it may be not easy to make an upgrade for those PSK implementation that
relies on ServerKeyExchange.psk_identity_hint.
Considering the following initi
On 2015-11-27 15:35, Bryan A Ford wrote:
The idea of encrypting TLS record headers has come up before, the most
important purpose being to hide record lengths and boundaries and make
fingerprinting and traffic analysis harder.
How, exactly, would this be significantly harder? The adversary will
On 26 November 2015 at 18:38, Xuelei Fan wrote:
> What's the consideration to place selected_group out of the extensions filed
> in HelloRetryRequest?
An extension would work, except that I believe that extensions in
HelloRetryRequest are going to carry somewhat different semantics to
those in ot
It makes sense to me.
It's OK if TLS 1.3 only supports (EC)DHE cipher suites. If it is extended
to support other cipher suites, for example PSK or KRB5 cipher suites
(which do not require named groups), the HelloRetryRequest.selected_group
may be redundant if this extra RTT is required. As the
S
13 matches
Mail list logo
