On Monday, October 31, 2016 07:26:30 pm Matt Caswell wrote:
> On 31 October 2016 at 23:13, David Benjamin wrote:
> > On Mon, Oct 31, 2016 at 6:34 PM Kurt Roeckx wrote:
> >>
> >> On Mon, Oct 31, 2016 at 07:11:10PM +, David Benjamin wrote:
> >> > On Mon, Oct 31, 2016 at 2:57 PM Ilari Liusvaara
On Monday, October 31, 2016 08:05:59 pm Matt Caswell wrote:
> On 31/10/16 23:53, Dave Garrett wrote:
> >> I came up with some alternative wording that I think captures the
> >> discussion:
> >>
> >> https://github.com/tlswg/tls13-spec/pull/748
> &
On Tuesday, November 08, 2016 09:55:36 am Roel Peeters wrote:
> we are also wondering whether or not the Hello Retry Request will be
> included or omitted in the standard. Leaving it out will make TLS 1.3
> vulnerable again to downgrade attacks ...
Why are you wondering about this? HRR is in the s
On Thursday, November 17, 2016 09:12:48 pm Sean Turner wrote:
> The consensus in the room was to leave it as is, i.e., TLS1.3, and to not
> rebrand it to TLS 2.0, TLS 2, or TLS 4. We need to confirm this decision on
> the list so please let the list know your top choice between:
>
> - Leave it
(replies to a bunch of ideas in this thread)
As the person who lit the match under this latest bikeshed debate, personally,
I don't see a strong consensus building here. Leaving the bikeshed unpainted
seems like the option we're headed for, at this rate. I'm fine with TLS 1.3 if
that's the resu
On Thursday, December 15, 2016 08:32:32 am Guballa Jens (ETAS-PSC/ECS) wrote:
> - Page 108 (appendix C.4): "If an implementation negotiates use of TLS 1.2,
> then negotiation of
> cipher suites also supported by TLS 1.3 SHOULD be preferred, if
> available."
> TLS cipher suites for TLS1.
On Friday, March 10, 2017 10:29:30 am Viktor Dukhovni wrote:
> Instead of looking for a kludgey replacement SNI in DNS (that won't get
> deployed,
> and provides rather weak obfuscation) it seems more sensible to publish keys
> in
> DNS that make it possible to encrypt the entire client HELLO, SN
Yes, a proper "differences from TLS 1.2" section needs to be written to replace
the draft changelog.
Dave
On Tuesday, March 14, 2017 05:31:18 am Yoav Nir wrote:
> Hi.
>
> I will give the entire document a more thorough read, but I wanted to comment
> on section 1.2 earlier. Its title is “Maj
On Tuesday, March 28, 2017 01:37:29 pm Mark Dunn wrote:
> should the text that reads
> ClientHellos will contain at least two extensions,
> “supported_versions” and either “key_share” or “pre_shared_key”.
> be changed to
> ClientHellos will always contain extensions.
>
> Both "key_share
On Tuesday, March 28, 2017 11:31:56 am Short, Todd wrote:
> I didn’t bring this up in the meeting this morning, but I’d like to see
> section 1.2 “Major Differences from TLS 1.2” cleaned up. We don’t need to
> list the changes at each draft. Instead, only the major difference from RFC
> 5246, et
On Tuesday, March 28, 2017 02:23:33 am Kaduk, Ben wrote:
> Should Alert.level be Alert.legacy_level?
Yep. Trivial to fix, so quick PR filed for it.
Dave
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
On Monday, April 24, 2017 12:39:32 pm Eric Rescorla wrote:
> 9 bytes seems a bit cramped. What I suggest here is that we remove the "TLS
> 1.3, ", as it was just there by analogy to the handshake context and then
> we are back to having 18 bytes.
>
> If people feel like we should have some "TLS" p
On Monday, April 24, 2017 07:21:13 pm Eric Rescorla wrote:
> Hence, the following proposal for the complete label, where the longest
> string is 18 bytes.
>
> 16 tls13 ext binder# was external psk binder key
> 16 tls13 res binder# was resumption psk binder key
> 17 tls13 c e traffic#
On Wednesday, May 10, 2017 03:28:48 pm Ilari Liusvaara wrote:
> On Wed, May 10, 2017 at 07:28:51PM +0200, Hubert Kario wrote:
> > Yes, encrypted SNI was discussed and ultimately rejected.
> >
> > But do we really have to send the literal value? Don't we need to just make
> > sure that the client
On Friday, May 12, 2017 11:17:45 pm Christian Huitema wrote:
> The "server DH Key" poses a significant forward secrecy issue. Suppose
> that the key is compromised. Now the secret police can find out what
> nasty sites was accessed by whom. That can be plus plus not good for
> said dissidents.
*Th
On Monday, May 15, 2017 07:56:44 am Hubert Kario wrote:
> On Saturday, 13 May 2017 07:21:06 CEST Dave Garrett wrote:
> > On Friday, May 12, 2017 11:17:45 pm Christian Huitema wrote:
> > > The "server DH Key" poses a significant forward secrecy issue. Suppose
> >
On Tuesday, May 16, 2017 07:35:16 am Hubert Kario wrote:
> On Monday, 15 May 2017 22:10:00 CEST Dave Garrett wrote:
> > On Monday, May 15, 2017 07:56:44 am Hubert Kario wrote:
> > > I respectfully disagree. That system requires tight coupling between the
> > > TLS impl
On Tuesday, May 16, 2017 12:37:42 pm Viktor Dukhovni wrote:
>* RFC7250 raw public keys
Just as a footnote to anyone reading this discussion that may not know:
The current version of the TLS 1.3 spec explicitly recommends RFC7250
raw public keys as a viable option and provides the needed inform
On Friday, May 19, 2017 12:38:27 am Benjamin Kaduk wrote:
> In section 4, "these cipher suites MUST NOT be negotiated in TLS
> versions prior to 1.2" should probably clarify that "these" cipher
> suites are the new ones specified by this document.
Probably should be: "the cipher suites defined in
On Friday, May 19, 2017 04:18:03 pm Daniel Migault wrote:
> 1) The current document mentions I-D.ietf-tls-rfc4492bis and
> I-D.ietf-tls-tls13 as normative. We can wait for these documents to become
> RFCs, but we can also dowref them to informational reference if we want to
> move that document
On Friday, May 19, 2017 04:51:21 pm Viktor Dukhovni wrote:
> Which brings us to some more undesirable layer violation in the current
> draft. The language in question is appropriate for updates to RFC5280,
> but does not belong in TLS. The problems in question are largely
> already addressed else
On Monday, May 22, 2017 05:31:55 pm Viktor Dukhovni wrote:
> So if putting the consensus to ban MD5/SHA-1 in its *proper context*
> is consistent with the WG consensus, let's do that.
Yes, please.
Citing discussion elsewhere in this thread (that probably should've all
been forked off with a diffe
On Monday, May 22, 2017 08:29:13 pm Viktor Dukhovni wrote:
> Setting a collision-resistance floor rather than naming some list
> of algorithms makes more sense to me, but if the WG really feels
> that naming some "verbotten" algorithms is better, so be it.
My preference would be to do both. Call o
On Tuesday, May 30, 2017 05:38:02 pm Victor Vasiliev wrote:
> TLS isn’t a magical “transport security solution”, it provides a very specific
> set of explicit security guarantees to the applications that use it. It can
> be
> used as a building block for the secure systems, but at the end of the
Correct; certs are never in the clear. There is no scenario where anything will
be unencrypted after the hellos in TLS 1.3+. If you're doing anything with an
old system that relies on this, the general advice is to upgrade your old
system to not do that anymore. If you're logging traffic from so
On Wednesday, June 07, 2017 01:38:59 am Raja ashok wrote:
> So I suggest we should consider compression on client certificate message
> also.
+1
Additionally, there's one bit of the spec which I question the need for: zlib
support. Unless someone can show a legitimate case where zlib will consi
On Wednesday, June 07, 2017 07:03:55 am Piotr Sikora wrote:
> > Additionally, there's one bit of the spec which I question the need for:
> > zlib support. Unless someone can show a legitimate case where zlib will
> > consistently and notably outperform brotli, I don't see the point in
> > defini
On Sunday, June 11, 2017 11:18:03 am Eric Rescorla wrote:
> Here's what I propose to do:
[...]
> - Mandate (SHOULD-level) that servers do some sort of bounded
> (at-most-N times) anti-replay mechanism and emphasize that
> implementations that forbid replays entirely (only allowing
> retransmi
On Tuesday, July 04, 2017 07:21:44 am Ilari Liusvaara wrote:
> However, this requires
> TLS 1.2 or newer, but that should not be a problem.
>
> - The proposed ciphersuites are really bad.
Just as a clarification, all new RFCs should ideally meet all of the following
criteria:
* AEAD only
* P
On Saturday, July 08, 2017 12:38:18 am Peter Gutmann wrote:
> Andreas Walz writes:
> >different TLS implementations do not seem to agree on how to implement
> >truncated HMAC
>
> It also says something about the status of this capability if three of the
> four known implementations can't interope
On Friday, July 07, 2017 11:14:10 am Salz, Rich wrote:
> On Thursday, July 06, 2017 10:01:08 pm Dave Garrett wrote:
> > Just as a clarification, all new RFCs should ideally meet all of the
> > following
> > criteria:
> > * AEAD only
> > * PFS only
> > * TLS
On Friday, July 07, 2017 03:02:43 am Matthew Green wrote:
> https://tools.ietf.org/html/draft-green-tls-static-dh-in-tls13-01
This document uses the terms:
"Ephemeral (EC)DHE" & "Static (EC)DHE"
The 'E' stands for ephemeral. Regardless of the technical, security, political,
logistical, ethical,
This thread blew up rather quickly. Replying on a topic with quotes from
various posts, below:
On Saturday, July 08, 2017 05:09:12 am Stephen Farrell wrote:
> On 08/07/17 03:06, Ackermann, Michael wrote:
> > Converting all session traffic to clear text is not a viable
> > alternative for ANY ente
Agreed; this conversation is not going to get anything to a real WG
consensus without causing people to flee the WG. The hard sell just
makes people more and more skeptical that this is really well
intentioned. Please, let's just let this mess die. As Rich Salz has
stated previously, we should
On 10/23/2017 12:39 PM, Ackermann, Michael wrote:
2. Modifying Server, application and logging infrastructure is a huge,
expensive proposition, that executive management would not be
receptive to at all. Not to mention the logistics to follow if
they were.
I'd just like to have
201 - 235 of 235 matches
Mail list logo
