Re: [TLS] Working Group Last Call for draft-ietf-tls-tls13-18

Joseph Salowey wrote: > > This is a working group last call announcement for draft-ietf-tls-tls13-18, > to run through November 20. If possible, we would like to receive comments > on the list by November 13 so they can be discussed at the meeting in > Seoul. We hope to address any substantive issu

Re: [TLS] Working Group Last Call for draft-ietf-tls-tls13-18

If the server_name remains in plaintext and full sight in ClientHello (where it needs to be for TLSv1.2 backwards compatibility anyway), then I don't have an issue. (I'm sorry for not reading the draft in full). Eric Rescorla wrote: > >> (2) hiding of the TLS extension SNI. >> Right now it

Re: [TLS] Working Group Last Call for draft-ietf-tls-tls13-18

Ilari Liusvaara wrote: > Martin Rex wrote: >> Joseph Salowey wrote: >> >> There are two seriously backwards-incompatible changes in the >> current proposal that provide zero value, but completely break >> backwards-compatibility with existing middleware infrast

Re: [TLS] Working Group Last Call for draft-ietf-tls-tls13-18

Ilari Liusvaara wrote: >>> >>> Hiding the types does have its benefits (and it is also used for >>> zero-overhead padding scheme). >> >> Nope, ZERO benefits. But it totally breaks the middleware >> _at_the_endpoints_! > > Also, things like this should have been discussed like year or two > ago.

Re: [TLS] Working Group Last Call for draft-ietf-tls-tls13-18

Salz, Rich wrote: >> Since then, I've seen exactly ZERO rationale why the cleartext contenttype, >> which has existed through SSLv3->TLSv1.2 would be a problem. > > Because it's kind of implied in the charter, about making as much private as > possible. > >> years), because it is actively bein

Re: [TLS] Working Group Last Call for draft-ietf-tls-tls13-18

Yoav Nir wrote: > > On 3 Nov 2016, at 16:31, Martin Rex wrote: >> >> Since then, I've seen exactly ZERO rationale why the cleartext contenttype, >> which has existed through SSLv3->TLSv1.2 would be a problem. With the >> removal of renegotiation from TL

Re: [TLS] Working Group Last Call for draft-ietf-tls-tls13-18

Yoav Nir wrote: > >> On 3 Nov 2016, at 20:20, Martin Rex wrote: >> >>> With visible content type, you can tell these two flows apart. >> >> (a) so what? for those interested, one can tell such flows appart >> pretty reliably by traffic analysis.

Re: [TLS] Working Group Last Call for draft-ietf-tls-tls13-18

Salz, Rich wrote: >> the PDUs are still pretty much predictable >> heuristically (by their ordering), even when they're padded. > > ... > >> So besides being completely pointless, can you describe any realistic >> problem that is worth breaking middleware at the endpoints so badly? > > I found

Re: [TLS] Working Group Last Call for draft-ietf-tls-tls13-18

Daniel Kahn Gillmor wrote: > > Martin Rex wrote: >> >> The problem here is that this breaks (network) flow control, existing >> (network socket) event management, and direction-independent connection >> closure, and does so completely without value. > >

Re: [TLS] Working Group Last Call for draft-ietf-tls-tls13-18

Eric Rescorla wrote: > > I'm not quite following who's who in this scenario, so some potentially > stupid > questions below. > > As I understand it, you have the following situation: > > - A Web application server > - Some middleware, which comes in two pieces > - A crypto-unaware network comp

Re: [TLS] Working Group Last Call for draft-ietf-tls-tls13-18

I'm sorry for the confusion. It seems I was wrong about OpenSSL behaviour. Watson Ladd wrote: > Martin Rex wrote: >> >> If you're vaguely familiar with OpenSSL: >> when SSL_read() has received and processed a TLS record with a >> close_notify alert, do y

Re: [TLS] Working Group Last Call for draft-ietf-tls-tls13-18

Benjamin Kaduk wrote: [ Charset windows-1252 unsupported, converting... ] > On 11/09/2016 11:42 AM, Martin Rex wrote: > > Nobody so far has provide a single example of *REAL* value. > > For the hiding of ContentType to provide real value, the prerequisites are: > > > &g

Re: [TLS] Working Group Last Call for draft-ietf-tls-tls13-18

Benjamin Kaduk wrote: [ Charset windows-1252 unsupported, converting... ] > On 11/10/2016 11:13 AM, Martin Rex wrote: > > > > There is a concept called "provable correctness", and folks (such as > > those from the miTLS implementation) are using this approach

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

Christian Huitema wrote: > > I prefer TLS 1.3, because is signals continuity with the > ongoing TLS deployment efforts. As long as the awful hiding of the ContentType information in TLS Records remains in this protocol, it will *NOT* easily deploy as a replacement of TLSv1.2. I'm OK with TLS 4,

Re: [TLS] Requiring that (EC)DHE public values be fresh

Adam Langley wrote: > > https://github.com/tlswg/tls13-spec/pull/840 is a pull request that > specifies that (EC)DH values must be fresh for both parties in TLS > 1.3. > > For clients, this is standard practice (as far as I'm aware) so should > make no difference. For servers, this is not always t

Re: [TLS] Awkward Handshake: Possible mismatch of client/server view on client authentication in post-handshake mode in Revision 18

I think the issue is more about the "principle of least surprise". The client needs to know whether it offered authentication by client cert and which client cert it offered. Whether the server accepted it, and caches the accepted cert in the session or in a session ticket, is the business of the

Re: [TLS] Awkward Handshake: Possible mismatch of client/server view on client authentication in post-handshake mode in Revision 18

David Benjamin wrote: > > Post-handshake auth exists basically entirely to service HTTP/1.1 reactive > client certificate which was previously hacked on via renegotiation. I > think we should not make this feature any more complicated than absolutely > necessary to support this mode, and we should

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

Ben Schwartz wrote: > > Like a lot of people here, I'm very interested in ways to reduce the > leakage of users' destinations in the ClientHello's cleartext SNI. It > seems like the past and current proposals to fix the leak are pretty > difficult, involving a lot of careful cryptography and chan

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

Ben Schwartz wrote: > Martin Rex wrote: > >>Ben Schwartz wrote: >>> >>> Like a lot of people here, I'm very interested in ways to reduce the >>> leakage of users' destinations in the ClientHello's cleartext SNI. It >>> seems

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

Ilari Liusvaara wrote: > On Fri, Mar 10, 2017 at 09:25:41AM +0100, Martin Rex wrote: >> >> You don't understand the purpose of SNI and how the (already weak) >> rfc2818 section 3.1 server endpoint identification and CABrowser Forum >> public CA Domain vali

Re: [TLS] RFC 6066 - Max fragment length negotiation

Peter Gutmann wrote: > Thomas Pornin writes: >> >>TLS 1.3 is moving away from the IoT/embedded world, and more toward a Web >>world. This is not necessarily _bad_, but it is likely to leave some people >>unsatisfied (and, in practice, people clinging to TLS 1.2). > > I would go slightly further

Re: [TLS] Enforcing stronger server side signature/hash combinations in TLS 1.2

Fries, Steffen wrote: > > based on your reply my conclusion is that > > - there is no (standard compliant) way for a server to use a SHA256 > based certificate for server side authentication in cases where the > client does not provide the signature_algorithm extension The statement quoted by E

Re: [TLS] Enforcing stronger server side signature/hash combinations in TLS 1.2

Eric Rescorla wrote: >> >> based on your reply my conclusion is that >> >> - there is no (standard compliant) way for a server to use a >> SHA256 based certificate for server side authentication in cases where the >> client does not provide the signature_algorithm extension > > Not quite.

Re: [TLS] Enforcing stronger server side signature/hash combinations in TLS 1.2

Viktor Dukhovni wrote: > > The net effect is that in practice you simply ignore the signature > algorithms when it comes to the certificate chain. Essentially correct. This is the only reasonable, highly backwards compatible and perfectly secure choice. > > I've never seen a TLS server that has

Re: [TLS] Enforcing stronger server side signature/hash combinations in TLS 1.2

Viktor Dukhovni wrote: > > > On Mar 24, 2017, at 1:08 AM, Martin Thomson > > wrote: > > > >> I've never seen > >> a TLS server that has multiple chains to choose from for the same > >> server identity. > [ https://www.cloudflare.com/ ] > > Both chains of course use SHA256. Actually, lookin

Re: [TLS] Enforcing stronger server side signature/hash combinations in TLS 1.2

oops, typo: Martin Rex wrote: > > Actually, looking at the DigiCert issued ECC cert for www.cloudflare.com > I'm a little confused. > > This is the cert chain (as visualized by Microsoft CryptoAPI): > > server-cert: CN=cloudflare.com, ... > co

Re: [TLS] Enforcing stronger server side signature/hash combinations in TLS 1.2

Ryan Sleevi wrote: > > I would say that the vast majority of servers deployed on the Internet > using commonly publicly trusted CAs have more than one chain to choose from > - often dependent on the installed trust anchors - but the servers may > simply not be aware of it, and relying on clients t

