Hi Willy and Amos, I think I am confused by what information is expected to go into the PP2_TYPE_AUTHORITY field and how it would be a suitable substitute for what SNI represents. Where would that information (server name?) come from outside the TLS handshake? And why is HTTP CONNECT mentioned at all in this discussion?
Again, excuse my ignorance but I just can’t seem to put two and two together. Thanks, Erik > On 2016 May 28, at 07:23, Willy Tarreau <[email protected]> wrote: > > Hi Amos, > > On Fri, May 27, 2016 at 06:39:45PM +1200, Amos Jeffries wrote: >> On 27/05/2016 2:42 a.m., Willy Tarreau wrote: >>> On Thu, May 26, 2016 at 10:20:36AM -0400, Erik Seres wrote: >>>> Hi Willy, >>>> >>>> Attached is my updated patch per your styling update request. >>> >>> Thanks Erik. I'm now CCing Dave and Amos, both of whom worked on this >>> 18 months ago. Amos requested the use of value 0x01 for ALPN and 0x02 >>> for SNI by then, though I don't know if in the end he implemlented >>> anything. Same for Dave who wanted to implement them in the protocol. >>> >>> Guys, for a bit of context, Erik proposes a patch to implement SNI on >>> PP2. If nobody implemented anything yet, maybe it's best to continue with >>> 0x23 and so on for now. Otherwise if anything was already implemented, we'll >>> stay on what was already done. Please however, do provide patches at least >>> for the doc if anything was done, as it's quite hard to have to dig through >>> e-mail archives to find the details :-/ >>> >>> Thus please just check between all of you and tell me if I apply the >>> attached patch or if we need to change the ID. We absolutely need to work >>> on this to define how to extend the protocol in the future and to register >>> new IDs... >> >> PP2_TYPE_AUTHORITY as 0x02 is already mentioned in your 1.5 and 1.6 PP >> documents. Though I have not taken the final step of using it as a >> substitute for SNI (was just about to start that actually - good timing). > > Ah thanks, I always forget that it is supposed to be equivalent to the SNI. > I searched quite a bit because I remembered it was supposed to be there but > couldn't find it. > >> AFAICT you have a good pattern started already and documented in section >> 2.2. >> <http://www.haproxy.org/download/1.6/doc/proxy-protocol.txt> >> >> There is a bit of a pattern in the registrations so far; >> - 0x0* are transport description details. >> * (protocol type, server authoruty) >> >> - 0x2* are TLS specific details. >> * (version, CN) >> >> - 0x3* namespace ?? >> >> >> Both ALPN and SNI are transport description details that have been >> essentially tacked onto TLS at the last minute. It makes sense to keep >> them separate as transport details at other levels. > > I understand. I just always forget that you justified that ALPN/SNI > made more sense in the transport layer :-) > >> The TLS layer requires SNI to be clamped to the underlying protocols >> authority value. Which means receivers will need to be verifying that >> SNI matches the PP2_TYPE_AUTHORITY value anyway. Duplicating it makes >> little sense. > > Sure. > >> One of the issues we are seeing with HTTP CONNECT messages is that there >> are already two HTTP representations of authority to correlate both up >> to TCP IP:port and down to TLS SNI. Either one being weird causes >> issues. IMO copying that duplication problem into PP2 would be a mistake. > > I totally agree. I'm pretty sure I'll ask you again next year, because > I couldn't find all the discussion on the subject :-) > > So Erik, it would be best to write that information into PP2_TYPE_AUTHORITY > (which is *not* in SSL) since it can be reused even for non-SSL protocols. > And if you're interested in implementing ALPN after it, you'll be very > welcome, and it will save me from asking Amos the same thing next time we > consider it. > > Best regards, > Willy
