On Tue, Feb 22, 2022 at 8:39 PM Benjamin Kaduk wrote:
> On Tue, Feb 22, 2022 at 08:27:02PM -0500, Shumon Huque wrote:
> > On Wed, Feb 16, 2022 at 4:29 AM Ilari Liusvaara <
> ilariliusva...@welho.com>
> > wrote:
> >
> > > I noticed that the "dnssec
On Wed, Feb 16, 2022 at 4:29 AM Ilari Liusvaara
wrote:
> I noticed that the "dnssec_chain" extension in the IANA registry lists
> only "CH" in the "TLS 1.3" column. However, the extension sends its
> response in the certificate message (section 2.2), so I think that
> column should read "CH, CT".
on to allow authenticated denial
chains to be delivered. Based on past list discussion, it appears to me
that there is rough consensus to allow that, and the yet unpublished draft
text in the github repo already includes it.
Shumon Huque
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
On Sat, Apr 28, 2018 at 3:01 PM, Paul Wouters wrote:
> On Sat, 28 Apr 2018, Shumon Huque wrote:
>
> This can be clearly seen from various comments on
>> list and at IETF/London, such as the point made many times that
>> the original purpose of this draft was to add
On Sat, Apr 28, 2018 at 3:01 PM, Paul Wouters wrote:
> On Sat, 28 Apr 2018, Shumon Huque wrote:
>
> [ not going to repeat my technical arguments here, just going to comment
> on process ]
>
> First, there is no agreement that your reason for doing pinning,
>> i.e. t
On Sat, Apr 28, 2018 at 2:17 PM, Richard Barnes wrote:
>
>
> On Sat, Apr 28, 2018 at 1:52 PM Viktor Dukhovni
> wrote:
>
>>
>>
>> > On Apr 28, 2018, at 12:19 PM, Shumon Huque wrote:
>> >
>> >This specification can also be used to optional
On Sat, Apr 28, 2018 at 1:40 PM, Viktor Dukhovni
wrote:
>
> > On Apr 28, 2018, at 12:26 PM, Shumon Huque wrote:
> >
> > So moving this feature into a new optional
> > extension (both the pinning field and a description of the associated
> > behavior) appe
ervers support this
extension, this allows the protocol to be bulletproof in a way that
satisfies even the security purist, so I'm glad it's in the core
spec.).
--
Shumon Huque
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
to deliver this extension.
Client applications could also employ a Trust on First Use (TOFU)
like strategy, whereby they would record the fact that a server
offered the extension and use that knowledge to require it for
subsequent connections.
Thanks,
--
Shumon Huque
On Wed, Apr 18, 2018 at 4:42 PM, Paul Wouters wrote:
>
> 2. Explicitly allow (but do not require) DoE be included
>>
>
> The document does not currently allow the extension to be empty. So if
> there is no TLSA record and the extension would be present, it therefore
> can only contain a DoE chai
try to
convince
implementers and deployers, now or in the future, that they need to use both
extensions in combination.
--
Shumon Huque
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
corresponding to an NXDOMAIN or NODATA response can be
returned.
I wonder if that, together with a new extension that can convey DANE
pinning information is a way forward ..
--
Shumon Huque
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
And also
develop a separate DANE pinning extension (now'ish ..)
--
Shumon Huque
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
age to get WG consensus on the
approach at a later date.
* Do something outside the protocol, and specific to applications
that want to include mechanisms to mandate DANE usage (like a HTTP
header).
--
Shumon Huque
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
Hi Kathleen,
Sorry for the delay. We'll have an updated draft addressing the IESG
discuss/comments shortly after the I-D submission window opens early
this week.
The one other sticking point is the issue that Viktor has raised about
extending
the protocol to provide pinning to prevent downgrade t
On Tue, Feb 27, 2018 at 6:36 PM, Nico Williams
wrote:
> On Tue, Feb 27, 2018 at 11:24:31AM -0500, Shumon Huque wrote:
> > On Tue, Feb 27, 2018 at 10:59 AM, Shumon Huque wrote:
> > > Several of us were well aware of this during the early days of the
> > > draft, but
On Wed, Feb 28, 2018 at 3:07 PM, Nico Williams
wrote:
> IF there's an objection to modifying the extension in order to add a
> pin-to-DANE TTL field, I would propose the following instead:
>
> Make the pin-to-DANE be "forever" but make it so it can easily be
> cleared if DANE is undeploye
On Tue, Feb 27, 2018 at 10:59 AM, Shumon Huque wrote:
>
>
> Several of us were well aware of this during the early days of the
> draft, but perhaps many folks did not fully appreciate the impacts
> until I elaborated on them last year, and added text that described
> t
On Mon, Feb 26, 2018 at 12:19 PM, Viktor Dukhovni
wrote:
>
> I think that as it stands, lack of authenticated denial of existence is
> a *fatal* flaw in the protocol. I just don't see a sufficiently practical
> scenario in which this extension confers a useful security benefit.
Viktor,
Is this
our
elaborating points, including a direct comparison with clients querying
DANE records themselves. It might also be worth a brief mention in the
Intro section that the protocol lacks authenticated denial and pointing
the reader/implementer to the Security Considerations section for mo
On Thu, Feb 22, 2018 at 11:08 AM, Kathleen Moriarty <
kathleen.moriarty.i...@gmail.com> wrote:
> On Thu, Feb 22, 2018 at 10:59 AM, Shumon Huque wrote:
> > On Wed, Feb 21, 2018 at 1:49 PM, Viktor Dukhovni
>
> >
> > Have other TLS extension specs gone into the de
On Wed, Feb 21, 2018 at 12:51 PM, Eric Rescorla wrote:
>
>
> On Wed, Feb 21, 2018 at 7:52 AM, Shumon Huque wrote:
>
>>
>> My comment was about what DANE mode choices the server is offering to
>> the client. Certainly, the client can decide whether it wants to use
On Wed, Feb 21, 2018 at 1:49 PM, Viktor Dukhovni
wrote:
>
>
> > On Feb 21, 2018, at 11:00 AM, Shumon Huque wrote:
> >
> > On Tue, Feb 13, 2018 at 5:50 PM, Martin Thomson <
> martin.thom...@gmail.com> wrote:
> > On Wed, Feb 14, 2018 at 4:07 AM, Kathlee
On Wed, Feb 21, 2018 at 2:48 PM, Paul Wouters wrote:
> On Wed, 21 Feb 2018, Shumon Huque wrote:
>
> Okay, got it. For people that have already implemented this, I think
>> there has been an implicit understanding that the format of the chain
>> data is a sequence of concate
On Wed, Feb 21, 2018 at 12:05 PM, Viktor Dukhovni
wrote:
>
>
> > On Feb 21, 2018, at 10:57 AM, Shumon Huque wrote:
> >
> > On Thu, Feb 8, 2018 at 11:35 AM, Viktor Dukhovni
> wrote:
> >
> > Summary as I see it:
> >
> > * Mandatory DANE: MU
On Wed, Feb 7, 2018 at 9:05 PM, Shumon Huque wrote:
> On Wed, Feb 7, 2018 at 1:22 PM, Alexey Melnikov
> wrote:
>
>> Alexey Melnikov has entered the following ballot position for
>> draft-ietf-tls-dnssec-chain-
On Tue, Feb 13, 2018 at 5:50 PM, Martin Thomson
wrote:
> On Wed, Feb 14, 2018 at 4:07 AM, Kathleen Moriarty
> wrote:
> > What's the behavior when the middlebox is a proxy, let's say existing
> > a managed network? I presume from from section 3.1 that this
> > negotiation doesn't work in that in
On Thu, Feb 8, 2018 at 11:35 AM, Viktor Dukhovni
wrote:
>
>
> Summary as I see it:
>
> * Mandatory DANE:
> MUST Refuse absence of TLSA RRs or failure
> of PKIX-TA(0) and PKIX-EE(1). Must fail when no TLSA RRs
> are cache and the server does not present the extension.
>
> * "Opportun
Sorry for my belated follow-up. Was temporarily overwhelmed by the
day job ..
On Thu, Feb 8, 2018 at 9:49 AM, Eric Rescorla wrote:
> On Thu, Feb 8, 2018 at 6:18 AM, Shumon Huque wrote:
>
> > > IMPORTANT: I'm not sure that this is actually sufficient to allow an
> > &g
On Thu, Feb 8, 2018 at 4:51 AM, Willem Toorop wrote:
> Op 08-02-18 om 03:27 schreef Shumon Huque:
> > On Wed, Feb 7, 2018 at 8:21 AM, Mirja Kühlewind > <mailto:i...@kuehlewind.net>> wrote:
> >
> > Mirja Kühlewind has entered the following ballot position
DNS documents, and we felt it
was redundant to redefine them in another format.
>
> . DNSKEY
> RRSIG(. DNSKEY)
> How does this differ from the algorithm that you would use in response to
the
> TLSA query?
Sorry, I don't follow your comment here. Differ from what? Can you
elaborate?
>
>the draft is adopted by the WG, the authors expect to make an early
>allocation request as specified in [RFC7120].
> Do you want this to be marked RECOMMENDED?
In response to Mirja's earlier comment, I think we are taking out this
sentence.
Shumon Huque
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
by the WG, the authors expect to make an
early allocation request as specified in [RFC7120]."
Agreed. It's a little late for that! :-)
We will remove it.
Shumon Huque
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
On Wed, Feb 7, 2018 at 6:22 PM, Ben Campbell wrote:
> Ben Campbell has entered the following ballot position for
> draft-ietf-tls-dnssec-chain-extension-06: Yes
>
> --
> COMMENT:
>
ive reference, but it is not even listed in
> References.
>
Ok, we will add it.
> --
> COMMENT:
> --
>
> The first mention of NSEC3 need a normative reference.
>
Yup
r the
full chain, then it doesn't need to send the dnssec_chain for subsequent
connections.
If it has only cached other portions of the chain, then it needs to.
We can clarify this.
Shumon Huque
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
e is no attestation of
>
> Nit: "...in the certificate..."
>
> Nit: Add closing paren after [RFC7671]
>
>
> ---
>
> §4:
>
> > specific processing needed for aliases and wildcards. If DNS
> > responses messages contain any domain names utilizing name
>
> Nit: "response"
>
>
Adam - nits have been noted, and will be fixed.
Shumon Huque
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
records that can (also) validate the MX or SRV
records, which it doesn't do right now.
In early discussions about the scope of this draft, I believe we decided to
omit the MX/SRV case to keep things simple. This is why the draft only
references RFC 6698 and 7671, and not 7672 and 7673. (Well it mentions 7672
only tangentially to suggest that such clients likely won't need this
mechanism).
Shumon Huque
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
TF protocols need to have
technical countermeasures to prevent pervasive monitoring).
I doubt that we will be able to get consensus on IETF endorsement. Speaking
only for myself, I am against the IETF/TLS wg endorsing a protocol that
degrades the security of the TLS protocol.
resumption, but it's so simple that it's probably worth doing.
Thanks!
--
Shumon Huque
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
sented anything else, it would not be considered invalid. Similarly, if
the chain included embedded unexpected extraneous records, I would expect
the client implementation to ignore those (or even invalidate the whole
chain if it wanted to be more draconian). If necessary, w
or (2) present a dnssec_chain that
demonstrates that there is no secure TLSA record, or that there is no
secure delegation to the zone. I think this would solve the problem, but
this isn't practical any time soon (or perhaps ever).
I'm not suggesting that we need to come up with a solution
On Fri, Jul 7, 2017 at 11:34 AM, Jim Reid wrote:
>
> > On 7 Jul 2017, at 16:06, Shumon Huque wrote:
> >
> > IMO, the real gain from having the client cache data, is that the server
> could then potentially send a much smaller DNSSEC chain. But this requires
> the cl
validate the
portion of the chain that it needs to, without any wire protocol change.
I'm okay with mentioning that possibility.
IMO, the real gain from having the client cache data, is that the server
could then potentially send a much smaller DNSSEC chain. But this requires
the client to sign
updates roughly once a decade (DNS parameters change
> slowly). A secure channel to a *trusted* resolver would avoid the
> problem, but trustworthy off-device resolvers are very unlikely to
> be ubiquitous.
>
Regarding churn, I expect we'll
e zone's secure entry point and the ZSK).
Perhaps we should use an example with the KSK/ZSK split to make them look
more like the real world. Let me discuss with Willem Toorop (co-author) who
generated these ...
--
Shumon Huque
___
TLS mailing li
On Tue, Jul 4, 2017 at 4:50 PM, Ilari Liusvaara
wrote:
> On Tue, Jul 04, 2017 at 01:18:05PM -0400, Shumon Huque wrote:
> > On Tue, Jul 4, 2017 at 12:19 PM, Ilari Liusvaara <
> ilariliusva...@welho.com>
> > wrote:
> >
> > > On Tue, Jul 04, 2017
On Tue, Jul 4, 2017 at 12:19 PM, Ilari Liusvaara
wrote:
> On Tue, Jul 04, 2017 at 11:33:45AM -0400, Shumon Huque wrote:
>
> >
> > Since the ordering is a SHOULD on the server side, the client has to
> check
> > and perform canonical re-ordering if necessary any
On Tue, Jul 4, 2017 at 12:14 PM, Viktor Dukhovni
wrote:
>
> > On Jul 4, 2017, at 11:33 AM, Shumon Huque wrote:
> >
> > Yes, in fact the previous sentence to the one you quoted did say this
> more or less: " ... return a serialized authentication chain in the
>
[ stuff omitted ]
7) Section 4. Construction of Serialized Authentication Chains
>
> > The transport is "tcp" for TLS servers, and "udp" for DTLS servers.
> > The port number label is the left-most label, followed by the
> > transport, followed
ly aren't terribly compressible, although
I guess the same issue exists for certificate chains, and if it's worth it
for
the latter ..
--
Shumon Huque
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
E TLS
> >protocol [RFC6698], and the additional protocol requirements outlined
> >in [RFC7671].
>
> Some discussion of UKS may be appropriate here, since there'll probably
> be some day soon an update to RFC7671 that says that name checks are not
On Tue, Jul 28, 2015 at 10:05 PM, Viktor Dukhovni
wrote:
> On Tue, Jul 28, 2015 at 09:44:34PM -0400, Shumon Huque wrote:
>
> This is no longer the DNS response to a single query (iterative
> resolvers generally chase CNAMEs), since one first CNAME expands
> the original target hos
pe would allow both the
server's X.509 certificate chain and the corresponding DANE/DNSSEC chain to
be delivered in the server's Certificate Message. I believe the argument
for doing it via a new TLS extension was that it would allow us to mandate
the use of the DANE chain ("Must staple DANE") via the X.509 TLS Feature
Extension.
Shumon Huque
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
53 matches
Mail list logo