Re: [TLS] Enforcing stronger server side signature/hash combinations in TLS 1.2

Michael StJohns wrote: > Martin Rex wrote: >> oops, typo: >> >> Martin Rex wrote: >>> Actually, looking at the DigiCert issued ECC cert for www.cloudflare.com >>> I'm a little confused. >>> >>> This is the cert chain (as v

Re: [TLS] Alert after sending ServerHello

Ilari Liusvaara wrote: >> In effect, we assume that the entire flight is processed atomically >> and generate errors based on that. Only when the entire flight is >> processed cleanly do we install keys and respond. > > My implementation processes message-by-message. So it installs the > client h

Re: [TLS] TLS RSA-PSS and various versions of TLS

Dr Stephen Henson wrote: > On 25/04/2017 15:36, Benjamin Kaduk wrote: >> >>RSASSA-PSS algorithms Indicates a signature algorithm using RSASSA- >> PSS [RFC3447 ] with mask >> generation function 1. The digest used in >> the mask generation fun

Re: [TLS] trusted_ca_keys

Salz, Rich wrote: > >> The certificate should have its own DN, use that. > > She's saying that it *doesn't.* > > SubjectDN is not unique. IssuerDN/Serial is unique, but this extension use > that. SubjectDN of a *Certificate Authority* **MUST** be unique. There is some wording in PKIX and X.50

Re: [TLS] trusted_ca_keys

Salz, Rich wrote: [ Charset windows-1252 unsupported, converting... ] > > There is some wording in PKIX and X.509 which creates the impression that a > > CA could be re-using the same Subject DName with different keys, but such > > an interpretation is a formally provable defect of the PKIX specifi

Re: [TLS] trusted_ca_keys

Salz, Rich wrote: [ Charset UTF-8 unsupported, converting... ] > > The organization info (O, L, ST, C, etc...) is supposed to differ in that > > case (CN > > is just one field of DN), rendering the full DNs distinct. > > But where and how is that enforced, or enforceable? Again, any links to sho

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

Benjamin Kaduk wrote: > > Some other editorial nits follow. > > 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. This reminds me of the specification goofs

Re: [TLS] Eric Rescorla's Discuss on draft-ietf-tls-ecdhe-psk-aead-04: (with DISCUSS and COMMENT)

Eric Rescorla wrote: > draft-ietf-tls-ecdhe-psk-aead-04: Discuss > > -- > DISCUSS: > -- > > The following text appears to have been added in -04 > >A server

Re: [TLS] Eric Rescorla's Discuss on draft-ietf-tls-ecdhe-psk-aead-04: (with DISCUSS and COMMENT)

It seems I had a typo in the new text. Martin Rex wrote: > Eric Rescorla wrote: >> draft-ietf-tls-ecdhe-psk-aead-04: Discuss >> >>

Re: [TLS] Adam Roach's No Objection on draft-ietf-tls-ecdhe-psk-aead-04: (with COMMENT)

Adam Roach wrote: > draft-ietf-tls-ecdhe-psk-aead-04: No Objection > > -- > COMMENT: > -- > > I agree with EKR's discuss -- specifying semantics for these cipher

Re: [TLS] Eric Rescorla's Discuss on draft-ietf-tls-ecdhe-psk-aead-04: (with DISCUSS and COMMENT)

Eric Rescorla wrote: > On Tue, May 23, 2017 at 9:34 PM, Martin Rex wrote: >> >> This change _still_ prohibits the server from negotiating these algorithms >> with TLSv1.1 and below. >> >> Could you elaborate a little on where and why you see a problem with this?

Re: [TLS] Eric Rescorla's Discuss on draft-ietf-tls-ecdhe-psk-aead-04: (with DISCUSS and COMMENT)

Watson Ladd wrote: >Martin Rex wrote: >> >> The suggestion to accept a recognized TLSv1.2 cipher suite code point >> as an alternative indicator for the highest client-supported protocol >> version is not really a "mechanism". It's efficient (with 0-byte

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

Ilari Liusvaara wrote: >On Wed, Jun 07, 2017 at 05:38:59AM +, Raja ashok wrote: >> Hi Victor & Alessandro, >> >> I have gone through the draft and I am having a doubt. >> >>> The extension only affects the Certificate message from the server. >>> It does not change the format of the Cert

Re: [TLS] datacenter TLS decryption as a three-party protocol

I just watched the presentation on static DH / TLS decryption in Enterprise settings of todays TLS session https://youtu.be/fv1AIgRdKkY?t=4473 and I'm seriously appalled by the amount of cluelessness in the Networking & IT Departments on the one hand, and by what seems like woefully inadequate

