Re: [DNSOP] Last Call: (The ALT Special Use Top Level Domain) to Proposed Standard

[Martin Thomson]

On Tue, Mar 14, 2023, at 09:44, Mark Nottingham wrote:
> I do wonder whether 'alt' is appropriate -- 'alternative' begs the 
> question of 'alternative to what?' and the answer is a technical detail 
> that most Internet users are blissfully unaware of. It seems to me that 
> it'd be better to choose something meaningful to users.

I still don't know why ".arc" never got off the ground.  An expansion of 
"alternative resolution context" addresses the DNS-centric perspective; the 
word implies OIDs, which interesting properties; and, who can resist the 
homonym, especially when there is Ark B [1].

[1] https://hitchhikers.fandom.com/wiki/Golgafrinchan_Ark_Fleet_Ship_B

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Breaking the logjam that is draft-ietf-dnsop-svcb-https

[Martin Thomson]

On Fri, Feb 24, 2023, at 05:03, Christopher Wood wrote:
> +1 to this plan. Once the ECH content is removed from this draft, the 
> authors of draft-ietf-tls-esni will work to incorporate it there as 
> necessary. 

Warren's proposed plan is good.

I'm less sure about the various options for documenting the intersection of ECH 
and SVCB (three so far have been suggested, all of which have drawbacks). This 
could be treated as a question of paper shuffling where document editors can be 
given some freedom, so I am happy to await the first proposed draft on the 
subject rather than try to litigate it here.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Ext] Questions / concerns with draft-ietf-dnsop-svcb-https (in RFC Editor queue)

[Martin Thomson]

On Thu, Sep 8, 2022, at 13:29, Brian Dickson wrote:
> If no AliasMode record was processed, then $QNAME would be the origin 
> name PLUS the prefix(es) of type attrleaf ( underscore thingies). Those 
> won't be legitimate A/ owner names (and shouldn't exist), and if a 
> client did that it would be harmful (to the client), at least a little 
> bit harmful (trying something that won't work.)

(FWIW, I had trouble parsing this last bit.)

Can the AliasMode record reference a name that includes attrleaf labels, such 
that this could be as non-functional as using the attrleaf-laden original 
$QNAME?

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] HSTS on receiving a signed HTTPS record (was: Questions / concerns with draft-ietf-dnsop-svcb-https ...)

[Martin Thomson]

On Wed, Aug 31, 2022, at 18:39, Brian Dickson wrote:
> One additional suggested addition to the end of section 3.1 is:
>>If DNS responses are cryptographically protected, and at least
>>one HTTPS AliasMode record has been received successfully,
>>clients MAY apply Section 9.5 (HSTS equivalent) restrictions
>>even when reverting to non-SVCB connection modes. Clients
>>also MAY treat resolution or connection failures subsequent
>>to the initial cryptographically protected AliasMode record
>>as fatal.
> [Brian's note: this last would provide some guidance to implementers of 
> clients: a signed HTTPS AliasMode record is a strong signal that the 
> DNS operator is discouraging fallback, albeit at a "MAY" level.]
>
> NB: The 2.4.3 change could be removed as it is mostly independent, as 
> could the last addition to 3.1. 
> The 1.2 change is very minor, is not too important but presents a 
> succinct clarification on the hostname vs domain name thing.
> The 2.4.2 change and section 3 changes together are fixes for the 
> prefix/no-prefix issue (which was basically a scrivener's error, and 
> does not change the semantics at all.) They should stay or go as one 
> unit.

I somewhat like this change, but I would generalize to receiving any signed 
HTTPS record during resolution, rather than limiting it to AliasMode.

That said, it is somewhat gratuitous.  I'd want it standardized if that was 
what was expected, but I'd prefer to defer that to an extension/follow-up.

(In case you hadn't guessed, I tend to agree with those arguing for no change 
to the spec.)

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Questions / concerns with draft-ietf-dnsop-svcb-https (in RFC Editor queue)

[Martin Thomson]

On Wed, Aug 24, 2022, at 08:30, Stephen Farrell wrote:
> Currently chromium and firefox disagree on whether ECH is
> setup correctly for one of my test pages

I'm fairly confident that that is a bug on the Firefox end.  The person looking 
into it has been on leave, but as far as I can tell the DNS and server side is 
OK.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] IANA Policy for SVCB

[Martin Thomson]

I agree with Tommy.

Selecting an expert who is able to recognize when wider review might help is a 
far lower bar than the one Ray suggests might be necessary.

On Wed, Mar 23, 2022, at 05:29, Tommy Pauly wrote:
> If this space is not extensible from non-IETF RFCs, we’ll have missed 
> the mark. The space is designed to be large (65K) to allow new work to 
> easily use this extensibility. We don’t need to be too conservative 
> with this space.
>
> I disagree that there wouldn’t be good experts — we have authors of the 
> document who have seen it through, and we have more people using this 
> RR and gaining expertise.
>
> Expert review is the right balance here.
>
> Tommy
>
>> On Mar 22, 2022, at 9:24 AM, Murray S. Kucherawy  wrote:
>> 
>> On Tue, Mar 22, 2022 at 9:10 AM Ray Bellis  wrote:
>>> I am concerned that the set of Expert Reviewers necessary to handle SVCB 
>>> needs to have both expert DNS experience *and* detailed knowledge of the 
>>> SVCB model for this to work.
>>> 
>>> I am not sure there's anybody who fits that criteria.
>> 
>> Specification Required also assumes a community that can produce them, which 
>> presumably contains the right experts.
>> 
>> Are we actually moving toward IETF Review here?
>> 
>> -MSK
>> ___
>> DNSOP mailing list
>> DNSOP@ietf.org
>> https://www.ietf.org/mailman/listinfo/dnsop
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] IANA Policy for SVCB

[Martin Thomson]

On Wed, Mar 23, 2022, at 02:45, Murray S. Kucherawy wrote:
> On Mon, Mar 21, 2022 at 2:20 AM Ben Schwartz 
>  wrote:
>> [...] any individual I-D is considered a qualified specification as soon as 
>> it is uploaded to the Datatracker.
>
> Do you have a reference that asserts this?  An I-D that isn't published 
> will expire, which would appear to contradict "permanent and readily 
> available".

There is precedent (TLS docs), but I don't know if there is a reference.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] IANA Policy for SVCB

[Martin Thomson]

I favour #3 over #2 on the basis that you can't reasonably put the "how to 
convert" text into a registry.

On Mon, Mar 21, 2022, at 20:19, Ben Schwartz wrote:
> Hi DNSOP,
>
> The latest draft of the SVCB specification says [1]
>
>>   Entries in this registry are subject to a First Come First Served
>>   registration policy ([RFC8126], Section 4.4).  The Format Reference
>>   MUST specify how to convert the SvcParamValue's presentation format
>>   to wire format and MAY detail its intended meaning and use.
>
> IANA initially approved this text, but after it was highlighted during 
> IESG review [2], IANA determined that this text is not compatible with 
> IANA policy [3] because it requires too much technical judgement during 
> registration processing.
>
> This leaves us with several possible options:
> 1. Change the MUST to SHOULD, or otherwise indicate that IANA is not 
> expected to enforce anything about the contents of the format 
> reference.  Registrations might appear without a suitable format 
> reference, resulting in keys that are difficult to parse and serialize 
> interoperably (e.g. same zone file produces different results in 
> different authoritative server implementations).
> 2. Change the registration policy to Expert Review, relying on the 
> designated expert to enforce this rule.  Registrations might be 
> processed more slowly.
> 3. Change the registration policy to Specification Required.  This is 
> similar to #2 but incorporates formal guidance about what kinds of 
> documents qualify as a "specification" (e.g. must be "permanent and 
> readily available").  Note that this is not "RFC Required": any 
> individual I-D is considered a qualified specification as soon as it is 
> uploaded to the Datatracker.
>
> Personally, I favor #3.  What do you think?
>
> --Ben Schwartz
>
> [1] 
> https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-svcb-https-08#section-15.3.1
> [2] 
> https://mailarchive.ietf.org/arch/msg/dnsop/73Pa2Dipc5uW2gdqzIvObcLRn9k/
> [3] 
> https://mailarchive.ietf.org/arch/msg/dnsop/Z62e6s0-Tmh0CC9XcS7FHRneJt8/
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
> Attachments:
> * smime.p7s

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] HTTPS upgrades (was Re: Benjamin Kaduk's Discuss on draft-ietf-dnsop-svcb-https-08: (with DISCUSS and COMMENT))

[Martin Thomson]

On Wed, Mar 2, 2022, at 14:18, Benjamin Kaduk via Datatracker wrote:
> This (mostly implicit) requirement is a potential barrier for adoption of
> the HTTPS RRtype, and while the precondition is very often going to be
> satisfied, I wanted to get a sense for whether we should make the
> requirement more explicit, and possibly more prominent in the document
> (e.g., mention it in the Introduction).  I don't know what the right
> answer is, but it seems important enough to ensure that the topic receives
> deliberate consideration.

Your point about highlighting more than loss of functionality is a good one.  
The idea that request semantics might be altered by swapping the scheme is far 
more relevant.

That said, I'm comfortable with deploying with the upgrade requirement as 
stated.  While we did have a number of examples where the assumed HTTP<->HTTPS 
equivalence did not hold in the past, the diminishing share of cleartext HTTP 
usage is overwhelmingly the vestiges that do not have any HTTPS service on the 
same name.  

As noted, those servers with a need to maintain distinct resources that differ 
only in scheme simply cannot use the HTTPS RR.  That is entirely appropriate.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] SVCB/HTTPS, ECH, and AltSvc

[Martin Thomson]

Hey,

I've just opened https://github.com/MikeBishop/dns-alt-svc/issues/326

It's a bit long and I won't repeat it here, but I don't think that the current 
state of the document is good with respect to its handling of ECH and 
alternative services.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

[Martin Thomson]

On Thu, May 20, 2021, at 11:32, Brian Dickson wrote:
> Is it one of those things that are "Well, we think we might need 
> something", or is it "We already know something we need"?

The former is definitely a factor.  Though you might reasonably say that 
defining another HTTPSv2 codepoint is feasible, that path doesn't scale 
particularly well.

For the latter, there is a fairly long list of things that don't have enough 
substance to be really defensible.

Off the cuff, we have discussed in TLS some options that would improve 
performance and reliability.  It's not clear whether those would fall into 
extension codepoints on the ECH configuration or the SVCB/HTTPS record.  In 
QUIC, we are discussing whether ALPN binds to QUIC versions and the 
implications of that.  Some versions of AltSvc designs relied on QUIC version 
indications there.  The outcome of that discussion might point toward needing 
more parameters on HTTPS for QUIC version negotiation.
 
I would have thought that the former would be sufficient in this case.  The 
fact that this space has been static an unmovable in the past has repressed a 
bunch of opportunities.  Locking this down now would return us to that state 
and would be exceedingly unwise (at least in my view).

Note that I say that as someone who generally tries to avoid creating extension 
points.  But I've been convinced that extensibility is perhaps the key feature 
that SVCB delivers.  I'm surprised to find that you think otherwise.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

[Martin Thomson]

On Thu, May 20, 2021, at 11:08, Paul Wouters wrote:
> This discussion should be around reasonable and secure wire and
> presentation formats, not about "but we already deployed this".
> It should surely be taken into account if changing at this point
> gives enough benefits, but the idea of changing should not be
> dismissed out of hand.

Fair point.  I would request that if changes are made, then a new codepoint is 
used.  I think that is a reasonable request.  If that means that this codepoint 
is now burned and unusable; and that is a problem due to a scarce supply, then 
maybe more care is needed in future about early allocations (I agree that this 
one was premature).

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

[Martin Thomson]

On Thu, May 20, 2021, at 10:35, Brian Dickson wrote:
> I was under the impression that the extensibility is for the SVCB type, 
> and not strictly needed for HTTPS.

It is absolutely needed for HTTPS.

I also want to add to what Tommy (P) said about deployment.  We've deployed the 
current wire format (that's what you get when you assign a codepoint people!)  
Changes would have serious implications.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] SVCB without A/AAAA records at the service name

[Martin Thomson]

My apologies here, I think that I misunderstood the structure of the proposed 
algorithm originally, however, that might be an opportunity to improve the 
description.

My conclusion here is not the same as yours.  If you require SVCB, you might 
need a different algorithm, or at a minimum you need to run the math (as you 
have) for whether you will get a TargetName and whether the TargetName will be 
"." before considering the optimizations you are promoting.

If you use HTTPS as the example, the algorithm, as described, is completely 
reasonable.  But HTTPS is weird.  If you are looking at a new protocol 
deployment, other factors, such as compatibility with HTTPS deployments, might 
change those numbers considerably.  That is, P_svcb in this alternative setting 
is 1.  If we were to do this for a protocol that was allergic to HTTPS - SMTP 
is probably a bad example because MX exists, but imagine a similar deployment 
arrangement - the result might be that the probability of there being a 
TargetName in the record is closer to 0 due to the prevalence of outsourcing of 
serving.  At that point, you might decide not to spend the cycles on A/ 
queries.

HTTPS is also weird in the sense that it is so aggressively latency sensitive.  
Even if P_targethost was extraordinarily low (maybe not 1%, but we've wasted 
cycles on gains with far worse odds), we'd still probably spend the effort on 
it.

So I think that you have this entirely backwards.   The concurrent querying of 
SVCB and A/ is some combination of an optimization and unique to the one 
worked example we have.  Acknowledging that might allow the draft to be much 
clearer about the logical structure of the process clients follow AND make it 
clearer where the optimization opportunities are and how clients might 
reasonably decide to take advantage of them.  Then you can explain how 
different deployment choices (such TargetName == ".") might further take 
advantage of those optimizations.

As it is, the algorithm is presented as being definitive, but it really isn't.  
What you have is the optimized version of the algorithm, with no real 
acknowledgment that alternatives might exist.

--Martin




On Wed, Jan 27, 2021, at 06:59, Ben Schwartz wrote:
> I'd like to try to get to consensus on this point, which is one of the 
> last open issues for the draft.
> 
> To restate my previous argument, let P_svcb be the probability that a 
> SVCB record is present, and if so, let P_targethost be the probability 
> that it contains a TargetName that is the hostname.  Then (ignoring 
> Additional Section processing) the initial /A query saves (1 - 
> P_svcb) + P_svcb*P_targethost resolver roundtrips, on average.  
> 
> Currently, for HTTPS, P_svcb is about 15%(!), and P_targethost is 
> ~100%*, so this always saves one resolver roundtrip.
> 
> For a SVCB-reliant protocol, P_svcb is 100%, so the formula simplifies 
> to "P_targethost".  If P_svcb for HTTPS were to approach 100%, the 
> result would be the same, even though HTTPS is not SVCB-reliant.
> 
> In other words, keeping P_targethost high, and using speculative 
> queries, is good for performance when SVCB is heavily used.
> 
> * Assuming Cloudflare has the only current large-scale deployment of 
> HTTPS records.
> 
> On Tue, Jan 19, 2021 at 10:00 PM Ben Schwartz  wrote:
> > 
> > 
> > On Tue, Jan 19, 2021 at 7:40 PM Martin Thomson  wrote:
> >> On Wed, Jan 20, 2021, at 09:17, Ben Schwartz wrote:
> >> > As I noted in that discussion, the client generally doesn't know in 
> >> > advance that they aren't needed.  
> >> 
> >> I am asserting that the client very much knows.  Indeed, it has to know.  
> >> If we define a new protocol that relies on SVCB and that protocol is able 
> >> to use SVCB exclusively (which would be a good thing in my view, all this 
> >> parallel DNS querying is unnecessary, even if the DNS protocol is pretty 
> >> good at it), then a client can very much know.
> > 
> > Querying in parallel is of course just an optimization, but the client 
> > can't obviously know that those queries won't be needed, even for a 
> > protocol that uses SVCB exclusively.
> > 
> > Every SVCB mapping ultimately relies on A/ records for the ServiceMode 
> > TargetName.  The client doesn't know what that TargetName will be until it 
> > gets the SVCB response.  However, in every protocol considered thus far, 
> > the most likely TargetName is the original hostname (or its CNAME alias).  
> > By querying that name in parallel, the client can short-circuit a 
> > subsequent lookup and reduce latency.  This has nothing to do with fallback.
> > 
> > Section 10.2 ("Structuring zones for performance") takes this ob

