Re: [TLS] Draft TLS Extension for Path Validation

[Robert Moskowitz]

I am working with Ashley and Rob Segers of FAA on this.  I don't make 
any claims of being able to comment on the TLS content.  I am providing 
IETF mentoring.  I work with Rob in ICAO TFSG items.



We want this discussed at IETF114.  Perhaps in SECDISPATCH if it does 
not need its own BOF.  Or as a TLS topic.


Bob

On 5/25/22 12:40, Ashley Kopman wrote:

Hi TLS,

I have just submitted a draft TLS Extension for Path Validation 
https://www.ietf.org/archive/id/draft-segers-tls-cert-validation-ext-00.txt 



The proposal is for a Path Validation Extension to provide a 
new protocol for TLS/DTLS allowing inclusion of certificate path 
validation information in the TLS/DTLS handshake. Specifically, 
it covers the use of Server-based Certificate Validation Protocol 
(SCVP) for path validation.


We are also finalizing a use case for civil aviation air-to-ground 
communications which should be submitted in the next day.


Please have a look at the draft and provide feedback.

Thank you,

Ashley Kopman




___
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] Draft TLS Extension for Path Validation

[Robert Moskowitz]

Peter,

SCVP *IS* being used in aviation applications today in ground-to-ground 
cases.  But the comm cost for air-to-ground is excessive.  So this is 
directly what at least US FAA and EU EUROCONTROL are implementing.


Aviation, through ICAO, is building their own PKI.  The CP is in final 
drafting and a number of CA companies have signed on.  Testbed testing 
for various applications are in progress.  I just got off a video call 
for a PoC planning session that will cover activities through the end of 
the year.


Aviation is finally going digital.

Ashley is working on the use case draft which will point to a slide deck 
as well that shows the use case.


So this is important in one community:  Civil Aviation.

Bob

On 5/26/22 04:46, Peter Gutmann wrote:

An indirect question on the overall premise here: Given that SCVP is
essentially nonexistent (unless there's some niche market somewhere using it
that I'm not aware of, which is why I didn't use an unqualified
"nonexistent"), does it really matter much?  If an RFC falls in the forest and
all that...

Peter.

___
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] Draft TLS Extension for Path Validation

[Robert Moskowitz]

Oh, and it is this community's input to see that this is well designed 
as once something is put into a plane, it tends to be there for years...


On 5/26/22 04:46, Peter Gutmann wrote:

An indirect question on the overall premise here: Given that SCVP is
essentially nonexistent (unless there's some niche market somewhere using it
that I'm not aware of, which is why I didn't use an unqualified
"nonexistent"), does it really matter much?  If an RFC falls in the forest and
all that...

Peter.

___
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] Draft TLS Extension for Path Validation

[Robert Moskowitz]

This is the Aviation use case I mentioned in earlier mails.

I will be submitting a BOF request tomorrow, performa.

Of course it is for the ADs to decide if this is a standalone BOF or a 
20min slot in SECDISPATCH.


How much time people want to discuss it is in large measure related to 
the discussion we engender here.


Thank you for your attention.  And thank you for reviewing and making 
this a solid design that we can get deployed for avaiation Air-to-ground 
and any similar use case.


Bob

On 5/26/22 19:43, Ashley Kopman wrote:


The use case for the D(TLS) Path Validation extension in civil 
aviation has been submitted 
https://www.ietf.org/archive/id/draft-segers-tls-cert-val-ext-use-case-00.txt there 
is also referenced slide deck available 
http://conceptsbeyond.com/resources/SCVPValidationRequest_UseCase_CB.pdf


Thank you,
Ashley Kopman

On May 26, 2022, at 8:36 AM, Ashley Kopman 
 wrote:


Ilari,

Thank you for your feedback.

You are correct in assuming that this was designed after the OCSP 
status_request extension. It is a valid point that the extension can 
likely be omitted from the server hello. The intent was to 
communicate to the client that the server supports the extension and 
will respond with the path validation information. However, since it 
is allowed for the server to respond with the extension and then not 
supply the path validation, it is not very useful overhead. I will 
remove the extension from the server hello.


You are also correct that sending the certificate chain becomes 
unnecessary. It was my intent to communicate that, but looking back 
at the draft, I don’t think I made it clear. I will add it.


Thank you,

Ashley


On May 25, 2022, at 2:23 PM, Ilari Liusvaara 
 wrote:


On Wed, May 25, 2022 at 12:40:13PM -0400, Ashley Kopman wrote:

Hi TLS,

I have just submitted a draft TLS Extension for Path Validation
https://www.ietf.org/archive/id/draft-segers-tls-cert-validation-ext-00.txt 



The proposal is for a Path Validation Extension to provide a new
protocol for TLS/DTLS allowing inclusion of certificate path
validation information in the TLS/DTLS handshake. Specifically, it
covers the use of Server-based Certificate Validation Protocol
(SCVP) for path validation.


Looking at how this is integrated to (D)TLS:


For (D)TLS 1.2, the server extension does not seem to be technically
necressary, and omitting it could simplify things. Yes, this design
is the same as one used for OCSP stapling (status_request), but I
found the server hello extension in OCSP to be seemingly unnecressary
extra complexity.

For (D)TLS 1.3, why there are seemingly two server extensions, one in
server hello, which is usually only used for low-level crypto stuff,
which this is not, and another in certificate message (which makes
sense for certificate-related thing.


And this is maybe a stupid question, but I didn't find an answer by
quickly looking at the draft nor the SCVP RFC, does the server need to
send the certificate chain to the client if it sends the SCVP response,
or just the end-entity certificate? Omitting the chain could save
quite a bit of handshake size.



-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

[TLS] Fwd: New BOF request revision uploaded: bofreq-moskowitz-scvp-validation-request-tls-extension-00

[Robert Moskowitz]

I have submitted the BOF request.  The ADs and this workgroup will 
decide how they want to handle getting this work adopted.


Bob


 Forwarded Message 
Subject: 	New BOF request revision uploaded: 
bofreq-moskowitz-scvp-validation-request-tls-extension-00

Date:   Fri, 27 May 2022 05:40:58 -0700
From:   IETF Secretariat 
To: 	The IAB , The IESG , 
r...@labs.htt-consult.com




Robert Moskowitz has uploaded 
bofreq-moskowitz-scvp-validation-request-tls-extension-00 See 
https://datatracker.ietf.org/doc/bofreq-moskowitz-scvp-validation-request-tls-extension/


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

[TLS] SCHC for DTLS

[Robert Moskowitz]

Is there any activity to define SCHC rules for DTLS?

I want this for Unmanned Aircraft (UA) Network Remote ID (Net-RID) 
communications from the UA to the Net-RID Service Provider (SP).


See

https://datatracker.ietf.org/doc/draft-moskowitz-drip-secure-nrid-c2/

I am compressing ESP traffic using rfc 8750 and:

https://datatracker.ietf.org/doc/draft-mglt-ipsecme-diet-esp/

SCHC is negotiated in IKE (and will be in HIP) and SA tables allow the 
ESP receiver to recognize a SCHC compressed ESP Header and act properly.


It is not so simple with DTLS.  First UDP is below DTLS, so how do you 
compress it?  The way I see it, SCHC would need to be assigned an IP 
Protocol type so that the transport processing can start right up with 
the SCHC rule for UDP and then on to DTLS and then the cipher.


Or at least how I see the challenge.

So I am looking for any extant work on SCHC for DTLS and/or interest in 
this activity.


The CoAP SCHC work, rfc 8824, dodge DTLS compression.  Or that is how I 
read it.


Thanks

Bob

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

Re: [TLS] SCHC for DTLS

[Robert Moskowitz]

Greetings Hannes,

This is for the record layer.  And I really don't know how much would be 
gained.


But as I would see it, this use of SCHC would be for UDP/DTLS/cipher.  
Since it is starting with UDP, SCHC would have to be an IP Protocol (not 
currently defined as such).  So you loose 1 byte for the SCHC rule, 
against the 8 probably saved in compressing UDP to 0 bytes.  Then there 
is the cipher.  Try AES-GCM-12; what is currently used for the IV?  Can 
something like rfc8750 be added to use the seq # in the DTLS header and 
gain maybe 16 bytes?  I really don't know the DTLS header at all.  I 
have tried to find some decent layout as I am use to for ESP in 4303 
(Fig 1) for side-by-side comparison.


But if it means being able to fit over some UHF carrier for unmanned 
aircraft (UA) Network Remote ID (Net-RID) and Command and Control (C2)?  
Worth the effort.


So this is not something I could do myself, but something that I see 
using and thus pitching in on doing it.


On 5/30/22 05:33, Hannes Tschofenig wrote:


Bob, is this about compressing the DTLS record layer or the DTLS 
handshake protocol?


For the former, I wonder how much is there actually to compress (when 
using DTLS 1.3)?


*From:* TLS  *On Behalf Of * Eric Rescorla
*Sent:* Friday, May 27, 2022 5:30 PM
*To:* Robert Moskowitz 
*Cc:*  
*Subject:* Re: [TLS] SCHC for DTLS

On Fri, May 27, 2022 at 6:27 AM Robert Moskowitz 
 wrote:


Is there any activity to define SCHC rules for DTLS?

Not to my knowledge.

-Ekr


I want this for Unmanned Aircraft (UA) Network Remote ID (Net-RID)
communications from the UA to the Net-RID Service Provider (SP).

See

https://datatracker.ietf.org/doc/draft-moskowitz-drip-secure-nrid-c2/

I am compressing ESP traffic using rfc 8750 and:

https://datatracker.ietf.org/doc/draft-mglt-ipsecme-diet-esp/

SCHC is negotiated in IKE (and will be in HIP) and SA tables allow
the
ESP receiver to recognize a SCHC compressed ESP Header and act
properly.

It is not so simple with DTLS.  First UDP is below DTLS, so how do
you
compress it?  The way I see it, SCHC would need to be assigned an IP
Protocol type so that the transport processing can start right up
with
the SCHC rule for UDP and then on to DTLS and then the cipher.

Or at least how I see the challenge.

So I am looking for any extant work on SCHC for DTLS and/or
interest in
this activity.

The CoAP SCHC work, rfc 8824, dodge DTLS compression. Or that is
how I
read it.

Thanks

Bob

___
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

Re: [TLS] SCHC for DTLS

[Robert Moskowitz]

Great to know.  thanks.  My feable attempts to find this were coming up 
empty.  But now I should be able to put some things together.


I am assuming that the DTLS header is part of the AEAD protection. Thus 
I can squeeze out the UDP CRC?


I recall seeing length in the DTLS header, but I do not have it in front 
of me.  Also want to drop that from the UDP header...


Anyway, this is good info.

On 5/30/22 12:12, Eric Rescorla wrote:
We spent a fair bit of time working to shrink the DTLS 1.3 record 
layer, so I'm not sure how much room there is for optimization.
See: 
https://www.rfc-editor.org/rfc/rfc9147.html#name-the-dtls-record-layer


Specifically, the longest header (w/o CID) is 5 octets and the 
shortest is 2 octets. The sequence number is used for the IV, so 
there's no extra there.


-Ekr

On Mon, May 30, 2022 at 6:28 AM Robert Moskowitz 
 wrote:


Greetings Hannes,

This is for the record layer.  And I really don't know how much
would be gained.

But as I would see it, this use of SCHC would be for
UDP/DTLS/cipher.  Since it is starting with UDP, SCHC would have
to be an IP Protocol (not currently defined as such).  So you
loose 1 byte for the SCHC rule, against the 8 probably saved in
compressing UDP to 0 bytes.  Then there is the cipher.  Try
AES-GCM-12; what is currently used for the IV?  Can something like
rfc8750 be added to use the seq # in the DTLS header and gain
maybe 16 bytes? I really don't know the DTLS header at all.  I
have tried to find some decent layout as I am use to for ESP in
4303 (Fig 1) for side-by-side comparison.

But if it means being able to fit over some UHF carrier for
unmanned aircraft (UA) Network Remote ID (Net-RID) and Command and
Control (C2)?  Worth the effort.

So this is not something I could do myself, but something that I
see using and thus pitching in on doing it.

On 5/30/22 05:33, Hannes Tschofenig wrote:


Bob, is this about compressing the DTLS record layer or the DTLS
handshake protocol?

For the former, I wonder how much is there actually to compress
(when using DTLS 1.3)?

*From:* TLS  <mailto:tls-boun...@ietf.org>
*On Behalf Of * Eric Rescorla
*Sent:* Friday, May 27, 2022 5:30 PM
*To:* Robert Moskowitz 
<mailto:rgm-...@htt-consult.com>
*Cc:*  <mailto:tls@ietf.org> 
<mailto:tls@ietf.org>
*Subject:* Re: [TLS] SCHC for DTLS

On Fri, May 27, 2022 at 6:27 AM Robert Moskowitz
 wrote:

Is there any activity to define SCHC rules for DTLS?

Not to my knowledge.

-Ekr


I want this for Unmanned Aircraft (UA) Network Remote ID
(Net-RID)
communications from the UA to the Net-RID Service Provider (SP).

See

https://datatracker.ietf.org/doc/draft-moskowitz-drip-secure-nrid-c2/

I am compressing ESP traffic using rfc 8750 and:

https://datatracker.ietf.org/doc/draft-mglt-ipsecme-diet-esp/

SCHC is negotiated in IKE (and will be in HIP) and SA tables
allow the
ESP receiver to recognize a SCHC compressed ESP Header and
act properly.

It is not so simple with DTLS.  First UDP is below DTLS, so
how do you
compress it?  The way I see it, SCHC would need to be
assigned an IP
Protocol type so that the transport processing can start
right up with
the SCHC rule for UDP and then on to DTLS and then the cipher.

Or at least how I see the challenge.

So I am looking for any extant work on SCHC for DTLS and/or
interest in
this activity.

The CoAP SCHC work, rfc 8824, dodge DTLS compression.  Or
that is how I
read it.

Thanks

Bob

___
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

Re: [TLS] SCHC for DTLS

[Robert Moskowitz]

On 5/30/22 13:03, Eric Rescorla wrote:



On Mon, May 30, 2022 at 9:38 AM Robert Moskowitz 
 wrote:


Great to know.  thanks.  My feable attempts to find this were
coming up empty.  But now I should be able to put some things
together.

I am assuming that the DTLS header is part of the AEAD
protection.  Thus I can squeeze out the UDP CRC?


The DTLS header is included in the AD, yes.


I recall seeing length in the DTLS header, but I do not have it in
front of me.  Also want to drop that from the UDP header...


DTLS 1.3 has a header mode in which it omits the length and just uses 
the UDP length. That may be easier.


My way of thinking is that the DTLS length is protected.  So the SCHC 
rule has the source and dest UDP ports as static and derives the UDP 
length from the DTLS length.  The CRC is just built as if the ICV is 
bad, the packet gets dropped there.


So pick up 7 bytes.  May or may not make a difference...

Well actually the target size is 16 bytes, as this is what is spent in 
MAVlink for Seq#, CRC, and keyed MAC.  You can't equal that with 8 bytes 
UDP, 12 bytes GCM-12, and whatever DTLS is.


One thing we have discussed on the IPSECME list is inbound packet 
processing.  With the IP protocol being ESP, how does the ESP layer 
'know' that this is a diet-esp compressed header?  Well the first byte 
would have to map to a SPI that is uniquely diet-esp and rule out 
looking at 4-byte full SPIs.  This (inbound SPI selection) can be 
controlled by IKE.


So a similar thing here.  Assume that UDP is compressed to zero, so if 
the beginning of the DTLS header would look like a UDP source port, but 
map to the SCHC rule, then for this limited use case, it would not be 
necessary to have SCHC as an IP protocol and use 1 byte for 
over-the-wire SCHC rule.




-Ekr


Anyway, this is good info.

On 5/30/22 12:12, Eric Rescorla wrote:

We spent a fair bit of time working to shrink the DTLS 1.3 record
layer, so I'm not sure how much room there is for optimization.
See:
https://www.rfc-editor.org/rfc/rfc9147.html#name-the-dtls-record-layer

Specifically, the longest header (w/o CID) is 5 octets and the
shortest is 2 octets. The sequence number is used for the IV, so
there's no extra there.

-Ekr

On Mon, May 30, 2022 at 6:28 AM Robert Moskowitz
 wrote:

Greetings Hannes,

This is for the record layer.  And I really don't know how
much would be gained.

But as I would see it, this use of SCHC would be for
UDP/DTLS/cipher.  Since it is starting with UDP, SCHC would
have to be an IP Protocol (not currently defined as such). 
So you loose 1 byte for the SCHC rule, against the 8 probably
saved in compressing UDP to 0 bytes.  Then there is the
cipher.  Try AES-GCM-12; what is currently used for the IV? 
Can something like rfc8750 be added to use the seq # in the
DTLS header and gain maybe 16 bytes?  I really don't know the
DTLS header at all.  I have tried to find some decent layout
as I am use to for ESP in 4303 (Fig 1) for side-by-side
comparison.

But if it means being able to fit over some UHF carrier for
unmanned aircraft (UA) Network Remote ID (Net-RID) and
Command and Control (C2)?  Worth the effort.

So this is not something I could do myself, but something
that I see using and thus pitching in on doing it.

On 5/30/22 05:33, Hannes Tschofenig wrote:


Bob, is this about compressing the DTLS record layer or the
DTLS handshake protocol?

For the former, I wonder how much is there actually to
compress (when using DTLS 1.3)?

*From:* TLS 
<mailto:tls-boun...@ietf.org> *On Behalf Of * Eric Rescorla
*Sent:* Friday, May 27, 2022 5:30 PM
*To:* Robert Moskowitz 
<mailto:rgm-...@htt-consult.com>
*Cc:*  <mailto:tls@ietf.org> 
<mailto:tls@ietf.org>
*Subject:* Re: [TLS] SCHC for DTLS

On Fri, May 27, 2022 at 6:27 AM Robert Moskowitz
 wrote:

Is there any activity to define SCHC rules for DTLS?

Not to my knowledge.

-Ekr


I want this for Unmanned Aircraft (UA) Network Remote ID
(Net-RID)
communications from the UA to the Net-RID Service
Provider (SP).

See


https://datatracker.ietf.org/doc/draft-moskowitz-drip-secure-nrid-c2/

I am compressing ESP traffic using rfc 8750 and:

https://datatracker.ietf.org/doc/draft-mglt-ipsecme-diet-esp/

SCHC is negotiated in IKE (and will be in HIP) and SA
tables allow the
ESP receiver to recognize a SCHC compressed ESP Header
and act properly.

It is not so simple with DTLS. First UDP is be

[TLS] Fwd: New Version Notification for draft-moskowitz-lpwan-ipnumber-00.txt

[Robert Moskowitz]

Here is my draft for asking for an Internet Protocol Number assigned to 
SCHC as we have been discussing on both the Ipsecme and Tls lists.


I also posted this to the lpwan list.

I welcome comments and help (co-authors welcomed!).

Bob



 Forwarded Message 
Subject: 	New Version Notification for 
draft-moskowitz-lpwan-ipnumber-00.txt

Date:   Fri, 03 Jun 2022 08:33:59 -0700
From:   internet-dra...@ietf.org
To: Robert Moskowitz 




A new version of I-D, draft-moskowitz-lpwan-ipnumber-00.txt
has been successfully submitted by Robert Moskowitz and posted to the
IETF repository.

Name: draft-moskowitz-lpwan-ipnumber
Revision: 00
Title: IP Number for SCHC
Document date: 2022-06-03
Group: Individual Submission
Pages: 6
URL: https://www.ietf.org/archive/id/draft-moskowitz-lpwan-ipnumber-00.txt
Status: https://datatracker.ietf.org/doc/draft-moskowitz-lpwan-ipnumber/
Html: https://www.ietf.org/archive/id/draft-moskowitz-lpwan-ipnumber-00.html
Htmlized: 
https://datatracker.ietf.org/doc/html/draft-moskowitz-lpwan-ipnumber



Abstract:
This document requests an Internet Protocol Number assignment for
SCHC so that SCHC can be used for IP independent SCHC of other
transports such as UDP and ESP.



The IETF Secretariat

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

[TLS] DTLS support of SCHC

[Robert Moskowitz]

I have been doing more research on using SCHC with DTLS for general UDP 
applications.


For this I am using MAVlink

https://mavlink.io/en/

As my UDP app example.

I see EKR's point on the small header design of DTLS 1.3 per RFC9147 fig 
3.  I will use:


2-byte CID
1-byte Seq# (same as MAVlink)
2-byte Length (max MAVlink after compression is 263 bytes)

The SCHC rules allow for compressing 16 bytes within MAVlink and 
eliminating transport of the UDP header.


The challenge is without the UDP header, and assuming NextHeader is UDP, 
how does the UDP layer handle this datagram?  The UDP Destination Port 
is the DTLS Seq and 1st byte of the length.


This seems to fraught with failure modes, and that the NextHeader really 
MUST be SCHC as I have defined in draft-moskowitz-lpwan-ipnumber.


This is really the first question:  Is there anyway to do this without 
adding SCHC as an IP Number?


Next is does the RuleID need to be explicit in the packet or can it be 
implicit?  I think that would depend on the IP Source Addr.  If this is 
the ONLY SCHC RuleID from that addr, then, yes it can be implicit, 
saving the byte.


Finally setting up SCHC.  Is static configuration the only option? Well 
for MAVlink use, this is not so much an issue, as there is a limited 
pairing between UA/GCS.  But should there be a DTLS SCHC negotiation as 
link in draft-mglt-ipsecme-ikev2-diet-esp-extension?


I welcome your comments/observations.

Oh, why work hard to save 24 bytes over the 'wire'?  For some wireless 
links that might be all it takes to result in fragmentation and 
potentially doubling the link usage.


Other UDP apps might have other savings.  This might have general 
aviation usage beyond what I have looked at todate.


Thanks.

Bob

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

[TLS] Why TLSA RR and not CERT RR?

[Robert Moskowitz]

Recently I have been in a discussion about DNS RR that hold X.509 
certificates.


I am asking this here, as I *Think* there may be some knowledge here 
without me joining other lists...


I was aware of DANE's rfc6698 that holds both X.509 certs or 
SubjectPublicKeyInfo.


But I was pointed at rfc4398  Which does NOT handle 
SubjectPublicKeyInfo, but handles X.509 and other formats.


Interesting that they both end in '98' and this is way after Jon was 
around seeing to how RFC numbers were assigned  :)


What was the deciding point not to use 4398 for DANE?  (and now DANCE)

What is 4398 currently used for?  Why was it not just updated to add 
SubjectPublicKeyInfo rather than add a new RR?


And then there is rfc7250 which references 6698...

Thank you.


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

Re: [TLS] Why TLSA RR and not CERT RR?

[Robert Moskowitz]

Kind of thought so.

So where do I ask where CERT records are being used?

thanks

On 6/26/22 09:22, Eric Rescorla wrote:
Well, this really isn't a question for the TLS WG as DANE is external 
to TLS.


With that said, ISTM that the primary purpose of DANE is to indicate 
which certificates are acceptable rather than to convey them, as TLS 
already knows how to convey them.


-Ekr


On Sun, Jun 26, 2022 at 5:05 AM Robert Moskowitz 
 wrote:


Recently I have been in a discussion about DNS RR that hold X.509
certificates.

I am asking this here, as I *Think* there may be some knowledge here
without me joining other lists...

I was aware of DANE's rfc6698 that holds both X.509 certs or
SubjectPublicKeyInfo.

But I was pointed at rfc4398  Which does NOT handle
SubjectPublicKeyInfo, but handles X.509 and other formats.

Interesting that they both end in '98' and this is way after Jon was
around seeing to how RFC numbers were assigned  :)

What was the deciding point not to use 4398 for DANE?  (and now DANCE)

What is 4398 currently used for?  Why was it not just updated to add
SubjectPublicKeyInfo rather than add a new RR?

And then there is rfc7250 which references 6698...

Thank you.


___
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] Why TLSA RR and not CERT RR?

[Robert Moskowitz]

Ah, RFC 6944...

Yes, not a TLS issue; did not think it was, directly.  But I see.

DIG, dig, dig..

On 6/26/22 09:32, Robert Moskowitz wrote:

Kind of thought so.

So where do I ask where CERT records are being used?

thanks

On 6/26/22 09:22, Eric Rescorla wrote:
Well, this really isn't a question for the TLS WG as DANE is external 
to TLS.


With that said, ISTM that the primary purpose of DANE is to indicate 
which certificates are acceptable rather than to convey them, as TLS 
already knows how to convey them.


-Ekr


On Sun, Jun 26, 2022 at 5:05 AM Robert Moskowitz 
 wrote:


Recently I have been in a discussion about DNS RR that hold X.509
certificates.

I am asking this here, as I *Think* there may be some knowledge here
without me joining other lists...

I was aware of DANE's rfc6698 that holds both X.509 certs or
SubjectPublicKeyInfo.

But I was pointed at rfc4398  Which does NOT handle
SubjectPublicKeyInfo, but handles X.509 and other formats.

Interesting that they both end in '98' and this is way after Jon was
around seeing to how RFC numbers were assigned  :)

What was the deciding point not to use 4398 for DANE?  (and now
DANCE)

What is 4398 currently used for?  Why was it not just updated to add
SubjectPublicKeyInfo rather than add a new RR?

And then there is rfc7250 which references 6698...

Thank you.


___
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] Why TLSA RR and not CERT RR?

[Robert Moskowitz]

Thanks Eric!

I will use them in draft-ietf-drip-registries for our X.509 certs and 
our 'custom' attestation certs (private OID will be needed). And then 
the powers-that-be can sort it out as we move forward.


But at least this way I can put forth the discussion point and the 
implementors can proceed with their PoC.


And most likely take it to a DNS list.  And hall talk at 114!

Bob

On 6/26/22 16:14, Eric Rescorla wrote:

I'm not aware of any major application which uses CERT records.

-Ekr


On Sun, Jun 26, 2022 at 6:41 AM Robert Moskowitz 
 wrote:


Ah, RFC 6944...

Yes, not a TLS issue; did not think it was, directly.  But I see.

DIG, dig, dig..

On 6/26/22 09:32, Robert Moskowitz wrote:

Kind of thought so.

So where do I ask where CERT records are being used?

thanks

On 6/26/22 09:22, Eric Rescorla wrote:

