Re: [TLS] Adoption call for draft-salowey-tls-rfc8447bis

[Martin Thomson]

One additional bug I noticed:

Exporter Value  | Recommended |
|-|
client finished | Y |
server finished | Y |
master secret   | Y |
key expansion   | Y |

These should probably be 'D', based on the note in RFC 5705 (which oddly, 
references itself in the equivalent of third person here):

   Note: (1) These entries are reserved and MUST NOT be used for the
   purpose described in RFC 5705, in order to avoid confusion with
   similar, but distinct, use in RFC 5246.

On Thu, Feb 24, 2022, at 08:41, Martin Thomson wrote:
> Adopt.
>
> I found the changes from 8447 hard to find without a diff:
>
> https://www.ietf.org/rfcdiff?url1=rfc8447&url2=draft-salowey-tls-rfc8447bis-01
>
> Some comments on the content:
>
> * Recommended = D requires standards action.  I think that you might 
> want IETF consensus instead.
>
> * A lot of the "changes" here have already been carried out.  Perhaps 
> this document can be a lot shorter.  I still think that the generic 
> text is useful to keep, but there are sections that concentrate only on 
> stuff that has already been done by IANA.  Maybe those sections can go.
>
> * This cites a specific draft version of TLS 1.3 rather than RFC 8446 
> and I can't see why.
>
> On Sat, Feb 19, 2022, at 14:32, Christopher Wood wrote:
>> Hi folks,
>>
>> Following up on the TLS WG meeting in IETF 112 and draft update in 
>> December, this email begins an adoption call for 
>> draft-salowey-tls-rfc8447bis, located here:
>>
>>https://datatracker.ietf.org/doc/draft-salowey-tls-rfc8447bis/
>>   
>> This adoption call will last for two weeks. Please reply to this email 
>> by March 4 indicating whether you think this document should be adopted 
>> and worked on by the WG.
>>
>> Thanks,
>> Chris
>>
>>
>> ___
>> 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] Adoption call for draft-salowey-tls-rfc8447bis

[Martin Thomson]

Adopt.

I found the changes from 8447 hard to find without a diff:

https://www.ietf.org/rfcdiff?url1=rfc8447&url2=draft-salowey-tls-rfc8447bis-01

Some comments on the content:

* Recommended = D requires standards action.  I think that you might want IETF 
consensus instead.

* A lot of the "changes" here have already been carried out.  Perhaps this 
document can be a lot shorter.  I still think that the generic text is useful 
to keep, but there are sections that concentrate only on stuff that has already 
been done by IANA.  Maybe those sections can go.

* This cites a specific draft version of TLS 1.3 rather than RFC 8446 and I 
can't see why.

On Sat, Feb 19, 2022, at 14:32, Christopher Wood wrote:
> Hi folks,
>
> Following up on the TLS WG meeting in IETF 112 and draft update in 
> December, this email begins an adoption call for 
> draft-salowey-tls-rfc8447bis, located here:
>
>https://datatracker.ietf.org/doc/draft-salowey-tls-rfc8447bis/
>   
> This adoption call will last for two weeks. Please reply to this email 
> by March 4 indicating whether you think this document should be adopted 
> and worked on by the WG.
>
> Thanks,
> Chris
>
>
> ___
> 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] tlsflags and "responses"

[Yoav Nir]

Hi.

I have merged the PR following review and proposed changes by Chris and Martin 
Thomson.

The only point that remains open is Ekr’a suggestion to allow (require?) 
sending the extension when empty.

Yoav

> On 22 Feb 2022, at 7:35, Yoav Nir  wrote:
> 
> I have just submitted PR #20 to allow unacknowledged flags.  It is a rewrite 
> of section 3 (rules)
> 
> https://github.com/tlswg/tls-flags/pull/20 
> 
> 
> It still requires that the flag extension not be sent when empty.  Let me 
> know if that’s a problem as well.
> 
> Yoav
> 
>> On 21 Feb 2022, at 2:21, Martin Thomson > > wrote:
>> 
>> I missed this text in draft-ietf-tls-tlsflags:
>> 
>>   A server that supports this extension and also supports at least one
>>   of the flag-type features that use this extension and that were
>>   declared by the ClientHello extension SHALL send this extension with
>>   the intersection of the flags it supports with the flags declared by
>>   the client.  
>> 
>> While sloppy on my part [1], I want to make it clear that this is a 
>> show-stopper for me. Requiring an echo prevents a flag extension from 
>> attaching semantics to a "response".
>> 
>> I agree with Ilari's earlier point that these should work just like 
>> extensions.  If the server has no need to echo a flag, it should not be 
>> required to do that.  That allows the flag value in a "response" to carry 
>> semantics.
>> 
>> Cheers,
>> Martin
>> 
>> [1] I missed this in the second WGLC, though in my defense, I don't think 
>> the resolution and changes resulting from the first WGLC were very clearly 
>> communicated.
>> 
>> ___
>> 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] Adoption call for draft-salowey-tls-rfc8447bis

