[prev in list] [next in list] [prev in thread] [next in thread]
List: gnutls-dev
Subject: Re: [gnutls-devel] =?utf-8?q?DANE_validation?=
From: Peter Williams <home_pw () msn ! com>
Date: 2013-02-17 20:30:09
Message-ID: SNT401-EAS7085747C4A310D0AE9A776920C0 () phx ! gbl
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
[Attachment #4 (text/plain)]
out of interest, if a PKIX Chain validation has occurred signaling invalidity of an \
leaf issuer and THEN an issuer-only (non-PKIX) check is made on the next protocol \
run, does GNU-TLS regard the issuer as invalidated?
Who controls - the authenticated DNS zone that may continue to confirm the issuer or \
the evidence collected from a previous chain validation?
Sent from Windows Mail
From: Nikos Mavrogiannopoulos
Sent: February 17, 2013 11:40 AM
To: Gabor Toth
CC: gnutls-devel
Subject: Re: [gnutls-devel] DANE validation
On Sun, Feb 17, 2013 at 5:09 PM, Gabor Toth <tg@tgbit.net> wrote:
> Hi,
>
> I've taken a brief look at the DANE validation functionality GnuTLS provides.
> It seems incomplete, even though from the documentation one might assume
> otherwise. Problematic points I found so far:
Hello Gabor,
What you consider an issue, is intentional. The DANE protocol (which
is supposedly DNS-Based Authentication of Named Entities), tries to
enforce methods of authentication that are unrelated to DNS. The DANE
implementation of gnutls is restricted to the DNS validation aspect
only. If one would like to do PKIX validation he can do it, but not
through the DANE subsystem.
You may see reasoning behind that at:
http://nmav.gnutls.org/2012/10/some-thoughts-on-dane-protocol.html
> - in case of usage 0 & 2, only the direct issuer is checked instead of the
> whole chain
That's also intentional. What scenario do you have in mind that is not
covered by the current case?
> As described in the RFC[1], PKIX path validation should be performed either using \
> the trust anchor specified in the TLSA record (usage 2), or using the system trust
> anchors (usage 0 & 1)
In gnutls DANE validation is independent to other certificate
validation methods. One can do PKIX validation, DANE (as DNS-based),
TOFU (trust on first use) or any combination of them.
One could of course strictly follow the DANE RFC validation methods if
he needs to.
regards,
Nikos
_______________________________________________
Gnutls-devel mailing list
Gnutls-devel@lists.gnutls.org
http://lists.gnupg.org/mailman/listinfo/gnutls-devel
[Attachment #5 (text/html)]
<html><head><style data-externalstyle="true">
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph {
margin-top:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
margin-bottom:.0001pt;
}
p.MsoListParagraphCxSpFirst, li.MsoListParagraphCxSpFirst, \
div.MsoListParagraphCxSpFirst, p.MsoListParagraphCxSpMiddle, \
li.MsoListParagraphCxSpMiddle, div.MsoListParagraphCxSpMiddle, \
p.MsoListParagraphCxSpLast, li.MsoListParagraphCxSpLast, div.MsoListParagraphCxSpLast \
{ margin-top:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
margin-bottom:.0001pt;
line-height:115%;
}
</style><style><!--
.EmailQuote {
padding-left:4pt;
margin-left:1pt;
border-left-color:rgb(128, 0, 0);
border-left-width:2px;
border-left-style:solid;
}
--></style></head><body><div data-externalstyle="false" \
style="font-family:Calibri,'Segoe UI',Meiryo,'Microsoft YaHei UI','Microsoft JhengHei \
UI','Malgun Gothic','Khmer UI','Nirmala UI',Tunga,'Lao \
UI',Ebrima,sans-serif;font-size:16px;"><div>out of interest, if a PKIX Chain \
validation has occurred signaling invalidity of an leaf issuer and THEN an \
issuer-only (non-PKIX) check is made on the next protocol run, does GNU-TLS regard \
the issuer as invalidated? </div><div> </div><div \
data-focusfrompointer="true">Who controls - the authenticated DNS zone that may \
continue to confirm the issuer or the evidence collected from a previous chain \
validation?</div><div data-focusfrompointer="true"> </div><div \
data-focusfrompointer="true"> </div><div \
data-signatureblock="true"><div> </div><div>Sent from Windows \
Mail</div><div> </div></div> <div style="border-top-color: rgb(225, 225, 225); \
border-top-width: 1px; border-top-style: solid;"> <strong>From:</strong> Nikos \
Mavrogiannopoulos<br> <strong>Sent:</strong> February 17, 2013 \
11:40 AM<br> <strong>To:</strong> Gabor \
Toth<br> <strong>CC:</strong> gnutls-devel<br> <strong>Subject:</strong> Re: \
[gnutls-devel] DANE validation<br> </div> <div> </div>
<font size="2"><span style="font-size: 10pt;"><div class=" PlainText">On Sun, Feb 17, \
2013 at 5:09 PM, Gabor Toth <tg@tgbit.net> wrote:<br> > Hi,<br>
><br>
> I've taken a brief look at the DANE validation functionality GnuTLS \
provides.<br> > It seems incomplete, even though from the documentation one might \
assume<br> > otherwise. Problematic points I found so far:<br>
<br>
Hello Gabor,<br>
What you consider an issue, is intentional. The DANE protocol (which<br>
is supposedly DNS-Based Authentication of Named Entities), tries to<br>
enforce methods of authentication that are unrelated to DNS. The DANE<br>
implementation of gnutls is restricted to the DNS validation aspect<br>
only. If one would like to do PKIX validation he can do it, but not<br>
through the DANE subsystem.<br>
<br>
You may see reasoning behind that at:<br>
<a tabindex="-1" href="http://nmav.gnutls.org/2012/10/some-thoughts-on-dane-protocol.html">http://nmav.gnutls.org/2012/10/some-thoughts-on-dane-protocol.html</a><br>
<br>
> - in case of usage 0 & 2, only the direct issuer is checked instead of \
the<br> > whole chain<br>
<br>
That's also intentional. What scenario do you have in mind that is not<br>
covered by the current case?<br>
<br>
> As described in the RFC[1], PKIX path validation should be performed either \
using the<br> > trust anchor specified in the TLSA record (usage 2), or using the \
system trust<br> > anchors (usage 0 & 1)<br>
<br>
In gnutls DANE validation is independent to other certificate<br>
validation methods. One can do PKIX validation, DANE (as DNS-based),<br>
TOFU (trust on first use) or any combination of them.<br>
<br>
One could of course strictly follow the DANE RFC validation methods if<br>
he needs to.<br>
<br>
regards,<br>
Nikos<br>
<br>
_______________________________________________<br>
Gnutls-devel mailing list<br>
Gnutls-devel@lists.gnutls.org<br>
<a tabindex="-1" href="http://lists.gnupg.org/mailman/listinfo/gnutls-devel">http://lists.gnupg.org/mailman/listinfo/gnutls-devel</a><br>
</div></span></font>
</div></body></html>
_______________________________________________
Gnutls-devel mailing list
Gnutls-devel@lists.gnutls.org
http://lists.gnupg.org/mailman/listinfo/gnutls-devel
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic