Re: [TLS] Working group last call for draft-ietf-tls-subcerts-07

[Ryan Sleevi]

On Wed, May 20, 2020 at 6:40 PM Russ Housley  wrote:

> MINOR
>
> Section 1 also says:
>
>Because the above problems do not relate to the CA's inherent
>function of validating possession of names, 
>
> The CA is responsible for confirming that the public key in the
> certificate corresponds to a private key that can be used by the
> certificate subject.  This is usually done by a proof of possession
> mechanism.  So, I think that the start of this sentence should be
> reworded to avoid the impression that the CA only validates the
> name.
>

The existing framing is correct. The most widely used Internet PKI, the Web
PKI, intentionally doesn’t not require a proof of possession mechanism. It
is not used as an authentication mechanism (i.e. a binding of a key to an
identity) but an authorization mechanism (i.e. a binding of an authorized
set of identities to a key).

The “CA only validates the name” is not just an impression, it’s the
widespread running code. Due to how TLS certificates are used (online
protocol negotiation, without non-repudiation support), there’s no risk
opened nor any necessity to do a strong proof of possession binding, even
in cases of strong identity binding.

QUESTION
>
> While I have no objection to the DelegationUsage extension,
> I wonder is an extended key usage would provide the same
> confidence in the certificate.
>

In practice, no. As things currently are, it would unfortunately undermine
the confidence, although this an entirely fair and reasonable question.

As a recap (and more for those without the same context you have) the way
5280 and it’s predecessors were designed, the Certificate Policies
extension is the primary means of expressing or indicating compliance to a
particular policy. If a relying party explicitly attempts to validate a
certificate, for a RP-determined Certificate Policy, then they can know
whether or not that certificate complied with their expectations for
issuance and management. This is all defined within 5280, albeit quite
complex, and involves processing rules for both leaves and intermediates,
as well as the ability to map between different policies (via
policyMappings), such that an RP expecting policy A can validate a
certificate bearing only policy B, provided some trusted party in the
certification path asserted that B was equal-or-equivalent-to A

Additionally, certificates have the extendedKeyUsage, which is most
commonly used to restrict the protocol or protocols a given certificate can
be used for. In RFC 5280 and friends, this restriction only applies to lead
certificates. However, from the very earliest days of PKIX, the two main
implementations (Microsoft and Netscape) diverged from this, in unspecified
ways that ultimately PKIX declined to incorporate, to allow EKUs to be used
on intermediates to restrict the protocols that certificates can be issued
for. If a leaf EKU is not a subset of its issuing chain, then that EKU is
not permitted; much like policy OIDs.

This divergence, which has existed since the very earliest days of TLS,
resulted in a different approach to managing policy than the idealized goal
of PKIX. Rather than having every relying party application provide an
initial policy, such as a policy OID assigned by the root store vendor
(typically the OS/browser vendor), to indicate compliance with the root
store’s policy, and using policy mappings for that, implementations simply
used the EKU as a joint indicator for “uses protocol X and complies with
the issuance policies for protocol X, as defined by the root store vendor”.

This whole long preamble builds to our present day. In wide practice, and
even for those root stores/OSes/applications that do not implement EKU
chaining in the fashion mentioned above, the mere presence of an EKU is the
indicator for compliance with a set of policies, and altering EKUs, like
altering policy OIDs, requires issuing new intermediates permitted for that
EKU.

If DC certificates only bore a DC EKU, they would, in effect, be exempt
from all of the certificate policies widely practiced for the issuance of
TLS certificates, which would reduce the confidence in the certificate.
They would also typically require the CA to issue new intermediate
certificates prior to being able to issue such certificates that were
accepted. For applications, the certificate validation libraries apply
local policy to certificates based on their EKU via technical measures, to
ensure they match the expected issuance policy, such as checking for
certificate transparency information or limiting the maximum validity
period the application will accept.

