In London, I was on the agenda to talk about certificate-based authentication
with external pre-shared key (PSK). We ran out of time, and I did not get to
make the presentation. The slides are in the proceedings; see
https://datatracker.ietf.org/meeting/101/materials/slides-101-tls-sessa-certi
We've had a lot of discussion on this thread that has pointed out that
there are enough issues with the current document that we should recommend
that the AD pull it back from the RFC editor.
Concerns have been raised about the trade-offs associated with pinning and
I do not think we currently hav
On Wed, Apr 18, 2018 at 2:22 PM, Joseph Salowey wrote:
> We've had a lot of discussion on this thread that has pointed out that
> there are enough issues with the current document that we should recommend
> that the AD pull it back from the RFC editor.
>
> Concerns have been raised about the trad
On 4/18/18 10:22 AM, Joseph Salowey wrote:
> Concerns have been raised about the trade-offs associated with pinning
> and I do not think we currently have consensus to add pinning. While I
> think it may be possible to come to consensus on pinning I think it may
> take some time. I believe we can
On Wed, 18 Apr 2018, Joseph Salowey wrote:
This is a combined response of Viktor, Nico and Paul.
Concerns have been raised about the trade-offs associated with pinning and I
do not think we currently have consensus to add
pinning. While I think it may be possible to come to consensus on pin
On Wed, Apr 18, 2018 at 4:42 PM, Paul Wouters wrote:
> On Wed, 18 Apr 2018, Joseph Salowey wrote:
>
> This is a combined response of Viktor, Nico and Paul.
>
> Concerns have been raised about the trade-offs associated with pinning
>> and I
>> do not think we currently have consensus to add
>>
> On Apr 18, 2018, at 4:47 PM, Richard Barnes wrote:
>
> I do not support adding a field to the protocol with semantics to be defined
> later. Especially a 16-byte field, which is a fair bit of cruft to carry
> around.
The 16-byte is a typo. It was supposed to be 16-bit. My fault. Sorry.
On Wed, Apr 18, 2018 at 4:48 PM, Viktor Dukhovni
wrote:
>
>
> > On Apr 18, 2018, at 4:47 PM, Richard Barnes wrote:
> >
> > I do not support adding a field to the protocol with semantics to be
> defined later. Especially a 16-byte field, which is a fair bit of cruft to
> carry around.
>
> The 16
> On Apr 18, 2018, at 4:47 PM, Richard Barnes wrote:
>
> I do not support adding a field to the protocol with semantics to be defined
> later.
And the semantics are defined. The server must send zero, and the client must
read it as zero. The propose semantics PROHIBIT pinning, which is wh
> On Apr 18, 2018, at 4:52 PM, Richard Barnes wrote:
>
> Secondary point. Still don't think we should deliberately include undefined
> fields, e.g., because part of the discussion is whether 16 bits is the right
> size.
16 bits is clearly enough. If the units are hours that gets you ~7.5 y
On Wed, Apr 18, 2018 at 04:52:14PM -0400, Richard Barnes wrote:
> On Wed, Apr 18, 2018 at 4:48 PM, Viktor Dukhovni
> wrote:
>
> >
> >
> > > On Apr 18, 2018, at 4:47 PM, Richard Barnes wrote:
> > >
> > > I do not support adding a field to the protocol with semantics to be
> > defined later. Espe
On Wed, Apr 18, 2018 at 4:56 PM, Viktor Dukhovni
wrote:
>
>
> > On Apr 18, 2018, at 4:52 PM, Richard Barnes wrote:
> >
> > Secondary point. Still don't think we should deliberately include
> undefined fields, e.g., because part of the discussion is whether 16 bits
> is the right size.
>
> 16 bi
On Wed, Apr 18, 2018 at 4:56 PM, Nico Williams
wrote:
> On Wed, Apr 18, 2018 at 04:52:14PM -0400, Richard Barnes wrote:
> > On Wed, Apr 18, 2018 at 4:48 PM, Viktor Dukhovni >
> > wrote:
> >
> > >
> > >
> > > > On Apr 18, 2018, at 4:47 PM, Richard Barnes wrote:
> > > >
> > > > I do not support a
On Wed, Apr 18, 2018 at 05:01:54PM -0400, Richard Barnes wrote:
> On Wed, Apr 18, 2018 at 4:56 PM, Viktor Dukhovni
> wrote:
> > > On Apr 18, 2018, at 4:52 PM, Richard Barnes wrote:
> > >
> > > Secondary point. Still don't think we should deliberately include
> > undefined fields, e.g., because p
> On Apr 18, 2018, at 5:03 PM, Richard Barnes wrote:
>
> The only "reserved" in RFC 5246 is a few code points that are reserved for
> private use. No reserved fields.
The field is NOT reserved, it carries an "extension support lifetime" of
16-bits whose zero value means "DO NOT PIN". Other
On Wed, Apr 18, 2018 at 4:42 PM, Paul Wouters wrote:
>
> 2. Explicitly allow (but do not require) DoE be included
>>
>
> The document does not currently allow the extension to be empty. So if
> there is no TLSA record and the extension would be present, it therefore
> can only contain a DoE chai
Nico Williams writes:
>That's just silly. Really, 7.5 years (relative, not absolute) measured in
>hours is plenty good enough, and more than outlives current device
>obsolescence. This isn't subject to Moore's law or anything like it.
I don't know what devices you work with, but for the ones w
> On Apr 18, 2018, at 11:25 PM, Peter Gutmann wrote:
>
>> That's just silly. Really, 7.5 years (relative, not absolute) measured in
>> hours is plenty good enough, and more than outlives current device
>> obsolescence. This isn't subject to Moore's law or anything like it.
>
> I don't know w
On Wed, Apr 18, 2018 at 11:34:14PM -0400, Viktor Dukhovni wrote:
> > On Apr 18, 2018, at 11:25 PM, Peter Gutmann
> > wrote:
> >> That's just silly. Really, 7.5 years (relative, not absolute) measured in
> >> hours is plenty good enough, and more than outlives current device
> >> obsolescence. T
19 matches
Mail list logo
