Re: [TLS] TLS 1.3 - Support for compression to be removed

However, for those ClientHello’s that support older versions, the compression_method field may contain other values. This means that if a TLSv1.3 client happened to support compression for TLSv1.2, it would be unable to negotiate that via a single ClientHello. There’s no way to attempt to negoti

Re: [TLS] TLS 1.3 - Support for compression to be removed

wrote: Eric Rescorla wrote: Short, Todd mailto:tsh...@akamai.com>> wrote: However, for those ClientHello?s that support older versions, the compression_method field may contain other values. This means that if a TLSv1.3 client happened to support compression for TLSv1.2, it would be una

Re: [TLS] PR for anti-downgrade mechanism

On Oct 9, 2015, at 8:48 AM, Karthikeyan Bhargavan mailto:karthik.bharga...@gmail.com>> wrote: - There is a 1/(2^N) chance that valid connections to TLS 1.2 servers will be dropped by TLS 1.3 clients, because of this proposal. This only happens for servers that do not use the unix timest

Re: [TLS] Clarification on interleaving app data and handshake records

Hi Matt: I agree with your interpretation, in that there should be no records of any type between the CSS and the Handshake/Finished message, even during re-handshake. The full handshake (and subsequent key material) cannot be validated until the Handshake/Finished messages has been received an

Re: [TLS] PR for anti-downgrade mechanism

Does the sentinel have to be the first N bytes? RFC 5246 (S7.4.1.2) specifies Random as a combination of a uint32 time value and 28 random bytes. Rather than risk breaking backwards compatibility by changing the definition of the first 4 bytes, perhaps the sentinel can be moved to another locat

Re: [TLS] New Version Notification for draft-zhou-tls-server-redirect-00.txt

I agree with Ben here. This is very much application-layer (HTTPS) functionality being pushed down into the security (TLS) layer. HTTP(S) already has a fully functional redirect mechanism, why does this functionality need to be pushed to a lower layer? All the cases described in the Introduction

Re: [TLS] HelloRetryRequest and stateless reject

I like the idea. If the functionality is to be merged, perhaps harmonizing the names and contents of the messages (if possible)? -- -Todd Short // tsh...@akamai.com // "One if by land, two if by sea, three if by the Internet." On Oct 21, 2015, at 1:32 PM, Eric Rescorla

Re: [TLS] Controlling use of SHA-1

Fundamentally, it is up to the client (or server when doing Client Authentication) to choose whether or not to trust a received certificate chain. I am all for deprecating SHA-1 (and MD-5 and MD-2, and other weaker message digests), but “I’m not sure it’s a good idea” (SM) to force the issue in a

[TLS] Record header size?

Apologies if this has been brought up before. Has there been any consideration to changing the record header for encrypted traffic to be 4 bytes (i.e. 32-bits)? 5 bytes is a very awkward size, and some processors do not handle odd byte offsets well (it was a complaint I heard from Cisco router/

Re: [TLS] Record header size?

bytes, etc.) with additional options thrown in, not that I am proposing that. -- -Todd Short // tsh...@akamai.com<mailto:tsh...@akamai.com> // "One if by land, two if by sea, three if by the Internet." On Nov 17, 2015, at 10:40 AM, Peter Gutmann mailto:pgut...@cs.auckland.ac.nz>&g

Re: [TLS] Record header size?

I would say that 32-bits would be optimal, since that is the typical word-size of processors that need alignment. 2-bytes isn’t much better than 5-bytes in this regard. -- -Todd Short // tsh...@akamai.com // "One if by land, two if by sea, three if by the Internet." On

Re: [TLS] Record header size?

ed in hearing about the design you have in mind. -Ekr On Tue, Nov 17, 2015 at 12:59 PM, Short, Todd mailto:tsh...@akamai.com>> wrote: I would say that 32-bits would be optimal, since that is the typical word-size of processors that need alignment. 2-bytes isn’t much better than 5-

Re: [TLS] Record header size?

