On Thu, Oct 3, 2019 at 10:19 AM Christopher Wood
wrote:
> On Wed, Oct 2, 2019, at 8:08 PM, Rob Sayre wrote:
> > On Thu, Oct 3, 2019 at 3:54 AM Christopher Wood
> wrote:
> > >
> > > > I understand the meaning of count is the higher limit of ticket and
> the
> > > > server can provides any
> On Oct 2, 2019, at 11:20 PM, Christopher Wood wrote:
>
> Asking for one upon resumption seems reasonable to me. Thanks to you and
> Viktor for bringing up this case!
Thanks! Much appreciated.
My other point, which I probably obscured in too many words, is
that a client that prefers to
On Wed, Oct 2, 2019, at 4:04 PM, Nico Williams wrote:
> On Tue, Oct 01, 2019 at 10:56:00AM -0400, Viktor Dukhovni wrote:
> > I've read the draft, it looks quite useful and reasonable. It would
> > be good to see this published.
>
> +1
>
> > I have one idea (implemented in OpenSSL 1.1.1 on the
On Wed, Oct 2, 2019, at 8:08 PM, Rob Sayre wrote:
> On Thu, Oct 3, 2019 at 3:54 AM Christopher Wood wrote:
> >
> > > I understand the meaning of count is the higher limit of ticket and the
> > > server can provides any tickets between 0 and count. If that is
> > > correct, this could be
On Thu, Oct 3, 2019 at 3:54 AM Christopher Wood wrote:
>
> > I understand the meaning of count is the higher limit of ticket and the
> > server can provides any tickets between 0 and count. If that is
> > correct, this could be clearly stated and indication to chose an
> > appropriated value for
On Tue, Oct 01, 2019 at 10:56:00AM -0400, Viktor Dukhovni wrote:
> I've read the draft, it looks quite useful and reasonable. It would
> be good to see this published.
+1
> I have one idea (implemented in OpenSSL 1.1.1 on the server side)
> that may be worth mentioning in this context (and
Hi,
Please see my comments.
Yours,
Daniel
On Wed, Oct 2, 2019 at 4:55 PM Christopher Wood wrote:
> Hi Daniel,
>
> Please see inline below.
>
> On Wed, Oct 2, 2019, at 1:42 PM, Daniel Migault wrote:
> > Hi,
> >
> > Please find some comments on the draft.
> >
> > In the introduction, I believe
Hi folks,
draft-ietf-tls-exported-authenticator requires some IANA changes that were not
discussed during WGLC. The proposed changes are below. Please let the list know
by next week (10/9) if you object to them, and if so, please explain why.
> Value: EXPORTER-server authenticator handshake
Hi Daniel,
Please see inline below.
On Wed, Oct 2, 2019, at 1:42 PM, Daniel Migault wrote:
> Hi,
>
> Please find some comments on the draft.
>
> In the introduction, I believe both limitations may be merged into one
> limitation which is the number of ticket is a server only decision. The
I concur with Hubert, and think that DER in this context is perfectly OK.
On 10/2/19, 6:59 AM, "TLS on behalf of Hubert Kario" wrote:
On Wednesday, 2 October 2019 00:15:13 CEST Peter Gutmann wrote:
> Hubert Kario writes:
> >a lax DER parser sounds like an oxymoron to me... :)
Hi,
Sean Turner wrote:
> "You can change the text, but I do not believe it will change the
> implementations."
I would much rather have a future proof RFC that forbids negotiation of DTLS
1.0 with the knowledge that some implementations will temporary violate that,
than having an RFC that
Oops. Here are the referenced links:
[1] https://github.com/tlswg/draft-ietf-tls-external-psk-importer/pull/10
[2] https://github.com/tlswg/draft-ietf-tls-external-psk-importer/issues/20
On Wed, Oct 2, 2019, at 6:54 AM, Christopher Wood wrote:
> This update includes recent feedback received on
This update includes recent feedback received on the list and GitHub. There are
three major changes:
- Target KDFs instead of hash algorithms when importing external PSKs
- Add an opaque "context" slot to the ImportedIdentity struct and describe its
use for Selfie mitigations
- Remove backwards
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Transport Layer Security WG of the IETF.
Title : Importing External PSKs for TLS
Authors : David Benjamin
Christopher A.
Since this had support in the room, we would really like to get a sense if
there are any objections to this. Baring any negative comments, we’ll ask ekr
to merge this on 10/7.
spt
> On Oct 1, 2019, at 23:40, Eric Rescorla wrote:
>
> Hi folks,
>
> As discussed in Montreal, I've prepared a
Hiya,
On 02/10/2019 14:17, Sean Turner wrote:
> You can change the text, but I do not believe it will change the
> implementations. I would leave the text as is and NOT do an updates
> header.
WFM. I have executed that NOOP:-)
S.
0x5AB2FAF17B172BEA.asc
Description: application/pgp-keys
> On Oct 1, 2019, at 21:14, Eric Rescorla wrote:
>
>
>
> On Tue, Oct 1, 2019 at 1:04 AM John Mattsson
> wrote:
> Hi,
>
> I think draft-ietf-tls-oldversions-deprecate needs to update
> draft-ietf-rtcweb-security-arch as well.
>
> draft-ietf-rtcweb-security-arch-20 uses DTLS and even
> On Oct 2, 2019, at 12:23, Hubert Kario wrote:
>
> Signed PGP part
> On Wednesday, 2 October 2019 13:18:07 CEST Hubert Kario wrote:
>> On Tuesday, 1 October 2019 17:01:54 CEST Eric Rescorla wrote:
>>> On Tue, Oct 1, 2019 at 5:27 AM John Mattsson >>
>>> 40ericsson@dmarc.ietf.org> wrote:
On Wednesday, 2 October 2019 13:18:07 CEST Hubert Kario wrote:
> On Tuesday, 1 October 2019 17:01:54 CEST Eric Rescorla wrote:
> > On Tue, Oct 1, 2019 at 5:27 AM John Mattsson >
> > 40ericsson@dmarc.ietf.org> wrote:
> > > Dan Brown wrote:
> > > > ANSI X9.62-2005 was withdrawn in 2015
> > >
On Tuesday, 1 October 2019 17:01:54 CEST Eric Rescorla wrote:
> On Tue, Oct 1, 2019 at 5:27 AM John Mattsson
> 40ericsson@dmarc.ietf.org> wrote:
> > Dan Brown wrote:
> > > ANSI X9.62-2005 was withdrawn in 2015
> >
> > Ok, that TLS 1.3 is relying on a withdrawn publication that used to be
>
The following errata report has been submitted for RFC8446,
"The Transport Layer Security (TLS) Protocol Version 1.3".
--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid5868
--
Type: Technical
On Wednesday, 2 October 2019 00:15:13 CEST Peter Gutmann wrote:
> Hubert Kario writes:
> >a lax DER parser sounds like an oxymoron to me... :)
>
> That's why I assumed it was an accident/error. Writing a spec that relies
> on buggy parser implementations in order to work is asking for trouble.
22 matches
Mail list logo