Re: [Uta] ALPN recommendations in draft-ietf-uta-rfc7525bis-01

2021-09-19 Thread Christian Huitema
On 9/19/2021 3:42 AM, Julien ÉLIE wrote: Hi all, There is a piece missing. Yaron mentioned Alpaca. For that what we need to say is what Alexey might fear: application protocols MUST define ALPN labels and use them. Reading the sentence, I also understand that applications MUST check the ALP

Re: [Uta] ALPN recommendations in draft-ietf-uta-rfc7525bis-01

2021-09-19 Thread Julien ÉLIE
Hi all, There is a piece missing. Yaron mentioned Alpaca. For that what we need to say is what Alexey might fear: application protocols MUST define ALPN labels and use them. Reading the sentence, I also understand that applications MUST check the ALPN label, if that extension is used. It see

Re: [Uta] ALPN recommendations in draft-ietf-uta-rfc7525bis-01

2021-08-01 Thread Martin Thomson
On Sun, Aug 1, 2021, at 10:58, John Levine wrote: > Well, you know, ALPACA is the predictable result of three decades of > web browsers accepting any crud from > broken web servers and trying to guess what it was supposed to mean. Curious, that's not how I read it. If you look, it's non-HTTP s

Re: [Uta] ALPN recommendations in draft-ietf-uta-rfc7525bis-01

2021-08-01 Thread John R Levine
YS: some of the attacks do not depend on the client executing JavaScript, but rather on the use of cookies (bearer tokens) which can be intercepted/logged/uploaded on the server side. I don't know of bearer tokens being used in SMTP, but it doesn't look like an HTTP-only notion. Mail sessions

Re: [Uta] ALPN recommendations in draft-ietf-uta-rfc7525bis-01

2021-08-01 Thread Yaron Sheffer
On 8/1/21, 20:27, "John R Levine" wrote: > This is one way to frame the problem. Another is that TLS is (1) > typically only authenticated on the server side and (2) not > cryptographically bound to the IP or port, the combination resulting in > potential cross-protocol attacks

Re: [Uta] ALPN recommendations in draft-ietf-uta-rfc7525bis-01

2021-08-01 Thread John R Levine
This is one way to frame the problem. Another is that TLS is (1) typically only authenticated on the server side and (2) not cryptographically bound to the IP or port, the combination resulting in potential cross-protocol attacks. We as a community (inclusive of all protocols) are trying to mit

Re: [Uta] ALPN recommendations in draft-ietf-uta-rfc7525bis-01

2021-08-01 Thread Yaron Sheffer
On 8/1/21, 03:59, "Uta on behalf of John Levine" wrote: It appears that Martin Thomson said: >There is a piece missing. Yaron mentioned Alpaca. For that what we need to say is what Alexey might fear: application protocols >MUST define ALPN labels and use them. Well, you know,

Re: [Uta] ALPN recommendations in draft-ietf-uta-rfc7525bis-01

2021-07-31 Thread John Levine
It appears that Martin Thomson said: >There is a piece missing. Yaron mentioned Alpaca. For that what we need to say >is what Alexey might fear: application protocols >MUST define ALPN labels and use them. Well, you know, ALPACA is the predictable result of three decades of web browsers accept

Re: [Uta] ALPN recommendations in draft-ietf-uta-rfc7525bis-01

2021-07-31 Thread Martin Thomson
There is no binding to an IP or port. The only relevant binding here is to a TLS connection. On Thu, Jul 29, 2021, at 04:16, Yaron Sheffer wrote: > Yes, of course it would. > > Thanks, > Yaron > > On 7/28/21, 20:24, "Uta on behalf of Grant Taylor" > gtaylor=40tnetconsulting@dmarc.

Re: [Uta] ALPN recommendations in draft-ietf-uta-rfc7525bis-01

2021-07-31 Thread Martin Thomson
On Thu, Jul 29, 2021, at 00:19, Peter Saint-Andre wrote: > Yes. This text could be phrased more clearly: implementations of TLS > itself must support the ALPN extension, but application protocols can > choose to support ALPN or not. I know that this what you are trying to say, so I am not disag

Re: [Uta] ALPN recommendations in draft-ietf-uta-rfc7525bis-01

2021-07-28 Thread Yaron Sheffer
Yes, of course it would. Thanks, Yaron On 7/28/21, 20:24, "Uta on behalf of Grant Taylor" wrote: On 7/28/21 8:27 AM, Yaron Sheffer wrote: > This is about different protocol servers sharing the same IP, but*not* > the same port. There's nothing to bind the encrypted TLS con

Re: [Uta] ALPN recommendations in draft-ietf-uta-rfc7525bis-01

2021-07-28 Thread Grant Taylor
On 7/28/21 8:27 AM, Yaron Sheffer wrote: This is about different protocol servers sharing the same IP, but*not* the same port. There's nothing to bind the encrypted TLS connection to a particular port, and that's the problem addressed here Is there something that binds the encrypted TLS connec

Re: [Uta] ALPN recommendations in draft-ietf-uta-rfc7525bis-01

2021-07-28 Thread Yaron Sheffer
Hi Akexey, This is about different protocol servers sharing the same IP, but *not* the same port. There's nothing to bind the encrypted TLS connection to a particular port, and that's the problem addressed here - an IMAP client being forced to talk to an FTP server. Obviously you can have IMAP

Re: [Uta] ALPN recommendations in draft-ietf-uta-rfc7525bis-01

2021-07-28 Thread Peter Saint-Andre
Hi Alexey! On 7/28/21 7:31 AM, Alexey Melnikov wrote: > Hi, > > Section 3.8 of the draft says: >    TLS implementations (both client- and server-side) MUST support the >    Application-Layer Protocol Negotiation (ALPN) extension [RFC7301]. > > This looks fine to me. I assume it is still up to ap

[Uta] ALPN recommendations in draft-ietf-uta-rfc7525bis-01

2021-07-28 Thread Alexey Melnikov
Hi, Section 3.8 of the draft says:    TLS implementations (both client- and server-side) MUST support the    Application-Layer Protocol Negotiation (ALPN) extension [RFC7301]. This looks fine to me. I assume it is still up to application protocols to decide whether or not use of ALPN is require