On Fri, Apr 24, 2020 at 11:51 AM chris - <chrispat...@gmail.com> wrote:
> > I don't think that's at all obvious. Again, the problem with the >> pseudo-header is you are authenticating some abstract information, *not* >> what is actually on the wire, and that allows the attacker to manipulate >> what's on the wire undetected. We have no analysis for the impact of that. >> > > Yes, this is the way I see it. I think you can get by with implicitly > authenticating things, but when you start doing this, the details of how to > decode the data on the wire begin to really matter for the proof (and > potentially for an attacker). This can get complicated if, as you say, the > header's content is highly variable. So, I would recommend authenticating > what's on the wire. I don't think it would hurt to authenticate more than > this, e.g., other fields that the sender and receiver need to agree on. > FWIW, if the consensus of the group were to authenticate both the "pseudoheader information" and the bits on the wire, I could potentially live with that. My rank ordering of options I consider potentially acceptable is: 1. Ban implciit CIDs. 2. Authenticate both the wire format and the abstract information. I am strongly opposed to authenticating only the abstract information. -Ekr P.S. QUIC uses the same implicit length mechanism, so we should form a common theory. > Chris P. >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
