On Thu, Apr 29, 2021 at 11:38 AM Stephen Farrell <stephen.farr...@cs.tcd.ie> wrote:
> > > On 29/04/2021 19:28, Salz, Rich wrote: > > To make it obvious (I thought it was): I agree, and think we need to > > make that fact more widely known. > > I think I agree but seems like ECH may add a subtlety - maybe > what we need to promote is the idea that new protocols should > define new ALPN strings, but also that intermediaries can't > depend on those to route connections as the inner and outer > ALPN values can be independent in the case of ECH (use of > which might not that visible to the application if a library > were to default to use of ECH where possible). > Correct. The purpose of ALPN in this context is to avoid cross-protocol attacks on the endpoints. Reliance on them by intermediaries is difficult absent some fairly strong assumptions about the endpoints. -Ekr > Cheers, > S. > > > > > From: Eric Rescorla <e...@rtfm.com> Date: Thursday, April 29, 2021 at > > 2:24 PM To: Rich Salz <rs...@akamai.com> Cc: Martin Thomson > > <m...@lowentropy.net>, "dns-priv...@ietf.org" <dns-priv...@ietf.org>, > > "tls@ietf.org" <tls@ietf.org> Subject: Re: [dns-privacy] [TLS] Martin > > Duke's No Objection on draft-ietf-dprive-xfr-over-tls-11: (with > > COMMENT) > > > > Probably not, but I agree with MT. > > > > The general idea here is that any given protocol trace should only be > > interpretable in one way. So, either you need the interior protocol > > to be self-describing or you need to separate the domains with ALPN. > > I don't believe that either the IP ACL or mTLS addresses this issue, > > and in fact arguably mTLS makes the problem worse because it provides > > authenticated protocol traces which might be usable for > > cross-protocol attacks. > > > > -Ekr > > > > > > On Thu, Apr 29, 2021 at 7:26 AM Salz, Rich > > <rsalz=40akamai....@dmarc.ietf.org<mailto:40akamai....@dmarc.ietf.org>> > > wrote: > >> No new protocol should use TLS without ALPN. It only opens space > >> for cross-protocol attacks. Did the working group consider this > >> possibility in their discussions? > > > > I don't believe that message has been made as public as it should > > be. > > > > _______________________________________________ dns-privacy mailing > > list dns-priv...@ietf.org<mailto:dns-priv...@ietf.org> > > https://www.ietf.org/mailman/listinfo/dns-privacy< > https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/dns-privacy__;!!GjvTz_vk!EtJaCTiH36U_bsA5vP82lZpBELKgq8908Dnb9MmdFc9M0FfjBeJMg3QwgwSs$ > > > > > > > > > > _______________________________________________ TLS mailing list > > TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls > > >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