Recall that the design of DC is also possible via simply nameConstrained
subCAs, but part of the reason for DC is that it does not require or
reduces dependencies on external PKIs in order to satisfy local protocol
needs. The same argument applies here against EKU: to use EKU would place
ongoing dependencies back on those external PKI, be incompatible with h

Re: [TLS] Working group last call for draft-ietf-tls-subcerts-07

[Salz, Rich]

  *   While I have no objection to the DelegationUsage extension,
I wonder is an extended key usage would provide the same
confidence in the certificate.

FWIW, a new extendedKeyUsage value would be easier to add into OpenSSL, and I’m 
looking at adding this there (sic).
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Working group last call for draft-ietf-tls-subcerts-07

[Russ Housley]

> On May 21, 2020, at 10:12 AM, Ryan Sleevi  wrote:
> 
> 
> On Wed, May 20, 2020 at 6:40 PM Russ Housley  > wrote:
> MINOR
> 
> Section 1 also says:
> 
>Because the above problems do not relate to the CA's inherent
>function of validating possession of names, 
> 
> The CA is responsible for confirming that the public key in the
> certificate corresponds to a private key that can be used by the
> certificate subject.  This is usually done by a proof of possession
> mechanism.  So, I think that the start of this sentence should be
> reworded to avoid the impression that the CA only validates the
> name.
> 
> The existing framing is correct. The most widely used Internet PKI, the Web 
> PKI, intentionally doesn’t not require a proof of possession mechanism. It is 
> not used as an authentication mechanism (i.e. a binding of a key to an 
> identity) but an authorization mechanism (i.e. a binding of an authorized set 
> of identities to a key).
> 
> The “CA only validates the name” is not just an impression, it’s the 
> widespread running code. Due to how TLS certificates are used (online 
> protocol negotiation, without non-repudiation support), there’s no risk 
> opened nor any necessity to do a strong proof of possession binding, even in 
> cases of strong identity binding.

The CSR is signed with the key to be certified.  That is proof of possession.

> 
> QUESTION
> 
> While I have no objection to the DelegationUsage extension,
> I wonder is an extended key usage would provide the same
> confidence in the certificate.
> 
> In practice, no. As things currently are, it would unfortunately undermine 
> the confidence, although this an entirely fair and reasonable question.
> 
> As a recap (and more for those without the same context you have) the way 
> 5280 and it’s predecessors were designed, the Certificate Policies extension 
> is the primary means of expressing or indicating compliance to a particular 
> policy. If a relying party explicitly attempts to validate a certificate, for 
> a RP-determined Certificate Policy, then they can know whether or not that 
> certificate complied with their expectations for issuance and management. 
> This is all defined within 5280, albeit quite complex, and involves 
> processing rules for both leaves and intermediates, as well as the ability to 
> map between different policies (via policyMappings), such that an RP 
> expecting policy A can validate a certificate bearing only policy B, provided 
> some trusted party in the certification path asserted that B was 
> equal-or-equivalent-to A
> 
> Additionally, certificates have the extendedKeyUsage, which is most commonly 
> used to restrict the protocol or protocols a given certificate can be used 
> for. In RFC 5280 and friends, this restriction only applies to lead 
> certificates. However, from the very earliest days of PKIX, the two main 
> implementations (Microsoft and Netscape) diverged from this, in unspecified 
> ways that ultimately PKIX declined to incorporate, to allow EKUs to be used 
> on intermediates to restrict the protocols that certificates can be issued 
> for. If a leaf EKU is not a subset of its issuing chain, then that EKU is not 
> permitted; much like policy OIDs.
> 
> This divergence, which has existed since the very earliest days of TLS, 
> resulted in a different approach to managing policy than the idealized goal 
> of PKIX. Rather than having every relying party application provide an 
> initial policy, such as a policy OID assigned by the root store vendor 
> (typically the OS/browser vendor), to indicate compliance with the root 
> store’s policy, and using policy mappings for that, implementations simply 
> used the EKU as a joint indicator for “uses protocol X and complies with the 
> issuance policies for protocol X, as defined by the root store vendor”.
> 
> This whole long preamble builds to our present day. In wide practice, and 
> even for those root stores/OSes/applications that do not implement EKU 
> chaining in the fashion mentioned above, the mere presence of an EKU is the 
> indicator for compliance with a set of policies, and altering EKUs, like 
> altering policy OIDs, requires issuing new intermediates permitted for that 
> EKU.
> 
> If DC certificates only bore a DC EKU, they would, in effect, be exempt from 
> all of the certificate policies widely practiced for the issuance of TLS 
> certificates, which would reduce the confidence in the certificate. They 
> would also typically require the CA to issue new intermediate certificates 
> prior to being able to issue such certificates that were accepted. For 
> applications, the certificate validation libraries apply local policy to 
> certificates based on their EKU via technical measures, to ensure they match 
> the expected issuance policy, such as checking for certificate transparency 
> information or limiting the maximum validity period the application will 
> accept.
> 
> R