Re: [TLS] datacenter TLS decryption as a three-party protocol

Martin Rex wrote: > > There were a few issues with F5 loadbalancers (that were just forwarding > traffic, _not_ acting as reverse proxy) related to a borked F5 option called > "FastL4forward", which occasionally caused the F5 box to truncate TCP streams > (the box rece

Re: [TLS] Is there a way forward after today's hum?

I'm sorry, Russ, but I think this would be seriously deceiving. Russ Housley wrote: > > If a specification were available that used an extension that involved > both the client and the server, would the working group adopt it, work > on it, and publish it as an RFC? > > I was listening very car

Re: [TLS] datacenter TLS decryption as a three-party protocol

Colm MacCárthaigh wrote: > > If you maintain that draft-green is Wiretapping, then that is also the > correct term for what is happening today. Today, operators are using a > static key, used on the endpoints they control, to decrypt traffic > passively. The only difference is DH vs RSA, and I kno

Re: [TLS] 32 byte randoms in TLS1.3 hello's

Peter Gutmann wrote: > Christian Huitema writes: > >>On 7/25/2017 4:57 PM, Peter Gutmann wrote: >>> Are we talking about the same thing here? >> >>Not sure. > > OK, I'd say we are :-). This isn't about which PRNG or randomness source to > use but the need for a separation between PRNG-for-sec

Re: [TLS] 32 byte randoms in TLS1.3 hello's

Colm MacCárthaigh wrote: > Martin Rex wrote: >> >> Since you also have no idea whether and how the internal hardware design >> behind Intel RDRAND is backdoored, you should not be using any of its >> output without an at least 10x cryptographic compression in any ca

Re: [TLS] 32 byte randoms in TLS1.3 hello's

Colm MacCárthaigh wrote: > Martin Rex wrote: >> >> With RDRAND, you would use e.g. SHA-256 to compress 10*256 = 2560 Bits of >> a black-box CPRNG output into a 256-bit _new_ output that you >> actually use in communication protocols. > > If the relation betwee

Re: [TLS] RSASSA-PSS in certificates and "signature_algorithms"

Eric Rescorla wrote: > > Generally, the idea with signature schemes is that they are supposed to > reflect both the capabilities of your TLS stack and the capabilities of > your PKI verifier [0]. So, yes, if you advertise this it is supposed to > work. So, ideally we would just say that it's as Il

Re: [TLS] RSASSA-PSS in certificates and "signature_algorithms"

Ilari Liusvaara wrote: > On Tue, Sep 12, 2017 at 01:02:19PM +0200, Martin Rex wrote: >> >> A new TLS extension to convey acceptable signatures on certs would be >> needed, and for this, it would be preferable to pass along ASN.1 >> OIDs from AlgIds (not full AlgIds, t

Re: [TLS] Update on TLS 1.3 Middlebox Issues

Eric Rescorla wrote: > > two options: > > - Try to make small adaptations to TLS 1.3 to make it work better with > middleboxes. Return to the proper TLSv1.2 record format with true ContentTypes (hiding them doesn't add any security anyways). With the needlessly broken ContentTypes, we will be u

Re: [TLS] Update on TLS 1.3 Middlebox Issues

Ilari Liusvaara wrote: > > And even if the changes might not be directly consequential to > security, the changes to get through some more annoying middleboxes > might be quite annoying to implement. > > E.g. there probably are several different middeboxes that have a > configuration that actuall

Re: [TLS] Update on TLS 1.3 Middlebox Issues

Ilari Liusvaara wrote: [ Charset UTF-8 unsupported, converting... ] > On Mon, Oct 09, 2017 at 07:21:01PM +0200, Martin Rex wrote: >> >> Fixing the backwards-incompatibilities in the TLS record layer >> would be terribly useful for streaming-optimized IO layers as well, >&

Re: [TLS] Update on TLS 1.3 Middlebox Issues

Hannes Tschofenig wrote: > > On 10/10/2017 10:52 AM, Martin Rex wrote: >> Nope, none at all. I'm _not_ asking for protocol changes, just that >> the TLS handshake continues to end with CCS + HS, and ContentTypes >> remain visible. Contents of all handshake messages

[TLS] editorial error in draft-ietf-tls-rfc4492bis-17

I just noticed a strange inconsistency in section 6 of draft-ietf-tls-rfc4492bis-17 https://tools.ietf.org/html/draft-ietf-tls-rfc4492bis-17#section-6 The last of the "must implement 1 of these 4" list of cipher suites at the end of section 6 is not contained in the table at the beginning of

<    1   2