On Fri, Sep 9, 2016 at 4:22 AM, Ilari Liusvaara
wrote:
> On Thu, Sep 08, 2016 at 09:59:22PM -0400, Hugo Krawczyk wrote:
> > On Thu, Sep 8, 2016 at 5:29 AM, Ilari Liusvaara <
> ilariliusva...@welho.com>
> > wrote:
> >
> > > On Wed, Sep 07, 2016 at 07:43:53PM -0400, Hugo Krawczyk wrote:
> > >
> > >
I'm happy to make all alerts fatal.
I also like the state in the pull requests where some cases require that
if an alert is sent, it is a specific alert, while leaving flexibility
in other cases (and preventing us from having to exhaustively enumerate
all possible causes for alerts).
It would als
While there seems to be some support for adding SHA-3 to TLS, we're not
seeing enough support to add it as part of TLS 1.3. Individual drafts that
specify ciphers suites can always be separately considered though.
Cheers,
J&S
On Fri, Sep 9, 2016 at 4:30 AM, Martin Thomson
wrote:
> On 9 Septem
On Fri, Sep 09, 2016 at 02:50:59PM -0500, Benjamin Kaduk wrote:
> I made a few notes on the pull request. Generally, I support the
> change, but I get the sense that it may aid the cryptographic properties
> if we keep the resumption_context and do not overload the resumption_psk
> as much.
One p
I made a few notes on the pull request. Generally, I support the
change, but I get the sense that it may aid the cryptographic properties
if we keep the resumption_context and do not overload the resumption_psk
as much.
I have a slight (i.e., unjustified) preference for doing
ClientHello-with-blo
The discussion about KeyUpdate-related changes has trailed off so it is time to
begin to bring the discussion to a close. It appears that there as if there is
support to land https://github.com/tlswg/tls13-spec/pull/61. But, there’s
still some discussion about how to add both P3 and P4 [0]. I
We don't do cert rollover, we shouldn't do PSK rollver.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
My personal take on your questions:
Andreas Walz wrote:
>
> (1) Several server implementations seem to ignore the list of proposed
> compression methods in a ClientHello and simply select null compression
> even if that has not been in the ClientHello's list.
Sounds like reasonable behaviour (i
Hi Benjamin,
regarding the use case you describe below: at least for us at ARM this
is not the way how we plan to use PSK. We use a key distribution
protocol (namely OMA LWM2M) to provision the PSK identity and the PSK
secret used with TLS.
So, from that point of view there is no need for a
Hi Ekr,
thanks for the response.
The psk_identity_hint in RFC 4279 was sent from the server to the client
and was a mechanism that was believed to be needed by the 3GPP in their
bootstrapping architecture, which in the end was never widely used (as
far as I know). So, not necessarily a super
Hi Ekr,
I read through the text and I think it is an improvement.
I only had one question that is only slightly related to your edits
because it came up in the interop testing with the Mint implementation.
"
Servers requiring this extension SHOULD respond to a ClientHello
lacking a "server_na
Hi Christian,
could you provide a bit more background why you are working on such a
solution?
Ciao
Hannes
On 08/18/2016 07:47 PM, Christian Huitema wrote:
Daniel Kaiser and I are working on a “pairing” specification in the
context of DNS SD. Short Authentication Strings are one of the prefe
Dear all,
we are working on an approach/framework for testing TLS implementations
(currently only servers, but clients are planned for the future as well). While
running our tests against a bunch of different TLS (server) implementations, we
found several types of suspicious behaviour (see belo
I like this approach.
On 09/08/2016 06:04 PM, David Benjamin wrote:
Hi folks,
I’d like to revisit the question of version negotiation.
EKR wrote up some text for moving version negotiation to an extension:
https://github.com/tlswg/tls13-spec/pull/632
I would like us to adopt this proposal.
I
Hi Ekr,
I have no problems with the suggested change but I would like to note
that we are losing one feature with this change.
Limiting the client to only send a single psk_identity prevents the
client from sending a ticket together with the long-term PSK identity in
the same message. This w
Hi all,
the current spec says:
---
2.3. Zero-RTT Data
When resuming via a PSK with an appropriate ticket (i.e., one with the
“allow_early_data” flag), clients can also send data on their first
flight (“early data”).
---
I am wondering why I cannot use Zero-RTT with just PSK-based
authentic
On 9 September 2016 at 20:02, Gilles Van Assche wrote:
> My point was technically how to best use FIPS 202 in RSA PSS, and we (as
> Keccak team) would be more than happy to help in that area.
And I'm more than happy to have the work happen, but I think that we
can do things in stages.
__
I don't mind if this is done in a separate spec.
My point was technically how to best use FIPS 202 in RSA PSS, and we (as
Keccak team) would be more than happy to help in that area.
Kind regards,
Gilles
On 09/09/16 06:20, Martin Thomson wrote:
> On 7 September 2016 at 18:24, Ilari Liusvaara
>
On 9 September 2016 at 18:22, Ilari Liusvaara wrote:
> Basically, one can't make a distinction between static ("non-resumption)
> and dynamic ("resumption") PSKs here. Because such distinction would
> run into security problems with some other features.
You mean that there is no inherent propert
On Thu, Sep 08, 2016 at 09:59:22PM -0400, Hugo Krawczyk wrote:
> On Thu, Sep 8, 2016 at 5:29 AM, Ilari Liusvaara
> wrote:
>
> > On Wed, Sep 07, 2016 at 07:43:53PM -0400, Hugo Krawczyk wrote:
> >
> > - The hash has output length at most input length (true for all SHA-2
> > variants)
> >
>
> Just
20 matches
Mail list logo
