[prev in list] [next in list] [prev in thread] [next in thread]
List: ietf-tls
Subject: Re: [TLS] Proposals for draft-ietf-tls-subcerts-02
From: Nick Sullivan <nick () cloudflare ! com>
Date: 2018-07-26 23:03:25
Message-ID: CAFDDyk-s+AcmrG=stfhANyCrB1eXxgu7Qx-E-d+rmzStZM6DTg () mail ! gmail ! com
[Download RAW message or body]
I support these changes.
Nick
On Thu, Jul 26, 2018 at 11:01 AM Patton,Christopher J <cjpatton@ufl.edu>
wrote:
> Thanks all for the feedback! In light of your observations, we've revised
> the changes proposed for draft-02:
> https://github.com/tlswg/tls-subcerts/pull/13.
>
>
> The changes for draft-02 are as follows:
>
>
>
>
> - Drop support for TLS 1.2.
> - Add the protocol version and credential signature algorithm to the
> Credential structure.
>
>
> - Specify undefined behavior in a few cases: when the client receives
> a DC without indicated support; when the client indicates the extensio=
n in
> an invalid protocol version; and when DCs are sent as extensions to
> certificates other than the end-entity certificate.
>
>
> Any additional feedback is welcome.
>
>
> Thanks,
>
> Christopher Patton
>
>
> ------------------------------
> *From:* Blumenthal, Uri - 0553 - MITLL <uri@ll.mit.edu>
> *Sent:* Tuesday, July 24, 2018 4:40 PM
> *To:* Ilari Liusvaara; Patton,Christopher J
> *Cc:* tls@ietf.org
> *Subject:* Re: [TLS] Proposals for draft-ietf-tls-subcerts-02
>
> I object to re-interpreting/overloading the Critical flag. It has one and
> only one meaning: "If the parser does not understand the given attribute,
> it must abort parsing if this attribute is marked as Critical (or ignore
> this attribute and continue parsing if the Critical flag is not set)".
>
>
> =EF=BB=BFOn 7/24/18, 16:25, "TLS on behalf of Ilari Liusvaara" <
> tls-bounces@ietf.org on behalf of ilariliusvaara@welho.com> wrote:
>
> On Tue, Jul 24, 2018 at 07:24:09PM +0000, Patton,Christopher J wrote:
> > Hi all,
> >
> >
> > I've taken the liberty of addressing the changes to the delegated
> credentials extension that were requested at IETF:
> >
> > https://github.com/tlswg/tls-subcerts/pull/13
>
> >
> >
> > The changes that would be adopted in draft-02 are as follows:
> >
> > * Drop support for TLS 1.2.
> > * Allow the critical bit of the X.509 extension to be set.
> > * Add the protocol version and credential signature algorithm
> > to the Credential structure.
> > * Make the KeyUsage of the delegation certificate stricter.
> > * Specify undefined behavior in a few cases.
> >
> > It was suggested that we add optional "must-use-DC" semantics to th=
e
> > certificate. The solution we came up with was to add a "strict" fla=
g
> > to the extension that is set if (and only if) the extension is mark=
ed
> > critical. The idea is that if the "strict" flag is set and the serv=
er
> > doesn't offer a DC, then client must abort the handshake, In my
> opinion,
> > the complexity this adds to the protocol outweighs the potential
> benefits.
> >
> > Comments on the PR are welcome.
>
> This has the signifcant critical flag issue. It should at minimum be
> explicitly called out, as I do not know any precendent for this kind =
of
> behavior (check that some extension is critical yes, but not changing
> meaning of extension depending on critical flag).
>
>
> I watched the presentation and the resulting Q&A again. Short summary
> of
> relevant stuff:
>
> - The motivation in the slides is to reduce exposure of private keys =
to
> memory disclosure vulernabilities, without reducing performance.
> - The orignal proposal was to add a TLS Feature extension value. No
> discussion.
> - The drawback of "strict mode" would be causing issues with servers
> that can not effectively switch between certificates.
> - There is question about fallback. Paraphrased answer: LURK.
>
>
> TLS Feature extensions have some really unwnated properties here. The=
y
> are never critical on client side, and they have OR-inheritance. You
> definitely do not want OR-inheritance here.
>
> Well, after this, the best usecase I can come up with strict flag is
> still dealing with LURK endpoints that can not do proof-of-possession
> or format checking[1].
>
>
> [1] TLS 1.2 and 1.3 servers should only ask for signatures and only
> over the following kinds of data:
>
> - <64 bytes> 03 00 17 41 04 <64 bytes>
> - <64 bytes> 03 00 18 61 04 <96 bytes>
> - <64 bytes> 03 00 19 85 04 <132 bytes> (rare, P-521)
> - <64 bytes> 03 00 1A 41 04 <64 bytes> (rare, brainpool)
> - <64 bytes> 03 00 1B 61 04 <96 bytes> (rare, brainpool)
> - <64 bytes> 03 00 1C 81 04 <128 bytes> (rare, brainpool)
> - <64 bytes> 03 00 1D 20 <32 bytes>
> - <64 bytes> 03 00 1E 38 <56 bytes> (rare, X448)
> - <64 spaces> "TLS 1.3, server CertificateVerify" 00 <32 bytes>
> - <64 spaces> "TLS 1.3, server CertificateVerify" 00 <48 bytes>
>
> None of these covers delegated credential signatures, which would
> cause any attempt to ask for DC signature to fail if the format is
> checked..
>
>
>
> -Ilari
>
>
> _______________________________________________
> 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
>
[Attachment #3 (text/html)]
<div dir="ltr">I support these changes.<div><br></div><div>Nick</div></div><br><div \
class="gmail_quote"><div dir="ltr">On Thu, Jul 26, 2018 at 11:01 AM \
Patton,Christopher J <<a href="mailto:cjpatton@ufl.edu">cjpatton@ufl.edu</a>> \
wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 \
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">
<div id="m_-5309836735414366107divtagdefaultwrapper" \
style="font-size:12pt;color:#000000;font-family:Calibri,Helvetica,sans-serif" \
dir="ltr"> <p style="margin-top:0;margin-bottom:0">Thanks all for the feedback! In \
light of your observations, we've revised the changes proposed for draft-02: <a \
href="https://github.com/tlswg/tls-subcerts/pull/13" \
class="m_-5309836735414366107OWAAutoLink" id="m_-5309836735414366107LPlnk33846" \
target="_blank">https://github.com/tlswg/tls-subcerts/pull/13</a>.<br> </p>
<p style="margin-top:0;margin-bottom:0"><br>
</p>
<p style="margin-top:0;margin-bottom:0">The changes for draft-02 are as follows:</p>
<p style="margin-top:0;margin-bottom:0"></p>
<div>
<ul style="margin-bottom:0px;margin-top:0px"></ul></div></div></div><div \
dir="ltr"><div id="m_-5309836735414366107divtagdefaultwrapper" \
style="font-size:12pt;color:#000000;font-family:Calibri,Helvetica,sans-serif" \
dir="ltr"><div><ul style="margin-bottom:0px;margin-top:0px"> <li><span \
style="font-size:12pt"></span><span style="font-size:12pt">Drop support for TLS \
1.2.</span><br> </li><li><span style="font-size:12pt"></span><span \
style="font-size:12pt">Add the protocol version and credential signature algorithm to \
the Credential structure.</span><br> </li></ul></div></div></div><div dir="ltr"><div \
id="m_-5309836735414366107divtagdefaultwrapper" \
style="font-size:12pt;color:#000000;font-family:Calibri,Helvetica,sans-serif" \
dir="ltr"><div><ul style="margin-bottom:0px;margin-top:0px"><li><span \
style="font-size:12pt"></span><span style="font-size:12pt">Specif</span><span \
style="font-size:12pt">y undefined behavior in a few cases: when the client receives \
a DC without indicated support; when the client indicates the extension in an \
invalid protocol version; and when DCs are sent as extensions to certificates other \
than the end-entity certificate.</span><br> </li></ul>
</div>
<br>
<p></p>
<p style="margin-top:0;margin-bottom:0">Any additional feedback is welcome.</p>
<p style="margin-top:0;margin-bottom:0"><br>
</p>
<p style="margin-top:0;margin-bottom:0"><span \
style="font-size:12pt">Thanks,</span></p> <p \
style="margin-top:0;margin-bottom:0">Christopher Patton</p> <br>
<br>
<div style="color:rgb(0,0,0)">
<hr style="display:inline-block;width:98%">
<div id="m_-5309836735414366107divRplyFwdMsg" dir="ltr"><font face="Calibri, \
sans-serif" style="font-size:11pt" color="#000000"><b>From:</b> Blumenthal, Uri - \
0553 - MITLL <<a href="mailto:uri@ll.mit.edu" \
target="_blank">uri@ll.mit.edu</a>><br> <b>Sent:</b> Tuesday, July 24, 2018 4:40 \
PM<br> <b>To:</b> Ilari Liusvaara; Patton,Christopher J<br>
<b>Cc:</b> <a href="mailto:tls@ietf.org" target="_blank">tls@ietf.org</a><br>
<b>Subject:</b> Re: [TLS] Proposals for draft-ietf-tls-subcerts-02</font>
<div> </div>
</div></div></div></div><div dir="ltr"><div \
id="m_-5309836735414366107divtagdefaultwrapper" \
style="font-size:12pt;color:#000000;font-family:Calibri,Helvetica,sans-serif" \
dir="ltr"><div style="color:rgb(0,0,0)"> <div \
class="m_-5309836735414366107BodyFragment"><font size="2"><span \
style="font-size:11pt"> <div class="m_-5309836735414366107PlainText">I object to \
re-interpreting/overloading the Critical flag. It has one and only one meaning: \
"If the parser does not understand the given attribute, it must abort parsing if \
this attribute is marked as Critical (or ignore this attribute and continue parsing \
if the Critical flag is not set)". <br> <br>
<br>
On 7/24/18, 16:25, "TLS on behalf of Ilari Liusvaara" <<a \
href="mailto:tls-bounces@ietf.org" target="_blank">tls-bounces@ietf.org</a> on behalf \
of <a href="mailto:ilariliusvaara@welho.com" \
target="_blank">ilariliusvaara@welho.com</a>> wrote:<br> <br>
On Tue, Jul 24, 2018 at 07:24:09PM +0000, Patton,Christopher J wrote:<br>
> Hi all,<br>
> <br>
> <br>
> I've taken the liberty of addressing the changes to the delegated \
credentials extension that were requested at IETF:<br> > <br>
> <a href="https://github.com/tlswg/tls-subcerts/pull/13" \
id="m_-5309836735414366107LPlnk118561" class="m_-5309836735414366107OWAAutoLink" \
target="_blank"> https://github.com/tlswg/tls-subcerts/pull/13</a><br>
<br>
> <br>
> <br>
> The changes that would be adopted in draft-02 are as follows:<br>
> <br>
> * Drop support for TLS 1.2.<br>
> * Allow the critical bit of the X.509 extension to be set.<br>
> * Add the protocol version and credential signature algorithm<br>
> to the Credential structure.<br>
> * Make the KeyUsage of the delegation certificate stricter.<br>
> * Specify undefined behavior in a few cases.<br>
> <br>
> It was suggested that we add optional "must-use-DC" semantics \
to the<br>
> certificate. The solution we came up with was to add a "strict" \
flag<br>
> to the extension that is set if (and only if) the extension is marked<br>
> critical. The idea is that if the "strict" flag is set and the \
server<br>
> doesn't offer a DC, then client must abort the handshake, In my \
opinion,<br>
> the complexity this adds to the protocol outweighs the potential \
benefits.<br> > <br>
> Comments on the PR are welcome.<br>
<br>
This has the signifcant critical flag issue. It should at minimum be<br>
explicitly called out, as I do not know any precendent for this kind of<br>
behavior (check that some extension is critical yes, but not changing<br>
meaning of extension depending on critical flag).<br>
<br>
<br>
I watched the presentation and the resulting Q&A again. Short summary \
of<br> relevant stuff:<br>
<br>
- The motivation in the slides is to reduce exposure of private keys to<br>
memory disclosure vulernabilities, without reducing performance.<br>
- The orignal proposal was to add a TLS Feature extension value. No<br>
discussion.<br>
- The drawback of "strict mode" would be causing issues with \
servers<br> that can not effectively switch between certificates.<br>
- There is question about fallback. Paraphrased answer: LURK.<br>
<br>
<br>
TLS Feature extensions have some really unwnated properties here. They<br>
are never critical on client side, and they have OR-inheritance. You<br>
definitely do not want OR-inheritance here.<br>
<br>
Well, after this, the best usecase I can come up with strict flag is<br>
still dealing with LURK endpoints that can not do proof-of-possession<br>
or format checking[1].<br>
<br>
<br>
[1] TLS 1.2 and 1.3 servers should only ask for signatures and only<br>
over the following kinds of data:<br>
<br>
- <64 bytes> 03 00 17 41 04 <64 bytes><br>
- <64 bytes> 03 00 18 61 04 <96 bytes><br>
- <64 bytes> 03 00 19 85 04 <132 bytes> (rare, P-521)<br>
- <64 bytes> 03 00 1A 41 04 <64 bytes> (rare, brainpool)<br>
- <64 bytes> 03 00 1B 61 04 <96 bytes> (rare, brainpool)<br>
- <64 bytes> 03 00 1C 81 04 <128 bytes> (rare, brainpool)<br>
- <64 bytes> 03 00 1D 20 <32 bytes><br>
- <64 bytes> 03 00 1E 38 <56 bytes> (rare, X448)<br>
- <64 spaces> "TLS 1.3, server CertificateVerify" 00 <32 \
bytes><br>
- <64 spaces> "TLS 1.3, server CertificateVerify" 00 <48 \
bytes><br> <br>
None of these covers delegated credential signatures, which would<br>
cause any attempt to ask for DC signature to fail if the format is<br>
checked..<br>
<br>
<br>
<br>
-Ilari<br>
<br>
<br>
_______________________________________________<br>
TLS mailing list<br>
<a href="mailto:TLS@ietf.org" target="_blank">TLS@ietf.org</a><br>
<a href="https://www.ietf.org/mailman/listinfo/tls" \
id="m_-5309836735414366107LPlnk966636" class="m_-5309836735414366107OWAAutoLink" \
target="_blank"> https://www.ietf.org/mailman/listinfo/tls</a><br>
<br>
</div>
</span></font></div>
</div></div></div>
_______________________________________________<br>
TLS mailing list<br>
<a href="mailto:TLS@ietf.org" target="_blank">TLS@ietf.org</a><br>
<a href="https://www.ietf.org/mailman/listinfo/tls" rel="noreferrer" \
target="_blank">https://www.ietf.org/mailman/listinfo/tls</a><br> </blockquote></div>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic