Re: Security of alternative handshakes

On Thu, Apr 22, 2021, at 14:11, Watson Ladd wrote: > With TLS 1.3 we finally added domain > separation to what is signed, but one hopes protocol X does the same > but different. Good catch Watson. This is an important assumption to state. Opened: https://github.com/quicwg/version-negotiation/iss

Security of alternative handshakes

Dear WG, After the meeting I was thinking through the security of version negotiation and I realized that there is a wrinkle with the way TLS and QUIC are layered, and proposals such as noise-QUIC. And that wrinkle is that while TLS is secure, and noise-QUIC is secure, nothing says that they are s

Re: Do we need compatible version negotiation at all? (Re: Version negotiation: the bare minimum?)

Hi, David, Christian, Thank you for your comments. 2021年4月21日(水) 23:48 David Schinazi : > Hi Kazuho, > > First, to confirm: your characterization of compatible VN matches my > understanding. > > Then, on the topic of what we need, let's start with basics. Your point > that QUICv1 has extension p

Re: Quic: the Elephant in the Room

On Wed, Apr 21, 2021 at 12:56 PM Michael Thomas wrote: > > On 4/21/21 9:46 AM, Lars Eggert wrote: > > > > I also got told that signing a zone is tantamount to "boiling the ocean". > > You're misquoting David. He said: > > > > On 2021-4-20, at 20:20, David Schinazi wrote: > >> I'm not saying that

Re: Quic: the Elephant in the Room

On 4/21/21 9:46 AM, Lars Eggert wrote: I also got told that signing a zone is tantamount to "boiling the ocean". You're misquoting David. He said: On 2021-4-20, at 20:20, David Schinazi wrote: I'm not saying that a 3-packet handshake would be bad, I'm saying that it's not worth boiling the

Re: Quic: the Elephant in the Room

Hi, On 2021-4-21, at 19:11, Michael Thomas wrote: > I am a newcomer. I came here against my better judgement as I stated on the > IETF list. I have emails from you in my IETF mail archive at least as far back as 2006. But I assume you mean that you are a newcomer to the QUIC WG. > I immediate

Re: Quic: the Elephant in the Room

On 4/21/21 7:16 AM, Lars Eggert wrote: Hi, On 2021-4-21, at 16:57, Michael Thomas wrote: And that was apparently enough to cause the chairs to go ballistic. It was not polite whatsoever. It was a first class snarl. the message that was sent said: "This thread is not discussing a QUIC

Re: Do we need compatible version negotiation at all? (Re: Version negotiation: the bare minimum?)

I'll note that there are many ways for an attacker to close a QUIC connection during the handshake: - send ICMP port unreachable - send a version negotiation packet with no real versions - send an initial with a ServerHello of the attacker's choosing - send a retry with a token of the attacker's ch

Re: Do we need compatible version negotiation at all? (Re: Version negotiation: the bare minimum?)

Maybe the first question is, do we need to support what you call "incompatible" version negotiation, i.e., the original design from 4 years ago. It was taken off the spec for a number of reasons, of which I remember two: 1) VN packets are easy to spoof by ill-intended third parties. We can pr

Re: Do we need compatible version negotiation at all? (Re: Version negotiation: the bare minimum?)

Hi Kazuho, First, to confirm: your characterization of compatible VN matches my understanding. Then, on the topic of what we need, let's start with basics. Your point that QUICv1 has extension points is true, but we've designed QUIC as a versioned protocol to allow innovation outside of the confi

Re: Please review PRs for the Manageability Draft

Thanks for progress on these drafts Mirja. I wanted to call out a key recommendation in #305 , since I think it could cause unexpected issues in the presence of NAT rebinding. I'm not sure what the best options are here, but I wanted to ensure

Re: Quic: the Elephant in the Room

Hi, On 2021-4-21, at 16:57, Michael Thomas wrote: > And that was apparently enough to cause the chairs to go ballistic. It > was not polite whatsoever. It was a first class snarl. the message that was sent said: "This thread is not discussing a QUIC-specific issue. There are more appropr

Re: Quic: the Elephant in the Room

On 4/20/21 6:27 PM, Eric Rescorla wrote: Having read the thread, I think the chairs handled this appropriately. You made a suggestion, several people, most notably David Schinazi told you why they didn't think that it was an improvement, and you responded by complaining that David didn't wan

Re: QUIC + Noise

Hi Dirkjan, Thanks for sharing this. I was aware of some of the nQUIC work presented during the EPIQ workshop in 2018 but I'm not sure we've previously discussed noise on this list. It's interesting to see that some work has continued in quinn, a summary of the delta's from earlier designs me be e

I-D Action: draft-ietf-quic-manageability-11.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the QUIC WG of the IETF. Title : Manageability of the QUIC Transport Protocol Authors : Mirja Kuehlewind Brian Trammell

I-D Action: draft-ietf-quic-applicability-11.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the QUIC WG of the IETF. Title : Applicability of the QUIC Transport Protocol Authors : Mirja Kuehlewind Brian Trammell

Re: QUIC + Noise

The prototype implementation Dirkjan mentions is related to a paper "nQUIC: Noise-Based QUIC Packet Protection" [1] that was presented at the EPIQ workshop in 2018, and which includes more details on this concept. With best regards, Robin [1]: https://eprint.iacr.org/2019/028.pdf On Wed, 21 Apr

QUIC + Noise

Since another thread (that I don't want to participate in) discussed ideas about reusing parts of the QUIC specification without relying on the web PKI, I thought I might mention that we have some experiments going on in Quinn with using QUIC with the Noise protocol. As far as I know, this has been

Re: Analysis of version negotiation

2021年4月21日(水) 16:38 Martin Thomson : > Hey folks, > > I spent a few minutes and updated this document. Part of that involved > removing another field (the most tricky one). > > The resulting protocol can be very simple in the end: > > A simple transport parameter is needed for each endpoint with

Re: Analysis of version negotiation

Hey folks, I spent a few minutes and updated this document. Part of that involved removing another field (the most tricky one). The resulting protocol can be very simple in the end: A simple transport parameter is needed for each endpoint with a list of values: the client sends all compatibl