Re: [DNSOP] SVCB without A/AAAA records at the service name

[Martin Thomson]

On Wed, Jan 20, 2021, at 09:17, Ben Schwartz wrote:
> As I noted in that discussion, the client generally doesn't know in 
> advance that they aren't needed.  

I am asserting that the client very much knows.  Indeed, it has to know.  If we 
define a new protocol that relies on SVCB and that protocol is able to use SVCB 
exclusively (which would be a good thing in my view, all this parallel DNS 
querying is unnecessary, even if the DNS protocol is pretty good at it), then a 
client can very much know.

> Another thing I like about the arrangement in #288 is that it 
> simplifies a protocol-independent app/library boundary.  The app can 
> say "SVCBQuery(hostname, prefixes)" and get back a fully resolved 
> object like {svcbEntries: [{...}, ...], hostIPs: [...]}.  

I'm suggesting that the interface might be a little wider.  If the interface is 
provided with a scheme, them the library might be able to lookup the scheme and 
know whether A/ is needed, but it might be better to have a very different 
interface for those protocols that might need fallback as opposed to those that 
don't.

A protocol might genuinely need SVCB.  If additional SVCB information is 
critical to the operation of the protocol (think ECH here, but there might be 
other reasons for this), then the API might look like (eliding the attr-leaf 
and prefixing stuff):

svcb.query(name) -> svcbEntry[] // where the API fills in an address (or 
addresses) for each svcbEntry

This is far more ergonomic for something that doesn't care about A/.  And 
less wasteful.  If a fallback is possible, then you get something very 
different, which requires additional logic to handle:

svcb.query_with_fallback(name) -> Either

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] SVCB without A/AAAA records at the service name

[Martin Thomson]

On Wed, Jan 20, 2021, at 02:09, Ben Schwartz wrote:
> I think #288 is quite "specific" about what happens in that case.  
> (Whether it's "sensible" is a separate question.)

Sorry, I was talking mostly about #299, which has the problem I identified.

The problem with #288 is that it doesn't say that the A/ queries aren't 
made if they aren't needed.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] SVCB without A/AAAA records at the service name

[Martin Thomson]

On Sat, Jan 16, 2021, at 06:01, Ben Schwartz wrote:
> FWIW, I think this is really an editorial question.  
...
> https://github.com/MikeBishop/dns-alt-svc/pull/288
... 
> https://github.com/MikeBishop/dns-alt-svc/pull/289

Neither of these work for me.  Both do the same thing in different ways.  Both 
are unspecific about what changes might be made to the algorithm.  That leads 
to far less certainty about how the information is consumed than I think is 
sensible.

What I'm looking for here is for the specification to describe what happens 
when the protocol needs to fall back to A/ and what happens when it does 
not.  The first is important, because that is what HTTP will need.  The second 
because I think that is a better approach for any new protocol (I had hoped 
that webtransport would be able to take advantage of this, but they made a 
different choice for reasons I'm yet to understand).

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] SVCB without A/AAAA records at the service name

[Martin Thomson]

As requested (I'm not engaged here enough to understand the terms of 
engagement, so my apologies for using an interaction form I'm accustomed to), 
moving discussion from https://github.com/MikeBishop/dns-alt-svc/issues/287 to 
here:

The SVCB draft basically mandates a fallback to A/.  I think that this is 
not universal and that this should instead be made an option.

For HTTP, the fallback is necessary.  For a new protocol, a fallback could be 
undesirable.  Especially if you want to deploy that protocol using a service 
name on which you have already deployed HTTP.  If you don't want your HTTP 
servers getting connection attempts for the new protocol, the fallback is more 
nuisance than useful.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] Fwd: [TLS] Authenticating incompatible protocols

[Martin Thomson]

FYI, in particular for those who are following the SVCB work.

The lack of authentication for the results of SVCB discovery were a concern for 
me.  I am not entirely comfortable with the idea that we are shipping a 
protocol without any real protection against downgrade attack.  So I wrote up a 
rough draft.

My initial thinking was that this was general enough that TLS is the right 
venue, but I can also see reasons for having some discussion here.

- Original message -
From: Martin Thomson 
To: t...@ietf.org
Subject: [TLS] Authenticating incompatible protocols
Date: Tuesday, July 14, 2020 11:21

The work in DNSOP on the SVCB record raised a few awkward questions about the 
potential for downgrade attacks.  Where protocols aren't compatible -- that is, 
A is not compatible with B if you can't attempt A and negotiate B -- you don't 
get downgrade protection.  ALPN only really protects against downgrades with 
compatible protocols.

With QUIC, and increasing diversity of protocol usage across TLS and DTLS, 
there are more opportunities for incompatible protocols to be used.

I've done a quick writeup of something that might work:

https://datatracker.ietf.org/doc/draft-thomson-tls-snip/
https://martinthomson.github.io/snip/draft-thomson-tls-snip.html

Thoughts would be appreciated.

As a footnote: this makes some assumptions about the way that ALPN is used.  
That is, this relies on the same ALPN not being used in incompatible protocols. 
 The ALPN registry already lists one counterexample in stun.turn [RFC7443] 
which can be used over both DTLS and TLS.  I personally think that was a 
mistake, but I know that others disagree.

___
TLS mailing list
t...@ietf.org
https://www.ietf.org/mailman/listinfo/tls

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Ext] Call for Adoption: draft-belyavskiy-rfc5933-bis

