The notes from the interim meeting mentions 'tls-unique' and points to
issue #228 on github. I want to get your attention on the draft below.
Doesn't it do what you are looking for? There is a little in the way of
a problem statement in the TLS interim meeting notes, so it is hard to
tell what th
On Thu, Oct 8, 2015 at 11:29 AM, Simon Josefsson
wrote:
> The notes from the interim meeting mentions 'tls-unique' and points to
> issue #228 on github. I want to get your attention on the draft below.
> Doesn't it do what you are looking for? There is a little in the way of
> a problem stateme
Eric Rescorla writes:
> On Thu, Oct 8, 2015 at 11:29 AM, Simon Josefsson
> wrote:
>
>> The notes from the interim meeting mentions 'tls-unique' and points to
>> issue #228 on github. I want to get your attention on the draft below.
>> Doesn't it do what you are looking for? There is a little i
On Thu, Oct 8, 2015 at 12:16 PM, Simon Josefsson
wrote:
> Eric Rescorla writes:
>
> > On Thu, Oct 8, 2015 at 11:29 AM, Simon Josefsson
> > wrote:
> >
> >> The notes from the interim meeting mentions 'tls-unique' and points to
> >> issue #228 on github. I want to get your attention on the draft
> > The introduction says:
> >
> >There exists a TLS extension [I-D.ietf-tls-session-hash] that
> > modify TLS so that the definition of 'tls-unique' [RFC5929] has the
> > intended properties. If widely implemented and deployed, the
> > channel binding type in this document would not offer any
On Thu, Oct 8, 2015 at 1:20 PM, Simon Josefsson wrote:
> > > The introduction says:
> > >
> > >There exists a TLS extension [I-D.ietf-tls-session-hash] that
> > > modify TLS so that the definition of 'tls-unique' [RFC5929] has the
> > > intended properties. If widely implemented and deployed
Eric Rescorla writes:
> On Thu, Oct 8, 2015 at 1:20 PM, Simon Josefsson wrote:
>
>> > > The introduction says:
>> > >
>> > >There exists a TLS extension [I-D.ietf-tls-session-hash] that
>> > > modify TLS so that the definition of 'tls-unique' [RFC5929] has the
>> > > intended properties. If
On Thu, Oct 08, 2015 at 12:04:51PM +0200, Eric Rescorla wrote:
>
> Well, TLS 1.3 doesn't have a PRF, but instead explicitly uses HKDF.
>
> With that said, I don't really understand the structure of your draft:
> Instead of referencing the PRF and session_hash directly, why not instead
> use RFC 5
Hiya,
First, thanks all for all your ongoing work on TLS1.3. I'm sure we're
all aware that this is important stuff that needs to be, and is being,
done carefully with due attention to security analysis.
Early in the process we had some brief discussion of pausing towards
the end of the work to g
Eric Rescorla wrote:
> Short, Todd wrote:
>>
>> However, for those ClientHello?s that support older versions, the
>> compression_method field may contain other values. This means that if a
>> TLSv1.3 client happened to support compression for TLSv1.2, it would be
>> unable to negotiate that via a
Eric specifically clarified it:
On Oct 7, 2015, at 5:15 PM, Eric Rescorla mailto:e...@rtfm.com>>
wrote:
Sorry, I spoke carelessly. It must contain solely the null method.
-Ekr
So the text needs to be corrected to reflect that. This will avoid the backward
compatibility issues.
IMHO, the text
On Thu, Oct 8, 2015 at 11:22 PM, Martin Rex wrote:
> Eric Rescorla wrote:
> > Short, Todd wrote:
> >>
> >> However, for those ClientHello?s that support older versions, the
> >> compression_method field may contain other values. This means that if a
> >> TLSv1.3 client happened to support compre
12 matches
Mail list logo
