I just posted an agenda for the Berlin meeting (
https://www.ietf.org/proceedings/96/agenda/agenda-96-tls)
Our main focus for the meeting will be TLS 1.3, but I am hopeful that we
will have time for some other topics. The specific details of the 1.3
topics will likely change as we get closer to t
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Transport Layer Security of the IETF.
Title : Elliptic Curve Cryptography (ECC) Cipher Suites for
Transport Layer Security (TLS) Versions 1.2 and Earlier
Aut
This is also what is still proposed in the -01 version at the top of this
thread:
https://tools.ietf.org/html/draft-nygren-tls-client-puzzles-01
By leveraging the HelloRetryRequest in TLS 1.3, it provides client puzzles
as an extension mechanism to TLS without requiring changes to the state
m
On Fri, Jul 08, 2016 at 04:25:09PM +, Fossati, Thomas (Nokia - GB) wrote:
> Hi Ilari,
> My use case is an IoT device that voluntarily (or better, knowingly)
> migrates its attachment from IP to GSM-SMS and vice-versa and wants to
> keep the (painfully) negotiated session open. Here the client
Hi Ilari,
On 08/07/2016 14:25, "ilariliusva...@welho.com on behalf of Ilari
Liusvaara" wrote:
>However, turns out this doesn't actually work as well as hoped in
>practice. The problem is that client can't really change address
>voluntarily
>(even if it is behind CGNAT, it probably can't change th
On Thu, Jul 7, 2016 at 7:29 PM Watson Ladd wrote:
> I don't think we can use name constraints here. Yes, they are opt-in
> and clients can indicate support, but it may well be that a TLS
> implementation doesn't know if its X509 validation code will support
> them as it hands the certificate to a
On Jul 8, 2016 6:50 AM, "Joseph Salowey" wrote:
>
> We would like to have all comments in on this by Friday, July 7, 2016.
>
> Also, to clarify, Hugo's interpretation is correct:
>
> Option 1 - use the same key for protecting both *post*-handshake and
applications messages.
I don't object to this
Hi all,
based on the feedback from Ilari this week I have drafted initial text
that talks about rekeying and the use of the epoch value.
8.8. Epoch Values and Rekeying
A recipient of a DTLS message needs to select the correct keying
material in order to process an incoming message.
Hi everyone,
This draft extends TLS 1.3 to provide pinning of the TLS server using a
stateless ticket. This is similar to public-key pinning but not quite,
and our goal was to overcome the deployment issues that prevent
widespread deployment of HPKP.
Version -02 of the draft incorporates learnin
We would like to have all comments in on this by Friday, July 7, 2016.
Also, to clarify, Hugo's interpretation is correct:
Option 1 - use the same key for protecting both *post*-handshake and
applications messages.
On Thu, Jul 7, 2016 at 2:44 AM, Hugo Krawczyk
wrote:
> I do not have an obje
On Fri, Jul 08, 2016 at 11:06:46AM +, Fossati, Thomas (Nokia - GB) wrote:
> Hi Nikos,
>
> On 08/07/2016 10:55, "Nikos Mavrogiannopoulos" wrote:
> >On Fri, 2016-07-08 at 09:29 +, Fossati, Thomas (Nokia - GB) wrote:
> >
> >As long as both the client and the server are able to notify each ot
On Fri, Jul 8, 2016 at 6:09 AM, Ilari Liusvaara
wrote:
>
> There is validity start time in there, the relative end time would
> be relative to that.
>
> That is, instead of saying "this is valid from t1 to t2", saying "this
> is valid from t to t+dt".
>
> No real perference either way, it was jus
Hi Nikos,
On 08/07/2016 10:55, "Nikos Mavrogiannopoulos" wrote:
>On Fri, 2016-07-08 at 09:29 +, Fossati, Thomas (Nokia - GB) wrote:
>
>> > > > How would the hash chain matching work for a server handling
>> > > > multiple
>> > > > clients?
>> > > Sorry, I'm not sure I understand the question.
On Mon, Jul 04, 2016 at 05:03:12PM +0300, Ilari Liusvaara wrote:
> - KeyUpdate does not work in DTLS. Might just use epochs for similar
> purpose, and reserve first few epochs for special purposes.
Eeh... Epochs have the problem that processing records with epochs
far into the future is expensi
On Thu, Jul 07, 2016 at 07:29:08PM -0700, Watson Ladd wrote:
> On Jul 7, 2016 12:29 PM, "Eric Rescorla" wrote:
>
> How about limit to ECDSA certificates? This eliminates the
> Bleichenbacher issues. We can also make this opt in via an extension
> to the EE certificate: since the certificate is no
On Thu, Jul 07, 2016 at 08:08:11PM -0400, Kyle Rose wrote:
> On Thu, Jul 7, 2016 at 6:13 PM, Ilari Liusvaara
> wrote:
>
> >
> > I also checked if one could do some funky stuff with credential lifetime
> > notation to limit the lifetime. Nothing came up (apart for using 16-bit
> > count in decasec
On Fri, 2016-07-08 at 09:29 +, Fossati, Thomas (Nokia - GB) wrote:
> > > > How would the hash chain matching work for a server handling
> > > > multiple
> > > > clients?
> > > Sorry, I'm not sure I understand the question. Are you asking
> > > what
> > > happens if there is an Id collision be
On 08/07/2016 10:05, "Nikos Mavrogiannopoulos" wrote:
>On Fri, 2016-07-08 at 08:59 +, Fossati, Thomas (Nokia - GB) wrote:
>
>> > How would the hash chain matching work for a server handling
>> > multiple
>> > clients?
>> Sorry, I'm not sure I understand the question. Are you asking what
>> ha
Hi Nikos,
On 08/07/2016 09:44, "Nikos Mavrogiannopoulos" wrote:
>On Fri, 2016-07-08 at 08:34 +, Fossati, Thomas (Nokia - GB) wrote:
>> Hi Nikos, Stephen,
>>
>> It seems to me that both your views (high resistance to traceability
>> and
>> low resource investment on server side) can be accomm
On Fri, 2016-07-08 at 08:59 +, Fossati, Thomas (Nokia - GB) wrote:
> > How would the hash chain matching work for a server handling
> > multiple
> > clients?
> Sorry, I'm not sure I understand the question. Are you asking what
> happens if there is an Id collision between two separate hash ch
On Fri, 2016-07-08 at 08:34 +, Fossati, Thomas (Nokia - GB) wrote:
> Hi Nikos, Stephen,
>
> It seems to me that both your views (high resistance to traceability
> and
> low resource investment on server side) can be accommodated in a
> single scheme.
> Going back to the hash chain proposal tha
Hi Nikos, Stephen,
It seems to me that both your views (high resistance to traceability and
low resource investment on server side) can be accommodated in a single
scheme.
Going back to the hash chain proposal that Stephen did a few emails ago on
this same thread. If:
1. the length of the hash c
Hi,
After several discussions (including the ones Douglas points out) I have
also come round to option 1 as the preferred way forward. For our symbolic
analysis in Tamarin it should not make a big difference anyway.
Best,
Cas
On Thu, Jul 7, 2016 at 8:47 PM, Douglas Stebila wrote:
> With Hugo
23 matches
Mail list logo