[Martin Thomson]

On Fri, Jun 19, 2020, at 01:30, Paul Hoffman wrote:
> It might be better, and faster, for this WG to adopt a one-paragraph 
> draft that makes the DS registry "RFC required", like the other 
> DNSSEC-related registries.

I think you mean "Specification Required".  RFC required has the same net 
effect, but the side effect being that you burden the ISE with these requests.

As long as the space of codepoints isn't too small (2^16 is fine), then I see 
no reason not to allow external publications request a value as long as they 
don't abuse the privilege.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Call for Adoption: draft-belyavskiy-rfc5933-bis

[Martin Thomson]

On Wed, Jun 17, 2020, at 04:49, Dmitry Belyavsky wrote:
> I don't think there are good or bad time periods to adopt nation-wide 
> crypto profiles. For me, the difference between the GOST profile and 
> hypothetical Korean or German profile is close to zero, and if anybody 
> brings such a profile for standardization, I'd like to support it.

I agree with Olafur on this.  The reason we standardize is so that we can have 
a single - ideally very small - set of algorithms that are widely implemented.  
Because you want every one of those algorithms in every implementation.

In a system like the DNS, you can't really limit the people who might need to 
consume your signature, so the set of acceptable signing algorithms needs to be 
small.  Ideally you have just two: one that is established, and one that is 
new; or one using one technique and a backup using a different technique.

TLS has mostly gotten this part right.  We're much closer to the point of 
having just two in TLS 1.3.  There are a few algorithms that exist to address 
narrow application domains (IoT, *cough*), but at least you can make a case for 
TLS deployments in a closed environment.  For that case, TLS allows for 
codepoint allocation, but avoids an IETF recommendation for those algorithms.  
I don't think that DNS needs that same capability; deciding based on whether 
algorithms are good for global system is the only relevant criterion.

If we all agree that GOST is superior to RSA (it probably is) and EdDSA (I 
doubt it, but I don't have an opinion), then adoption to replace an existing 
algorithm would be fine.  That didn't happen last time, so that suggests it 
would be better for RFC 5933 to be deprecated entirely.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] RDBD (Related Domains By DNS)

[Martin Thomson]

On Wed, Mar 4, 2020, at 06:11, Brotman, Alex wrote:
> https://datatracker.ietf.org/doc/draft-brotman-rdbd/

As I think I mentioned before, there is similar work going on at higher layers 
of the stack.  See https://github.com/krgovind/first-party-sets

That work acknowledges a number of things, most critically what policy 
decisions might be made as a result of these declarations.  The policies that 
are bound to these declarations could determine the shape of the design.

In that work, the question of whether declarations can be trusted has turned 
out to be a massive problem.  The relevant policy being contemplated is the 
sharing of Web state (e.g., cookies).  In that context, there are incentive 
structures in place that lead to the strong possibility that some entities 
would willingly declare a "relationship" with others just to circumvent certain 
aspects of applicable policies.  That in turn means that the design of the 
system has to take this style of abuse into account.

To me, that indicates that knowing something about the policies that would be 
applied is not incidental to the work.

Separately, it appears as though there is no ready means of disavowal other 
than expiration of the records.  Having a means for repudiation of declarations 
would be good.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] QUIC and udp options

[Martin Thomson]

On Fri, Feb 14, 2020, at 05:56, Paul Vixie wrote:
> something of this form will likely be created, in order to support quic, a 
> new 
> udp based transport protocol which is expected to be used by http/3.

Not wanting to distract from Paul's request for consideration of the UDP 
options draft.  However, this point seems to be a stretch.  This has only been 
discussed very briefly on the QUIC mailing list in relation to a non-working 
group proposal.  From my perspective, I don't see QUIC creating a dependency on 
UDP options in any way.  So "will likely" is really only speculation.

I suggest that if you are interested in this topic we take this to the QUIC 
list.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] RDBD draft updated

[Martin Thomson]

There's an interesting (web-only) effort looking at a similar problem: 
https://github.com/krgovind/first-party-sets  There, the goal is to establish 
commonality for the purposes of sharing state (and fate).

