Re: Fwd: New Version Notification for draft-kazuho-quic-authenticated-handshake-00.txt

[Kazuho Oku <[e-mail]>]

Hi Mikkel,

Thank you for your comments. My responses inline.

2018年12月14日(金) 22:05 Mikkel Fahnøe Jørgensen <[e-mail]>:
>
> Some thoughts:
>
> 1. this is the only way to go both due to SNI privacy / censoring, and injection attacks.
> 2. if this is not v1, we risk a split similar to http vs https, which could defer acceptance for a decade - but OTOH there are is complexity to discuss - maybe consider a simple v1 and a better v2.

Yeah. I think we should better not delay the standardization process
of QUIC for having authenticated Initials. There is no guarantee that
ESNI would be standardized the way it is now, or if it would be
standardized in time.

> 3. depending on an external DNS service and signature design, this might be more vulnerable to gov. coercion than TLS records alone. Does this matter?

Would you mind elaborating a bit more?

I'm not sure I'm following, but I do not see the difference in terms
of vulnerability, because spoofing (or dropping) ESNI Resource Records
are as easy as attacking A (and AAAA) records.

> 4. text should consider alternative key distribution mechanisms for private networks over public networks. I.e. I don’t trust/bother with DNS, but I can install public keys at all clients, or shared symmetric keys.

Agreed. TLS 1.3 allows not only X. 509 certificates but also the use
of pre-shared keys for the handshake. QUIC supports that. Therefore,
it would make sense to define how you can extract the HMAC key from
the pre-shared keys.

> 5. I am concerned about DoS attacks on public key crypto - it may take time to verify tag.

The proposal (hereafter referred to as QUIC-AH (i.e., authenticated
handshake)) supports Retry. So the server can postpone the public key
crypto operations until validating the client address.

After that, the issue is not about the proposal, but about ESNI
requiring an additional public key operation. Servers would be
required to do that even with QUICv1 + ESNI. But anyways, I do not
think requiring three public key operations (ESNI, TLS 1.3 key
exchange, signing the CertificateVerify message) instead of two is a
security concern.

> 6. I don’t understand the initial crypto being the same as v1 - does this mean that client TP is still externally visible - shouldn’t that be avoided?

Initial crypto needs to be the same as v1 (or to be precise, it needs
to be decryptable without any key), because the the values of ESNI
extension is used for calculating the secret used for validating the
HMAC.

Regarding if other extension should be protected by the ESNI shared
secret, referring to the appendix of ESNI draft [1] might be a good
idea. Though, admittedly, some of the advantages and disadvantages
being listed in the appendix are not applicable to QUIC-AH.

[1] https://tools.ietf.org/html/draft-ietf-tls-esni-02#appendix-D

> 7. is this tied too heavily in with TLS considering other versions that might want to use more light weight crypto - e.g. version negotiation is now after public crypto, and public crypto flavour might be unfriendly to constrained devices.

Yeah my view is that for QUIC using TLS (that's what we are working
on), using ESNI keys to protect Initial packets is the correct thing
to do, because ESNI is the only pre-shared keys that are actually used
in the HTTPS use case. I do not think that QUIC-AH is more tied to TLS
than that.

> 8. The entire DNS infrastructure is in need of an overhaul, including possibly DNS over QUIC. How does that work?

The semantics of DNS is not changing. DoT, DoH, DoQ, they are all
conveyers of DNS messages that use different encodings than DNS over
UDP.

> 9. HMAC - what about new hashes like SHA-3? Yes - QUIC v1 also uses HMAC same question, same answer.
> 10. This still doesn’t address rewriting source/target IP addresses either as a replacement, or a race, in handshake and migration, so some analysis is needed to state this is a significant improvement despite of this.

I am not sure if we have an issue in relation no QUIC-AH.

My understanding is that we are mitigating post-handshake address
rewriting attacks in QUIC v1. IIUC, address rewriting attacks during
handshake is not an issue because we do not allow the peers to change
the address.

