On Wed 2018-12-05 17:08:44 +0900, Bret Jordan wrote:
> Now this WG is finally starting to talk about a solution to a real
> problem and need. We can either address the use case and need here in
> the IETF, or we can let the solutions be done else where. I would
> personally prefer we take this
> The WG is chartered to make TLS a fast, secure, confidential transport
> layer. Let's keep the charter goals in mind.
>
>--dkg
+ 1
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
On 05/12/2018 08:08, Bret Jordan wrote:
> Now this WG is finally starting to talk about a solution to a real
> problem and need. We can either address the use case and need here
> in the IETF, or we can let the solutions be done else where. I would
> personally prefer we take this work item
I think we should be more open minded and look at the needs from a 360 degree
deployment perspective. The real power of the IETF is in looking at all the
needs and requirements and designing solutions for them.
We should flesh this out. It seems like several people on this list so far have
Now this WG is finally starting to talk about a solution to a real problem and
need. We can either address the use case and need here in the IETF, or we can
let the solutions be done else where. I would personally prefer we take this
work item back and solve it here in the IETF.
Finally,
Comments inline
Sent from my Commodore 128D
PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050
> On Dec 5, 2018, at 7:33 PM, Stephen Farrell wrote:
>
>
>
>> On 05/12/2018 10:22, Bret Jordan wrote:
>> I think we should be more open minded and look at the needs from a
>> 360
On Wed 2018-12-05 20:15:08 +0900, Bret Jordan wrote:
>> On Dec 5, 2018, at 7:33 PM, Stephen Farrell
>> wrote:
>>> On 05/12/2018 10:22, Bret Jordan wrote:
>>> I think we should be more open minded and look at the needs from a
>>> 360 degree deployment perspective.
>>
>> I think we should avoid
On Wed, Dec 5, 2018 at 12:09 AM Bret Jordan wrote:
> Now this WG is finally starting to talk about a solution to a real problem
> and need. We can either address the use case and need here in the IETF, or
> we can let the solutions be done else where. I would personally prefer we
> take this
>One mitigating factor of the ETSI standard, i suppose, is that the
CABForum's Baseline Requirements forbid issuance of a certificate with
any subjectAltName other than dNSName or iPAddress, so otherName looks
like it must not be issued by standard public CAs.
Ooh, good catch.
* Or it could be said the TLS WG had no consensus to not work on it. When
there is a tie who wins? It seems like working on a solution that works for the
larger community is the right solution. The use case and need is a valid
requirement.
That’s not the way it works. When deciding
I like the gist of what Tony is saying. Key escrow (it should be called
"secret escrow", but I digress) itself is not really the problem in a
datacenter - those guys struggle to solve the key distribution problem. If it
was one-server-to-one-tool then we would not be having this discussion.
On Wed, Dec 5, 2018 at 8:28 AM Salz, Rich wrote:
>
> Or it could be said the TLS WG had no consensus to not work on it. When
> there is a tie who wins? It seems like working on a solution that works for
> the larger community is the right solution. The use case and need is a valid
>
On 12/5/18 7:27 AM, Salz, Rich wrote:
> That’s not the way it works. When deciding whether or not to adopt
> something as a WG item, unless there is consensus to DO it, then the
> consensus is DO NOT do it. There is no tie. A decision was made, and
> by not adopting this work, the WG decided to
1. Perhaps the kind folks at Qualsys ssllabs.com have some recent stats for us,
given that they track DH reuse under "Protocol Details" when you run their
https://www.ssllabs.com/ssltest/analyze.html tool. 2. The DoS (prevention)
engineers should also weigh in on this. Would servers not start
I like the intent of draft-dkg-tls-reject-static-dh-01, but this part will cost
servers some perf:
"Given the concerns in Section 2 and the necessary client mitigations
in the subsections above, servers need to avoid giving the appearance
of using non-ephemeral DH. Servers MUST NOT
See https://dl.acm.org/citation.cfm?id=2987480 Quote: "As we will discuss
later, we empirically find that at least 7.2% of HTTPS domains in the Alexa Top
Million reuse DHE values and 15.5% reuse ECDHE values." On Wed, 05 Dec
2018 13:59:07 -0500 Stephen Farrell wrote
Hiya, Thanks
On Wed, Dec 05, 2018 at 06:59:07PM +, Stephen Farrell wrote:
> My main concern is that a server playing a
> draft-green-like game could just choose DH
> values more cleverly and avoid detection.
We can forbid static server DH keys, and should attempt to preclude them
by encouraging clients to
> On Dec 5, 2018, at 2:19 PM, R duToit wrote:
>
> Quote: "As we will discuss later, we empirically find that at least 7.2% of
> HTTPS domains in the Alexa Top Million reuse DHE values and 15.5% reuse ECDHE
> values."
That survey is now dated. Library defaults matter, and it used to be
the
Would you believe my timezone is GMT+120?
This is good to advance
On 11/7/18, 2:35 AM, "Christopher Wood" wrote:
This is the working group last call for the "Exported Authenticators
in TLS" draft available at
https://datatracker.ietf.org/doc/draft-ietf-tls-exported-authenticator/.
Hiya,
Thanks for writing this, I would support it
being progressed if we conclude that it's
feasible and not easily defeated.
My main concern is that a server playing a
draft-green-like game could just choose DH
values more cleverly and avoid detection.
E.g. if the DH values are derived via
Still stuck in that five-day-behind timezone, but I read this doc and have no
problems. Advance it.
From: Joseph Salowey
Date: Wednesday, November 7, 2018 at 2:40 AM
To: "tls@ietf.org"
Subject: [TLS] WGLC for draft-ietf-tls-dtls-connection-id
This is the working group last call for the
21 matches
Mail list logo