A great counter-example in that case is the relationship between github.com and 
github.io, which are administratively the same, but purposefully distinct from 
the perspective of web state.  

All this makes me wonder what your intent is with respect to semantics.

   o  0: states that no relationship exists between the domains

   o  1: states that some relationship exists between the domains

That's incredibly vague.

If you consider the possibility of there being richer expressions of semantics, 
this starts to look a bit like link relations at the DNS layer: 
https://tools.ietf.org/html/rfc8288

On Tue, Oct 1, 2019, at 07:17, Stephen Farrell wrote:
> 
> Hi all,
> 
> As per discussion at IETF 105, Alex and I did some more
> work on the RDBD draft (lots of text edits and a bit of
> prototyping) and have posted a new version. [1]
> 
> We'd be very interested in folks' opinions.
> 
> Thanks,
> Stephen & Alex.
> 
> [1] https://tools.ietf.org/html/draft-brotman-rdbd-03
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
> 
> Attachments:
> * 0x5AB2FAF17B172BEA.asc
> * signature.asc

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] I-D Action: draft-ietf-dnsop-alt-tld-12.txt

[Martin Thomson]

> Abstract:
>This document reserves a string (ALT) to be used as a TLD label in
>non-DNS contexts.  It also provides advice and guidance to developers
>developing alternative namespaces.

In discussion, the alternative name .arc was proposed as short for "alternative 
resolution context".  Unless the intent was a direct invocation of the best 
parts of Usenet, in which case carry on.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Ext] Call for Adoption: draft-sah-resolver-information

[Martin Thomson]

On Sun, Aug 4, 2019, at 00:37, Paul Hoffman wrote:
> > I think that I might have said this before, but I don't think that asking 
> > an HTTP server about a DNS server is the right solution.  
> 
> It is not "the" right solution, but it is one of them. That's why there 
> is also a DNS-based solution in the same document.

Let me be slightly more pointed then.  I think that documenting a solution that 
has one protocol speak for another would be a bad idea.  Even if there is a 
better way to do the same thing in a "better" way.
 
> > For connection-oriented interactions, having the information associated 
> > with a connection (and not a server identity) would be even better.
> 
> Not sure what you mean by "connection-oriented interactions". DNS is 
> not connection-oriented at all.

Neither is HTTP, but it uses connection-oriented interactions: TCP connections. 
 There is still a strong desire in HTTP to retain the stateless nature of the 
protocol, but we have cracked that open slightly.  Building some ability to 
talk directly to the next hop in a limited fashion, as we are now able to with 
HTTP/2, has some real benefits.
 
> > The RESINFO RRtype seems OK, but I have less confidence in my ability to 
> > assess that aspect of this.  The only thing that bothers me is the 
> > potential for 1.0.0.10.in-addr.arpa and friends to leak and ruin the 
> > protocol for everyone.  
> 
> Please say more here. Who do you think would be publishing at 10.0.0.1? 

A good proportion of the resolvers I talk to operate from 1918 space, how else 
would they advertise this information?  I don't care if they are merely 
proxies, and nor should it matter if they are.

The fact that they are proxies means that my ISP is likely going to be the one 
fielding RESINFO queries for 10.0.0.1 and friends.

> If the WG finds this to be too much of an edge case, we can certainly 
> eliminate the inventory, but it feels to me that requiring that every 
> response always contain every known name-value pair is onerous.

The sort of filtering you are contemplating isn't supported by the protocol you 
define.  It's also quite a bit more complicated to specify and build.  If there 
is a need for subdivision for performance reasons, which would have to be 
proven, there might be better ways to approach this.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Call for Adoption: draft-sah-resolver-information

[Martin Thomson]

On Sat, Aug 3, 2019, at 01:04, Tim Wicinski wrote:
> This starts a Call for Adoption for draft-sah-resolver-information

I think that I might have said this before, but I don't think that asking an 
HTTP server about a DNS server is the right solution.  If this is information 
about the operation of a participant in the DNS protocol, then I think that 
this needs to use the DNS protocol. For connection-oriented interactions, 
having the information associated with a connection (and not a server identity) 
would be even better.

This also bakes in the notion that a DNS resolver is identified by IP address.  
The domain name part is probably OK, but I don't know which trust anchors to 
use.  I think that the document is assuming that we'll use the Web PKI, but it 
doesn't say that (nor does RFC 8310, as far as I can tell).  If you can answer 
the question "why not DANE?" then you might start to understand my concerns 
here.

The RESINFO RRtype seems OK, but I have less confidence in my ability to assess 
that aspect of this.  The only thing that bothers me is the potential for 
1.0.0.10.in-addr.arpa and friends to leak and ruin the protocol for everyone.  
I realize that there are no good solutions here, but it would be good if there 
were a little more clarity on the constraints this group thought applied to the 
design.

The inventory thing is fairly irregular.  The names of fields are right there 
already, why insist on repeating them in an array?

With all that, I think that it would be premature to assume that this is the 
right direction.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] re original_transport indicator

[Martin Thomson]

On Sat, Apr 7, 2018 at 9:29 AM, Paul Vixie  wrote:
> my original design added an http header, which was seen as even worse.
> someone suggested adding to the content-type, and i went along with it even
> though there is no difference in actual type of actual content.