>
> Mikkel
>
> On 14 December 2018 at 03.34.20, Kazuho Oku ([e-mail]) wrote:
>
> TL;DR: Christian and I have submitted an I-D that proposes a flavor of
> QUIC v1 that uses the Encrypted SNI key to authenticate Initial
> packets. Initial packets are no longer vulnerable to man-on-the-side
> attacks; the entire handshake process becomes tamper-proof.
>
> https://datatracker.ietf.org/doc/draft-kazuho-quic-authenticated-handshake/
>
> ## Background
>
> So far, we have spent multiple efforts to make QUIC resistant to
> man-on-the-side attacks. Among them, mitigating injection attacks of
> Initial packets has been the biggest head-ache.
>
> There have been various proposals (including #2045, #2053, #2076), but
> the question has always been if it's worth the effort, because there
> are so many attack vectors (e.g. injection of a packet carrying a
> corrupt header, invalid or unknown frames, ACKs with unsent PNs,
> crafted TLS Hellos, HelloRetryRequests, crafted Version Negotiation or
> Retry packets) and it is doubtful if having mitigations for just one
> or few types of attacks are meaningful. We want to close all the
> attack vectors, however it is like building house of cards.
>
> ## The Proposed Approach
>
> The draft introduces a different approach. It relies on the Encrypted
> SNI [1]. For people not familiar with Encrypted SNI, it is an
> extension of TLS 1.3 that uses a public key distributed using DNS to
> encrypt the SNI. Encrypted SNI is currently a TLS WG draft, has
> multiple implementations, and it is already deployed by Cloudflare and
> Mozilla.
>
> The approach proposed by the draft is to use a shared secret that is
> derived from the Encrypted SNI key to authenticate the Initial
> packets, using HMAC. Because the shared key can only be calculated by
> the endpoints, an attacker cannot spoof the Initial packets. Spoofed
> packets will be detected by HMAC and will be to dropped.
>
> The draft disables Version Negotiation (because the DNS record of
> Encrypted SNI can carry a list of QUIC versions supported by the
> server), a different client-side behavior for handling Retry packets,
> and also introduces a CONNECTION_CLOSE packet to communicate handshake
> failures without affecting the transport state.
>
> And of course, it also uses a different QUIC version number in the
> long packet header field so that the Initial packets of QUIC v1 and
> the authenticated Initial packets of the proposal can be handled
> differently.
>
> Other than that, the protocol is identical to QUIC v1, including the
> handling of 0-RTT, Handshake, 1-RTT packets and the frames being
> contained by them. IMO, the differences are small and isolated well
> enough that QUIC v1 stacks can easily add support for the flavor
> proposed by the I-D.
>
> There are other benefits too. We have always hoped to have multiple
> versions of QUIC being deployed from early days in order to prevent
> ossification. The proposal makes that happen. Besides, one interesting
> aspect of the proposed protection of Initial packets is that MITM
> boxes (with root certificates) would not be possible to terminate the
> connection _unless_ they also block the distribution of Encrypted SNI
> DNS records, and that even then, the existence of such MITM boxes is
> detectable. Raising the bar of implementing and deploying MITM boxes
> as well as detecting them is beneficial for the evolution of the
> protocol.
>
> The downside of the proposal is that it only protects QUIC connections
> going to servers that provide the Encrypted SNI DNS records. But
> considering our failing attempts to address the Initial packet
> injection attacks, and considering the amount of interest we have seen
> for Encrypted SNI, I think that the proposed approach is the way
> forward.
>
> Please let us know what you think. Thank you in advance.
>
> PS. The GitHub repository of the I-D is:
> https://github.com/kazuho/draft-kazuho-quic-authenticated-handshake
>
> ---------- Forwarded message ---------
> From: <[e-mail]>
> Date: 2018年12月14日(金) 11:30
> Subject: New Version Notification for
> draft-kazuho-quic-authenticated-handshake-00.txt
> To: Kazuho Oku <[e-mail]>, Christian Huitema <[e-mail]>
>
>
>
> A new version of I-D, draft-kazuho-quic-authenticated-handshake-00.txt
> has been successfully submitted by Kazuho Oku and posted to the
> IETF repository.
>
> Name: draft-kazuho-quic-authenticated-handshake
> Revision: 00
> Title: Authenticated Handshake for QUIC
> Document date: 2018-12-14
> Group: Individual Submission
> Pages: 9
> URL:
> https://www.ietf.org/internet-drafts/draft-kazuho-quic-authenticated-handshake-00.txt
> Status:
> https://datatracker.ietf.org/doc/draft-kazuho-quic-authenticated-handshake/
> Htmlized:
> https://tools.ietf.org/html/draft-kazuho-quic-authenticated-handshake-00
> Htmlized:
> https://datatracker.ietf.org/doc/html/draft-kazuho-quic-authenticated-handshake
>
>
> Abstract:
> This document explains a variant of QUIC protocol version 1 that uses
> the ESNI Keys to authenticate the Initial packets thereby making the
> entire handshake tamper-proof.
>
>
>
>
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> The IETF Secretariat
>
>
>
> --
> Kazuho Oku
>


-- 
Kazuho Oku