Re: [Add] The ADD WG has placed draft-pauly-add-deer in state "Call For Adoption By WG Issued"

[Tommy Pauly <[e-mail]>]

> On Jan 20, 2021, at 7:13 AM, Stephen Farrell <[e-mail]> wrote:
> 
> 
> Hiya,
> 
> On 15/01/2021 01:35, IETF Secretariat wrote:
>> The ADD WG has placed draft-pauly-add-deer in state
>> Call For Adoption By WG Issued (entered by Glenn Deen)
> 
> The mechanism defined here (using SVCB) is fine so I'm not
> against adoption but ISTM the draft is currently based on
> some false premises, the first of which is IMO likely to
> lead to extended and mostly-pointless debate:
> 
> - The equivalence called for here won't apply in many cases,
> neither in terms of some (impossible?) functional definition
> for equivalence, nor in terms of involving the "same entity."
> I think this all looks like an RFC6919 "MUST (but we know
> you won't)" and I don't see how we benefit from adding that
> to an already controversial and complicated area. I'd say
> better to not insist on any particular semantics except
> that using SVCB like this ought always result in an as-good
> or better TLS setup, so (were it up to me, which it's not)
> I'd re-title this as something like "Discovering Encrypted
> Related Resolvers" and re-word a good bit accordingly.

The name and terminology is based on the discussion going on in the ADD working group previously; I think I’m speaking for all the authors when I say that that terminology can certainly and should change, and would be certainly eligible to refine even after adoption.

> 
> - 4.1 will call for a SAN containing an IP address that
> cannot be authenticated by a CA in many cases (the address
> of the unencrypted resolver) - I don't see the utility of
> that TBH. (This is separate from use of private addresses.)

Again, this is a point we can continue to discuss or change. I think it is useful given that some resolvers can and indeed do support such certificates already, but that can be decided by the WG.

> 
> - 4.2's insistence on the same IP address seems odd to me.
> I suspect there's an underlying difference in interpretation
> of the term opportunistic there, which isn't uncommon - IMO
> even very "weak" opportunistic modes are useful if they can
> lead deployments towards use of a fully authenticated mode
> but the text here seems to instead consider opportunistic
> mode as an undesirable end-state and not as an intermediate
> state. I doubt we'll all agree on that based on this draft
> though, as this has been an ongoing disagreement for a
> bunch of years already:-)
> 
> In case the above isn't clear: again, I'm not against
> adoption but would argue we'd all be better of if the
> above were fixed first.

While that’s certainly a direction, I’d prefer to see such decisions be made as a matter of working group consensus and agreement, and not under individual authorship.

Thanks,
Tommy

> 
> One other change that (if needed) would be fine to fix
> after adoption is that I'm unsure that all of the clients
> we'd like to do this will be able to handle, and keep up
> with, the full complexity of SVCB. Could be the best way
> to handle that is to wait and see what people implement
> and then profile down to requiring use of SVCB records
> that are supported by all known implementations. OTOH,
> if it turns out everyone uses some well-tested and capable
> SVCB library, then this'd likely be moot. I'm not aware
> there is any such library at the moment though.
> 
> Cheers,
> S.
> 
> 
> <OpenPGP_0x5AB2FAF17B172BEA.asc>-- 
> Add mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/add