Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

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

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

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

Re: [TLS] draft-green-tls-static-dh-in-tls13-01

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

Re: [TLS] draft-green-tls-static-dh-in-tls13-01

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,

Re: [TLS] Truncated HMAC: what to do with the MAC key?

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

Re: [TLS] An IETF draft on TLS based on ECCSI public key (RFC 6507)

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 *

Re: [TLS] Closing on 0-RTT

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 >

Re: [TLS] adopted: draft-ghedini-tls-certificate-compression

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 > >

Re: [TLS] adopted: draft-ghedini-tls-certificate-compression

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

Re: [TLS] Encrypted SNI

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

Re: [TLS] Security review of TLS1.3 0-RTT

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

Re: [TLS] Better weak hash language (was Re: AD Review of draft-ietf-tls-tls13)

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

[TLS] Better weak hash language (was Re: AD Review of draft-ietf-tls-tls13)

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

Re: [TLS] AD Review of draft-ietf-tls-tls13

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

Re: [TLS] FW: New Version Notification for draft-ietf-tls-ecdhe-psk-aead-04.txt

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

Re: [TLS] secdir review of draft-ietf-tls-ecdhe-psk-aead-03

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

Re: [TLS] AD Review of draft-ietf-tls-tls13

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

Re: [TLS] Encrypted hellos (was Re: "Encrypted" SNI)

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 > > >

Re: [TLS] Encrypted hellos (was Re: "Encrypted" SNI)

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 > >

Re: [TLS] Issue #964: Shortened HKDF labels

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

Re: [TLS] Issue #964: Shortened HKDF labels

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"

Re: [TLS] WGLC: draft-ietf-tls-tls13-19

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

Re: [TLS] draft-ietf-tls-tls13-19 section 1.2 cleanup

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,

Re: [TLS] 4.1.2 Client Hello ammendment

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

Re: [TLS] WGLC: draft-ietf-tls-tls13-19

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

Re: [TLS] New Draft: Using DNS to set the SNI explicitly

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,

Re: [TLS] Comments to draft tls13-18

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

Re: [TLS] Confirming consensus: TLS1.3->TLS*

