> On 7 Mar 2021, at 17:25, Benjamin Kaduk
> wrote:
>
> On Sun, Mar 07, 2021 at 12:15:24PM +, Graham Bartlett wrote:
>>
>> I would imagine that the implementation would pull the session down once
>> the certificate expires, so the session only lasts for the lifetime of the
>> certificate.
Hi,
First of all thanks for all the discussion on that question, which is great
input also to the discussion in IEC.
> From: TLS On Behalf Of Hannes Tschofenig
> I think it is useful to start with the problem description.
The problem that was addressed so far with the session renegotiation in
The IESG has received a request from the Transport Layer Security WG (tls) to
consider the following document: - 'Connection Identifiers for DTLS 1.2'
as Proposed Standard
The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substant
Peter can certainly speak for himself :) but I don't think it's never.
I think it's also the kind of thing where someone does things manually, and
then goes out into the field for a service operation. So not just never, but
also situations where automation isn't appropriate and installing softw
I am glad that someone in the working group is looking at this. However, as I
reviewed this before the wg meeting, I was completely puzzled by this text
(from section 6.1):
3DH
C computes K = H(g^y ^ PrivU || PubU ^ x || PubS ^ PrivU || IdU || IdS )
S computes K = H(g^x ^ PrivS || PubS ^
Again, last minute reviews...
It would appear that the exact computations that both the client and the server
need to perform needs to be explicitly spelled out, as there are several
possibilities.
Here is the one I could see that appear to have the security properties that
you appear to be lo
Well overdue. We should do this.
The title "Deprecating FFDH(E) Ciphersuites in TLS" doesn't seem to match the
document content. I only see static or semi-static DH and ECDH key exchange
being deprecated (in the document as non-ephemeral).
___
TLS m
Taking a step back from the crypto, I'm trying to make sure I
understand the desired security properties. As I understand the
situation:
- the client has a preconfigured key pair (X_c, Y_c)
- the server is anonymous (i.e., doesn't have a valid TLS cert).
- the server is preconfigured with informat
+1 for forbidding more old crap.
Lack of forward secrecy should imply at least NOT RECOMMENDED.
Does it make sense to forbid things for TLS 1.0 and TLS 1.1 when we soon have
an RFC forbidding use of TLS 1.0 and TLS 1.1?
Cheers,
John
-Original Message-
From: TLS on behalf of Martin T
Agreed. I'll change the title to reflect that.
> On Mar 8, 2021, at 7:33 AM, Martin Thomson wrote:
>
> Well overdue. We should do this.
>
> The title "Deprecating FFDH(E) Ciphersuites in TLS" doesn't seem to match the
> document content. I only see static or semi-static DH and ECDH key excha
Dear all,
Sorry about my audio quality issues: my laptop is a bit of a potato
and there may have been some coupling from my mike via the
table/directionality not as good as it should be.
My concern is that this protocol depends on things that TLS does not
claim to provide like secrecy of public k
On Mon, Mar 08, 2021 at 08:51:31AM +, Fries, Steffen wrote:
> The problem that was addressed so far with the session renegotiation in TLS
> 1.2 was motivated by different points.
>
> - Recommendation in RFC 5246 regarding the use of the SessionID lifetime
> - Regular session key update for
I'd suggest we also deprecate TLS 1.2 TLS_DHE_*, even when ephemeral:
- The construction is broken. The leak itself in the Raccoon attack comes
from TLS 1.2 removing leading zeros. We can't change the meaning of the
existing code points, so any fix there would involve dropping them.
- It lacks gr
One thing at a time?
On Tue, Mar 9, 2021, at 05:05, David Benjamin wrote:
> I'd suggest we also deprecate TLS 1.2 TLS_DHE_*, even when ephemeral:
>
> - The construction is broken. The leak itself in the Raccoon attack
> comes from TLS 1.2 removing leading zeros. We can't change the meaning
> of
TLS_DHE is weak when used with interoperable key lengths. It also causes
interop issues dues to several instances of under-specification (leading zeros,
lack of group negotiation). I'm in favor of deprecating TLS_DHE.
Cheers,
Andrei
-Original Message-
From: TLS On Behalf Of Martin Tho
If the draft to deprecate 1.0 and 1.1 becomes an RFC while this is still a
draft, I'll remove all mention of 1.0/1.1.
> On Mar 8, 2021, at 8:34 AM, John Mattsson
> wrote:
>
> +1 for forbidding more old crap.
>
> Lack of forward secrecy should imply at least NOT RECOMMENDED.
>
> Does it make
On Mon, Mar 08, 2021 at 10:52:15AM -0800, Carrick Bartle wrote:
> If the draft to deprecate 1.0 and 1.1 becomes an RFC while this is still a
> draft, I'll remove all mention of 1.0/1.1.
I expect it to become an RFC this week.
-Ben
___
TLS mailing list
I'm not opposed to expanding the scope of this document to include deprecating
DHE. Is there a major advantage to that being its own draft?
> On Mar 8, 2021, at 10:09 AM, Martin Thomson wrote:
>
> One thing at a time?
>
> On Tue, Mar 9, 2021, at 05:05, David Benjamin wrote:
>> I'd suggest we
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Transport Layer Security WG of the IETF.
Title : TLS Encrypted Client Hello
Authors : Eric Rescorla
Kazuho Oku
As discussed during today's call, -10 is now out. I'll update pointers in the
interop matrix and related pages.
Stay tuned for a doodle to schedule the interim meetings!
Best,
Chris (no hat)
On Wed, Feb 24, 2021, at 10:07 AM, Christopher Wood wrote:
> The WG previously decided to make draft-iet
I guess it's a question of what the goal of this draft is. I don't
particularly care as long as it's self-consistent. :-)
We've got the title, "FFDH(E)", which would suggest targeting TLS_DH_*,
TLS_DHE_*, and even NamedGroup.ffdhe*, and not anything around ECDH(E).
We've got the contents, which ar
On 3/8/2021 8:00 AM, Eric Rescorla wrote:
Taking a step back from the crypto, I'm trying to make sure I
understand the desired security properties. As I understand the
situation:
- the client has a preconfigured key pair (X_c, Y_c)
- the server is anonymous (i.e., doesn't have a valid TLS cert)
Great, sounds good to me then.
> On Mar 8, 2021, at 11:24 AM, David Benjamin wrote:
>
> I guess it's a question of what the goal of this draft is. I don't
> particularly care as long as it's self-consistent. :-)
>
> We've got the title, "FFDH(E)", which would suggest targeting TLS_DH_*,
> TLS
Hi Scott,
On 3/8/21 7:09 AM, Scott Fluhrer (sfluhrer) wrote:
Again, last minute reviews…
It would appear that the exact computations that both the client and
the server need to perform needs to be explicitly spelled out, as
there are several possibilities.
Here is the one I could see th
Hi Eric,
On 3/8/21 8:00 AM, Eric Rescorla wrote:
Taking a step back from the crypto, I'm trying to make sure I
understand the desired security properties. As I understand the
situation:
- the client has a preconfigured key pair (X_c, Y_c)
- the server is anonymous (i.e., doesn't have a valid
Hi Christian,
On 3/8/21 11:49 AM, Christian Huitema wrote:
The list of requirement reminds me of two scenarios: the Anima problem
of "bringing a clean device into the new owner's network"; and the
corporate Wi-Fi problem of "connecting a device to the corporate
Wi-Fi". In the Anima proble
On Mon, Mar 8, 2021 at 1:18 PM Dan Harkins wrote:
>
> Hi Eric,
>
> On 3/8/21 8:00 AM, Eric Rescorla wrote:
>
> Taking a step back from the crypto, I'm trying to make sure I
> understand the desired security properties. As I understand the
> situation:
>
> - the client has a preconfigured key pa
It is sad that nobody is willing to discuss the obvious downsides of this
proposal as written, which should at least be mentioned in the security
considerations. Without discussing the downsides we're reducing engineering
to politics. If we discuss the downsides then we can substantially improve
th
Brian Smith wrote:
> It is sad that nobody is willing to discuss the obvious downsides of this
> proposal as written, which should at least be mentioned in the security
> considerations. Without discussing the downsides we're reducing engineering
> to politics. If we discuss the downsides then we
Hi Brian,
* Look at Windows Server 2012 and similar legacy products that are in
widespread use, which don't support any PFS cipher suites except FFDHE.
Windows Server 2012/Windows 8 support both TLS_ECDHE_ECDSA and TLS_ECDHE_RSA
cipher suites: TLS Cipher Suites in Windows 8 - Win32 apps | M
Chrome dropped TLS 1.2 DHE nearly five years ago now. I don't have data on
the current DHE-to-RSA conversion, but I can tell you what it was then.
When we put it under a fallback for measurement, only 2% of connections
negotiated DHE. Of that 2%, 95% used 1024-bit DHE. That means we really
only had
> I think the blanket prohibition of reuse of ECDHE keys is maybe not really
> justified.
Why is that?
> IMO that's the part that should have deprecation of RSA cipher suites done at
> the same time.
RSA seems to me to be too off-topic for this draft. (It also seems to me that
RSA is still to
David Benjamin writes:
>[*] From the conclusion of the paper: "The most straightforward mitigation
>against the attack is to remove support for TLS-DH(E) entirely, as most major
>client implementations have already stopped supporting them"
Just as you need to automatically add "in mice" to the e
Brian Smith writes:
>It would be useful for the browser vendors that recently dropped FFDHE
>support to share their measurements for how much RSA key exchange usage
>increased after their changes. That would help us quantify the real-world
>impact of this change.
... in mice.
Peter.
_
On Mon, Mar 08, 2021 at 07:08:31PM -0800, Carrick Bartle wrote:
> > I think the blanket prohibition of reuse of ECDHE keys is maybe not
> > really justified.
>
> Why is that?
Because there are still many TLS (non-web) implementations that don't
do ECDHE.
Is there a credible active MiTM attack t
Brian Smith wrote:
>Deprecating FFDHE key exchange without deprecating RSA key exchange will
>substantially increase the usage >of RSA key exchange and thus make server key
>compromise more dangerous. At a minimum, RSA key >exchange should be
>deprecated at the same time, in the same document.
On Mon, Mar 8, 2021 at 10:16 PM John Mattsson wrote:
> Brian Smith wrote:
> >Deprecating FFDHE key exchange without deprecating RSA key exchange will
> substantially increase the usage >of RSA key exchange and thus make server
> key compromise more dangerous. At a minimum, RSA key >exchange shoul
> -Original Message-
> From: TLS On Behalf Of Viktor Dukhovni, Sent: Montag,
> 8. März 2021 19:05
> > The problem that was addressed so far with the session renegotiation in TLS
> 1.2 was motivated by different points.
> >
> > - Recommendation in RFC 5246 regarding the use of the SessionI
On Mon, Mar 08, 2021 at 10:25:29PM -0800, Rob Sayre wrote:
> On Mon, Mar 8, 2021 at 10:16 PM John Mattsson wrote:
> >
> > Viktor Dukhovni wrote:
> > >In practice security improves more when you raise the ceiling, rather the
> > >floor.
> >
> > Let’s start with mandating support of
> > TLS_ECDHE_RS
On Tue, Mar 09, 2021 at 07:28:26AM +, Fries, Steffen wrote:
> > My take is such measures are much too complicated. Just keep the connection
> > lifetime short, and make a new one from time to time. Also keep certificate
> > lifetimes short. Where DNSSEC is an option on both ends, you can al
40 matches
Mail list logo
