Hi,
Just wanted to remind everybody that we’ve got two non-TLS1.3 items we’re
looking for WG input on:
- Before 12 July, we’d like to know your thoughts about progressing
draft-ietf-tls-pwd (Watson and ekr responded):
https://mailarchive.ietf.org/arch/msg/tls/WrNa7PXTZn2ZhfmoQDA_pnUVuN4
- Befo
> On Jul 10, 2016, at 03:36, g_e_montene...@yahoo.com wrote:
>
> Hi,
>
> I'm curious as to the relationship between this TLS WG draft and the DICE
> profile for IoT (currently in Auth48):
> https://tools.ietf.org/html/draft-ietf-dice-profile
>
> The dice profile uses two TLS ciphershuites
>
>
I think I can take this bit:
On Jul 10, 2016, at 06:51, Peter Dettman wrote:
>
> I'm also curious whether there is a precedent in other RFCs for an
> explicit minimum curve bits, or perhaps a de facto implementer's rule?
I’d be happy to be wrong here. but to my knowledge no there’s not been an
On Mon, Jul 11, 2016 at 7:27 AM, Sean Turner wrote:
> Hi,
>
> Just wanted to remind everybody that we’ve got two non-TLS1.3 items we’re
> looking for WG input on:
>
> - Before 12 July, we’d like to know your thoughts about progressing
> draft-ietf-tls-pwd (Watson and ekr responded):
> https://ma
I agree with Watson's assessment here. This seems like the wrong design
choice.
I'm not familiar with OpenSSL's cert selection, but I don't believe that
the issue
that this change is intended to address applies to NSS, for two reasons:
1. NSS does cert selection during client hello processing [0]
OpenSSL determines which certificate to use during ClientHello processing,
but it has a mode where, if intermediates were not explicitly configured
and only a leaf, it path-builds right before sending the Certificate
message. But I don't see any reason why it can't be changed to compute this
earlie
I also don't like the AUTH48 changes -- there's no protocol-level reason
to weaken the MUST, since a server that can't handle the extra
state/processing can just not implement the extension at all.
-Ben
On 07/11/2016 10:34 AM, Eric Rescorla wrote:
> I agree with Watson's assessment here. This see
On Monday, July 11, 2016 10:27:21 am Sean Turner wrote:
> - Before 12 July, we’d like to know your thoughts about progressing
> draft-ietf-tls-pwd (Watson and ekr responded):
> https://mailarchive.ietf.org/arch/msg/tls/WrNa7PXTZn2ZhfmoQDA_pnUVuN4
This document defines new cipher suites using obso
Folks,
I've just submitted draft-ietf-tls-tls13-14.txt and it should
show up on the draft repository shortly. In the meantime you
can find the editor's copy in the usual location at:
http://tlswg.github.io/tls13-spec/
The major changes in this document are:
* A big restructure to make it read
Some of the discussions I've had with people about post-handshake client
authentication have raised the question of whether application traffic secrets
should be updated automatically upon post-handshake client authentication: the
thinking being that every change in context should be accompanied
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 : The Transport Layer Security (TLS) Protocol Version
1.3
Author : Eric Rescorla
Filename
I'm glad I have to opportunity to make you happy Sean :-)
On Mon, July 11, 2016 7:40 am, Sean Turner wrote:
> I think I can take this bit:
>
> On Jul 10, 2016, at 06:51, Peter Dettman
> wrote:
>>
>> I'm also curious whether there is a precedent in other RFCs for an
>> explicit minimum curve bi
On Mon, Jul 11, 2016 at 9:16 AM, David Benjamin
mailto:david...@chromium.org>> wrote:
> OpenSSL determines which certificate to use during ClientHello processing,
> but it has a mode where, if intermediates were not explicitly configured and
> only a leaf, it path-builds right before sending th
Hi Douglas,
As currently defined, post-handshake client auth allows the same client to
present different identities, but not to repudiate a previously presented
identity. So in your example, from the TLS perspective, the client is both
Alice and Bob, and therefore I think the same EKM value mak
Not taking any position on the question, which I think is a fine thing
to ask, but...
I'd just like to point out that the example is flawed in the sense
that the system permits both users to share state. When Alice logs
out, that needs to include any state that might have been accumulated
to Alic
On Mon, Jul 11, 2016 at 9:13 PM, Martin Thomson
wrote:
> Not taking any position on the question, which I think is a fine thing
> to ask, but...
>
> I'd just like to point out that the example is flawed in the sense
> that the system permits both users to share state. When Alice logs
> out, that
On Mon, Jul 11, 2016 at 7:56 PM, Hugo Krawczyk
wrote:
>
>
> On Mon, Jul 11, 2016 at 9:13 PM, Martin Thomson
> wrote:
>
>> Not taking any position on the question, which I think is a fine thing
>> to ask, but...
>>
>> I'd just like to point out that the example is flawed in the sense
>> that the
On Mon, Jul 11, 2016 at 12:08:00PM -0700, Eric Rescorla wrote:
> Folks,
>
> I've just submitted draft-ietf-tls-tls13-14.txt and it should
> show up on the draft repository shortly. In the meantime you
> can find the editor's copy in the usual location at:
> As usual, comments welcome.
> -Ekr
Did
Just replying to a few points.
On Tuesday, July 12, 2016 12:16:24 am Ilari Liusvaara wrote:
> ### Hello Retry Request
>
> > selected_group
> > : The mutually supported group the server intends to negotiate and
> > is requesting a retried ClientHello/KeyShare for.
> > {:br }
>
> What is writte
Hi Sean,
That might be a good thing, yes. If so, it would be best to make that
relationship explicit with an "Updates: " header note, referencing DICE in this
document, and explaining how it is extending it.
thanks,
Gabriel
On Monday, July 11, 2016 7:35 AM, Sean Turner wrote:
> On
20 matches
Mail list logo
