I also opened https://github.com/tlswg/draft-ietf-tls-svcb-ech/issues/17 to
add examples there.
Erik
On Sun, Oct 6, 2024 at 10:36 AM Erik Nygren <erik+i...@nygren.org> wrote:
> There's nothing prohibiting this in RFC 9460 and there may be reasonable
> operational use-cases for this,
> but operationally if you do it that way then all servers in the TargetName
> need to support the ech value.
> If they don't, then this would be a misconfiguration.
>
> If you have different pools of servers with separate ech configurations
> then you need to use distinct TargetNames.
> For cases such as with Multi-CDN it's important to make sure that distinct
> TargetNames get used.
>
> This may be worth an explicit example in draft-ietf-tls-svcb-ech?
> For example, if you actually have two different servers with different ECH
> keys
> then you'd need to do something like:
>
> puzzle.test.defo.ie. 60 AAAA 2a00:c6c0:0:134:2:0:0:cd1
> puzzle.test.defo.ie. 60 AAAA 2a00:c6c0:0:134:2:0:0:cd2
> puzzle-1.test.defo.ie <http://puzzle.test.defo.ie>. 60 AAAA
> 2a00:c6c0:0:134:2:0:0:cd1
> puzzle-2.test.defo.ie <http://puzzle.test.defo.ie>. 60 AAAA
> 2a00:c6c0:0:134:2:0:0:cd2
> puzzle.test.defo.ie. 60 HTTPS 1 puzzle-1.test.defo.ie
> <http://puzzle.test.defo.ie>.
>
> ech=AEP+DQA/TwAgACANGCk5QZ0GWrmu1p7U3L2M73gyADqZkxhSy8x2/EIBLAAEAAEAAQAQY2QyLnRlc3QuZGVmby5pZQAA
> puzzle.test.defo.ie. 60 HTTPS 1 puzzle-2.test.defo.ie
> <http://puzzle.test.defo.ie>.
>
> ech=AEP+DQA/BAAgACCW2/dfOBZAtQU55/py/BlhdRdaauPAkrERAUwppoeSEgAEAAEAAQAQY2QxLnRlc3QuZGVmby5pZQAA
>
> (Note that Google Chrome's implementation doesn't fully support RFC 9460
> yet and would ignore these and not use ECH,
> but that's a bug in Chrome which really needs to get fixed.)
>
> Erik
>
>
>
> On Sat, Oct 5, 2024 at 6:17 PM Watson Ladd <watsonbl...@gmail.com> wrote:
>
>> Dear dnsop,
>>
>> In the course of discussing implementations of ECH I and Stephen
>> Farrel arrived at opposite conclusions about whether or not RFC 9460
>> prohibits or allows the following kind of configuration.
>>
>> The zone puzzle.test.defo.ie has the following contents:
>>
>> puzzle.test.defo.ie. 60 AAAA 2a00:c6c0:0:134:2:0:0:cd1
>> puzzle.test.defo.ie. 60 AAAA 2a00:c6c0:0:134:2:0:0:cd2
>> puzzle.test.defo.ie. 60 HTTPS 1 .
>>
>> ech=AEP+DQA/TwAgACANGCk5QZ0GWrmu1p7U3L2M73gyADqZkxhSy8x2/EIBLAAEAAEAAQAQY2QyLnRlc3QuZGVmby5pZQAA
>> puzzle.test.defo.ie. 60 HTTPS 1 .
>>
>> ech=AEP+DQA/BAAgACCW2/dfOBZAtQU55/py/BlhdRdaauPAkrERAUwppoeSEgAEAAEAAQAQY2QxLnRlc3QuZGVmby5pZQAA
>> (Apologies for small listing errors: DNS is not a technology I know
>> nearly as much as I should)
>>
>> This is two different incompatible HTTPS records for the same
>> TargetName. My view is that this is not permissible: a server that
>> operates this way must expect either AAAA to receive a connection
>> configured with either ECH record, as outlined in section 2.4.3. There
>> is not an explicit prohibition on having two different HTTPS records
>> for the same target name, but I think this should be addressed
>> explicitly as it raises the question of which to use for a client and
>> makes a lot of text not make sense.
>>
>> Sincerely,
>> Watson Ladd
>>
>> --
>> Astra mortemque praestare gradatim
>>
>> _______________________________________________
>> DNSOP mailing list -- dnsop@ietf.org
>> To unsubscribe send an email to dnsop-le...@ietf.org
>>
>
_______________________________________________
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org