Well, this really isn't a question for the TLS WG as DANE is
external to TLS.

With that said, ISTM that the primary purpose of DANE is to
indicate which certificates are acceptable rather than to convey
them, as TLS already knows how to convey them.

-Ekr


On Sun, Jun 26, 2022 at 5:05 AM Robert Moskowitz
 wrote:

Recently I have been in a discussion about DNS RR that hold
X.509
certificates.

I am asking this here, as I *Think* there may be some
knowledge here
without me joining other lists...

I was aware of DANE's rfc6698 that holds both X.509 certs or
SubjectPublicKeyInfo.

But I was pointed at rfc4398  Which does NOT handle
SubjectPublicKeyInfo, but handles X.509 and other formats.

Interesting that they both end in '98' and this is way after
Jon was
around seeing to how RFC numbers were assigned  :)

What was the deciding point not to use 4398 for DANE?  (and
now DANCE)

What is 4398 currently used for?  Why was it not just
updated to add
SubjectPublicKeyInfo rather than add a new RR?

And then there is rfc7250 which references 6698...

Thank you.


___
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] Why TLSA RR and not CERT RR?

[Robert Moskowitz]

Viktor,

thank you for your response.

For those uses that are DANE/DANCE/TLS related, TLSA records WILL be 
used.  See