A header field isn't all bad.  At least from my perspective, anyway.
That said, it is true that adding to the content is a better choice.
I appreciate that this isn't a great fit in this case.

> i am generally supportive of this approach; in fact i wish i'd thought of
> it. the specifics will be different, as in:
>
> /proxy_dns?proto=tcp
> /proxy_dns?proto=udp

/request{?dns}{?proto} is the way you would write that.

> i object, as before, to "dns-udpwireformat" as a name. these are dns
> messages, which when carried by udp are raw, and when carried in tcp are
> preceded by a two-octet length indicator for framing of multiple messages
> sharing the same stream. so, the string to be registered should be
> "dns-message".

I agree with this principle, and have expressed similar concerns with
the name.  However, I just checked the media type registry [1] and I
think that a better choice is message/dns.  Just like message/http and
message/sip.

[1] https://www.iana.org/assignments/media-types/media-types.xhtml#message

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] re original_transport indicator

[Martin Thomson]

+1 to this.

And maybe there is an outcome that doesn't need this parameter.  I
probably misunderstood some of the expectations people have for the
parameter.  With the benefit of time and sleep, it's possible that I
now understand the disconnect.

My model of content-type - and by extension its parameters - is of a
description of the content.  However, it appears as though at least
some people had different uses for the parameter: for requests, it
would be an instruction/suggestion to the server to make a DNS request
using the identified transport; for responses, it would be a
description of where the DNS request came from.

I never considered that interpretation, but - assuming that this is
what it was - and the intent was to provide a means for the client to
control how the server makes requests (and to see how they were made).
In that case, I have a possible alternative design for the use case in
the dnsop draft.

Right now, DOH doesn't really say how a DNS API Server gets its
responses.  It could be that the API server is part of a resolver, or
it could be that the DNS API Server makes a request to another
resolver.  But specific uses of the DOH protocol could come with
additional constraints that would enable the use cases in the dnsop
draft, at least as I understand them.

If the goal of the dnsop draft is to extend the reach of a DNS client
(note: not a DNS API client) across a network that is in some way less
hostile to HTTP than it is to DNS, then I think that it can still use
DOH.  A DNS API server could be configured to operate in a very simple
mode with no caching, just direct transposition of a request from HTTP
to a request on UDP or TCP.  A DNS client could be configured with two
DNS API clients.  Each client uses a different DNS API Server
endpoint.  Those endpoints would be specifically configured to use
only UDP or TCP.

For instance:
https://use.only/tcp{?dns} would cause the server to make a request using TCP.
https://use.only/udp{?dns} would cause the server to make a request using UDP.

At this point, this is simple DOH, but with extra contextual
information about server operation.

The concerns about the requirement for HTTPS is a relevant concern.
If there are cases where an unprotected HTTP connection carrying DNS
is expected to traverse a network without modification where DNS
encounters difficulty, maybe the dnsop draft can concentrate on that
particular aspect of this.  I don't think that the suggestion in DOH
to use HTTP/2 is a problem; DOH permits the use of any version of
HTTP.

On Fri, Apr 6, 2018 at 6:53 AM, Patrick McManus  wrote:
> Hi All,
>
> We've had quite a thread re the -05 optional parameter to the
> dns-udpwireformat registration.
>
> The parameter is defined as having no meaning for DoH, but was included to
> accommodate a use case the dnsop wg is considering. Future proofing, if you
> like.
>
> Upon consideration (and a read of 6838), I think including this in doh is
> premature because Media Type registrations can be updated by mechanisms laid
> out in RFC6838 and in this case such an update could occur without impacting
> existing DoH deployments. (i.e. it does not need to be future proofed).
>
> Therefore the definition of the parameter should accompany the work that
> makes use of it if a future standards document chooses to go down that path.
> As a bonus we avoid unused clutter if it doesn't happen. I also get the
> feeling that there isn't yet strong consensus on the anticipated use case or
> the exact form it needs to take - we should let that process work itself out
> separately before registration.
>
> I've chatted with Paul, and our recommendation is to remove the
> original_transport parameter from DoH and encourage dnsop to update the
> registration if/when a different standard needs to make use of it.
>
> thoughts?
>
> -Patrick
>

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Doh] [Ext] Re: Alternate proposal for transport indication in draft-ietf-dnsop-dns-wireformat-http

[Martin Thomson]

On Thu, Apr 5, 2018 at 2:42 AM, Paul Vixie  wrote:
> that would be low fidelity. i need to run clients whose internet experience
> will not be influenced by middleboxes.

So don't include the middlebox in your communications.  It's all the
rage nowadays.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Ext] Re: [Doh] Alternate proposal for transport indication in draft-ietf-dnsop-dns-wireformat-http

[Martin Thomson]

On Tue, Apr 3, 2018 at 11:27 PM, Paul Hoffman  wrote:
> Martin: Are you saying that you want DOH to remove the optional parameter 
> from the application/dns-udpwireformat registration? If so, what do you 
> propose for the DNSOP WG?

Right now, abandon draft-ietf-dnsop-dns-wireformat-http.  But I'll
concede that I'm probably missing something.

By my current understanding, draft-ietf-dnsop-dns-wireformat-http is
indistinguishable from a specific implementation of
draft-ietf-doh-dns-over-https.  That is, if a DOH server wanted to
service all its queries by forwarding requests to a resolver [1], I
can't see how that would be disallowed by DOH, and that's exactly what
draft-ietf-dnsop-dns-wireformat-http appears to describe.