[Eric Rescorla]

I support adoption.


On Wed, Feb 23, 2022 at 10:45 AM Salz, Rich  wrote:

> Oops.  Reply over reply-all, not common :)
>
> On 2/23/22, 12:34 PM, "Christopher Wood"  wrote:
>
> Oops — I think you accidentally replied only to me. Would you mind
> replying on the list as well?
>
> > On Feb 19, 2022, at 7:23 AM, Salz, Rich  wrote:
> >
> >>  Following up on the TLS WG meeting in IETF 112 and draft update in
> December, this email begins an adoption call for
> draft-salowey-tls-rfc8447bis, located here:
> >
> > I support adoption and will help read/review/comment on the doc.
> >
>
>
> ___
> 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] Adoption call for draft-salowey-tls-rfc8447bis

[Salz, Rich]

Oops.  Reply over reply-all, not common :)

On 2/23/22, 12:34 PM, "Christopher Wood"  wrote:

Oops — I think you accidentally replied only to me. Would you mind replying 
on the list as well?

> On Feb 19, 2022, at 7:23 AM, Salz, Rich  wrote:
> 
>>  Following up on the TLS WG meeting in IETF 112 and draft update in 
December, this email begins an adoption call for draft-salowey-tls-rfc8447bis, 
located here:
> 
> I support adoption and will help read/review/comment on the doc. 
> 


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

Re: [TLS] dnssec_chain entry in IANA registry seems to be missing CT

[Eric Rescorla]

On Wed, Feb 23, 2022 at 6:25 AM Salz, Rich  wrote:

> >It is probably "best" (for some definition of "best") to publish an
> RFC
> that Updates: 9102 and has the revised directive to IANA.
>
> I hope that is excessive.
>
> >Probably an errata report should be filed against RFC 9102 regardless.
> IANA might be able to use the errata report without the updating RFC,
> but you'd have to ask.
>
> I would go this route.  File an errata, and email the registry and see if
> that's sufficient documentation.
>

Seems like it's a publicly available permanent document, so it should be
enough. If IANA doesn't think so, well, we're preparing 8447-bis

-Ekr


>
> ___
> 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] dnssec_chain entry in IANA registry seems to be missing CT

[Salz, Rich]

>It is probably "best" (for some definition of "best") to publish an RFC
that Updates: 9102 and has the revised directive to IANA.

I hope that is excessive.

>Probably an errata report should be filed against RFC 9102 regardless.
IANA might be able to use the errata report without the updating RFC,
but you'd have to ask.

I would go this route.  File an errata, and email the registry and see if 
that's sufficient documentation.

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

Re: [TLS] DTLS for Delegated Credentials (draft-ietf-tls-subcerts)?

[Hannes Tschofenig]

Hi Sean, Hi all,

I think the document should also include a reference to DTLS since there is no 
reason that sub-certs do not apply to DTLS as well.

Ciao
Hannes


-Original Message-
From: TLS  On Behalf Of Sean Turner
Sent: Wednesday, February 16, 2022 9:26 PM
To: TLS List 
Subject: [TLS] DTLS for Delegated Credentials (draft-ietf-tls-subcerts)?

Hi

During Ben Kaduk’s AD review of draft-ietf-tls-subcerts, he noted that we need 
to address whether the I-D can also apply to DTLS. This might be useful for 
WebRTC, for example.

Right now the I-D exclusively mentions TLS. The fix might be as easy as a 
global replace of TLS with (D)TLS. Can anybody think of a reason to preclude 
DTLS?

We also need to say one way or the other becase we need to tell IANA to what to 
put in the “DTLS-Only” column when registering the “delegated_credentials” 
extension.

Cheers,
spt (for the chairs)
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
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