Re: [TLS] Additional changes for draft-ietf-tls-iana-registry-updates

> On Mar 26, 2018, at 18:18, Benjamin Kaduk wrote: > > IANA noted that this is effectively the > same as closing the registries in terms of the difficulty of making > further registrations, though I am not sure that the authors replied to > the question that I think I asked about what the proc

[TLS] Formal analysis of Exported Authenticators

Hi all, A number of people expressed interest in the Tamarin model we made of Exported Authenticators. For those interested, you can see the code, along with an explanatory guide here [0]. The full analysis report is a work-in-progress

Re: [TLS] Additional changes for draft-ietf-tls-iana-registry-updates

Was there a consensus to no longer accept 1.2 hash/sig alg identifiers? I don't recall that, and it clearly wasn't David's intent, as his mail to the list today shows. Seems like there's just some confusion that can be fixed with some text pointers. The registry shouldn't be closed

Re: [TLS] Additional changes for draft-ietf-tls-iana-registry-updates

On 03/26/2018 12:24 PM, Salz, Rich wrote: > Is it now impossible adding new things to TLS 1.2? I don't believe the WG > understood that this would be the situation. So I disagree with your claim > that this was our understanding of the situation. I was under the impression that the WG was well

Re: [TLS] Additional changes for draft-ietf-tls-iana-registry-updates

On Mon, Mar 26, 2018 at 1:25 PM Salz, Rich wrote: > Is it now impossible adding new things to TLS 1.2? I don't believe the WG > understood that this would be the situation. So I disagree with your claim > that this was our understanding of the situation. > > Okay, it turns out that David's neat

Re: [TLS] Additional changes for draft-ietf-tls-iana-registry-updates

Is it now impossible adding new things to TLS 1.2? I don't believe the WG understood that this would be the situation. So I disagree with your claim that this was our understanding of the situation. Okay, it turns out that David's neat hack make some things harder. So what? _

Re: [TLS] Additional changes for draft-ietf-tls-iana-registry-updates

On 03/23/2018 07:59 AM, Salz, Rich wrote: > So we have two registries that share a number space. > > Sounds like the right solution is for the registries to coordinate. > Well, there are three registries involved -- two existing one octet registries that apply to TLS 1.2 and below, and a new TLS

Re: [TLS] Problem with DTLS 1.2 handshake

On Mon, Mar 26, 2018 at 6:48 AM, Jim Schaad wrote: > Yes, I am talking about the TLS record MAC. > > > > In my case this was happening because of a misconfiguration on the PSK. > When we finally figured out that this was a MAC error on the record, then > we immediately looked at the values of the

Re: [TLS] Problem with DTLS 1.2 handshake

Yes, I am talking about the TLS record MAC. In my case this was happening because of a misconfiguration on the PSK. When we finally figured out that this was a MAC error on the record, then we immediately looked at the values of the PSK knowing that this was the most likely failure. The fa

Re: [TLS] Problem with DTLS 1.2 handshake

First, just for clarification, you mean the TLS record MAC on the Finished rather than the TLS Finished MAC, right? Assuming that is correct, then I believe this is reasonable behavior. It makes the protocol somewhat more resistant to damaged bits on the wire. Note that QUIC takes this position ev

[TLS] Problem with DTLS 1.2 handshake

I appear to have run across an implementation that does not appear to violate the specification, but which in my opinion is just plain wrong. I am doing a handshake with PSK. On the second flight from the client it sends [ChangeCipherSpec] Finished The server sees that the ChangeCipherSpec occ

Re: [TLS] Breaking into TLS for enterprise "visibility" (don't do it)

For the monitoring part, I have never felt the need to monitor anything outside the end points of the connections. If I need to decrypt packets online in order to troubleshoot it, it’s because my application is currently not providing enough information in the debug logs. And in order to consoli

Re: [TLS] Breaking into TLS for enterprise "visibility" (don't do it)

MITM as a solution doesn't scale for the needs of the enterprise. Packet decryption and inspection is needed at many locations within the data center: at many tiers of an application, within the virtual environment, and within the cloud environment, all of which may be TLS encrypted. Speaking

Re: [TLS] Breaking into TLS for enterprise "visibility" (don't do it)

To clarify for anyone who has confusion on the enterprise TLS visibility use case, I think enterprises need to be able to do out-of-band decryption anywhere in the network that they own. It would be reasonable to terminate TLS on the enterprise's Internet connection, both inbound TLS and outbou