e could suggest other mailing lists
who might show an interest (ACE?). Other questions and suggestions are welcome.
--
Tony
-Original Message-
From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org]
Sent: 30 November 2017 17:01
To: Tony Putman
Subject: New Version Notific
From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Katriel Cohn-Gordon
> If you add the fourth (static-static) DH, you should be protected
> against poor generation of ephemeral keys.
Thanks, this sounds like a good idea. It can be precomputed (and stored if
all comms is to a single server) so
Hi,
I got little interest in my previous draft on using triple-DH authenticated key
agreement for TLS 1.2. In case the reason was that everyone is focussed on TLS
1.3, I have now produced a new I-D which specifies how this same method would
work for TLS 1.3. It is published at
https://www.ietf
For externally established PSKs (especially for IoT devices) the identity can
be as simple as a serial number, easily enumerated. I think it would be a
mistake to place requirements on the structure of the identity to resolve this
(if it needs resolving); IMHO treating the situation in the same
Should the TLS 1.3 draft request a new registry for psk_key_exchange_modes?
Initially, I thought that there was no way to extend it, but the email below
from
Martin Thomson suggests adding a new codepoint, so I thought it best to check
that this wasn't an oversight in the draft.
-- Tony
-Or
David,
I think this is a valid concern. It's been commented on
(https://www.ietf.org/mail-archive/web/tls/current/msg25579.html) that the
draft has NO requirements on the underlying transport. There are potentially
other transports for TLS (such as being worked by the ATLAS WG) which may not
h
Hi Ekr,
Firstly, thanks for this. My primary reason for putting together draft-putman
was to propose a handshake exchange which only uses a single asymmetric
algorithm. If this proposal is extended to include raw public keys (I think
these are already supported, but not mentioned in the text) a
Fully agree. Defer it until there is a need.
-- Tony
From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of David Schinazi
Sent: 08 March 2018 17:48
To: Tony Putman
Cc: tls@ietf.org
Subject: Re: [TLS] TLS 1.3, how to close the read side of a connection?
Hi Tony,
I agree with you, TLS should not
I've been thinking about this on and off.
From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Eric Rescorla
Sent: 08 March 2018 23:25
I think that this and draft-putman are not competing, but rather that they
serve different use cases
Agreed. It sounds like you have a set of use cases where you
Hi Richard,
I work in the IoT space and am interested in handshakes that involve little
computation but offer better protection than symmetric PSK in the event of
server breach.
From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Richard Barnes
Sent: 11 April 2018 15:54
[…]
We would love to h
Hi Richard,
I don't think that you can protect against server compromise with SPAKE2. The
server can store w*N as you suggest, but it also has to store w*M because it
must calculate y*(T-w*M). An attacker that learns w*M and w*N from a
compromised server can then impersonate a client.
The res
Victor,
> Nor have I, and I rather think that introducing fixed-(EC)DH ciphers into
> TLS was a mistake, and glad to see them gone in TLS 1.3.
Can you please explain to me the problem with (EC)DH ciphers? If it's the
lack of forward secrecy, then I understand. If there are other problems,
then I
I take no position on whether this is a good idea or not. Regarding the draft
itself, I was expecting to see a clear definition of the integrity check
computation in terms of an AEAD-Encrypt computation. Something along the lines
of:
AEAD-Encrypt-HMAC(write_key, nonce, additional_data, plainte
Hi all,
I've recently started working in the IoT space and wish to standardize
our transport security by introducing the use of DTLS. It seems that the
usual practice is to use PSK for mutual authentication, but I'm not
happy with this solution. A breach of server security allows not only
server i
From: ilariliusva...@welho.com [mailto:ilariliusva...@welho.com]
> So basically triple-DH.
>
> As with any new mode, it would require security analysis (which is not
> exactly simple).
Thanks for the keyword, Ilari: I've now found
http://ieee-security.org/TC/SP2015/papers-archived/6949a232.pdf w
From: Eric Rescorla [mailto:e...@rtfm.com]
It's pretty straightforward to mix the static server DH share into the final
traffic keys (that last 0 input in the key schedule is kind of a placeholder
for that). As you say, the client's key is more difficult, but mixing into the
Finished MAC would be r
From: Nikos Mavrogiannopoulos [mailto:n...@redhat.com]
> If you worry about client impersonation there is TLS with SRP
> (RFC5054), which can also provide protection against server
> impersonation on the SRP-RSA mode. The latter is only defined over FF,
> i.e, there is no EC-based version of SRP de
All,
Thanks for your many comments. I still feel that this would be a useful
addition to the TLS authentication methods, and Eric expressed an interest in
seeing this fleshed out more, so should my next step be to compose a draft
document?
In response to the comments, I have searched the past
18 matches
Mail list logo