Re: [TLS] Working group last call for draft-ietf-tls-subcerts-07

[Ryan Sleevi]

On Thu, May 21, 2020 at 10:51 AM Russ Housley  wrote:

>
>
> On May 21, 2020, at 10:12 AM, Ryan Sleevi  wrote:
>
>
> On Wed, May 20, 2020 at 6:40 PM Russ Housley  wrote:
>
>> MINOR
>>
>> Section 1 also says:
>>
>>Because the above problems do not relate to the CA's inherent
>>function of validating possession of names, 
>>
>> The CA is responsible for confirming that the public key in the
>> certificate corresponds to a private key that can be used by the
>> certificate subject.  This is usually done by a proof of possession
>> mechanism.  So, I think that the start of this sentence should be
>> reworded to avoid the impression that the CA only validates the
>> name.
>>
>
> The existing framing is correct. The most widely used Internet PKI, the
> Web PKI, intentionally doesn’t not require a proof of possession mechanism.
> It is not used as an authentication mechanism (i.e. a binding of a key to
> an identity) but an authorization mechanism (i.e. a binding of an
> authorized set of identities to a key).
>
> The “CA only validates the name” is not just an impression, it’s the
> widespread running code. Due to how TLS certificates are used (online
> protocol negotiation, without non-repudiation support), there’s no risk
> opened nor any necessity to do a strong proof of possession binding, even
> in cases of strong identity binding.
>
>
> The CSR is signed with the key to be certified.  That is proof of
> possession.
>

None of these CAs are required to use CSRs or validate signatures. You’re
describing ways a CA could implement POP, but as I said, proof of
possession is not required.

That’s why the current text more accurately reflects the rough consensus of
popular root programs and the running code that trusts those CAs.

It’s certainly true that implementors of DC could reach agreements with CAs
to require POPs, but it’s also not necessary for the protocol (DC or
broadly TLS), which is why it’s not done or required.