(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

Re: [TLS] Confirming consensus: TLS1.3->TLS*

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

Re: [TLS] COSIC's look on TLS 1.3

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

Re: [TLS] supported_versions question

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 >

Re: [TLS] supported_versions question

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,

Re: [TLS] New review through the TLS 1.3 Editor's Copy

On Monday, October 17, 2016 02:10:30 pm Ilari Liusvaara wrote: > > %%% Authentication Messages > > > If sent by a server, the signature algorithm MUST be one offered in the > > client's "signature_algorithms" extension unless no valid certificate chain > > can be > > produced without unsupported

Re: [TLS] Deprecating alert levels

On Monday, October 17, 2016 01:04:18 pm Martin Rex wrote: > This list is already missing the warning-level "unrecognized_name" alert, > and such a change would imply that all new/unrecognized alerts are going > to be treated as fatal forever (i.e. that no new warning-level alerts > can ever be

Re: [TLS] PR#634: Registry for TLS protocol version ID

On Wednesday, October 12, 2016 07:00:34 pm Eric Rescorla wrote: > This PR involves two changes: > > 1. Attaching the term "ID" to version and defining new enum code points. > 2. Creating a registry > > The first of these seems obfuscatory and unhelpful. The second just seems > unnecessary. Other

Re: [TLS] Industry Concerns about TLS 1.3

Mandating forward secrecy for TLS 1.3+ has been a strong consensus of this working group, so there's no point in myself or any other contributors just mass-replying with a big "no" here. That said, there is one puzzling thing I'm curious about: On Thursday, September 22, 2016 01:19:48 pm BITS

Re: [TLS] [Cfrg] 3DES diediedie

On Tuesday, September 06, 2016 04:40:30 pm Derek Atkins wrote: > Ben Laurie writes: > > An ARM is far too much hardware to throw at "read sensor/munge data/send > > data". > > > > The question is not "how much hardware?" but "price?" - with ARMs > > including h > > /w

Re: [TLS] SHA-3 in SignatureScheme

On Friday, September 02, 2016 07:32:06 am Eric Rescorla wrote: > On Fri, Sep 2, 2016 at 3:42 AM, Ilari Liusvaara > wrote: > > I also don't see why this should be in TLS 1.3 spec, instead of being > > its own spec (I looked up how much process BS it would be to get the >

Re: [TLS] Terminology clarification around SSL & TLS

On Thursday, September 01, 2016 03:17:50 pm Julien ÉLIE wrote: > There's still something I find confusing: on the one hand, SSL is badly > broken and "diediedied", it is a proprietary protocol name, and the > consensus in the TLS WG seems to be "long live TLS" but on the other > hand major

Re: [TLS] SHA-3 in SignatureScheme

On Thursday, September 01, 2016 02:30:54 pm Scott Fluhrer (sfluhrer) wrote: > > On Thursday, 1 September 2016 12:43:31 CEST Benjamin Kaduk wrote: > > > On 09/01/2016 12:38 PM, Hubert Kario wrote: > > > > The SHA-3 standard is already published and accepted[1], shouldn't > > > > TLSv1.3 include

Re: [TLS] TLS 1.3 -> TLS 2.0?

On Thursday, September 01, 2016 02:05:25 am Judson Wilson wrote: > > I like TLS/2 aesthetically, and represents a similar level of > > progress/reset that HTTP saw when it jumped from 1.1 to /2. > > What is the slash in the name all about? Is it simply playing off the HTTP > start line

Re: [TLS] TLS 1.3 -> TLS 2.0?

On Wednesday, August 31, 2016 06:42:28 pm Erik Nygren wrote: > Is it worth having a poll (hate it, neutral, love it) on options to judge > preference > It seems like options are (I may have missed some): > > - TLS 1.3 (ie, the default if we do nothing) > - TLS 2.0 > - TLS 2 > - TLS/2 > - TLS 4.0

Re: [TLS] TLS 1.3 -> TLS 2.0?

On Wednesday, August 31, 2016 06:35:13 pm Nick Sullivan wrote: > I am reluctant to endorse a name change from TLS 1.3 to TLS 2.0. I was too, until we created a new cipher suite negotiation incompatible with previous versions. > I see a few immediate issues with the proposal: > - it causes

Re: [TLS] Terminology clarification around SSL & TLS

On Wednesday, August 31, 2016 12:44:02 pm Daniel Kahn Gillmor wrote: > i would like to continue to be able to say unambiguously that all known > versions of SSL are badly broken and should be avoided. Let's not muddy > those waters further. +1 ___ TLS

Re: [TLS] TLS 1.3 -> TLS 2.0?

(replies to 4 separate but related posts, below) On Wednesday, August 31, 2016 03:52:44 am Peter Gutmann wrote: > Julien ÉLIE writes: > >Considering that possible change, wouldn't it be useful to go on working on > >draft-gutmann-tls-lts-05, and consider TLS-LTS not as a

Re: [TLS] TLS 1.3 -> TLS 2.0?

On Tuesday, August 30, 2016 02:36:51 pm Xiaoyin Liu wrote: > I support this change as long as there is no technical change (version ID > remains 0x0304). To reiterate, I am also against changing the version ID. However, I do think it's worth updating the context string version number, otherwise

[TLS] TLS 1.3 -> TLS 2.0?

I occasionally see people ask why we're calling it TLS 1.3 when so much has changed, and I used to simply think that it was too bikesheddy to bother changing at this point. However, now that we've redone negotiation, we have new TLS 1.3+ only cipher suites. The old are not compatible with the

Re: [TLS] (confusing the issues) Re: [Cfrg] 3DES diediedie

Within this line of thought, an unlimited-key-use-diediedie would have far more value. An RFC precisely defining a set of key data limits would address both this 3DES issue as well as AES and any other cipher. As cited on https://sweet32.info/ , data limits is a primary way Mozilla is dealing

Re: [TLS] Thoughts on Version Intolerance

On Thursday, July 21, 2016 06:42:52 am Hubert Kario wrote: > On Wednesday, 20 July 2016 19:30:27 CEST Martin Rex wrote: > > Any ClientHello with > 200 Cipher suite code points indicates fairly insane > > Client behaviour, so rejecting it is _perfectly_sane_ server behaviour. > > and which part of

Re: [TLS] Refactoring the negotiation syntax

On Wednesday, July 13, 2016 01:12:54 pm Eric Rescorla wrote: > The basic idea here is to factor out the TLS 1.3 negotiation into three > mostly orthogonal axes. > > - Symmetric cipher/PRF -- indicated by the cipher suite list as in TLS 1.2 > - Key exchange -- indicated by the key_shares and

Re: [TLS] Server-side missing_extension MUSTs

On Wednesday, July 13, 2016 01:01:13 pm Eric Rescorla wrote: > It's natural to pick the cipher suite first and then look for the key_share > extension, so if, for instance, you pick a PSK-only cipher suite, then you > wouldn't look for the key_share. Agreed. That's why I'm ok with the current "no

Re: [TLS] Server-side missing_extension MUSTs

On Wednesday, July 13, 2016 01:23:53 am David Benjamin wrote: > I'm also curious what cases were you envisioning missing_extension to be > useful. I spend a lot of my time triaging TLS-related bugs in Chrome, so > I'm certainly not blind to TLS handshake errors being difficult to > diagnose,

Re: [TLS] Server-side missing_extension MUSTs

On Tuesday, July 12, 2016 10:51:22 pm Eric Rescorla wrote: > I generally agree with David here. > > -Ekr > > P.S. Back in Seattle, we had rough consensus to change the alert requirements > [0] so that > you didn't have to send alerts, but if you sent an alert, you had to send > alert X. That's

Re: [TLS] Server-side missing_extension MUSTs

On Tuesday, July 12, 2016 09:58:46 pm David Benjamin wrote: > I would like to remove the missing_extension MUSTs on the server side. Full > justification in the PR. > https://github.com/tlswg/tls13-spec/pull/544 > > On the client, it is perfectly feasible to mandate a particular alert > value.

Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt

Just replying to a few points. On Tuesday, July 12, 2016 12:16:24 am Ilari Liusvaara wrote: > ### Hello Retry Request > > > selected_group > > : The mutually supported group the server intends to negotiate and > > is requesting a retried ClientHello/KeyShare for. > > {:br } > > What is

Re: [TLS] Reminders

On Monday, July 11, 2016 10:27:21 am Sean Turner wrote: > - Before 12 July, we’d like to know your thoughts about progressing > draft-ietf-tls-pwd (Watson and ekr responded): > https://mailarchive.ietf.org/arch/msg/tls/WrNa7PXTZn2ZhfmoQDA_pnUVuN4 This document defines new cipher suites using

[TLS] More hello entropy? (was: PR 508: Move downgrade sentinel to end)

On Sunday, July 03, 2016 07:02:05 pm Eric Rescorla wrote: > This seems reasonable, as the > only real argument against is that conformant TLS 1.3 servers will have > only 20 bytes of entropy when doing TLS 1.2 compat (if they put the time in > the top 32 bytes), as opposed to 24 if they randomize

Re: [TLS] Consensus call for keys used in handshake and data messages

On Monday, June 20, 2016 08:39:11 pm Eric Rescorla wrote: > Nobody seems super-excited about either Option 1 or Option 2, so it's > at least worth noting that there's one of the options I claimed was > rejected earlier, namely separately encrypting the content type in > roughly the manner

Re: [TLS] [FORGED] Re: no fallbacks please [was: Downgrade protection, fallbacks, and server time]

On Tuesday, June 07, 2016 05:08:00 pm David Benjamin wrote: > On Tue, Jun 7, 2016 at 5:06 PM Yoav Nir wrote: > > > On 7 Jun 2016, at 8:33 PM, Hubert Kario wrote: > > > On Tuesday 07 June 2016 17:36:01 Yoav Nir wrote: > > >> I’m not sure this helps. > > >>

Re: [TLS] Fwd: I-D Action: draft-lemon-tls-blocking-alert-00.txt

On Tuesday, June 07, 2016 03:57:32 pm Ted Lemon wrote: > The point of the different result codes is to give the end-user some basis > for figuring out why they didn't get to the site. "Malicious site" is > different than "policy violation." A malicious site is a site that serves > malware, or

Re: [TLS] Closing on keys used for handshake and data messages

On Friday, June 03, 2016 05:54:53 pm Joseph Salowey wrote: > Unfortunately, the TLS record framing is not easily compatible with having > multiple keys used simultaneously: because we encrypt the content type, it > is not possible to use it to determine which key to use to decrypt. We > examined a

Re: [TLS] no fallbacks please [was: Downgrade protection, fallbacks, and server time]

The idea of using an empty extension as an indicator really isn't fundamentally different from what I'm suggesting here. We'd just have an arbitrary set of new version indicators mixed in with extensions instead of inside a new generalized basket. My replacement was (again, it's over a year

Re: [TLS] Issue 472: Remove redundant warning alerts

On Saturday, May 21, 2016 06:16:39 pm Eric Rescorla wrote: > https://github.com/tlswg/tls13-spec/issues/472 > > http://tlswg.github.io/tls13-spec/#error-alerts says: > > Therefore, warning alerts are not very useful when > the sending party wants to continue the connection, and thus are

Re: [TLS] Call for WG adoption of draft-mattsson-tls-ecdhe-psk-aead

On Tuesday, April 26, 2016 11:20:40 am Hannes Tschofenig wrote: > If you are already paying the price of the asymmetric crypto (in terms > of flash usage/CPU speed/RAM utilization then just switch to a raw > public key or a certificate based ciphersuite (since there is very > little additional

Re: [TLS] TLS 1.2 Long-term Support Profile vs HTTP/2.0

On Friday, April 01, 2016 03:54:51 am Nikos Mavrogiannopoulos wrote: > On Wed, 2016-03-16 at 12:36 +, Peter Gutmann wrote: > > After a number of, uh, gentle reminders from people who have been > > waiting for > > this, I've finally got around to posting the TLS-LTS draft I > > mentioned a

Re: [TLS] call for consensus: changes to IANA registry rules for cipher suites

On Wednesday, March 30, 2016 03:20:08 pm Ilari Liusvaara wrote: > On Wed, Mar 30, 2016 at 12:05:26PM -0400, Daniel Kahn Gillmor wrote: > > On Wed 2016-03-30 11:33:09 -0400, Benjamin Kaduk wrote: > > > I am not sure that we want to be in the business of explicitly marking > > > things as insecure

Re: [TLS] Why again can't we use TLS signing certs to create short-lived sub-certs?

On Wednesday, March 30, 2016 11:22:15 am Eric Rescorla wrote: > 1. Add a "this is only usable for TLS 1.3 [or for subcerts]" extension to > PKIX. Adding a PKIX extension to mandate a minimum threshold of security configuration (e.g. PFS+AEAD w/o resumption or SHA1 or any support for TLS <1.2)

Re: [TLS] A TLS extension transfering service indication information

On Monday, March 28, 2016 09:50:13 pm Dacheng Zhang wrote: > https://datatracker.ietf.org/doc/draft-zhang-tls-service-indication-extension/ You really should not use SNI as your abbreviation, as it will just be frequently confused with the server_name extension which is already the dominant use

Re: [TLS] Ensuring consistent strength across certificate, ECDHE, cipher, and MAC

On Tuesday, March 22, 2016 08:38:13 pm Timothy Jackson wrote: > How would this group feel about a proposal to address this by specifying in > the 1.3 specification that implementations must ensure that the strength of > the certificate must be >= strength of ECDHE/DHE >= strength of the cipher?

Re: [TLS] TLS 1.2 Long-term Support Profile draft posted

On Monday, March 21, 2016 09:59:27 pm Tony Arcieri wrote: > On Mon, Mar 21, 2016 at 12:42 PM, Dave Garrett <davemgarr...@gmail.com> wrote: > > Frankly, I think this document should be renamed "Extended Support > > Profile", rather than "Long-term Supp

Re: [TLS] PSK in TLS 1.3

On Monday, March 21, 2016 06:08:45 pm Eric Rescorla wrote: > Ah, I see. Let me see if I can clear this up, if you wanted to send a PR, > that wouldn't help too. I assume you meant "wouldn't hurt" or "would help" here. ;) Dave ___ TLS mailing list

Re: [TLS] TLS 1.2 Long-term Support Profile draft posted

On Monday, March 21, 2016 10:38:43 am Hubert Kario wrote: > If your hardware really can't do anything better than 2048 bit RSA, it's > not LTS, it's a crippled embedded system, and it definitely shouldn't > get a stamp of approval "good for next X0 years" or anything similar > like a LTS

Re: [TLS] TLS 1.2 Long-term Support Profile draft posted

https://tools.ietf.org/html/draft-gutmann-tls-lts-01#section-3.2 > TLS-LTS adds a hash of the domain parameters into the master secret > to protect against the use of manipulated curves/domain parameters: > > o TLS-LTS implementations MUST include a SHA-256 hash of the EDH or > ECDH

[TLS] Splitting all stateless 0RTT into its own document (was Re: analysis of wider impact of TLS1.3 replayabe data)

(This thread has gotten long and winding, so I'm replying to these two portions bellow under a new subject. Reply after quotations.) On Monday, March 14, 2016 02:38:27 pm Bill Cox wrote: > On Mon, Mar 14, 2016 at 9:10 AM, Colm MacCárthaigh wrote: > > On Mon, Mar 14, 2016 at

Re: [TLS] AD review of draft-ietf-tls-chacha20-poly1305-04

On Thursday, March 10, 2016 02:41:58 pm Stephen Farrell wrote: > My question is: Should the WG take the opportunity to more > tightly define the key exchange parameters for these > ciphersuites? > > For example, TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256 could > REQUIRE RSA keys with >=2048 bit

Re: [TLS] Accepting that other SNI name types will never work.

Do we want to stick some simple new constraints on SNI in the TLS 1.3 draft spec? e.g. SHOULD have exactly one host_name which SHOULD be less than N bytes (significantly less than the current theoretical 64kB ceiling). Just adding a quick blurb for this in there somewhere seems like the

[TLS] Mass 0RTT of subresources with no prior knowledge (was Re: Do we actually need semi-static DHE-based 0-RTT?)

I just had an idea. There is significant doubt of how useful semi-static DHE 0RTT would be due to the difficulty of distributing the configs out-of-bound. I don't dispute this; I merely dispute that no capability is better than minimal, in this realm. There is another way that they could be

Re: [TLS] Do we actually need semi-static DHE-based 0-RTT?

On Friday, February 19, 2016 12:57:04 am Bill Cox wrote: > Having two different modes to achieve basically the same > thing in TLS 1.3 is a bad idea. On Friday, February 19, 2016 10:01:31 am Salz, Rich wrote: > I greatly prefer one way to do things. I do not fundamentally disagree. I would

Re: [TLS] Do we actually need semi-static DHE-based 0-RTT?

On Thursday, February 18, 2016 08:04:05 pm Eric Rescorla wrote: > PUBLISHED CONFIGURATIONS > The semi-static mode in principle allows the server to publish its > configuration (i.e., it's semi-static key), e.g., via DNS, which the > client can then use for 0-RTT handshakes on first contact.

Re: [TLS] WG last call of draft-ietf-avtcore-rfc5764-mux-fixes-05

Permanently gobbling up the majority of the codespace feels like excessive force here. For TLS 1.3, the first byte will always be one of alert(21), handshake(22), or application_data(23), even for custom types. The stated type for TLSCiphertext has been frozen to application_data(23) with the

Re: [TLS] Simplifying signature algorithm negotiation

On Friday, January 15, 2016 03:45:34 pm David Benjamin wrote: > This is a proposal for revising SignatureAlgorithm/HashAlgorithm. In TLS > 1.2, signature algorithms are spread across the handshake. [...] > I propose we fold the negotiable parameters under one name. [...] > 2. Remove HashAlgorithm,

Re: [TLS] Fixing TLS

On Tuesday, January 12, 2016 02:27:02 pm Bill Cox wrote: > On Tue, Jan 12, 2016 at 9:02 AM, Dave Garrett <davemgarr...@gmail.com> > wrote: > > On Tuesday, January 12, 2016 09:03:53 am Peter Gutmann wrote: > > > > I'll be the bearer of bad news and tell you

Re: [TLS] Fixing TLS

On Tuesday, January 12, 2016 03:03:42 pm Andrei Popov wrote: > On Tuesday, January 12, 2016 02:39:15 pm Dave Garrett wrote: > > I hope that Google's efforts to get QUIC as-is specced out go quickly and > > smoothly, and that it can be used as a basis to develop an official tot

Re: [TLS] Fixing TLS

On Tuesday, January 12, 2016 03:18:11 pm Eric Rescorla wrote: > On Tue, Jan 12, 2016 at 12:12 PM, Bill Cox wrote: > > I wish that were the plan (to upgrade QUIC crypto and eventually make that > > the new crypto platform). If I am not mistaken, QUICK crypto is going to >

Re: [TLS] Fixing TLS

On Tuesday, January 12, 2016 09:03:53 am Peter Gutmann wrote: > Martin's comment reminded me of the following that I've been meaning to > post... > > In a recent discussion among some crypto folks, the topic of what TLS 1.3 > could be came up. Now by TLS 1.3 I mean TLS 1.3 as a simple upgrade

Re: [TLS] MD5 diediedie (was Re: Deprecating TLS 1.0, 1.1 and SHA1 signature algorithms)

On Tuesday, January 12, 2016 12:32:08 am Viktor Dukhovni wrote: > > Also, when I say "prohibited" here, I mean _completely_. > > There is no Internet police, and the IETF does not get to prohibit > the use of MD5, we only get to write protocol standards. Of course, but the IETF can state that

Re: [TLS] What does it mean to not include 0-RTT message in the handshake hash?

On Sunday, December 27, 2015 11:55:16 pm Christian Huitema wrote: > On Saturday, December 26, 2015 9:08 PM, Dave Garrett wrote: > > On Thursday, December 24, 2015 08:08:25 pm Eric Rescorla wrote: > > > Well, this is a general requirement any time the record MAC is bad: > >

Re: [TLS] What does it mean to not include 0-RTT message in the handshake hash?

On Thursday, December 24, 2015 03:40:26 pm Christian Huitema wrote: > On Monday, December 21, 2015 6:30 PM, Martin Thomson wrote: > > On 22 December 2015 at 13:25, Christian Huitema > > wrote: > > >> Unless I'm confused (which is possible given the time of night), > > >>

Re: [TLS] What does it mean to not include 0-RTT message in the handshake hash?

On Thursday, December 24, 2015 04:48:58 pm Eric Rescorla wrote: > On Thu, Dec 24, 2015 at 4:26 PM, Dave Garrett <davemgarr...@gmail.com> > wrote: > > Do we have anything that protects against an intermediary stripping 0RTT > > messages from a handshake to force a

Re: [TLS] What does it mean to not include 0-RTT message in the handshake hash?

On Monday, December 21, 2015 09:25:44 pm Christian Huitema wrote: > > I was just going over this text today and realized it's kind of confusing > > (and the whole "handshake_hash" abstraction is starting to be less useful > > in light of the PR#316 reframing of the authentication block). > > Yes,

Re: [TLS] Explicit use of client and server random values

On Wednesday, December 16, 2015 11:12:42 am John Foley wrote: > I apologize if this topic was previously discussed, I've only recently > joined the TLS mailer list. While reviewing the TLS 1.3 draft (revision > 10), section 7 begins with the following wording: > > In order to begin

Re: [TLS] Explicit use of client and server random values

On Wednesday, December 16, 2015 04:15:00 pm John Foley wrote: > Thanks for answering my questions. Have you considered adding KAT > values for the key derivation steps? This would be helpful to > implementors. RFC5869 already has KAT values for HKDF-Extract and > HKDF-Expand. But the TLS

Re: [TLS] TLS Record Size Limitation

On Monday, December 07, 2015 04:00:54 pm Software Engineer 979 wrote: > Hello, > > I'm currently developing an data transfer application using OpenSSL. The > application is required to securely transfer large amounts of data over a > low latency/high bandwidth network. The data being transferred

Re: [TLS] Encrypted SNI

On Saturday, December 05, 2015 01:32:11 pm Eric Rescorla wrote: > Subject: SNI Encryption Part XLVIII > > Folks, > > TL;DR. > This message describes a technique for doing SNI encryption that just > requires (re)adding EncryptedExtensions to the client's first flight [0] > defining an extension

Re: [TLS] Fresh results

On Thursday, December 03, 2015 03:47:52 pm Yoav Nir wrote: > Wouldn’t it be better to mandate that if your TLS implementation supports > both TLS 1.2 and TLS 1.3 it should take actions necessary to mitigate the > bleichenbacher attack? > > In fact, if you don’t care much about very old

Re: [TLS] Encrypting record headers: practical for TLS 1.3 after all?

On Wednesday, December 02, 2015 01:00:26 pm Salz, Rich wrote: > Encrypted SNI doesn't give you the kind of protection you think that it does. > We (me and a colleague) did a pretty thorough analysis that showed this. It > was not a conclusion we expected, or wanted, to reach. It was

Re: [TLS] Fresh results

On Tuesday, December 01, 2015 02:28:49 pm Watson Ladd wrote: > https://www.nds.rub.de/media/nds/veroeffentlichungen/2015/08/21/Tls13QuicAttacks.pdf This analysis was done against TLS 1.3 draft 07 from July. It changed to RSA-PSS signatures for handshake messages in draft 09. (current is draft

[TLS] bikeshed: Forward Security or Secrecy?

Which do we like better: "Forward Security" or "Forward Secrecy"? The TLS 1.3 draft uses both interchangeably. The term is clearly in a state of flux, seeing as we've seemingly collectively agreed to drop the word "perfect" from the term, already. Personally, I prefer "security" because

Re: [TLS] Encrypting record headers: practical for TLS 1.3 after all?

Maybe I'm missing something, but hasn't this issue already been sufficiently dealt with via padding? https://tools.ietf.org/html/draft-ietf-tls-tls13-10#section-5.2.2 The record type and version fields are now frozen, and the record length field is not indicative of the real length if padding

Re: [TLS] Extensions "supported_groups" and "key_share" in TLS 1.3

On Thursday, November 26, 2015 06:02:09 pm Eric Rescorla wrote: > On Thu, Nov 26, 2015 at 2:50 PM, Dave Garrett <davemgarr...@gmail.com> > wrote: > > On Thursday, November 26, 2015 02:15:25 pm Ilari Liusvaara wrote: > > > I actually looked at the Editors's Copy

  1   2   >