Convince me that this isn't the case (or not, and I'll be in the rough on this).

--Martin

[1] ...after randomizing the ID.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Doh] Alternate proposal for transport indication in draft-ietf-dnsop-dns-wireformat-http

[Martin Thomson]

If I understand your response (not sure that I do), that seems pretty
academic and not at all persuasive.  For instance, if a client cared
about testing TCP capabilities, it can always do its own resolution.

On Tue, Apr 3, 2018 at 7:44 PM, Davey Song <songlinj...@gmail.com> wrote:
>
>
> On 3 April 2018 at 15:33, Martin Thomson <martin.thom...@gmail.com> wrote:
>>
>> This is intended to do what?  Indicate where the response came from?
>> Why does the client care?
>
> To keep the proxy (API client and server) transparent and bypass the
> middlebox along the path. Without the indicate, the API server has no clue
> what transport the client use (or would like to use. because there maybe
> cases that client would like to test TCP capablity of the far end resolver,
> I don't know). If no such indicate, It is either always using UDP or TCP by
> default (or by local configuration). It can be done as an choice for
> software implementation, but for protocol design IMHO, a indicate should be
> introduced to provide that information.
>
>>
>> I assume that it doesn't apply to requests,
>> or that would get into draft-bellis-dnsop-xpf territory.
>
> That's is the quesion whether the indicate should be carried in HTTP layer
> or DNS layer. If we use HTTP as a tranparent tunnel without any modification
> on upper layer message, I would prefer to use a HTTP indicate.
>
>>
>> BTW, you really need to drop UDP from the media type name now.
>> application/dns-udpwireformat;original_transport=tcp is a bit of a
>> contradiction.
>
>
> I agree.  I find no harm defining a media type "application/dns-wireformat"
> for DOH.
>
> Davey
>

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Doh] Alternate proposal for transport indication in draft-ietf-dnsop-dns-wireformat-http

[Martin Thomson]

This is intended to do what?  Indicate where the response came from?
Why does the client care?  I assume that it doesn't apply to requests,
or that would get into draft-bellis-dnsop-xpf territory.

BTW, you really need to drop UDP from the media type name now.
application/dns-udpwireformat;original_transport=tcp is a bit of a
contradiction.

On Mon, Mar 26, 2018 at 4:48 PM, Paul Hoffman  wrote:
> Given the use case in draft-ietf-dnsop-dns-wireformat-http, defining a new 
> media type seems like overkill, particularly given that it will be 
> transporting *the exact same* data as an existing media type. Instead, an 
> optional parameter could be added to the application/dns-udpwireformat 
> registration in the DOH document.
>
> Proposal:
>
> =
>
> In the media type definition, change "Optional parameters" to:
>
> Optional parameters: original_transport
>original_transport has two defined values, "udp" and "tcp".
>This is only expected to be used by servers.
>
> Also in the the DOH document, under Operational Considerations, we would add:
>
> This protocol does not define any use for the original_transport optional
> parameter of the application/dns-udpwireformat media type.
>
> =
>
> Then draft-ietf-dnsop-dns-wireformat-http could define the use of that 
> optional parameter as it sees fit.
>
> --Paul Hoffman
>
> ___
> Doh mailing list
> d...@ietf.org
> https://www.ietf.org/mailman/listinfo/doh

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Curdle] WGLC on draft-ietf-curdle-dnskey-eddsa-01

[Martin Thomson]

On 4 November 2016 at 09:11, Salz, Rich  wrote:
> I think the issue about signature  contexts first, and mainly, came up with 
> TLS which generates a variety of private key material based on shared secret 
> info, and the concern that those different keys could be used for  
> cross-protocol attacks.

There are a lot of ways that keys (particularly those in certificates)
might be used.  Context strings reduce the chances that those keys are
misused such that data from one context can be transplanted into
another.

Simon's proposal works better in this context.  If only all keys were
so single-minded.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Curdle] WGLC on draft-ietf-curdle-dnskey-eddsa-01

[Martin Thomson]

On 3 November 2016 at 14:55, Daniel Migault  wrote:
> The version to be reviewed is
> https://tools.ietf.org/html/draft-ietf-curdle-dnskey-eddsa-01

Does this use Ed25519 or Ed25519ctx?  It describes a context string,
which Ed25519 throws away.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Possible issues with DNS over HTTP wire format draft

[Martin Thomson]

Thanks for starting the discussion Shane.

On 8 August 2016 at 23:41, Shane Kerr  wrote:
> My own feeling is that this should be
> enough; apparently the recommendation to require TLS was made in the
> HTTP/2 working group and rejected, so I am not sure that we need to
> re-visit the entire discussion around the DNS over HTTP protocol.

That's the result of a fairly old discussion.  You will note that all
protocols that use HTTP developed since (a long time ago) all require
HTTPS.  The reasons that HTTP decided cleartext wasn't prohibited
don't apply to a new protocol.

Also note that HTTP/2 on the web is - at least to my knowledge -
exclusively HTTPS at the moment.  The RFC might not mandate
encryption, but no one has deployed the unencrypted variant at any
real scale.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop