Re: [TLS] extending the un-authenticated DTLS header

Ø I'd be interested in an analysis of the potential privacy impacts of this. Isn't this more or less the same as doing SPUD-for-DTLS? (If not, sorry for dragging in controversy:-) I don’t know SPUD but I see this work providing the same functionality as the Security Parameter Index (SPI) in the

[TLS] Resolving the Ed448 context issue in RFC4492bis

Hi, all As mentioned in Tuesday's session, Ed448 and Ed25519ctx add a new parameter to the signature function: a context string. Setting this string to a different value for each application (where application could be "PKIX", "TLS", "IKE") leads to different results and thus a signature made

Re: [TLS] housekeeping: uplift RFC 5289 to Proposed Standard

Note that Russ pointed out during the meeting that even though we can use this process a new RFC # will be minted at the end of the process. spt > On Nov 14, 2016, at 10:36, Sean Turner wrote: > > This email addresses the "Uplifting” bullet on slide 6 of the chair slides >

Re: [TLS] Point validation in 1.3

On Tue, Nov 15, 2016 at 05:02:24PM +0900, Yoav Nir wrote: > I think the performance enhancement (in terms of handshakes per second) > that you get by reusing ephemeral keys is so great, that we have to > assume people will do it. You don’t have to keep the keys indefinitely. > It’s fine to

Re: [TLS] supported_versions question

On Monday, 31 October 2016 20:19:15 CET Dave Garrett wrote: > On Monday, October 31, 2016 08:05:59 pm Matt Caswell wrote: > > On 31/10/16 23:53, Dave Garrett wrote: > > >> I came up with some alternative wording that I think captures the > > >> discussion: > > >> > > >>

Re: [TLS] extending the un-authenticated DTLS header

Sort of. Client uses one HOTP value from the sequence at a time, until it sees fit — for example, until it's on the same network attachment. When attachment changes (and its transport identifiers with it), before sending a new packet, it picks the next HOTP and sticks it in the record. When

Re: [TLS] [ALU] Re: extending the un-authenticated DTLS header

Okay, so you are saying that every packet has the same number? On 15 Nov 2016 6:30 PM, "Fossati, Thomas (Nokia - GB)" < thomas.foss...@nokia.com> wrote: > On 15/11/2016 09:20, "TLS on behalf of Martin Thomson" > wrote: > >This means

Re: [TLS] [ALU] Re: extending the un-authenticated DTLS header

On 15/11/2016 09:20, "TLS on behalf of Martin Thomson" wrote: >This means that you can guarantee privacy, but it forces >the server to do an exhaustive search of all of its active connections >(that is, O(N)) when it gets a 5-tuple

Re: [TLS] extending the un-authenticated DTLS header

On 15 November 2016 at 18:11, Nikos Mavrogiannopoulos wrote: >> I'm not seeing quite enough information here to implement this. How >> does a server know which of the many HOTP keys it has are in use? >> Surely you can't use the same HOTP key with every client. > > Not sure I

Re: [TLS] extending the un-authenticated DTLS header

On Tue, 2016-11-15 at 18:10 +0900, Martin Thomson wrote: > On 15 November 2016 at 17:34, Fossati, Thomas (Nokia - GB) > wrote: > > > > The draft proposes two ways to allocate the identifier (see 3rd > > para of > >

Re: [TLS] extending the un-authenticated DTLS header

On 15 November 2016 at 17:34, Fossati, Thomas (Nokia - GB) wrote: > The draft proposes two ways to allocate the identifier (see 3rd para of > https://thomas-fossati.github.io/draft-tls-cid/#rfc.section.1): > 1. Server decides unilaterally a value that is fixed for the

Re: [TLS] extending the un-authenticated DTLS header

On 15/11/2016 07:36, "TLS on behalf of Martin Thomson" wrote: >On 15 November 2016 at 16:12, Nikos Mavrogiannopoulos >wrote: >> TLDR; the privacy offered by this extension is the same as the privacy >> of DTLS over UDP.

Re: [TLS] Point validation in 1.3

I think the performance enhancement (in terms of handshakes per second) that you get by reusing ephemeral keys is so great, that we have to assume people will do it. You don’t have to keep the keys indefinitely. It’s fine to generate a new key every second or ten seconds or so. Which makes