draft-moskowitz-drip-secure-nrid-c2

Which I am working on an update to correct some errors and add MAVlink 
as a message format for NRID.


and these TLSA records will be installed? in DNS via
draft-ietf-drip-registries (still in need of serious work)

But in draft-ietf-drip-auth, we have attestations that are carried in 
very contrained messages, and there have been various opinions that 
these should also be in DNS.  So how?  CERT RR, it seems.  And again 
this will be done in drip-registries.


So there is a part of this which is TLS (and IPsec and HIP) and a part 
which is custom design work to fit into the mandated Unmanned Aircraft comm.


Fun to be had.

Bob


On 6/26/22 16:55, Viktor Dukhovni wrote:

On Sun, Jun 26, 2022 at 04:29:38PM -0400, Robert Moskowitz wrote:


I will use them in draft-ietf-drip-registries for our X.509 certs and
our 'custom' attestation certs (private OID will be needed). And then
the powers-that-be can sort it out as we move forward.

Why do the certificates need to be delivered via DNS?  Are TLS or DTLS
not suitable as protocols between the subject and relying party?

What is the management model for these certificates?  How will key
rollover at the subject be coördinated with changes in the DNS?

TLSA records are flexible in that they can specify trust-anchor keys or
certificates (typically their digests) as well as EE keys or
certificates.  Multiple TLSA records can be published at the same RRset,
and rollover is facilitated by requiring only one to match.

The need to tightly synchronise regular certificate rollovers with DNS
changes can be avoided by keeping EE keys stable, or publishing a stable
issuer trust-anchor key.  Alternatively, one can pre-publish future
EE public keys and then use that key in a later certificate rollover
if observed in DNS for a sufficient number of TTLs, or else renew the
certificate with the extant key.

So there are well-understood (if not yet universally practiced)
operational practices that enable robust deployments of DANE TLSA.

Is there something similar for the proposed use of CERT?  Is publication
of (often multi-kilobyte) full certificates in DNS a good idea?



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

Re: [TLS] Why TLSA RR and not CERT RR?

[Robert Moskowitz]

On 6/26/22 17:40, Jim Reid wrote:



On 26 Jun 2022, at 14:32, Robert Moskowitz  wrote:

So where do I ask where CERT records are being used?

Maybe in the dnsop WG. Or at the DNS-OARC meeting immediately after IETF114.


And I am splitting early Friday morning.


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

Re: [TLS] Why TLSA RR and not CERT RR?

[Robert Moskowitz]

Viktor,

One thing I left off is that it is possible that 
draft-moskowitz-drip-nrid-c2 will be a major use case for DANCE as I 
have discussed on the DANCE list.


The DRIP chairs want to wrap up current work before we tackle phase 2, 
but I have external players that want PoC for secure nrid NOW. So I keep 
working on all drafts in parallel.


Bob

On 6/26/22 16:55, Viktor Dukhovni wrote:

On Sun, Jun 26, 2022 at 04:29:38PM -0400, Robert Moskowitz wrote:


I will use them in draft-ietf-drip-registries for our X.509 certs and
our 'custom' attestation certs (private OID will be needed). And then
the powers-that-be can sort it out as we move forward.

Why do the certificates need to be delivered via DNS?  Are TLS or DTLS
not suitable as protocols between the subject and relying party?

What is the management model for these certificates?  How will key
rollover at the subject be coördinated with changes in the DNS?

TLSA records are flexible in that they can specify trust-anchor keys or
certificates (typically their digests) as well as EE keys or
certificates.  Multiple TLSA records can be published at the same RRset,
and rollover is facilitated by requiring only one to match.

The need to tightly synchronise regular certificate rollovers with DNS
changes can be avoided by keeping EE keys stable, or publishing a stable
issuer trust-anchor key.  Alternatively, one can pre-publish future
EE public keys and then use that key in a later certificate rollover
if observed in DNS for a sufficient number of TTLs, or else renew the
certificate with the extant key.

So there are well-understood (if not yet universally practiced)
operational practices that enable robust deployments of DANE TLSA.

Is there something similar for the proposed use of CERT?  Is publication
of (often multi-kilobyte) full certificates in DNS a good idea?



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

[TLS] TLS ECDSA nonce reuse attack?

[Robert Moskowitz]

I contact pointed me to the following:

https://medium.com/asecuritysite-when-bob-met-alice/the-state-of-tls-ecdsa-nonce-reuse-1489ab86e488

The article is unclear if this is a TLS 1.2 and/or 1.3 problem.  It does 
claim that 1.3 does not fix all problems with TLS.


It also seems this is a libraries implementation problem.  Lack of care 
in nonce selection.


So I do need to get back to the person that is wanting to know, and I 
have come up empty in any other information on this problem.


Thanks!

Bob

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

[TLS] Re: DTLS 1.3 bis

[Robert Moskowitz]

The ICAO Communication Panel has specified DTLS for air-to-ground 
security.  That won't change without a major lift effort, lots of years, 
and for many of them QUIC is too new and unproven.


:)

Actually there are good reasons for use of CoAP over-the-air.  Of course 
CoAP specifies DTLS...


FUN!

Fix DTLS.

On 11/12/24 17:52, Watson Ladd wrote:
I think anyone implementing would have discovered them.  The other 
question which I'll try not to ask too frequently is at what point do 
we just point users at QUIC?



On Tue, Nov 12, 2024 at 12:43 PM Russ Housley  
wrote:

>
> I agree that a bis is needed for DTLS 1.3, but I think that some of 
the things that David Benjiman talked about would have been 
discovered, especially the keyUpdate-related things, if there had been 
formal analysis of DTLS 1.3.  Please have the FATT take a look.

>
> Russ
>
>
> On Nov 12, 2024, at 3:29 PM, Joseph Salowey  wrote:
>
> At IETF 121, we discussed revised DTLS 1.3, aka a 
draft-ietf-tls-rfc9147bis. The chairs are proposing starting this I-D 
as a WG item with the existing RFC as a base. If you object to this 
please let the list know by 25 November 2024.

>
>
> Thanks,
>
> Deirdre, Joe, and Sean
>
>
> ___
> TLS mailing list -- tls@ietf.org
> To unsubscribe send an email to tls-le...@ietf.org
>
>
> ___
> TLS mailing list -- tls@ietf.org
> To unsubscribe send an email to tls-le...@ietf.org




___
TLS mailing list --tls@ietf.org
To unsubscribe send an email totls-le...@ietf.org
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org