>
> QUESTION
>>
>> While I have no objection to the DelegationUsage extension,
>> I wonder is an extended key usage would provide the same
>> confidence in the certificate.
>>
>
> In practice, no. As things currently are, it would unfortunately undermine
> the confidence, although this an entirely fair and reasonable question.
>
> As a recap (and more for those without the same context you have) the way
> 5280 and it’s predecessors were designed, the Certificate Policies
> extension is the primary means of expressing or indicating compliance to a
> particular policy. If a relying party explicitly attempts to validate a
> certificate, for a RP-determined Certificate Policy, then they can know
> whether or not that certificate complied with their expectations for
> issuance and management. This is all defined within 5280, albeit quite
> complex, and involves processing rules for both leaves and intermediates,
> as well as the ability to map between different policies (via
> policyMappings), such that an RP expecting policy A can validate a
> certificate bearing only policy B, provided some trusted party in the
> certification path asserted that B was equal-or-equivalent-to A
>
> Additionally, certificates have the extendedKeyUsage, which is most
> commonly used to restrict the protocol or protocols a given certificate can
> be used for. In RFC 5280 and friends, this restriction only applies to lead
> certificates. However, from the very earliest days of PKIX, the two main
> implementations (Microsoft and Netscape) diverged from this, in unspecified
> ways that ultimately PKIX declined to incorporate, to allow EKUs to be used
> on intermediates to restrict the protocols that certificates can be issued
> for. If a leaf EKU is not a subset of its issuing chain, then that EKU is
> not permitted; much like policy OIDs.
>
> This divergence, which has existed since the very earliest days of TLS,
> resulted in a different approach to managing policy than the idealized goal
> of PKIX. Rather than having every relying party application provide an
> initial policy, such as a policy OID assigned by the root store vendor
> (typically the OS/browser vendor), to indicate compliance with the root
> store’s policy, and using policy mappings for that, implementations simply
> used the EKU as a joint indicator for “uses protocol X and complies with
> the issuance policies for protocol X, as defined by the root store vendor”.
>
> This whole long preamble builds to our present day. In wide practice, and
> even for those root stores/OSes/applications that do not implement EKU
> chaining in the fashion mentioned above, the mere presence of an EKU is the
> indicator for compliance with a set of policies, and altering EKUs, like
> altering policy OIDs, requires issuing new intermediates permitted for that
> EKU.
>
> If DC certificates only bore a DC EKU, they would, in effect, be exempt
> from all of the certificate policies widely practiced for the issuance of
> TLS certificates, which would reduce the 

Re: [TLS] Bikeshedding ECHO

[Erik Nygren]

Are there any objections to "ECH" or should we just go with that?
(I'd like to update the parameter name in SRVB/HTTPSSVC accordingly based
on what gets decided.)


On Wed, May 20, 2020 at 11:37 PM Tommy Pauly  wrote:

> ECH is good. Go for it!
>
> Tommy
>
> On May 20, 2020, at 11:34 AM, Erik Nygren  wrote:
>
> 
>
> ECH works for me.  (I really don't care between ECH and ETCH and thing
> both are fine.)
>
> Erik
>
>
> On Wed, May 20, 2020 at 2:20 PM Christopher Wood 
> wrote:
>
>> On Tue, May 19, 2020, at 8:18 PM, Filippo Valsorda wrote:
>> > As a data point, I was fairly confused when ECHO came up in
>> > conversation, and had to stop to ask what it was. I think I would have
>> > had a better chance of figuring it out from context or search if it
>> > were called ECH, but don't have a strong preference for any specific
>> > name.
>> >
>> > ECH does have a remarkable short Wikipedia disambiguation list, FWIW.
>> > https://en.wikipedia.org/wiki/ECH
>>
>> ECH also works for me.
>>
>> Best,
>> Chris (no hat)
>>
>> ___
>> 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
>
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Bikeshedding ECHO

[Sean Turner]

Okay let’s call this done! ECH it is.

spt

Sent from my iPhone

>> On May 21, 2020, at 11:53, Erik Nygren  wrote:
> 
> Are there any objections to "ECH" or should we just go with that?
> (I'd like to update the parameter name in SRVB/HTTPSSVC accordingly based on 
> what gets decided.)
> 
> 
>> On Wed, May 20, 2020 at 11:37 PM Tommy Pauly  wrote:
>> ECH is good. Go for it!
>> 
>> Tommy
>> 
 On May 20, 2020, at 11:34 AM, Erik Nygren  wrote:
>>> 
>>> 
>>> ECH works for me.  (I really don't care between ECH and ETCH and thing both 
>>> are fine.)
>>> 
>>> Erik
>>> 
>>> 
 On Wed, May 20, 2020 at 2:20 PM Christopher Wood  
 wrote:
 On Tue, May 19, 2020, at 8:18 PM, Filippo Valsorda wrote:
 > As a data point, I was fairly confused when ECHO came up in 
 > conversation, and had to stop to ask what it was. I think I would have 
 > had a better chance of figuring it out from context or search if it 
 > were called ECH, but don't have a strong preference for any specific 
 > name.
 > 
 > ECH does have a remarkable short Wikipedia disambiguation list, FWIW. 
 > https://en.wikipedia.org/wiki/ECH
 
 ECH also works for me.
 
 Best,
 Chris (no hat)
 
 ___
 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
> ___
> 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

[TLS] Banning implicit CIDs in DTLS

[Christopher Wood]

PR #148 in the DTLS 1.3 draft (https://github.com/tlswg/dtls13-spec/pull/148) 
proposes banning implicit CIDs. This comes at an obvious cost in terms of bytes 
on the wire. However, in discussions on a parallel thread [1 and related], it's 
noted that this removes header malleability. 

Given that we don't have backing analysis suggesting that malleability (with 
the other AAD properties) is safe*, the chairs propose merging this PR as-is. 
To that end, please respond to the list by May 28, 2020, indicating whether or 
not you support this PR.

Thanks,
Chris, on behalf of the chairs

*One proposal to address this is by extending the AAD to include the 
pseudo-header. However, the chairs feel this is an unnecessary divergence from 
QUIC.

[1] https://mailarchive.ietf.org/arch/msg/tls/kFnlBW-TmlArcU0lD9UQdf_1t_o/

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Banning implicit CIDs in DTLS

[Eric Rescorla]

This would be my preferred resolution

On Thu, May 21, 2020 at 8:59 AM Christopher Wood 
wrote:

> PR #148 in the DTLS 1.3 draft (
> https://github.com/tlswg/dtls13-spec/pull/148) proposes banning implicit
> CIDs. This comes at an obvious cost in terms of bytes on the wire. However,
> in discussions on a parallel thread [1 and related], it's noted that this
> removes header malleability.
>
> Given that we don't have backing analysis suggesting that malleability
> (with the other AAD properties) is safe*, the chairs propose merging this
> PR as-is. To that end, please respond to the list by May 28, 2020,
> indicating whether or not you support this PR.
>
> Thanks,
> Chris, on behalf of the chairs
>
> *One proposal to address this is by extending the AAD to include the
> pseudo-header. However, the chairs feel this is an unnecessary divergence
> from QUIC.
>
> [1] https://mailarchive.ietf.org/arch/msg/tls/kFnlBW-TmlArcU0lD9UQdf_1t_o/
>
> ___
> 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] Banning implicit CIDs in DTLS

[Thomas Fossati]

Hi Chris,

On 21/05/2020, 17:00, "Christopher Wood"  wrote:
> *One proposal to address this is by extending the AAD to include the
> pseudo-header. However, the chairs feel this is an unnecessary
> divergence from QUIC.

I don't understand the "unnecessary" in the above para, i.e., why are we
so tied to QUIC in this case?  I'm asking because it looks like this was
a core criterion in the Chairs' proposal.

Cheers, t

IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Bikeshedding ECHO

[Gary Gapinski]

On 5/21/20 11:52 AM, Erik Nygren wrote:

Are there any objections to "ECH" or should we just go with that?


I have no objection, but would benefit from consensus on whether it 
(ECH) is an initialism or acronym. My opinion is that it is best as an 
initialism (as is, e.g., TLS).


___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Bikeshedding ECHO

[Christopher Wood]

To make it official, here's a PR making that change:

   https://github.com/tlswg/draft-ietf-tls-esni/pull/236

Please have a look. I'll merge in the next day or so.

Thanks!
Chris (no hat)

On Thu, May 21, 2020, at 8:58 AM, Sean Turner wrote:
>  Okay let’s call this done! ECH it is.
> 
> spt
> 
> Sent from my iPhone
> 
> > On May 21, 2020, at 11:53, Erik Nygren  wrote:
> > 
> > Are there any objections to "ECH" or should we just go with that?
> > (I'd like to update the parameter name in SRVB/HTTPSSVC accordingly based 
> > on what gets decided.)
> > 
> > 
> > On Wed, May 20, 2020 at 11:37 PM Tommy Pauly  wrote:
> >> ECH is good. Go for it!
> >> 
> >> Tommy
> >> 
> >>> On May 20, 2020, at 11:34 AM, Erik Nygren  >>> > wrote:
> >>> 
> >>> 
> >>> ECH works for me. (I really don't care between ECH and ETCH and thing 
> >>> both are fine.)
> >>> 
> >>>  Erik
> >>> 
> >>> 
> >>> On Wed, May 20, 2020 at 2:20 PM Christopher Wood  
> >>> wrote:
>  On Tue, May 19, 2020, at 8:18 PM, Filippo Valsorda wrote:
>   > As a data point, I was fairly confused when ECHO came up in 
>   > conversation, and had to stop to ask what it was. I think I would 
>  have 
>   > had a better chance of figuring it out from context or search if it 
>   > were called ECH, but don't have a strong preference for any specific 
>   > name.
>   > 
>   > ECH does have a remarkable short Wikipedia disambiguation list, FWIW. 
>   > https://en.wikipedia.org/wiki/ECH
>  
>   ECH also works for me.
>  
>   Best,
>   Chris (no hat)
>  
>   ___
>   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
> > ___
> > 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
>

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Bikeshedding ECHO

[Eric Rescorla]

I actually already merged it :)

On Thu, May 21, 2020 at 12:48 PM Christopher Wood 
wrote:

> To make it official, here's a PR making that change:
>
>https://github.com/tlswg/draft-ietf-tls-esni/pull/236
>
> Please have a look. I'll merge in the next day or so.
>
> Thanks!
> Chris (no hat)
>
> On Thu, May 21, 2020, at 8:58 AM, Sean Turner wrote:
> >  Okay let’s call this done! ECH it is.
> >
> > spt
> >
> > Sent from my iPhone
> >
> > > On May 21, 2020, at 11:53, Erik Nygren  wrote:
> > >
> > > Are there any objections to "ECH" or should we just go with that?
> > > (I'd like to update the parameter name in SRVB/HTTPSSVC accordingly
> based on what gets decided.)
> > >
> > >
> > > On Wed, May 20, 2020 at 11:37 PM Tommy Pauly  wrote:
> > >> ECH is good. Go for it!
> > >>
> > >> Tommy
> > >>
> > >>> On May 20, 2020, at 11:34 AM, Erik Nygren  > wrote:
> > >>>
> > >>>
> > >>> ECH works for me. (I really don't care between ECH and ETCH and
> thing both are fine.)
> > >>>
> > >>>  Erik
> > >>>
> > >>>
> > >>> On Wed, May 20, 2020 at 2:20 PM Christopher Wood <
> c...@heapingbits.net> wrote:
> >  On Tue, May 19, 2020, at 8:18 PM, Filippo Valsorda wrote:
> >   > As a data point, I was fairly confused when ECHO came up in
> >   > conversation, and had to stop to ask what it was. I think I
> would have
> >   > had a better chance of figuring it out from context or search if
> it
> >   > were called ECH, but don't have a strong preference for any
> specific
> >   > name.
> >   >
> >   > ECH does have a remarkable short Wikipedia disambiguation list,
> FWIW.
> >   > https://en.wikipedia.org/wiki/ECH
> > 
> >   ECH also works for me.
> > 
> >   Best,
> >   Chris (no hat)
> > 
> >   ___
> >   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
> > > ___
> > > 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
> >
>
> ___
> 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] Banning implicit CIDs in DTLS

[Martin Thomson]

On Fri, May 22, 2020, at 01:58, Christopher Wood wrote:
> PR #148 

I think that this is the right solution to this problem.

