Open Bug 1781078 Opened 3 years ago Updated 9 months ago

Firefox does not use the presence or absence of no-default-alpn

Categories

(Core :: Networking: DNS, defect, P2)

Product:
Core
Component:
Networking: DNS
Platform:
All
Unspecified
Type:
defect
Points:
7

Tracking

()

People

(Reporter: djackson, Unassigned)

References

(Blocks 1 open bug)

Details

(Whiteboard: [necko-triaged][necko-priority-next])

Draft draft-ietf-dnsop-svcb-https Section 9 states:

All the SvcParamKeys defined in Section 7 are permitted for use in HTTPS RRs. The default set of ALPN IDs is the single value "http/1.1".

We should treat any HTTPS RR without the no-default-alpn key set as including http/1.1. This is clarified by an example in 11.3.1:

  The domain owner could add this record:

   @ 7200 IN HTTPS 1 . alpn=h3

   to indicate that https://simple.example supports QUIC in addition to
   HTTP/1.1 over TLS over TCP (the implicit default).
Whiteboard: [necko-triaged]

7.1.1:

For "no-default-alpn", the presentation and wire format values MUST be empty. When "no-default-alpn" is specified in an RR, "alpn" must also be specified in order for the RR to be "self-consistent". (Section 2.4.3).

I'm unassigning myself as I won't get to this before PTO.

Assignee: djackson → nobody
Blocks: httpssvc
Priority: P1 → --
Whiteboard: [necko-triaged]
Priority: -- → P2
Whiteboard: [necko-triaged]
Whiteboard: [necko-triaged] → [necko-triaged][necko-priority-review]
Whiteboard: [necko-triaged][necko-priority-review] → [necko-triaged][necko-priority-queue]
Assignee: nobody → valentin.gosu
Whiteboard: [necko-triaged][necko-priority-queue] → [necko-triaged][necko-priority-review]
Assignee: valentin.gosu → nobody
Whiteboard: [necko-triaged][necko-priority-review] → [necko-triaged][necko-priority-next]
Flags: needinfo?(kershaw)
Points: --- → 7
Flags: needinfo?(kershaw)
You need to log in before you can comment on or make changes to this bug.