On Jan 10, 2020, at 9:45 AM, Dan Wing wrote:
> The signature could be retrieved and validated separately from the stamp
> itself. For example, after getting the DNS stamp, retrieve a well-known DNS
> object (TXT, new RR, whatever) which is signed by the external entity. That
> would keep the
On Jan 9, 2020, at 10:22 AM, Vladimír Čunát wrote:
> I see a bigger problem that some of desired assertions are in principle
> unverifiable, e.g. "no logging". Of course, we could (optionally) extend the
> string by a signature, but I suspect that'd increase the length a lot without
>
On Fri, Jan 10, 2020 at 8:55 AM Stephane Bortzmeyer
wrote:
> On Thu, Jan 09, 2020 at 10:29:29AM -0800,
> Eric Rescorla wrote
> a message of 181 lines which said:
>
> > > It means a standards compliant DoT implementation will have no
> > > client identifiers, a standards compliant DoH
On Thu, Jan 09, 2020 at 10:29:29AM -0800,
Eric Rescorla wrote
a message of 181 lines which said:
> > It means a standards compliant DoT implementation will have no
> > client identifiers, a standards compliant DoH implementation is
> > free to (and likely) to include them.
> >
>
> [Citation
On Fri, Jan 10, 2020 at 6:50 AM Paul Hoffman wrote:
> On Jan 9, 2020, at 7:41 PM, Eric Rescorla wrote:
> Section 3.5.1.2
>
> I admit that I don't understand the purpose of this section.
> Concentrating on minutiae, like the details of DHCP or ARP/NDP spoofing, is
> far too low
On Jan 9, 2020, at 7:41 PM, Eric Rescorla wrote:
Section 3.5.1.2
I admit that I don't understand the purpose of this section. Concentrating
on minutiae, like the details of DHCP or ARP/NDP spoofing, is far too low
level. If we were to simply assume the usual threat
On Thu, Jan 9, 2020 at 10:03 AM Sara Dickinson wrote:
>
>
> On 7 Jan 2020, at 22:47, Eric Rescorla wrote:
>
>
>
> On Tue, Jan 7, 2020 at 10:37 AM Sara Dickinson wrote:
>
>>
>>
>> On 19 Dec 2019, at 02:09, Eric Rescorla wrote:
>>
>>
>>
>> On Wed, Dec 18, 2019 at 7:06 AM Sara Dickinson wrote:
