On Fri, Nov 1, 2024 at 10:04 PM Christian Huitema <huitema@xxxxxxxxxxx> wrote:
On 11/1/2024 3:14 PM, John C Klensin wrote:
> --On Friday, November 1, 2024 13:36 -0700 Rob Sayre
> <sayrer@xxxxxxxxx> wrote:
>
>> Hi,
>>
>> I think the reason to encrypt everything is more innocuous.
>>
>> You get message integrity that way. This just helps prevent buggy
>> programs, as they will break right away.
> Rob,
>
> I'm sure our colleagues who spend their professional lives on
> security issues can explain this better than I can and will correct
> me if I get this wrong. With the understanding that I may not have
> the terminology quite right either, I think the answer is "no".
Actually, message integrity is a very nice side-benefit of doing
encryption.
Yep, this is what I meant, and it is a property listed at the beginning of the TLS RFC. You can always do more if you need integrity after TLS termination, though. Some people even believe there is no point in aiming for message integrity without encryption. I don't feel /that/ strongly.
I am not a Black Hat conference kind of person, but I have a lot of experience with this stuff on both sides of the connection. Some of it comes from a long time ago, when I worked on Firefox for around 5 years. I was in the airport on a work trip and the wifi was inserting ads with _javascript_ into the pages I was browsing. I just thought, ok that's it. I was embarrassed to be shipping that product, even though it wasn't the browser's fault exactly.
The wikipedia page on STARTTLS has a bunch of horror stories of just this sort, and the STARTTLS RFC (3207) is pretty clear about its limitations.
Of course, when you button this stuff up (HTTP/2, DNS, etc, always the same), some people will have a business model that relies on the traffic not being encrypted, and they will be upset. STARTTLS seems like it should be mentioned normatively, even if described with more detail in the A/S document. I think SHOULD works, since implementors can decide whether they want the properties described at the top of TLS RFC.
thanks,
Rob
