Re: [TLS] [dns-privacy] Martin Duke's No Objection on draft-ietf-dprive-xfr-over-tls-11: (with COMMENT)

[Allison Mankin]

Hi Ekr,

As Sara wrote, the spec had ALPN. The WG consensus during the IETF 108
meeting was very strong to take it out, including quite strong statements
from you along the lines that distinguishing between XoT and DOT was an
incorrect usage of ALPN.

I understand that the perspective changed since IETF108 (that WG discussion
was at the end of July 2020) and that communications were not wide enough
for us to know about it in March when the WG moved the draft to WGLC,
Directorates Review, and IETF LC

On Thu, Apr 29, 2021 at 14:25 Eric Rescorla  wrote:

> Probably not, but I agree with MT.
>
> The general idea here is that any given protocol trace should only be
> interpretable in one way. So, either you need the interior protocol to be
> self-describing or you need to separate the domains with ALPN. I don't
> believe that either the IP ACL or mTLS addresses this issue, and in fact
> arguably mTLS makes the problem worse because it provides authenticated
> protocol traces which might be usable for cross-protocol attacks.
>
> -Ekr
>
>
> On Thu, Apr 29, 2021 at 7:26 AM Salz, Rich  40akamai@dmarc.ietf.org> wrote:
>
>> >No new protocol should use TLS without ALPN.  It only opens space
>> for cross-protocol attacks.  Did the working group consider this
>> possibility in their discussions?
>>
>> I don't believe that message has been made as public as it should be.
>>
>> ___
>> dns-privacy mailing list
>> dns-priv...@ietf.org
>> https://www.ietf.org/mailman/listinfo/dns-privacy
>>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] draft-ietf-tls-dnssec-chain-extensions security considerations

[Allison Mankin]

I haven't chimed in on the mailing list on this draft, but I'm one of the
people who had discussions with browserfolk in hallways, in the corners of
interim meetings for HTTP2, and other such places, in order to see what it
would take to get a start on TLSA use by browsers.  Due to the floods of
traffic that occurred in this and other chains, I almost missed Joe's call
for answers to consensus questions, but I've responded inline.

Looking forward to discussion in Montreal.

On 26 June 2018 at 00:20, Joseph Salowey  wrote:

> Hi Folks,
>
> There has been some discussion with a small group of folks on github -
> https://github.com/tlswg/dnssec-chain-extension/pull/19.   I want to make
> sure there is consensus in the working group to take on the pinning work
> and see if there is consensus for modifications in the revision.  Please
> respond to the following questions on the list by July 10, 2018.
>
> 1.  Do you support the working group taking on future work on a pinning
> mechanism (based on the modifications or another approach)?
>
​I support future work if there is extensive engagement and involvement by
members of the browser community who have expressed concerns about pinning.


>
> 2.  Do you support the reserved bytes in the revision for a future pinning
> mechanism?
>
​Reserving the bytes without a mechanism is not a good idea, so no.  I
think the method for modifications or another approach is something to be
worked on in future too.


> 3.  Do you support the proof of denial of existence text in the revision?
>
​Yes, this text is good.​


>
> 4.  Do you support the new and improved security considerations?
>
​This text is a good addition - but there are a few things that might be
discussed.
Generally support them.


> Thanks,
>
> Joe
>
>
>
> On Tue, Jun 5, 2018 at 6:51 AM, Paul Wouters  wrote:
>
>> On Mon, 4 Jun 2018, Benjamin Kaduk wrote:
>>
>> Hi Ben,
>>
>> I've taken a stab at putting together some security considerations text
>>> for
>>> draft-ietf-tls-dnssec-chain-extension that reflects my understanding of
>>> the
>>> current state of affairs.  It's in a pull request at
>>> https://github.com/tlswg/dnssec-chain-extension/pull/19 , along with
>>> Viktor's
>>> commit to update the text about the actual DNS records involved (which as
>>> far as I can tell seems to improve the technical accuracy of the text),
>>> and
>>> also inserting a variable-length array that's reserved for future
>>> attempts
>>> to mitigate the (now-)documented security considerations.
>>>
>>
>> Thanks for writing the proposed text. The new opaque Reserved field
>> along with the denial of existence changes you propose addresses all
>> my concerns.
>>
>> One corner case that might be worth mentioning with the proposed DoE text
>> is the odd corner case of hitting a server with a Host header for which
>> it is not configured. You will hit the "default vhost" but you have no
>> appropriate extension data to populate for that hostname. So either the
>> server will return the (cached) TLSA/DoA data of the 'wrong' hostname,
>> or it could just omit the extension. I'd mostly like to say something to
>> prevent an implementation of forgetting this corner case and causing
>> some vulnerability in their code later on by pointing to bogus memory or
>> crashing on dereferencing a NULL.
>>
>> Some nits:
>>
>> If the server supports this extension it performs the appropriate
>> DNS queries,
>>
>> In my PR I had changed this into "obtains the appropriate DNS RRsets",
>> because I envision that TLS servers might not do DNS lookups themselves,
>> but just read this via a file or other method. Eg a cron job that
>> regenerates these hourly for all the hosted domains. It also reduces
>> some fear that all TLS servers suddenly could need to link against
>> a DNSSEC library. They don't if they can just reload a blob from disk
>> regularly to serve up.
>>
>> Similarly:
>>
>> it will need to rebuild
>>
>> is better written as "it will need rebuilt data"
>>
>>
>> "authenticates the chain"
>>
>> That should probably be "validate the chain", but the document has more
>> mixups of validate vs authenticate. In my PR request I had not corrected
>> them in an effort to keep the diff as small as possible.
>>
>> I had modified the examples slightly, so the NSEC example would show a
>> simpler NSEC chain (from www to zzz) instead of the one wrapping around
>> from www to the zone apex. The example quoted is the wrong NSEC record
>> (the one from apex to www.example.com does not show that the
>> _443._tcp.www.example.com does not exist, you need the one from
>> www..example.com  to the apex at the end of the
>> zone)
>>
>>
>> I'm not sure what you mean with:
>>
>> validated negative TTL
>>
>> I guess you mean to say the shortest TTL of any data in the chain? But
>> sometimes the negative cache time is larger then the TTL (eg if TTL = 0)
>> Since this is just generic DNS handling, I would probably j