DPI, admittedly, is an expensive process that slows down traffic. DPI is even more expensive on a protocol such as TLS where the record headers aren't always in the same place in every packet. DPI is usually off by default on most firewalls. The problem you are more likely to encounter are TLS

Re: [TLS] Record header size?

Yes, that is true, and would accomplish the goals of backwards compatibility along with keeping (at least) 32-bit alignment. Part of my non-stated goal was to also shrink the header, but *shrug*. I still like the idea of marking it with a different version number (8.0)? -- -Todd Short // tsh...@a

Re: [TLS] Record header size?

Yes, this has to do with encrypted records. The non-encrypted handshake records are already hard enough to parse that the 5-byte header doesn’t mean much. I have worked on designs where the general-purpose processor handled the handshake and non-encrypted records, and a crypto co-processor handl

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

This brings up an interesting point; having a record length that corresponds to the TCP segment size can help hardware implementations such that they don't need to deal with scatter/gather; i.e. one TCP segment corresponds to a single TLS record. This goes along with 8 (or 4) byte record lengths

[TLS] Draft-22 and Post-Handshake Authentication

Question on Post-Handshake Authentication (PHA): PHA can occur multiple times over a connection. The description for the "Handshake Context” is as follows (4.4): | || | | Post- | ClientHello ... client | client_applica

Re: [TLS] DNS-based Encrypted SNI

Fundamentally, unless this type of protection is baked into the protocol from the beginning, and is not an add-on option, any one/thing in the path can prevent the use of optional security features. Don’t want people to access site XYZ? Block DNSSEC, block _ESNI DNS requests/responses, block th

Re: [TLS] DNS-based Encrypted SNI

(Pardon phone typos below.) -- -Todd Short // Sent from my iPhone // "One if by land, two if by sea, three if by the Internet." On Jul 6, 2018, at 4:43 PM, Eric Rescorla mailto:e...@rtfm.com>> wrote: On Fri, Jul 6, 2018 at 12:55 PM, Short, Todd mailto:tsh...@ak

Re: [TLS] WG adoption call: draft-rescorla-tls-esni

I support WG adoption. -- -Todd Short // tsh...@akamai.com // "One if by land, two if by sea, three if by the Internet." From: Joseph Salowey Date: Tuesday, July 24, 2018 at 10:18 PM To: "" Subject: [TLS] WG adoption call: draft-rescorla-tls-esni The sense of the TLS@IETF102 room was the the

Re: [TLS] inappropriate_fallback

> On Aug 9, 2018, at 9:02 AM, Matt Caswell wrote: > > > > On 09/08/18 13:56, Peter Gutmann wrote: >> ​Eric Rescorla writes: >> >>> So if the server wants TLS 1.1, then it doesn't set the bytes. >> >> If that's the case then the text that says: >> >> If negotiating TLS 1.1 or below, TLS

Re: [TLS] inappropriate_fallback

-- -Todd Short // tsh...@akamai.com // "One if by land, two if by sea, three if by the Internet." > On Aug 9, 2018, at 12:11 PM, Hubert Kario wrote: > > On Thursday, 9 August 2018 16:09:02 CEST Short, Todd wrote: >>> On Aug 9, 2018, at 9:02 AM, Matt Caswell wrote:

Re: [TLS] WG adoption call: draft-moriarty-tls-oldversions-diediedie

I support adoption. -- -Todd Short // tsh...@akamai.com // "One if by land, two if by sea, three if by the Internet." On Aug 17, 2018, at 1:32 PM, Sean Turner mailto:s...@sn3rd.com>> wrote: At the TLS@IETF102 session, there seemed to be some interest in adopting draft-

Re: [TLS] Version negotiation, take two

We already have a useless field in the record header; the record_version is fixed to { 3, 1 }; and this is not a coincidence. I think it would be better to maintain a 1.2-compatible version negotiation for backwards compatibility, and have a more robust and expressive version negotiation option.

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

Throwing my hat into the ring, the basic record protocol has not changed. If anything, what is currently referred to as TLSv1.3 is really just a major update to the handshake messages. If the record protocol were to change to use a sane 4-byte header (which I proposed many months ago), then I t

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

Hi List: 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 al., should be included. It’s difficult to wade through

[TLS] draft-ietf-tls-tls13-21: Signature algorithms definition discrepancy

In section 4.2.3 the definitions oaf the signature scheme are thus: enum { ... /* Reserved Code Points */ private_use(0xFE00..0x), (0x) } SignatureScheme; This indicates that if the first byte is 254 (0xFE) or 255 (0xFF), that is is for private use. However, in sectio

Re: [TLS] draft-ietf-tls-tls13-21: Signature algorithms definition discrepancy

This ensures we don't collide with any existing TLS 1.2 private use allocations. On Wed, Jul 5, 2017 at 1:05 PM Short, Todd mailto:tsh...@akamai.com>> wrote: In section 4.2.3 the definitions oaf the signature scheme are thus: enum { ... /* Reserved Code Points */ private

Re: [TLS] draft-ietf-tls-tls13-21: Signature algorithms definition discrepancy

That wasn’t important enough for to create a PR. I did create PR 1044 to reconcile S4.2.3 and S11. -- -Todd Short // tsh...@akamai.com // "One if by land, two if by sea, three if by the Internet." From: David Benjamin Date: Wednesday, July 5, 2017 at 1:53 PM To: "Short, Todd&qu

Re: [TLS] WG adoption call: draft-thomson-tls-record-limit

I support adoption too. -- -Todd Short // tsh...@akamai.com // "One if by land, two if by sea, three if by the Internet." On Aug 5, 2017, at 6:57 AM, Martin Thomson mailto:martin.thom...@gmail.com>> wrote: On 5 August 2017 at 06:07, Benjamin Kaduk mailto:bka...@akamai.

Re: [TLS] draft-ietf-tls-tls13-21: TLS 1.3 record padding removal leaks padding size

The application can solve this by having its own padding. If it’s going to force all messages to be padded out to 1024 bytes by TLS, why not just make that part of the application protocol? Its not as though it’s trying to save bytes here. -- -Todd Short // tsh...@akamai.com

Re: [TLS] draft-ietf-tls-tls13-21: TLS 1.3 record padding removal leaks padding size

If the plaintext length indicates a message type, then this could lead to the issue the original query posted. In that an observer might know what message type was passed. TLS padding is supposed to prevent this (but it doesn’t necessarily). However, I argue that having TLS do significant paddi

Re: [TLS] draft-ietf-tls-tls13-21: TLS 1.3 record padding removal leaks padding size

On Aug 11, 2017, at 3:19 PM, Eric Rescorla mailto:e...@rtfm.com>> wrote: On Fri, Aug 11, 2017 at 11:32 AM, Short, Todd mailto:tsh...@akamai.com>> wrote: Also as pointed out by Andrei Popov, the application needs to tell TLS how much padding to apply, so either way, the application

Re: [TLS] What counts as the same ClientHello?

Hi Noah! See below… -- -Todd Short // tsh...@akamai.com // "One if by land, two if by sea, three if by the Internet." On Aug 22, 2017, at 10:16 AM, Noah Robbin mailto:noah_rob...@symantec.com>> wrote: Section 4.1.2 of the TLS 1.3 draft RFC specifies that the ClientHel

Re: [TLS] What counts as the same ClientHello?

Hannes: The ID indicates that the two ClientHellos must be identical except for the fields explicitly listed. If you strongly disagree, then you should request a change to the ID. I understand your opinions on the matter; but as written, the ID requires those fields extensions to be the same. H

Re: [TLS] TLSv1.3 Cookies

One comment below. -- -Todd Short // tsh...@akamai.com // "One if by land, two if by sea, three if by the Internet." On Sep 13, 2017, at 10:53 AM, Matt Caswell mailto:fr...@baggins.org>> wrote: I am looking at trying to implement the TLSv1.3 stateless cookie mechanism (