> On 11 May 2021, at 08:46, Paul Hoffman <paul.hoff...@icann.org> wrote:
>
> On May 10, 2021, at 9:56 AM, Ben Schwartz
> <bemasc=40google....@dmarc.ietf.org> wrote:
>>
>> I don't support breaking the SvcParams into separate RRs across the RRSet.
>> This would be an extremely inefficient encoding in wire format, and would
>> conflict with the usual understanding of resource records as independently
>> meaningful alternatives.
>
> Fully agree. It is a large change in the DNS protocol for a receiver to have
> to internally group multiple RRs based on matching (priorty | target) tuples
> and make security decisions based on the group, not on the record.
>
>> It would also require a dramatic rewrite of a specification that is now
>> widely deployed.
>
> Er, screw that. The fact that some developers deployed this even though it
> hadn't even completed WG last call, much less had a wider IETF review, is a
> problem for those developers to solve.
Actually, the process problem is that record format keeps changing AFTER the
code point has been assigned and the record format THEORETICALLY been FIXED.
When you go down the template route for code point assignment that FIXES
the wire and presentation formats.
A. Submission Date: 2020-06-18
B.1 Submission Type: [ X ] New RRTYPE [ ] Modification to RRTYPE
B.2 Kind of RR: [ X ] Data RR [ ] Meta-RR
C. Contact Information for submitter (will be publicly posted):
Name: Erik Nygren
Email Address: erik+ietf&nygren.org
International telephone number: +1 617 444 3938
Other contact handles:
D. Motivation for the new RRTYPE application.
Please keep this part at a high level to inform the Expert and
reviewers about uses of the RRTYPE. Most reviewers will be DNS
experts that may have limited knowledge of your application space.
The "HTTPS" DNS RR type facilitates the lookup of information
needed to make connections for origin resources, such as for HTTPS
URLs. HTTPS RRs allow an origin to be served from multiple network
locations, each with associated parameters (such as transport
protocol configuration and keys for encrypting the TLS
ClientHello). They also enable aliasing of apex domains, which is
not possible with CNAME. By providing more information to the
client before it attempts to establish a connection, these records
offer potential benefits to both performance and privacy.
For example, the presence of an HTTPS RR indicates that clients
should upgrade insecure "http" URLs to secure "https" URLs prior
to establishing a connection.
E. Description of the proposed RR type.
This description can be provided in-line in the template, as an
attachment, or with a publicly available URL.
See https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-svcb-https-00
F. What existing RRTYPE or RRTYPEs come closest to filling that need
and why are they unsatisfactory?
(from I-D.draft-ietf-dnsop-svcb-https-00 #appendix-A)
The SRV record [RFC2782] can perform a similar function to the SVCB
record, informing a client to look in a different location for a
service. However, there are several differences:
o SRV records are typically mandatory, whereas clients will always
continue to function correctly without making use of HTTPS RRs.
o SRV records cannot instruct the client to switch or upgrade
protocols, whereas HTTPS RRs can signal such an upgrade (e.g.. to
HTTP/2).
o SRV records are not extensible, whereas HTTPS RRs can be
extended with new parameters, such as for
TLS Encrypted Client Hello keys.
G. What mnemonic is requested for the new RRTYPE (optional)?
HTTPS
H. Does the requested RRTYPE make use of any existing IANA registry
or require the creation of a new IANA subregistry in DNS
Parameters? If so, please indicate which registry is to be used
or created. If a new subregistry is needed, specify the
allocation policy for it and its initial contents. Also include
what the modification procedures will be.
Yes, per I-D.draft-ietf-dnsop-svcb-https-00#section-12:
* Create a new "Service Binding (SVCB) Parameter Registry"
with an initial population of entries. This would
be shared with the SVCB RR type.
* Add an _https entry to the DNS Underscore
Global Scoped Entry Registry.
I. Does the proposal require/expect any changes in DNS
servers/resolvers that prevent the new type from being processed
as an unknown RRTYPE (see [RFC3597])?
No. While DNS servers and resolvers may perform performance
optimizations described in the I-D, these are optional
and do not preclude processing as an unknown RRTYPE.
J. Comments:
The plan is to bring draft-ietf-dnsop-svcb-https to Working Group
Last Call during Summer 2020. A early code point allocation
for the SVCB RRtype and HTTPS RRtype is requested to enable interop
testing between multiple implementations that are in-progress.
>> As for the question of commas, I continue to believe that the current text
>> is preferable. I believe that the behavior Dick is advocating for is in
>> fact the one that was present in the draft until -02 [1], changed here [2].
>> We changed this text after receiving complaints from WG members that the
>> algorithm as specified was too complicated, along with my own experiences
>> attempting to implement it in multiple codebases that apply char-string
>> decoding during or before tokenization.
>
> This is central to the problem of SVCB: it is more complex than traditional
> DNS RRtypes, and different developers have different views of what would make
> it simpler for them to implement and/or simpler for zone operators to type
> into zone files.
>
> I hope Dick's proposed simple addition is useful. I'm not a developer, and I
> don't write into zones very often, but I suspect that "it's all in one record
> that has an addition to the parsing" will be easier and safer to implement
> than "the receiver has to handle groups of records in a new way".
>
> --Paul Hoffman_______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