> *One proposal to address this is by extending the AAD to include the 
> pseudo-header. However, the chairs feel this is an unnecessary 
> divergence from QUIC.

I'm not sure that we need to concern ourselves with avoiding divergence.  I 
would instead point to the advantages of only authenticating what is on the 
wire: with multiple records in a datagram, having to prepend to the AAD means a 
performance hit of some kind.  Either because you need to pass AAD in two 
chunks (one for the extra bit, one for the on-the-wire header), which is not 
commonly supported in APIs, or you need to move or copy stuff around to create 
a single contiguous AAD.  The result is a small amount of complexity.

I can probably make a case for not including connection ID in the AAD entirely 
on the basis of it being analogous to IP or port, but unless that was formally 
verified, I wouldn't want to rely on that. So #148 WFM.  The number of cases 
where a connection ID can be omitted are vanishingly small anyway.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Banning implicit CIDs in DTLS

[Christopher Wood]

On Thu, May 21, 2020, at 9:22 AM, Thomas Fossati wrote:
> Hi Chris,
> 
> On 21/05/2020, 17:00, "Christopher Wood"  wrote:
> > *One proposal to address this is by extending the AAD to include the
> > pseudo-header. However, the chairs feel this is an unnecessary
> > divergence from QUIC.
> 
> I don't understand the "unnecessary" in the above para, i.e., why are we
> so tied to QUIC in this case?  I'm asking because it looks like this was
> a core criterion in the Chairs' proposal.

Sorry for the confusion! The point here was that QUIC authenticates what's on 
the wire, which we felt was important. I should have spelled that out. There 
are of course other things to consider, as Martin points out.

Best,
Chris

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] consensus call: changing cTLS and ECH to standards track

[Sean Turner]

It looks like the intended status for both draft-ietf-tls-ctls (aka cTLS) and 
draft-ietf-tls-esni (aka ECH) should be changed. It appears that both should be 
set to standards track; cTLS is now Informational and ECH is Experimental. If 
you object to changing the track for either of these drafts please send an 
email to the list stating why by 2359 UTC on 5 June 2020.

Cheers,
spt (for the Chairs)
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] adoption call for draft-dt-tls-external-psk-guidance

[Sean Turner]

This is a WG document adoption call for draft-dt-tls-external-psk-guidance (aka 
Guidance for External PSK Usage in TLS). This effort was kicked off @IETF106 by 
Ben Kaduk and supported by others in the audience. There was also some nominal 
amount of support for adopting the draft at the last virtual interim though no 
formal adoption call was issued at the interim.

If you support adopting this draft as a WG Document, then please send email 
indicating your support to the list. If you have any comments or reservations 
send them to the list too.

This adoption call completes at 2359 UTC 5 June 2020.

Cheers,
spt (for the chairs)
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] The TLS WG has placed draft-dt-tls-external-psk-guidance in state "Call For Adoption By WG Issued"

[IETF Secretariat]

The TLS WG has placed draft-dt-tls-external-psk-guidance in state
Call For Adoption By WG Issued (entered by Sean Turner)

The document is available at
https://datatracker.ietf.org/doc/draft-dt-tls-external-psk-guidance/


___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] adoption call for draft-dt-tls-external-psk-guidance

[Russ Housley]

I support adoption.

> On May 21, 2020, at 10:12 PM, Sean Turner  wrote:
> 
> This is a WG document adoption call for draft-dt-tls-external-psk-guidance 
> (aka Guidance for External PSK Usage in TLS). This effort was kicked off 
> @IETF106 by Ben Kaduk and supported by others in the audience. There was also 
> some nominal amount of support for adopting the draft at the last virtual 
> interim though no formal adoption call was issued at the interim.
> 
> If you support adopting this draft as a WG Document, then please send email 
> indicating your support to the list. If you have any comments or reservations 
> send them to the list too.
> 
> This adoption call completes at 2359 UTC 5 June 2020.
> 
> Cheers,
> spt (for the chairs)
> ___
> 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